[Bug target/89222] [7/8/9 regression] ARM thumb-2 misoptimisation of func ptr call with -O2 or -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222 --- Comment #6 from Jonathan Larmour --- Just to confirm with concrete values from a real program: myhandler2() is at 0x23a8 (which means the branch target address if the function is called should be 0x23a9 with LS bit set to indicate Thumb). The assembler inserts an R_ARM_ABS32 reloc for the symbol myhandler2 with addend of -1, and the linker sets the value at .L22 to 0x23a7, i.e. what is then loaded into r5 in the disassembly I provided. If I manually edit the asm to use "myhandler2" in place of "myhandler2-1" then the linker puts in 0x23a9 instead. If I use "myhandler2-2" in place of "myhandler2-1" then the linker puts in 0x23a7, same as the "myhandler2-1" case. So I infer that if the reloc is an offset of a *function* symbol, the behaviour of the linker is to compute the value and then always set the LS bit in the result. This matches the ABI at: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.swdev.abi/index.html specifically 4.6.1.1 (page 26) where the table indicates that R_ARM_ABS32 should be handled as "(S + A ) | T" where "T is 1 if the target symbol S has type STT_FUNC and the Symbol addresses a Thumb instruction; it is 0 otherwise." So it looks to me like the linker is right and GCC is mistaken. Wilco is exactly right that you shouldn't do arithmetic with function symbols, at least if there's any chance that the symbol is Thumb.
[Bug target/89261] New: ix86_data_alignment has wrong argument type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89261 Bug ID: 89261 Summary: ix86_data_alignment has wrong argument type Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: ubizjak at gmail dot com Target Milestone: --- Target: i386,x86-64 i386.c has int ix86_data_alignment (tree type, int align, bool opt) But "align" passed down is unsigned.
[Bug libstdc++/88066] [7/8 Regression] Relative includes in bits/locale_conv.h should be prefixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88066 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Sat Feb 9 00:40:31 2019 New Revision: 268714 URL: https://gcc.gnu.org/viewcvs?rev=268714&root=gcc&view=rev Log: PR libstdc++/88066 use <> for includes not "" Using #include "..." to include a header in the same directory fails if the user compiles with -I-, so always use something like for internal headers. I haven't added tests for this, because dg-options adds options to the end, and the position of -I- matters (if it's at the end then the tests won't find any headers in the build tree, as they're specified by -I options earlier in the flags). It's been manually tested though. PR libstdc++/88066 * include/bits/locale_conv.h: Use <> for includes not "". * include/ext/random: Likewise. * include/ext/vstring.h: Likewise. Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/include/bits/locale_conv.h branches/gcc-8-branch/libstdc++-v3/include/ext/random branches/gcc-8-branch/libstdc++-v3/include/ext/vstring.h
[Bug libstdc++/71044] Optimize std::filesystem implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71044 --- Comment #9 from Jonathan Wakely --- Author: redi Date: Sat Feb 9 00:25:39 2019 New Revision: 268713 URL: https://gcc.gnu.org/viewcvs?rev=268713&root=gcc&view=rev Log: Add noexcept to filesystem::path query functions In the standard these member functions are specified in terms of the potentially-throwing path decompositions functions, but we implement them without constructing any new paths or doing anything else that can throw. PR libstdc++/71044 * include/bits/fs_path.h (path::has_root_name) (path::has_root_directory, path::has_root_path) (path::has_relative_path, path::has_parent_path) (path::has_filename, path::has_stem, path::has_extension) (path::is_absolute, path::is_relative, path::_M_find_extension): Add noexcept. * src/c++17/fs_path.cc (path::has_root_name) (path::has_root_directory, path::has_root_path) (path::has_relative_path, path::has_parent_path) (path::has_filename, path::_M_find_extension): Add noexcept. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/fs_path.h trunk/libstdc++-v3/src/c++17/fs_path.cc
[Bug libstdc++/85494] implementation of random_device on mingw is useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85494 Jonathan Wakely changed: What|Removed |Added Target Milestone|9.0 |10.0
[Bug driver/69471] "-march=native" unintentionally breaks further -march/-mtune flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69471 H.J. Lu changed: What|Removed |Added CC||joseph at codesourcery dot com --- Comment #8 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00490.html
[Bug target/88343] [7/8 Regression] R31 is unconditionally saved/restored on powerpc-darwin even when it's not necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343
--- Comment #30 from Alan Modra ---
Author: amodra
Date: Fri Feb 8 22:20:58 2019
New Revision: 268708
URL: https://gcc.gnu.org/viewcvs?rev=268708&root=gcc&view=rev
Log:
[RS6000] Correct save_reg_p
Fixes lack of r30 save/restore on
// -m32 -fpic -ftls-model=initial-exec
__thread char* p;
char** f1 (void) { return &p; }
and
// -m32 -fpic -msecure-plt
extern int foo (int);
int f1 (int x) { return foo (x); }
These are both caused by save_reg_p returning false when the pic
offset table reg (r30 for ABI_V4) was used, due to the logic not
exactly matching that in rs6000_emit_prologue to set up r30.
I also noticed that save_reg_p isn't following the comment regarding
calls_eh_return (since svn 267049, git 0edf78b1b2a0), and the comment
needs tweaking too. For why the revised comment is correct, grep for
saves_all_registers in lra.c, and yes, we do want to save the pic
offset table reg for eh_return.
PR target/88343
* config/rs6000/rs6000.c (save_reg_p): Correct calls_eh_return
case. Match logic in rs6000_emit_prologue emitting pic_offset_table
setup.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
[Bug c++/89214] [7/8/9 Regression] ICE in digest_init_r, at cp/typeck2.c:1211 with -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89214
--- Comment #5 from Marek Polacek ---
But we actually called reshape_init:
7146 expr = reshape_init (totype, expr, complain);
7147 expr = get_target_expr_sfinae (digest_init (totype, expr,
complain),
7148 complain);
expr was {{TARGET_EXPR<...>}}, after the reshape_init {TARGET_EXPR<...>}, but
that still crashes.
[Bug other/89259] liboffloadmic/runtime/offload_omp_host.cpp:692: pointless test ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89259
David Binderman changed:
What|Removed |Added
CC||iverbin at gcc dot gnu.org
--- Comment #1 from David Binderman ---
svn blame says
238603iverbin // An incorrect size is treated as failure
238603iverbin if (size < 0) {
238603iverbin return 1;
238603iverbin }
[Bug rtl-optimization/87761] [9 regression][MIPS] New FAIL: gcc.target/mips/fix-r4000-10.c -O1 start with r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87761 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Can you please recheck with current trunk, many RA improvements related to r265398 change went into trunk since then.
[Bug middle-end/88560] [9 Regression] armv8_2-fp16-move-1.c and related regressions after r266385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #14 from Jakub Jelinek --- Hopefully fixed.
[Bug inline-asm/87984] [7/8/9 Regression] wrong code for local reg var input to asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #27 from rguenther at suse dot de ---
On February 8, 2019 6:35:29 PM GMT+01:00, "jakub at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
>
>--- Comment #24 from Jakub Jelinek ---
>FRE doesn't, as that breaks the #c9 testcase.
> a = 1;
> __asm__("add %1, %0" : "=r" o_12 : "r" a, "0" 0);
> __asm__ __volatile__("xor %%eax, %%eax" : : : "eax");
> i_13 = 1;
> a = 1;
> __asm__("add %1, %0" : "=r" o_18 : "r" a, "0" o_12);
> __asm__ __volatile__("xor %%eax, %%eax" : : : "eax");
> i_19 = 2;
> a = 1;
> __asm__("add %1, %0" : "=r" o_24 : "r" a, "0" o_18);
> __asm__ __volatile__("xor %%eax, %%eax" : : : "eax");
> i_25 = 3;
>to:
> a = 1;
> __asm__("add %1, %0" : "=r" o_12 : "r" a, "0" 0);
> __asm__ __volatile__("xor %%eax, %%eax" : : : "eax");
> __asm__("add %1, %0" : "=r" o_18 : "r" a, "0" o_12);
> __asm__ __volatile__("xor %%eax, %%eax" : : : "eax");
> __asm__("add %1, %0" : "=r" o_24 : "r" a, "0" o_18);
> __asm__ __volatile__("xor %%eax, %%eax" : : : "eax");
>If SCCVN would never record values for DECL_HARD_REGISTER vars or
>something
>similar, it wouldn't do this.
OK. I guess I misremember and it hurt never elides sets of reg vars.
Richard.
[Bug tree-optimization/88739] [7/8 Regression] Big-endian union bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739 --- Comment #56 from Jakub Jelinek --- Author: jakub Date: Fri Feb 8 19:01:37 2019 New Revision: 268706 URL: https://gcc.gnu.org/viewcvs?rev=268706&root=gcc&view=rev Log: PR tree-optimization/88739 * gcc.c-torture/execute/pr88739.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr88739.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug middle-end/88560] [9 Regression] armv8_2-fp16-move-1.c and related regressions after r266385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560 --- Comment #13 from Vladimir Makarov --- Author: vmakarov Date: Fri Feb 8 19:01:10 2019 New Revision: 268705 URL: https://gcc.gnu.org/viewcvs?rev=268705&root=gcc&view=rev Log: 2019-02-08 Vladimir Makarov PR middle-end/88560 * lra-constraints.c (process_alt_operands): Don't increase reject for memory when offset memory is required. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #31 from Eric Botcazou --- > I think it is important to find out why there are those differences in line > numbers. Is libbacktrace broken on Solaris, or not used at all, something > different? The libsanitizer does its private unwinding by means of _Unwind_Backtrace, which works fine. But, at the end, it overwrites the first address with the result of __builtin_return_address, which returns the address of the call instruction and not the return address on the SPARC (maybe you know why, Jakub?) so the first frame is off by 8 bytes. I have a tentative fixlet for the libsanitizer. Btw, Rainer, why did you disable fast unwinding on the SPARC? This puts the SPARC port in its own basket (admittedly with MIPS) so that's not very convenient.
[Bug inline-asm/87984] [7/8/9 Regression] wrong code for local reg var input to asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984 --- Comment #26 from Jakub Jelinek --- (In reply to Alexander Monakov from comment #25) > (In reply to Jakub Jelinek from comment #22) > > A function call must be assumed to clobber any call used registers of > > course. > > But calls already do have vops (well, const/pure don't, and I don't think we > > want to change that). > > Yes, and also plain arithmetic that becomes a libcall doesn't have vops. That is something GIMPLE can't figure out though.
[Bug inline-asm/87984] [7/8/9 Regression] wrong code for local reg var input to asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984 --- Comment #25 from Alexander Monakov --- (In reply to Jakub Jelinek from comment #22) > A function call must be assumed to clobber any call used registers of course. > But calls already do have vops (well, const/pure don't, and I don't think we > want to change that). Yes, and also plain arithmetic that becomes a libcall doesn't have vops.
[Bug lto/89260] ICE in read_cgraph_and_symbols, at lto/lto.c:2800 while compiling harfbuzz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89260 --- Comment #1 from ohaiziejohwahkeezuoz at xff dot cz --- ./aarch64-linux-musl-gcc -v Using built-in specs. COLLECT_GCC=./aarch64-linux-musl-gcc COLLECT_LTO_WRAPPER=/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/libexec/gcc/aarch64-linux-musl/8.2.1/lto-wrapper Target: aarch64-linux-musl Configured with: /workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/configure --target=aarch64-linux-musl --prefix=/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl --libdir=/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib --enable-languages=c,c++ --disable-werror --disable-nls --disable-multilib --disable-shared --enable-tls --enable-threads=posix --disable-libmudflap --disable-libsanitizer --disable-gnu-indirect-function --disable-libmpx --enable-deterministic-archives --enable-libstdcxx-time --enable-fully-dynamic-string --enable-cloog-backend=isl --enable-lto --enable-libgomp --enable-checking=release Thread model: posix gcc version 8.2.1 20190208 (GCC) Harfbuzz CFLAGS/LDFLAGS: -g0 -Os -fomit-frame-pointer -flto
[Bug c/89256] No optimized division by constant for __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89256 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #1 from Alexander Monakov --- It's not so easy, as this trick needs a widening multiply or a high-multiply operation: e.g. in func64, the compiler uses upper 64 bits of the 128-bit product of two 64-bit operands. In func128, it would need to obtain 128 upper bits of a 256-bit product, which no CPU offers as part of instruction set; so it would need to be a libcall for a TImode high-multiply operation.
[Bug inline-asm/87984] [7/8/9 Regression] wrong code for local reg var input to asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #24 from Jakub Jelinek ---
FRE doesn't, as that breaks the #c9 testcase.
a = 1;
__asm__("add %1, %0" : "=r" o_12 : "r" a, "0" 0);
__asm__ __volatile__("xor %%eax, %%eax" : : : "eax");
i_13 = 1;
a = 1;
__asm__("add %1, %0" : "=r" o_18 : "r" a, "0" o_12);
__asm__ __volatile__("xor %%eax, %%eax" : : : "eax");
i_19 = 2;
a = 1;
__asm__("add %1, %0" : "=r" o_24 : "r" a, "0" o_18);
__asm__ __volatile__("xor %%eax, %%eax" : : : "eax");
i_25 = 3;
to:
a = 1;
__asm__("add %1, %0" : "=r" o_12 : "r" a, "0" 0);
__asm__ __volatile__("xor %%eax, %%eax" : : : "eax");
__asm__("add %1, %0" : "=r" o_18 : "r" a, "0" o_12);
__asm__ __volatile__("xor %%eax, %%eax" : : : "eax");
__asm__("add %1, %0" : "=r" o_24 : "r" a, "0" o_18);
__asm__ __volatile__("xor %%eax, %%eax" : : : "eax");
If SCCVN would never record values for DECL_HARD_REGISTER vars or something
similar, it wouldn't do this.
[Bug inline-asm/87984] [7/8/9 Regression] wrong code for local reg var input to asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984 --- Comment #23 from rguenther at suse dot de --- On February 8, 2019 6:25:09 PM GMT+01:00, "jakub at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984 > >--- Comment #22 from Jakub Jelinek --- >(In reply to Alexander Monakov from comment #21) >> (In reply to Jakub Jelinek from comment #18) >> > We could cache a bool in struct function whether the function has >any local >> > hard register vars and just propagate that info during inlining >etc. and >> > just add virtual operand if there are any clobbers and any local >register >> > vars (or with that condition check them). >> >> This seems to dismiss comment #17. The clobber may be invisible on >GIMPLE >> due to function calls or just plain arithmetic that is turned to >libcalls. > >A function call must be assumed to clobber any call used registers of >course. >But calls already do have vops (well, const/pure don't, and I don't >think we >want to change that). >Another possibility is to just punt on trying to optimize hard register >vars in >gimple optimizers, leave that to RTL only. So, punt on them in SCCVN, >PRE, >FRE, etc. But we do that already...
[Bug c++/88761] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15478 when chaining lambda calls & fold-expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88761 Jakub Jelinek changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #7 from Jakub Jelinek --- *** Bug 88995 has been marked as a duplicate of this bug. ***
[Bug c++/88995] [8/9 Regression] internal compiler error: in lookup_template_class_1, at cp/pt.c:9471
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88995 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Jakub Jelinek --- Thanks, indeed, it was, just verified on 8.x branch #c1, #c3, #c4, #c5 testcase before (ICE) and after. Do we want the #c3 into the testsuite too, or is it sufficiently similar to lambda-generic-const6.C that it isn't worth it? *** This bug has been marked as a duplicate of bug 88761 ***
[Bug c++/89212] [8/9 Regression] ICE in fold_convert_loc at fold-const.c:2552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89212 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #6 from Marek Polacek --- https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00475.html
[Bug inline-asm/87984] [7/8/9 Regression] wrong code for local reg var input to asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984 --- Comment #22 from Jakub Jelinek --- (In reply to Alexander Monakov from comment #21) > (In reply to Jakub Jelinek from comment #18) > > We could cache a bool in struct function whether the function has any local > > hard register vars and just propagate that info during inlining etc. and > > just add virtual operand if there are any clobbers and any local register > > vars (or with that condition check them). > > This seems to dismiss comment #17. The clobber may be invisible on GIMPLE > due to function calls or just plain arithmetic that is turned to libcalls. A function call must be assumed to clobber any call used registers of course. But calls already do have vops (well, const/pure don't, and I don't think we want to change that). Another possibility is to just punt on trying to optimize hard register vars in gimple optimizers, leave that to RTL only. So, punt on them in SCCVN, PRE, FRE, etc.
[Bug lto/89260] New: ICE in read_cgraph_and_symbols, at lto/lto.c:2800 while compiling harfbuzz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89260 Bug ID: 89260 Summary: ICE in read_cgraph_and_symbols, at lto/lto.c:2800 while compiling harfbuzz Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: ohaiziejohwahkeezuoz at xff dot cz CC: marxin at gcc dot gnu.org Target Milestone: --- Target: aarch64-linux-musl Build: x86_64-linux-unknown Hello, I get ICE with gcc 8.2.1 (trunk) rev268702. gcc was built with: configure \ --target=$TARGET \ --prefix="$PREFIX" \ --libdir="$PREFIX/lib" \ --enable-languages=$langs \ --disable-werror \ --disable-nls \ --disable-multilib \ --disable-shared \ --enable-tls \ --enable-threads=posix \ --disable-libmudflap \ --disable-libsanitizer \ --disable-gnu-indirect-function \ --disable-libmpx \ --enable-deterministic-archives \ --enable-libstdcxx-time \ --enable-fully-dynamic-string \ --enable-cloog-backend=isl \ --enable-lto \ --enable-libgomp \ --enable-checking=release \ I'm trying to build the upstream harfbuzz 2.3.1 package. https://www.freedesktop.org/software/harfbuzz/release/ Sorry for not providing preprocessed file, but I'm not sure what to priovide, given that lto build step fails. Hopefully it will be easily reproducible. Let me know if I can provide more information. /bin/sh ../libtool --tag=CXX --mode=link aarch64-linux-musl-g++ -fno-rtti -g0 -Os -fomit-frame-pointer -flto -save-temps -fno-exceptions -fno-threadsafe-statics -fvisibility-inlines-hidden -L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib -g0 -Os -fomit-frame-pointer -flto -save-temps -static -all-static -o hb-ot-shape-closure hb-ot-shape-closure.o options.o ../src/libharfbuzz.la -lm -L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib -lglib-2.0 -pthread -L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib/../lib64 -lffi -L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib -lfreetype -L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib -L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib -lz -lpng16 -lz libtool: link: aarch64-linux-musl-g++ -fno-rtti -g0 -Os -fomit-frame-pointer -flto -save-temps -fno-exceptions -fno-threadsafe-statics -fvisibility-inlines-hidden -g0 -Os -fomit-frame-pointer -flto -save-temps -static -o hb-subset hb-subset.o options.o -pthread -L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib ../src/.libs/libharfbuzz.a -L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib/../lib64 -lm ../src/.libs/libharfbuzz-subset.a /workspace/megous.com/apps-c/static-deps/output/arm64-lto/builds/harfbuzz/src/harfbuzz-2.3.1/src/.libs/libharfbuzz.a -lglib-2.0 -lffi -lfreetype -lpng16 -lz -pthread libtool: link: aarch64-linux-musl-g++ -fno-rtti -g0 -Os -fomit-frame-pointer -flto -save-temps -fno-exceptions -fno-threadsafe-statics -fvisibility-inlines-hidden -g0 -Os -fomit-frame-pointer -flto -save-temps -static -o hb-shape hb-shape.o options.o -pthread -L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib ../src/.libs/libharfbuzz.a -L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib/../lib64 -lm -lglib-2.0 -lffi -lfreetype -lpng16 -lz -pthread libtool: link: aarch64-linux-musl-g++ -fno-rtti -g0 -Os -fomit-frame-pointer -flto -save-temps -fno-exceptions -fno-threadsafe-statics -fvisibility-inlines-hidden -g0 -Os -fomit-frame-pointer -flto -save-temps -static -o hb-view hb-view.o options.o ansi-print.o helper-cairo.o helper-cairo-ansi.o view-cairo.o -pthread -pthread -pthread -pthread -pthread -L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib ../src/.libs/libharfbuzz.a -L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib/../lib64 -lcairo -lgobject-2.0 -lglib-2.0 -lffi -lpixman-1 -lfontconfig -luuid -lxml2 -lm -lfreetype -lpng16 -lz -pthread libtool: link: aarch64-linux-musl-g++ -fno-rtti -g0 -Os -fomit-frame-pointer -flto -save-temps -fno-exceptions -fno-threadsafe-statics -fvisibility-inlines-hidden -g0 -Os -fomit-frame-pointer -flto -save-temps -static -o hb-ot-shape-closure hb-ot-shape-closure.o options.o -pthread -L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib ../src/.libs/libharfbuzz.a -L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib/../lib64 -lm -lglib-2.0 -lffi -lfreetype -lpng16 -lz -pthread lto1: internal co
[Bug inline-asm/87984] [7/8/9 Regression] wrong code for local reg var input to asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984 --- Comment #21 from Alexander Monakov --- (In reply to Jakub Jelinek from comment #18) > We could cache a bool in struct function whether the function has any local > hard register vars and just propagate that info during inlining etc. and > just add virtual operand if there are any clobbers and any local register > vars (or with that condition check them). This seems to dismiss comment #17. The clobber may be invisible on GIMPLE due to function calls or just plain arithmetic that is turned to libcalls.
[Bug target/89222] [7.x regression] ARM thumb-2 misoptimisation of func ptr call with -O2 or -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222 Wilco changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-02-08 Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/88995] [8/9 Regression] internal compiler error: in lookup_template_class_1, at cp/pt.c:9471
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88995 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #6 from Jason Merrill --- I think this was fixed by my patch for PR 88761.
[Bug libstdc++/89090] vector.tcc uses "if constexpr" in C++11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89090 --- Comment #8 from Jonathan Wakely --- That doesn't work. I don't get to control every G++ users' build system.
[Bug other/89259] New: liboffloadmic/runtime/offload_omp_host.cpp:692: pointless test ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89259
Bug ID: 89259
Summary: liboffloadmic/runtime/offload_omp_host.cpp:692:
pointless test ?
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
liboffloadmic/runtime/offload_omp_host.cpp:692]: (style) Checking if unsigned
expression 'size' is less than zero.
Source code is
// An incorrect size is treated as failure
if (size < 0) {
return 1;
}
but
size_t size,
[Bug testsuite/89258] [9 Regression] verify_gimple failed in gimple test pr80887 for 16-bit target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89258 Jozef Lawrynowicz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jozef Lawrynowicz --- (In reply to Jakub Jelinek from comment #1) > So you just want to guard this test with int32plus. Thanks, applied. Closing this PR.
[Bug testsuite/89258] [9 Regression] verify_gimple failed in gimple test pr80887 for 16-bit target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89258 --- Comment #2 from jozefl at gcc dot gnu.org --- Author: jozefl Date: Fri Feb 8 16:47:28 2019 New Revision: 268704 URL: https://gcc.gnu.org/viewcvs?rev=268704&root=gcc&view=rev Log: 2019-02-08 Jozef Lawrynowicz PR testsuite/89258 * gcc.dg/tree-ssa/pr80887.c: Require int32plus. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/pr80887.c
[Bug testsuite/89258] [9 Regression] verify_gimple failed in gimple test pr80887 for 16-bit target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89258 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- So you just want to guard this test with int32plus.
[Bug libstdc++/89090] vector.tcc uses "if constexpr" in C++11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89090 --- Comment #7 from Csaba Ráduly --- Don't be sad, use -std=c++17 :)
[Bug c++/89151] SFINAE-disabled member hides another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89151 --- Comment #4 from Csaba Ráduly --- As I said, GCC trunk (9) can compile this example. Did you check with the released 8.2.0 ?
[Bug testsuite/89258] New: [9 Regression] verify_gimple failed in gimple test pr80887 for 16-bit target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89258 Bug ID: 89258 Summary: [9 Regression] verify_gimple failed in gimple test pr80887 for 16-bit target Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: jozef.l at mittosystems dot com Target Milestone: --- Created attachment 45649 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45649&action=edit pr80887.c gcc.dg/tree-ssa/pr80887.c ICEs for msp430-elf on trunk. xgcc gcc/gcc/testsuite/gcc.dg/tree-ssa/pr80887.c -fgimple -msim -S gcc/gcc/testsuite/gcc.dg/tree-ssa/pr80887.c: In function 'f': gcc/gcc/testsuite/gcc.dg/tree-ssa/pr80887.c:6:1: error: type mismatch in binary expression 6 | f() | ^ unsigned int unsigned int long unsigned int u_9 = _4 + 4294967295; gcc/gcc/testsuite/gcc.dg/tree-ssa/pr80887.c:6:1: error: type mismatch in binary expression unsigned int unsigned int long unsigned int t2_12 = _6 + 4294967294; during GIMPLE pass: omplower gcc/gcc/testsuite/gcc.dg/tree-ssa/pr80887.c:6:1: internal compiler error: verify_gimple failed 0xbd430d verify_gimple_in_seq(gimple*) ../../gcc/tree-cfg.c:5094 0xacfd0a execute_function_todo ../../gcc/passes.c:1979 0xad0c02 execute_todo ../../gcc/passes.c:2031 --- The test passes on gcc-8-branch (less strict gimple checking in GCC8?). int size is 16-bits for msp430, the constants use in this test assume at least 32-bit int.
[Bug inline-asm/87984] [7/8/9 Regression] wrong code for local reg var input to asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984 --- Comment #20 from Segher Boessenkool --- (In reply to Richard Biener from comment #19) > Not sure if it > is generally advised/done to use scratch registers by simply clobbering > them. It is often done. Advised... I cannot think of a good reason to do this ever though. Segher
[Bug fortran/89240] Discrepancy in the return kind of MAX and MIN between all literal input parameters and input parameters that are variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89240 MarkEggleston changed: What|Removed |Added Attachment #45645|0 |1 is obsolete|| --- Comment #5 from MarkEggleston --- Created attachment 45648 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45648&action=edit Fix return kind for max and min Also includes changes to intrinsic documentation. Attachment redone as I forgot to tick the patch box.
[Bug fortran/89240] Discrepancy in the return kind of MAX and MIN between all literal input parameters and input parameters that are variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89240 --- Comment #3 from MarkEggleston --- Created attachment 45646 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45646&action=edit Change log for gcc/fortran for patch
[Bug fortran/89240] Discrepancy in the return kind of MAX and MIN between all literal input parameters and input parameters that are variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89240 --- Comment #4 from MarkEggleston --- Created attachment 45647 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45647&action=edit Change Log for testsuite for patch
[Bug fortran/89240] Discrepancy in the return kind of MAX and MIN between all literal input parameters and input parameters that are variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89240 --- Comment #2 from MarkEggleston --- Created attachment 45645 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45645&action=edit Fix return kind for max and min Also includes update to the intrinsic documentation.
[Bug tree-optimization/87665] [7 Regression] gcc HEAD (svn: 265340) breaks elements on resize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87665 Jakub Jelinek changed: What|Removed |Added CC||matt at ookypooky dot com --- Comment #23 from Jakub Jelinek --- *** Bug 89257 has been marked as a duplicate of this bug. ***
[Bug c++/89257] Bad optimisation at -O3 with vector of pairs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89257 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Jakub Jelinek --- Dup. *** This bug has been marked as a duplicate of bug 87665 ***
[Bug target/89222] [7.x regression] ARM thumb-2 misoptimisation of func ptr call with -O2 or -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222 Wilco changed: What|Removed |Added CC||wilco at gcc dot gnu.org --- Comment #5 from Wilco --- (In reply to Andrew Pinski from comment #4) > I think the bug is in the assembler or the linker: > .L22: > .word myhandler2-1 > > > > Basically what is happening is: > (__handler != ((__sighandler_t) 2)) && (__handler != ((__sighandler_t) > SIG_DFL)) > > is converted to: > > (((size_t)__handler)-1) <= 1 > > And then GCC emits myhandler2-1 in the constant pool which is correct but > the assembler/linker decides to put 0x23a7 in that location (See the > .L22 above) and then GCC adds +1 to it to try to make it myhandler2 (again). > > This is why using SIG_DFL of 5 works, it is just by accident because GCC > decides not to do the transformation or put myhandler2-1 in the constant > pool. > > Again I think this is an assembler/linker issue of putting the wrong value > for > > .L22: > .word myhandler2-1 The +1 is added by the assembler since it is a Thumb function. Then the compiler adds another +1, making it +2. Basically one shouldn't do arithmetic with function symbols since bit 0 encodes the Arm/Thumb state.
[Bug c++/89257] Bad optimisation at -O3 with vector of pairs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89257 --- Comment #1 from Matt A --- Apologies, I should have clarified this is on x86_64: $ g++ -v Using built-in specs. COLLECT_GCC=/software/thirdparty/gcc/7.2.0-0.el7_64/bin/g++ COLLECT_LTO_WRAPPER=/software/thirdparty/gcc/7.2.0-0.el7_64/libexec/gcc/x86_64-unknown-linux-gnu/7.2.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/software/thirdparty/gcc/7.2.0-0.el7_64 --with-system-zlib --enable-shared --enable-threads=posix --enable-laguages=all --with-ppl --with-cloog --build=x86_64-unknown-linux-gnu Thread model: posix gcc version 7.2.0 (GCC)
[Bug c++/89257] New: Bad optimisation at -O3 with vector of pairs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89257
Bug ID: 89257
Summary: Bad optimisation at -O3 with vector of pairs
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at ookypooky dot com
Target Milestone: ---
Code as follows:
--
#include
#include
struct Foo
{
Foo () = default;
Foo (Foo &&f)
: x (f.x)
, y (f.y)
{
f.y = 0;
}
int x = 123;
int y = 456;
};
int main ()
{
std::vector> v;
for (size_t i = 0; i < 10; ++i)
{
v.emplace_back ();
}
for (const auto &p : v)
{
printf ("%d\n", p.first.y);
}
}
--
When compiled with:
g++ -std=c++17 -O3 anyway.cpp
Prints:
--
0
0
0
0
0
0
0
0
456
456
--
I expect every line to print 456.
Works correctly at -O2, and at -std=c++14, and works with std::tuple in place
of std::pair. Also works on gcc-6.3.0.
I'm afraid I don't have newer compiler versions to test against (and Compiler
Explorer output is hard to interpret without getting rid of std::vector).
[Bug middle-end/89246] LTO produces references to cloned symbols which the compiler failed to clone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89246 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 45644 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45644&action=edit gcc9-pr89246.patch Untested fix.
[Bug target/89251] [2018-q4m] Wrong datatype optimization on bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89251
--- Comment #5 from Kochise ---
"The pointer I access is volatile, not the uint32_t behind"
Understand this :
((volatile MyRegDef*) ADDR)->enable; <- TYPO in the original message I couldn't
edit
Not this :
typedef union MyRegDef
{ struct
{ volatile uint32_t enable:1; <- this is stupid and should be
killed with fire
}
volatile uint32_t raw;
};
This should be avoided :
typedef union MyRegDef
{ struct
{ uint32_t enable:1;
uint32_t _1:31; <- forcing this or using volatile should even be
considered
}
uint32_traw;
};
Please understand that the same structure could/should be used to access either
memory or registers. Imagine if network ip header structures were "optimized",
that would be such a mess.
I'm not even talking about ((packed)) attributes, that's another story, but
since those bitfield should be treated fairly regardless of their location, the
compiler shouldn't "optimize" them.
And no, definitively no, "compiler flags" shouldn't have to flower to thwart
those "optimizations", see how much GCC already pushed the envelope :
https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html
If every time you get to disagree with the "standard" you create a new "gcc
extension" or new "compiler flags", then we're parting from the "standard" and
thus this shouldn't be named C anymore.
That the "standard" never really ruled about bitfield order is already baffling
and common sense (ie. current implementation) telling to start from bit 0 and
upward is a good thing.
But this bitfield datatype size "optimization" or this 'volatile' "trick" is
just mind blowing. I see nothing "elegant" to circumvent the problem. Perhaps
if I wanted the datatype to adapt, I would have used 'auto' instead of
'uint32_t'.
[Bug c++/88752] [8 Regression] ICE in enclosing_instantiation_of, at cp/pt.c:13328
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88752 --- Comment #8 from Marek Polacek --- Note this fix caused 89241, so it probably crashes with gcc-8 too.
[Bug middle-end/89246] LTO produces references to cloned symbols which the compiler failed to clone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89246 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-08 Component|ipa |middle-end Ever confirmed|0 |1
[Bug c++/88752] [8 Regression] ICE in enclosing_instantiation_of, at cp/pt.c:13328
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88752 --- Comment #7 from Jason Merrill --- Author: jason Date: Fri Feb 8 14:49:58 2019 New Revision: 268701 URL: https://gcc.gnu.org/viewcvs?rev=268701&root=gcc&view=rev Log: PR c++/88752 - ICE with lambda and constexpr if. * cp-tree.h (LAMBDA_EXPR_INSTANTIATED): New. * pt.c (tsubst_lambda_expr): Set it. (instantiated_lambda_fn_p): Check it. (enclosing_instantiation_of): Use it. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1z/constexpr-if26.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/cp-tree.h branches/gcc-8-branch/gcc/cp/pt.c
[Bug c++/88761] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15478 when chaining lambda calls & fold-expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88761 --- Comment #6 from Jason Merrill --- Author: jason Date: Fri Feb 8 14:50:03 2019 New Revision: 268702 URL: https://gcc.gnu.org/viewcvs?rev=268702&root=gcc&view=rev Log: PR c++/88761 - ICE with reference capture of constant. Here, we capture nf, then the use of the proxy decays to a constant during semantic processing of +nf. Since we saw some decay from proxy to constant, we walk through the lambda body to see which proxies are still used, but we weren't walking into subtrees of DECL_EXPR at all, so we missed the use of &nf in the initializer of y, and removed the capture. But then at instantiation time we try to use nf, don't have a proxy anymore, and ICE. * lambda.c (mark_const_cap_r): Do walk subtrees of DECL_EXPR for non-proxy decls. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1y/lambda-generic-const6.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/lambda.c
[Bug c++/86943] [7/8 Regression] Wrong code when converting stateless generic lambda to function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86943 --- Comment #14 from Jason Merrill --- Author: jason Date: Fri Feb 8 14:49:43 2019 New Revision: 268700 URL: https://gcc.gnu.org/viewcvs?rev=268700&root=gcc&view=rev Log: PR c++/86943 - wrong code converting generic lambda to pointer. * pt.c (tsubst_copy_and_build): Don't propagate CALL_FROM_THUNK_P. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-conv13.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/pt.c
[Bug c/89256] New: No optimized division by constant for __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89256
Bug ID: 89256
Summary: No optimized division by constant for __int128
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
Division by constant is not optimized for __int128 dividend.
// This function will use shift+multiply
int64_t func64( int64_t val )
{
return val / 1000;
}
// This function will call __divti3
__int128 func128( __int128 val )
{
return val / 1000;
}
It would be nice if GCC would use the same optimisation for __int128 and
unsigned __int128.
[Bug middle-end/89252] Vector load/store aren't used to initialize large memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89252
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #3 from Richard Biener ---
We're expanding from
foo (struct S * x)
{
[local count: 1073741824]:
*x_2(D) = array[0];
MEM[(struct S *)x_2(D) + 320B] = array[1];
not sure why we end up constant-folding the loads given 'array' cannot be
elided.
[Bug tree-optimization/86991] [8 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6919
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86991 --- Comment #8 from Richard Biener --- Author: rguenth Date: Fri Feb 8 14:38:31 2019 New Revision: 268699 URL: https://gcc.gnu.org/viewcvs?rev=268699&root=gcc&view=rev Log: 2019-02-08 Richard Biener Backport from mainline 2018-11-13 Richard Biener PR tree-optimization/86991 * tree-vect-loop.c (vect_is_slp_reduction): Delay reduction group building until we have successfully detected the SLP reduction. (vect_is_simple_reduction): Remove fixup code here. * gcc.dg/pr86991.c: New testcase. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr86991.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-vect-loop.c
[Bug tree-optimization/86991] [8 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6919
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86991 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||8.2.1 Resolution|--- |FIXED Known to fail|8.2.1 |8.2.0 --- Comment #7 from Richard Biener --- Fixed.
[Bug lto/88112] [9 regression] ICE in lto1: TYPE_FIELDS defined in incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88112 --- Comment #15 from Richard Biener --- Author: rguenth Date: Fri Feb 8 14:34:49 2019 New Revision: 268698 URL: https://gcc.gnu.org/viewcvs?rev=268698&root=gcc&view=rev Log: 2019-02-08 Richard Biener Backport from mainline 2019-02-03 Richard Biener PR debug/87295 * dwarf2out.c (copy_ancestor_tree): Register non-stubs as orig. * g++.dg/debug/dwarf2/pr87295.C: New testcase. 2019-01-29 Richard Biener PR debug/87295 * dwarf2out.c (collect_skeleton_dies): New helper. (copy_decls_for_unworthy_types): Call it. (build_abbrev_table): Do not try to replace DW_AT_signature refs with local refs. * g++.dg/lto/pr87295_0.C: New testcase. 2019-01-17 Richard Biener PR lto/86736 * dwarf2out.c (want_pubnames): Never generate pubnames sections and friends for the LTO part of debug info. 2019-01-24 Richard Biener PR lto/87187 * tree-streamer-out.c (write_ts_decl_common_tree_pointers): When in "legacy" debug mode make sure to reset self-origins. 2019-01-15 Richard Biener PR debug/88046 * dwarf2out.c (gen_member_die): Do not generate inheritance DIEs late. * g++.dg/lto/pr88046_0.C: New testcase. 2018-11-22 Richard Biener PR lto/87229 PR lto/88112 * lto-streamer-out.c (lto_is_streamable): Allow CALL_EXPRs which can appear in size expressions. * tree-streamer-in.c (unpack_ts_base_value_fields): Stream CALL_EXPR_BY_DESCRIPTOR. (streamer_read_tree_bitfields): Stream CALL_EXPR_IFN. * tree-streamer-out.c (pack_ts_base_value_fields): Stream CALL_EXPR_BY_DESCRIPTOR. (streamer_write_tree_bitfields): Stream CALL_EXPR_IFN. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/debug/dwarf2/pr87295.C branches/gcc-8-branch/gcc/testsuite/g++.dg/lto/pr87295_0.C branches/gcc-8-branch/gcc/testsuite/g++.dg/lto/pr88046_0.C Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/dwarf2out.c branches/gcc-8-branch/gcc/lto-streamer-out.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-streamer-in.c branches/gcc-8-branch/gcc/tree-streamer-out.c
[Bug debug/87295] [8 Regression][early debug] ICE with -ffat-lto-objects -fdebug-types-section -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87295 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||8.2.1 Resolution|--- |FIXED Known to fail|8.2.1 |8.2.0 --- Comment #18 from Richard Biener --- Fixed.
[Bug lto/86736] [9 regression] g++.dg/asan/pr81021.C -O2 -flto -flto-partition=none ICE at dwarf2out.c:31111
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86736 --- Comment #16 from Richard Biener --- Author: rguenth Date: Fri Feb 8 14:34:49 2019 New Revision: 268698 URL: https://gcc.gnu.org/viewcvs?rev=268698&root=gcc&view=rev Log: 2019-02-08 Richard Biener Backport from mainline 2019-02-03 Richard Biener PR debug/87295 * dwarf2out.c (copy_ancestor_tree): Register non-stubs as orig. * g++.dg/debug/dwarf2/pr87295.C: New testcase. 2019-01-29 Richard Biener PR debug/87295 * dwarf2out.c (collect_skeleton_dies): New helper. (copy_decls_for_unworthy_types): Call it. (build_abbrev_table): Do not try to replace DW_AT_signature refs with local refs. * g++.dg/lto/pr87295_0.C: New testcase. 2019-01-17 Richard Biener PR lto/86736 * dwarf2out.c (want_pubnames): Never generate pubnames sections and friends for the LTO part of debug info. 2019-01-24 Richard Biener PR lto/87187 * tree-streamer-out.c (write_ts_decl_common_tree_pointers): When in "legacy" debug mode make sure to reset self-origins. 2019-01-15 Richard Biener PR debug/88046 * dwarf2out.c (gen_member_die): Do not generate inheritance DIEs late. * g++.dg/lto/pr88046_0.C: New testcase. 2018-11-22 Richard Biener PR lto/87229 PR lto/88112 * lto-streamer-out.c (lto_is_streamable): Allow CALL_EXPRs which can appear in size expressions. * tree-streamer-in.c (unpack_ts_base_value_fields): Stream CALL_EXPR_BY_DESCRIPTOR. (streamer_read_tree_bitfields): Stream CALL_EXPR_IFN. * tree-streamer-out.c (pack_ts_base_value_fields): Stream CALL_EXPR_BY_DESCRIPTOR. (streamer_write_tree_bitfields): Stream CALL_EXPR_IFN. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/debug/dwarf2/pr87295.C branches/gcc-8-branch/gcc/testsuite/g++.dg/lto/pr87295_0.C branches/gcc-8-branch/gcc/testsuite/g++.dg/lto/pr88046_0.C Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/dwarf2out.c branches/gcc-8-branch/gcc/lto-streamer-out.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-streamer-in.c branches/gcc-8-branch/gcc/tree-streamer-out.c
[Bug debug/88046] [9 Regression] ICE in add_data_member_location_attribute at gcc/dwarf2out.c:19237 since r261885
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88046 --- Comment #8 from Richard Biener --- Author: rguenth Date: Fri Feb 8 14:34:49 2019 New Revision: 268698 URL: https://gcc.gnu.org/viewcvs?rev=268698&root=gcc&view=rev Log: 2019-02-08 Richard Biener Backport from mainline 2019-02-03 Richard Biener PR debug/87295 * dwarf2out.c (copy_ancestor_tree): Register non-stubs as orig. * g++.dg/debug/dwarf2/pr87295.C: New testcase. 2019-01-29 Richard Biener PR debug/87295 * dwarf2out.c (collect_skeleton_dies): New helper. (copy_decls_for_unworthy_types): Call it. (build_abbrev_table): Do not try to replace DW_AT_signature refs with local refs. * g++.dg/lto/pr87295_0.C: New testcase. 2019-01-17 Richard Biener PR lto/86736 * dwarf2out.c (want_pubnames): Never generate pubnames sections and friends for the LTO part of debug info. 2019-01-24 Richard Biener PR lto/87187 * tree-streamer-out.c (write_ts_decl_common_tree_pointers): When in "legacy" debug mode make sure to reset self-origins. 2019-01-15 Richard Biener PR debug/88046 * dwarf2out.c (gen_member_die): Do not generate inheritance DIEs late. * g++.dg/lto/pr88046_0.C: New testcase. 2018-11-22 Richard Biener PR lto/87229 PR lto/88112 * lto-streamer-out.c (lto_is_streamable): Allow CALL_EXPRs which can appear in size expressions. * tree-streamer-in.c (unpack_ts_base_value_fields): Stream CALL_EXPR_BY_DESCRIPTOR. (streamer_read_tree_bitfields): Stream CALL_EXPR_IFN. * tree-streamer-out.c (pack_ts_base_value_fields): Stream CALL_EXPR_BY_DESCRIPTOR. (streamer_write_tree_bitfields): Stream CALL_EXPR_IFN. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/debug/dwarf2/pr87295.C branches/gcc-8-branch/gcc/testsuite/g++.dg/lto/pr87295_0.C branches/gcc-8-branch/gcc/testsuite/g++.dg/lto/pr88046_0.C Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/dwarf2out.c branches/gcc-8-branch/gcc/lto-streamer-out.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-streamer-in.c branches/gcc-8-branch/gcc/tree-streamer-out.c
[Bug lto/87187] FAIL: gfortran.dg/short_circuiting_3.f90 -g -flto (internal compiler error) on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87187 --- Comment #10 from Richard Biener --- Author: rguenth Date: Fri Feb 8 14:34:49 2019 New Revision: 268698 URL: https://gcc.gnu.org/viewcvs?rev=268698&root=gcc&view=rev Log: 2019-02-08 Richard Biener Backport from mainline 2019-02-03 Richard Biener PR debug/87295 * dwarf2out.c (copy_ancestor_tree): Register non-stubs as orig. * g++.dg/debug/dwarf2/pr87295.C: New testcase. 2019-01-29 Richard Biener PR debug/87295 * dwarf2out.c (collect_skeleton_dies): New helper. (copy_decls_for_unworthy_types): Call it. (build_abbrev_table): Do not try to replace DW_AT_signature refs with local refs. * g++.dg/lto/pr87295_0.C: New testcase. 2019-01-17 Richard Biener PR lto/86736 * dwarf2out.c (want_pubnames): Never generate pubnames sections and friends for the LTO part of debug info. 2019-01-24 Richard Biener PR lto/87187 * tree-streamer-out.c (write_ts_decl_common_tree_pointers): When in "legacy" debug mode make sure to reset self-origins. 2019-01-15 Richard Biener PR debug/88046 * dwarf2out.c (gen_member_die): Do not generate inheritance DIEs late. * g++.dg/lto/pr88046_0.C: New testcase. 2018-11-22 Richard Biener PR lto/87229 PR lto/88112 * lto-streamer-out.c (lto_is_streamable): Allow CALL_EXPRs which can appear in size expressions. * tree-streamer-in.c (unpack_ts_base_value_fields): Stream CALL_EXPR_BY_DESCRIPTOR. (streamer_read_tree_bitfields): Stream CALL_EXPR_IFN. * tree-streamer-out.c (pack_ts_base_value_fields): Stream CALL_EXPR_BY_DESCRIPTOR. (streamer_write_tree_bitfields): Stream CALL_EXPR_IFN. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/debug/dwarf2/pr87295.C branches/gcc-8-branch/gcc/testsuite/g++.dg/lto/pr87295_0.C branches/gcc-8-branch/gcc/testsuite/g++.dg/lto/pr88046_0.C Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/dwarf2out.c branches/gcc-8-branch/gcc/lto-streamer-out.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-streamer-in.c branches/gcc-8-branch/gcc/tree-streamer-out.c
[Bug debug/87295] [8 Regression][early debug] ICE with -ffat-lto-objects -fdebug-types-section -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87295 --- Comment #17 from Richard Biener --- Author: rguenth Date: Fri Feb 8 14:34:49 2019 New Revision: 268698 URL: https://gcc.gnu.org/viewcvs?rev=268698&root=gcc&view=rev Log: 2019-02-08 Richard Biener Backport from mainline 2019-02-03 Richard Biener PR debug/87295 * dwarf2out.c (copy_ancestor_tree): Register non-stubs as orig. * g++.dg/debug/dwarf2/pr87295.C: New testcase. 2019-01-29 Richard Biener PR debug/87295 * dwarf2out.c (collect_skeleton_dies): New helper. (copy_decls_for_unworthy_types): Call it. (build_abbrev_table): Do not try to replace DW_AT_signature refs with local refs. * g++.dg/lto/pr87295_0.C: New testcase. 2019-01-17 Richard Biener PR lto/86736 * dwarf2out.c (want_pubnames): Never generate pubnames sections and friends for the LTO part of debug info. 2019-01-24 Richard Biener PR lto/87187 * tree-streamer-out.c (write_ts_decl_common_tree_pointers): When in "legacy" debug mode make sure to reset self-origins. 2019-01-15 Richard Biener PR debug/88046 * dwarf2out.c (gen_member_die): Do not generate inheritance DIEs late. * g++.dg/lto/pr88046_0.C: New testcase. 2018-11-22 Richard Biener PR lto/87229 PR lto/88112 * lto-streamer-out.c (lto_is_streamable): Allow CALL_EXPRs which can appear in size expressions. * tree-streamer-in.c (unpack_ts_base_value_fields): Stream CALL_EXPR_BY_DESCRIPTOR. (streamer_read_tree_bitfields): Stream CALL_EXPR_IFN. * tree-streamer-out.c (pack_ts_base_value_fields): Stream CALL_EXPR_BY_DESCRIPTOR. (streamer_write_tree_bitfields): Stream CALL_EXPR_IFN. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/debug/dwarf2/pr87295.C branches/gcc-8-branch/gcc/testsuite/g++.dg/lto/pr87295_0.C branches/gcc-8-branch/gcc/testsuite/g++.dg/lto/pr88046_0.C Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/dwarf2out.c branches/gcc-8-branch/gcc/lto-streamer-out.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-streamer-in.c branches/gcc-8-branch/gcc/tree-streamer-out.c
[Bug c++/87229] [8 Regression] ICE: tree code 'call_expr' is not supported in LTO streams
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87229 --- Comment #9 from Richard Biener --- Author: rguenth Date: Fri Feb 8 14:34:49 2019 New Revision: 268698 URL: https://gcc.gnu.org/viewcvs?rev=268698&root=gcc&view=rev Log: 2019-02-08 Richard Biener Backport from mainline 2019-02-03 Richard Biener PR debug/87295 * dwarf2out.c (copy_ancestor_tree): Register non-stubs as orig. * g++.dg/debug/dwarf2/pr87295.C: New testcase. 2019-01-29 Richard Biener PR debug/87295 * dwarf2out.c (collect_skeleton_dies): New helper. (copy_decls_for_unworthy_types): Call it. (build_abbrev_table): Do not try to replace DW_AT_signature refs with local refs. * g++.dg/lto/pr87295_0.C: New testcase. 2019-01-17 Richard Biener PR lto/86736 * dwarf2out.c (want_pubnames): Never generate pubnames sections and friends for the LTO part of debug info. 2019-01-24 Richard Biener PR lto/87187 * tree-streamer-out.c (write_ts_decl_common_tree_pointers): When in "legacy" debug mode make sure to reset self-origins. 2019-01-15 Richard Biener PR debug/88046 * dwarf2out.c (gen_member_die): Do not generate inheritance DIEs late. * g++.dg/lto/pr88046_0.C: New testcase. 2018-11-22 Richard Biener PR lto/87229 PR lto/88112 * lto-streamer-out.c (lto_is_streamable): Allow CALL_EXPRs which can appear in size expressions. * tree-streamer-in.c (unpack_ts_base_value_fields): Stream CALL_EXPR_BY_DESCRIPTOR. (streamer_read_tree_bitfields): Stream CALL_EXPR_IFN. * tree-streamer-out.c (pack_ts_base_value_fields): Stream CALL_EXPR_BY_DESCRIPTOR. (streamer_write_tree_bitfields): Stream CALL_EXPR_IFN. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/debug/dwarf2/pr87295.C branches/gcc-8-branch/gcc/testsuite/g++.dg/lto/pr87295_0.C branches/gcc-8-branch/gcc/testsuite/g++.dg/lto/pr88046_0.C Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/dwarf2out.c branches/gcc-8-branch/gcc/lto-streamer-out.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-streamer-in.c branches/gcc-8-branch/gcc/tree-streamer-out.c
[Bug c++/87229] [8 Regression] ICE: tree code 'call_expr' is not supported in LTO streams
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87229 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||8.2.1 Resolution|--- |FIXED Known to fail||8.2.0 --- Comment #8 from Richard Biener --- Fixed.
[Bug tree-optimization/89209] [9 Regression] ICE in build_ref_for_model, at tree-sra.c:1791
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89209 --- Comment #5 from Martin Jambor --- HWell, no. We create a special default-def SSA to insert into the IL the information that an uninitialized value is being loaded but now the SSA has aggregate type, which should not happen, I guess (even though it surprisingly works). We try to create only one such SSA name for each part of an aggregate. A simple solution would be to create a new one if V_C_E with an aggregate argument is on the RHS. I'll look into the code a bit more to see if I can find other options.
[Bug libstdc++/65229] pretty-printer exception on std::bitset<0>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65229 Jonathan Wakely changed: What|Removed |Added Target Milestone|9.0 |8.3
[Bug libstdc++/87787] [UBSAN] runtime error: null pointer passed as argument 2, which is declared to never be null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87787 Jonathan Wakely changed: What|Removed |Added Target Milestone|9.0 |8.3
[Bug libstdc++/65229] pretty-printer exception on std::bitset<0>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65229 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Fri Feb 8 14:16:09 2019 New Revision: 268693 URL: https://gcc.gnu.org/viewcvs?rev=268693&root=gcc&view=rev Log: PR libstdc++/65229 fix pretty printer for std::bitset<0> Backport from mainline 2018-11-23 Martin Sebor Jonathan Wakely PR libstdc++/65229 * python/libstdcxx/v6/printers.py (StdBitsetPrinter): Handle exception thrown for std::bitset<0>. * testsuite/libstdc++-prettyprinters/simple.cc: Test std::bitset<0>. Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/python/libstdcxx/v6/printers.py branches/gcc-8-branch/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple.cc
[Bug libstdc++/89128] Missing CTAD deduction guides for std::stack and std::queue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89128 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jonathan Wakely --- done --- Comment #4 from Jonathan Wakely --- Author: redi Date: Fri Feb 8 14:15:03 2019 New Revision: 268691 URL: https://gcc.gnu.org/viewcvs?rev=268691&root=gcc&view=rev Log: PR libstdc++/89128 add deduction guides for container adaptors Backport from mainline 2019-02-05 Jonathan Wakely PR libstdc++/89128 * include/bits/stl_queue.h (queue, priority_queue): Add deduction guides. * include/bits/stl_stack.h (stack): Likewise. * testsuite/23_containers/priority_queue/deduction.cc: New test. * testsuite/23_containers/queue/deduction.cc: New test. * testsuite/23_containers/stack/deduction.cc: New test. Added: branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/priority_queue/deduction.cc branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/queue/deduction.cc branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/stack/deduction.cc Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/include/bits/stl_queue.h branches/gcc-8-branch/libstdc++-v3/include/bits/stl_stack.h
[Bug libstdc++/88119] std::alignment_of returns wrong value (__alignof instead of alignof).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88119 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Fri Feb 8 14:14:57 2019 New Revision: 268690 URL: https://gcc.gnu.org/viewcvs?rev=268690&root=gcc&view=rev Log: PR libstdc++/88119 use alignof in std::alignment_of, not __alignof__ Now that __alignof__ and alignof sometimes disagree it matters which one we use. The standard says that std::alignment_of::value equals alignof(T), so we need to use that. Change the only uses of alignment_of to use __alignof__ to avoid a change in alignment. Backport from mainline 2018-11-29 Jonathan Wakely PR libstdc++/88119 * include/ext/aligned_buffer.h (__aligned_membuf): Add comment. (__aligned_buffer): Use __alignof__ instead of std::alignment_of. * include/std/type_traits (alignment_of): Use alignof instead of __alignof__. * testsuite/20_util/alignment_of/value.cc: Fix test to check values match alignof not __alignof__, as required by the standard. Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/include/ext/aligned_buffer.h branches/gcc-8-branch/libstdc++-v3/include/std/type_traits branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/alignment_of/value.cc
[Bug libstdc++/88119] std::alignment_of returns wrong value (__alignof instead of alignof).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88119 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Fixed for GCC 8.3
[Bug libstdc++/87308] pretty printer for std::any fails with: Python Exception Unknown manager function in std::any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87308 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Fri Feb 8 14:15:36 2019 New Revision: 268692 URL: https://gcc.gnu.org/viewcvs?rev=268692&root=gcc&view=rev Log: PR libstdc++/87308 adjust regex used in std::any pretty printer The regex used in the backported patch is simpler than the one in trunk, because it appears that LTO mangles the debug info on the branch, causing it to fail to match sometimes. The new test is also omitted from the branch, because it fails for the same reason. Backport from mainline 2018-11-23 Jonathan Wakely PR libstdc++/87308 (partial) * python/libstdcxx/v6/printers.py (StdExpAnyPrinter): Adjust regex to work around PR 88166. Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/python/libstdcxx/v6/printers.py
[Bug libstdc++/87787] [UBSAN] runtime error: null pointer passed as argument 2, which is declared to never be null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87787 --- Comment #13 from Jonathan Wakely --- Author: redi Date: Fri Feb 8 14:16:28 2019 New Revision: 268694 URL: https://gcc.gnu.org/viewcvs?rev=268694&root=gcc&view=rev Log: PR libstdc++/87787 avoid undefined null args to memcpy and memmove The C++ char_traits and ctype APIs do not disallow null pointer arguments, so we need explicit checks to ensure we don't forward null pointers to memcpy or memmove. Backport from mainline 2019-01-07 Jonathan Wakely PR libstdc++/87787 * include/bits/char_traits.h (char_traits::move): Do not pass null pointers to memmove. * include/bits/locale_facets.h (ctype::widen(const char*, const char*, char*)): Do not pass null pointers to memcpy. (ctype::narrow(const char*, const char*, char, char*)): Likewise. (ctype::do_widen(const char*, const char*, char*)): Likewise. (ctype::do_narrow(const char*, const char*, char, char*)): Likewise. Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/include/bits/char_traits.h branches/gcc-8-branch/libstdc++-v3/include/bits/locale_facets.h
[Bug c++/88166] Inconsistent placement of cv-quals and ptr-declarator in debuginfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88166 --- Comment #6 from Jonathan Wakely --- Author: redi Date: Fri Feb 8 14:15:36 2019 New Revision: 268692 URL: https://gcc.gnu.org/viewcvs?rev=268692&root=gcc&view=rev Log: PR libstdc++/87308 adjust regex used in std::any pretty printer The regex used in the backported patch is simpler than the one in trunk, because it appears that LTO mangles the debug info on the branch, causing it to fail to match sometimes. The new test is also omitted from the branch, because it fails for the same reason. Backport from mainline 2018-11-23 Jonathan Wakely PR libstdc++/87308 (partial) * python/libstdcxx/v6/printers.py (StdExpAnyPrinter): Adjust regex to work around PR 88166. Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/python/libstdcxx/v6/printers.py
[Bug libstdc++/89128] Missing CTAD deduction guides for std::stack and std::queue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89128 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jonathan Wakely --- done
[Bug c++/89232] c++: Fail to build when and the noreturn keyword is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89232 --- Comment #8 from Jonathan Wakely --- But you can include it in C++, because the header exists. If you just include it an do nothing, there's no problem (it's not part of the C++ standard and so your program is not portable, conforming C++, but it compiles). The problem is that you tried to use the 'noreturn' specifier in your function, and that is not valid in C++. Including a useless header that doesn't define anything in C++ is fairly harmless. Writing invalid C++ code is invalid, and that's what triggers an error. The problem is not the header, it's your code.
[Bug target/88656] [7/8/9 Regression] lr clobbered by thumb prologue before __builtin_return_address(0) reads from it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88656
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-02-08
CC||jakub at gcc dot gnu.org,
||ktkachov at gcc dot gnu.org,
||ramana at gcc dot gnu.org,
||rearnsha at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Confirmed with -march=armv6-m -mthumb -O2
void baz (void);
void *
foo (void)
{
asm volatile("" : : : "r8", "r9", "r4");
return __builtin_return_address (0);
}
void *
bar (void)
{
asm volatile("" : : : "r8", "r9", "r4");
baz ();
return __builtin_return_address (0);
}
[Bug tree-optimization/89253] [8/9 Regression] ICE in split_loop, at tree-ssa-loop-split.c:566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89253
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED |ASSIGNED
Keywords|ice-on-invalid-code |ice-on-valid-code
Last reconfirmed||2019-02-08
CC||matz at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
Target Milestone|--- |8.3
--- Comment #1 from Richard Biener ---
Confirmed on x86_64-linux. loop_version can (and does) fail here, possibly
because there's abnormal edges (computed goto) inside.
(gdb) p can_duplicate_loop_p (loop1)
$2 = false
but this isn't checked. I am testing
Index: gcc/tree-ssa-loop-split.c
===
--- gcc/tree-ssa-loop-split.c (revision 268679)
+++ gcc/tree-ssa-loop-split.c (working copy)
@@ -649,7 +649,8 @@ tree_ssa_split_loops (void)
false, true)
&& niter.cmp != ERROR_MARK
/* We can't yet handle loops controlled by a != predicate. */
- && niter.cmp != NE_EXPR)
+ && niter.cmp != NE_EXPR
+ && can_duplicate_loop_p (loop))
{
if (split_loop (loop, &niter))
{
[Bug target/69471] "-march=native" unintentionally breaks further -march/-mtune flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69471 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-08 CC||hjl.tools at gmail dot com Ever confirmed|0 |1 --- Comment #7 from H.J. Lu --- -march=native overrides everything, including, -march= after it: [hjl@gnu-cfl-2 gcc]$ cat /tmp/foo.c #ifndef __AVX512F__ # error No AVX512F #endif [hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -march=skylake-avx512 -S /tmp/foo.c [hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -march=native -march=skylake-avx512 -S /tmp/foo.c /tmp/foo.c:2:3: error: #error No AVX512F 2 | # error No AVX512F | ^ [hjl@gnu-cfl-2 gcc]$
[Bug ipa/87957] [9 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘identifier_node’ in warn_odr, at ipa-devirt.c:1051 since r265519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957 --- Comment #33 from Jan Hubicka --- Hi, I am testing the following fix: since we already decided about mangling we are in fact safe to remove everything that does not have assembler name on it. Honza Index: tree.c === --- tree.c (revision 268579) +++ tree.c (working copy) @@ -5152,7 +5152,8 @@ fld_simplified_type_name (tree type) /* Drop TYPE_DECLs in TYPE_NAME in favor of the identifier in the TYPE_DECL if the type doesn't have linkage. this must match fld_ */ - if (type != TYPE_MAIN_VARIANT (type) || ! type_with_linkage_p (type)) + if (type != TYPE_MAIN_VARIANT (type) + || !DECL_ASSEMBLER_NAME_SET_P (TYPE_NAME (type))) return DECL_NAME (TYPE_NAME (type)); return TYPE_NAME (type); }
[Bug d/89255] libphobos.unittests multilib handling broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89255 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug d/89255] New: libphobos.unittests multilib handling broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89255 Bug ID: 89255 Summary: libphobos.unittests multilib handling broken Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- The libphobos.unittests tests don't run properly for the non-default multilib (seen on both Solaris/SPARC and x86 as well as Linux/x86_64 and Linux/i686, but not dependent on the specific target). * E.g. on Solaris/x86 for the -m64 multilib, I see ld.so.1: unittest: fatal: libgdruntime_t.so.0: open failed: No such file or directory which not only produces confused libphobos.sum output Running /vol/gcc/src/hg/trunk/local/libphobos/testsuite/libphobos.unittests/unittests.exp ... FAIL: libphobos.unittests/druntime/shared/ld.so.1: FAIL: libphobos.unittests/druntime/shared/unittest: FAIL: libphobos.unittests/druntime/shared/fatal: FAIL: libphobos.unittests/druntime/shared/libgdruntime_t.so.0: FAIL: libphobos.unittests/druntime/shared/open FAIL: libphobos.unittests/druntime/shared/failed: FAIL: libphobos.unittests/druntime/shared/No FAIL: libphobos.unittests/druntime/shared/such FAIL: libphobos.unittests/druntime/shared/file FAIL: libphobos.unittests/druntime/shared/or FAIL: libphobos.unittests/druntime/shared/directory which later turns up in mail-report.log, but * indeed libgdruntime_t.so isn't built for non-default multilibs. libgdruntime_t.la is only built during make check, but the toplevel check targets lacks multilib handling.
[Bug tree-optimization/89247] [7/8 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.c:2409
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89247 Richard Biener changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #12 from Richard Biener --- *** Bug 87446 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/87446] [7/8/9 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.c:2431
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87446 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Richard Biener --- The later one has a nicer testcase (plain -O3) and I've fixed it there. *** This bug has been marked as a duplicate of bug 89247 ***
[Bug c++/89232] c++: Fail to build when and the noreturn keyword is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89232 --- Comment #7 from pere at hungry dot com --- I just think it would have been useful if the compiler said something like 'header file is not defined/available in C++' or something like that. It would provide feedback to the developer even if 'noreturn' is not used anywhere in the code to cause the error I ran into. Anywya, just an idea for you to consider, perhaps a feature request for a different bug report. :)
[Bug tree-optimization/89247] [7/8 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.c:2409
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89247 --- Comment #11 from Richard Biener --- Author: rguenth Date: Fri Feb 8 13:21:36 2019 New Revision: 268689 URL: https://gcc.gnu.org/viewcvs?rev=268689&root=gcc&view=rev Log: 2019-02-08 Richard Biener PR tree-optimization/89247 * tree-if-conv.c: Include tree-cfgcleanup.h. (version_loop_for_if_conversion): Record LOOP_VECTORIZED call. (tree_if_conversion): Pass through predicate vector. (pass_if_conversion::execute): Do CFG cleanup and SSA update inline, see if any if-converted loops we refrece in LOOP_VECTORIZED calls vanished and fixup. * tree-if-conv.h (tree_if_conversion): Adjust prototype. * gcc.dg/torture/pr89247.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr89247.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c trunk/gcc/tree-if-conv.h
[Bug tree-optimization/89247] [7/8 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.c:2409
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89247 Richard Biener changed: What|Removed |Added Known to work||9.0 Summary|[7/8/9 Regression] ICE in |[7/8 Regression] ICE in |expand_LOOP_VECTORIZED, at |expand_LOOP_VECTORIZED, at |internal-fn.c:2409 |internal-fn.c:2409 Known to fail|9.0 | --- Comment #10 from Richard Biener --- Fixed on trunk.
[Bug middle-end/89252] Vector load/store aren't used to initialize large memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89252 --- Comment #2 from H.J. Lu --- Created attachment 45643 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45643&action=edit A patch
[Bug driver/89249] mingw, paths with spaces, LTO -> collect2.exe: fatal error: CreateProcess: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89249 --- Comment #3 from Liviu Ionescu --- Hi Richard, Thank you for taking the time to investigate. Indeed, COLLECT_LTO_WRAPPER is escaped, while COMPILER_PATH is not: COLLECT_LTO_WRAPPER=c:/users/ilg/desktop/8.2.1\ \ \ \ \ 1.4-20190207-1853/bin/../libexec/gcc/arm-none-eabi/8.2.1/lto-wrapper.exe ... COMPILER_PATH=c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../libexec/gcc/arm-none-eabi/8.2.1/;c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../libexec/gcc/;c:/users/ilg/desktop/8.2.1 1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ However, COMPILER_PATH is also not escaped in the no-LTO case, which works, so I guess it is escaped somewhere else, and this is missing in the LTO code. The only meaningful place where COMPILER_PATH is used is in gcc.c:driver::maybe_run_linker(): putenv_from_prefixes (&exec_prefixes, "COMPILER_PATH", false); putenv_from_prefixes (&startfile_prefixes, LIBRARY_PATH_ENV, true); Right now I see convert_white_space() called only twice: lto_wrapper_file = find_a_file (&exec_prefixes, "lto-wrapper", X_OK, false); and linker_plugin_file_spec = convert_white_space (temp_spec); >From what I undestand, the path in 'exec_prefixes' should have been converted before putenv_from_prefixes() is called. 'exec_prefixes' seems constructed via add_prefix (&exec_prefixes, arg, NULL, PREFIX_PRIORITY_B_OPT, 0, 0); >From here... I'm kind of lost, the logic to manage paths is complex and I can't estimate the impacts of changes, but I think that this path change mandatory for Windows should be done in a single place, not everywhere the paths are finally consumed. So, we got a bit of understanding, but the ploblem seems to require more thinking and a careful solution, which I'm not able to provide. However, if someone can, I'm ready to try it.
[Bug target/89251] [2018-q4m] Wrong datatype optimization on bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89251 --- Comment #4 from Kochise --- The pointer I access is volatile, not the uint32_t behind. Why would I ? The 'volatile' keyword has no meaning to change the data size being processed, only removing the caching behavior of the compiler. If the compiler can decide to change the specified size of non-volatile datatypes, you really must consider reviewing some common practices. I wanted this to be uint32_t, keep it that way, thanks. Where in the standard is written that bitfield could be resized out from their base datatype ? What's the point anyway ? And 'volatile' would "prevent that" ? How unfriendly...
[Bug d/89254] std.net.curl and std.parallelism unittests hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89254 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug d/89254] New: std.net.curl and std.parallelism unittests hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89254
Bug ID: 89254
Summary: std.net.curl and std.parallelism unittests hang
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ro at gcc dot gnu.org
Target Milestone: ---
Target: i686-pc-linux-gnu
When building on Linux/i686, the std.net.curl and std.parallelism unitests
hang and never time out. Unfortunately, when trying to investigate with pstack
or gdb, those hang too and need to be killed explicitly.
strace shows
[pid 4] write(1, "bc_start_main [0xf2a7a742]\n", 27bc_start_main
[0xf2a7a742]
) = 27
[pid 4] write(1, "??:? ???[0x8049312]\n", 20??:? ???[0x8049312]
) = 20
[pid 4] rt_sigaction(SIGSEGV, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0},
NULL, 8) = 0
[pid 4] rt_sigaction(SIGBUS, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0},
NULL, 8) = 0
[pid 4] futex(0xf2936ba8, FUTEX_WAIT, 40001, NULL
This is ugly because the complete build/test never finishes without manual
investigation. To make things worse, each test is run twice when running a
multilibbed build due to broken multilib handling of libphobos.unittests
(to be reported separately).
[Bug tree-optimization/89252] Vector load/store aren't used to initialize large memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89252 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-08 CC||jakub at redhat dot com Depends on||28755 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- The code in question is added by commit d4cf8ff76d20953c1113f02bddfc22b61d7dd195 Author: jakub Date: Sun Sep 23 09:34:28 2007 + PR middle-end/28755 * expr.c (expand_constructor): New function. (expand_expr_real_1) : Call it. (expand_expr_real_1) : Call it if VALUE is CONSTRUCTOR. * gcc.dg/pr28755.c: New test. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28755 [Bug 28755] [4.2 Regression] duplicate members of arrays
[Bug libstdc++/88084] basic_string_view::copy doesn't use Traits::copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88084 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jonathan Wakely --- Fixed for GCC 8.3
[Bug libstdc++/83511] Missing default argument for basic_string_view::substr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83511 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Fixed for GCC 8.3
[Bug lto/88147] [9 Regression] ICE in linemap_line_start, at libcpp/line-map.c:781 starting from r265875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88147 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #12 from Martin Liška --- Let me work on that..
[Bug tree-optimization/89253] New: [8/9 Regression] ICE in split_loop, at tree-ssa-loop-split.c:566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89253 Bug ID: 89253 Summary: [8/9 Regression] ICE in split_loop, at tree-ssa-loop-split.c:566 Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- gfortran-9.0.0-alpha20190203 snapshot (r268503) ICEs when compiling the following (not necessarily valid) testcase w/ -O1 -fsplit-loops -fno-tree-dominator-opts: program jr integer :: w5, pg, zh w5 = 0 write (w5) assign 0002 to w5 do pg = 1, 3 if (pg .eq. 1) then do zh = 1, pg end do else goto w5 0001 zh = 0 0002 zh = 0 assign 0001 to w5 endif end do end % powerpc-e300c3-linux-gnu-gfortran-9.0.0-alpha20190203 -O1 -fsplit-loops -fno-tree-dominator-opts -w -c mvxcktth.f during GIMPLE pass: lsplit mvxcktth.f:1:0: 1 | program jr | internal compiler error: in split_loop, at tree-ssa-loop-split.c:566 0x688b22 split_loop /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190203/work/gcc-9-20190203/gcc/tree-ssa-loop-split.c:566 0x688b22 tree_ssa_split_loops /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190203/work/gcc-9-20190203/gcc/tree-ssa-loop-split.c:654 0x688b22 execute /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190203/work/gcc-9-20190203/gcc/tree-ssa-loop-split.c:708 (While my target here is powerpc, the ICE is not target-specific.) BTW, while -fsplit-loops is enabled at -O3 and higher, it is not documented as such in the user's manual.
[Bug c++/89232] c++: Fail to build when and the noreturn keyword is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89232 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- The header doesn't define the noreturn macro (and must not, because one needs to be able to e.g. use [[noreturn]] and if noreturn was say a macro defined to [[noreturn]], that wouldn't work very well). I don't see why you are looking for a warning, you got an error that is fairly readable when you try to use it as if it were a macro.
