[Bug target/87510] New: ICE in gen_reg_rtx, at emit-rtl.c:1155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87510
Bug ID: 87510
Summary: ICE in gen_reg_rtx, at emit-rtl.c:1155
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: segher at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: ppc64le-linux-gnu
Following ICEs:
$ cat ice.cpp
// RUN: %clang_cc1 -verify -fsyntax-only %s
float foof(float x);
double food(double x);
void foo(bool b, float f);
void bar() {
float c = 1.7;
bool b = c;
double e = 1.7;
b = e;
b = foof(4.0);
b = foof(c < 1); // expected-warning {{implicit conversion turns
floating-point number into bool: 'float' to 'bool'}}
b = food(e < 2); // expected-warning {{implicit conversion turns
floating-point number into bool: 'double' to 'bool'}}
foo(c, b);// expected-warning {{implicit conversion turns floating-point
number into bool: 'float' to 'bool'}}
foo(c, c);
}
$ gcc ice.cpp -mno-popcntd -mcpu=power9 -c
during RTL pass: split5
ice.cpp: In function ‘void bar()’:
ice.cpp:24:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1155
24 | }
| ^
0x58d260 gen_reg_rtx(machine_mode)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/emit-rtl.c:1155
0xfc1399 gen_floatdisf2(rtx_def*, rtx_def*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/config/rs6000/rs6000.md:6237
0xfc1ab2 gen_split_168(rtx_insn*, rtx_def**)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/config/rs6000/rs6000.md:5594
0x8645f6 try_split(rtx_def*, rtx_insn*, int)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/emit-rtl.c:3851
0xaa6451 split_insn
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/recog.c:2893
0xaaae87 split_all_insns_noflow()
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/recog.c:3055
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/87509] New: ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87509 Bug ID: 87509 Summary: ICE in extract_insn, at recog.c:2305 Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: segher at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: ppc64le-linux-gnu Following ICEs: $ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/test_fpscr_rn_builtin.c -mpower9-vector /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/test_fpscr_rn_builtin.c: In function ‘main’: /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/test_fpscr_rn_builtin.c:190:1: error: unrecognizable insn: 190 | } | ^ (insn 17 16 18 5 (set (reg:DF 155) (unspec_volatile:DF [ (const_double:DF 1.48219693752373963252970637860466411709517940784297e-323 [0x0.cp-1072]) ] UNSPECV_MFFSCRN)) "/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/test_fpscr_rn_builtin.c":48 -1 (nil)) during RTL pass: vregs /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/test_fpscr_rn_builtin.c:190:1: internal compiler error: in extract_insn, at recog.c:2305 0x571507 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/rtl-error.c:108 0x571523 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/rtl-error.c:116 0x570a10 extract_insn(rtx_insn*) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/recog.c:2305 0x7b75bf instantiate_virtual_regs_in_insn /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/function.c:1605 0x7b75bf instantiate_virtual_regs /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/function.c:1975 0x7b75bf execute /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/function.c:2024
[Bug ipa/83411] function multiversioning should clone the entire sub-callgraph
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83411 --- Comment #4 from Martin Liška --- Thank you Hannes for the report and also the nice blog post. I must agree that's sort of limitation, but I don't agree that it's limiting much: 1) Note that dispatch happens just once when an executable is started, dynamic linker resolves all IFUNC indirect calls. Since that you only pay for the indirect call. However as the target is constant, modern CPUs can predict that very well. 2) That said it's about finding reasonable big enough code that will be entered via MV. In your example you selected a function that does only popcount, which is extremely small and you pay for call overhead. So finding a point like your 'loop' and using flatten attribute can guarantee the call-chain is fully optimized. Would be interesting to come up with more examples from real applications. Anyway, I'm leaving for now this PR and will fix PR82625. It's obvious that user should pay for entering of MV world just once. Thanks.
[Bug ipa/87491] [9 Regression] ipa_fn_summary missing for node during inlining/dumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87491 --- Comment #2 from Martin Liška --- Author: marxin Date: Thu Oct 4 08:06:52 2018 New Revision: 264835 URL: https://gcc.gnu.org/viewcvs?rev=264835&root=gcc&view=rev Log: Call ultimate_alias_target for node being inlined (PR ipa/87491). 2018-10-04 Martin Liska PR ipa/87491 * ipa-inline.c (inline_to_all_callers_1): Call ultimate_alias_target for node being inlined. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c
[Bug ipa/87491] [9 Regression] ipa_fn_summary missing for node during inlining/dumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87491 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Fixed.
[Bug c++/87464] Gcc reports hard error instead of SFINAE out the related method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87464 Alex changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #3 from Alex --- Hello, I am sorry for the confusion. With "works" I did not mention the clang & VC compile the example -- of course the lines commended as "expected error" do not compile and shall not compile. The issue here is not "not compiling", but the wrong/misleading error reporting of GCC, especially compared to those of clang & VC. GCC reports a substitution failure at line 27 & 36 as hard error, what according to the SFINAE concept is not. The extra hard error report at those lines is misleading and could direct a c++ newbie into wrong direction: to repair this issue by "fixing" the enable_if guards. The clang and VC report a "note" for those lines, which is the better way, IMHO. best regards, Alex
[Bug target/87509] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87509 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-04 Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- Yes. I have a patch.
[Bug target/87511] New: [9 Regression][AArch64] UBFIZ instruction with invalid immediate emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87511
Bug ID: 87511
Summary: [9 Regression][AArch64] UBFIZ instruction with invalid
immediate emitted
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sudi at gcc dot gnu.org
Target Milestone: ---
When compiling the code below with aarch64 and -Os
int a, d;
struct {
signed f5 : 26;
signed f6 : 12;
} b;
signed char c;
void fn1() {
signed char *e = &c;
d = a * 10;
*e = d;
b.f6 = c;
b.f5 = 8 <= 3;
}
We get:
$ aarch64-none-elf-gcc -march=armv8-a -c test.c -o /dev/null -Os -Wall
/tmp/ccVimNZB.s: Assembler messages:
/tmp/ccVimNZB.s:20: Error: immediate value out of range 1 to 32 at operand 4 --
`ubfiz x0,x0,32,38'
This started somewhere between r260322 and r261702.
Seems to be incorrectly matching the below in IRA
//(insn:TI 30 22 35 (set (reg:DI 0 x0 [120])
// (and:DI (ashift:DI (reg:DI 0 x0 [orig:92 _3 ] [92])
// (const_int 32 [0x20]))
// (const_int 17587958185983 [0xfff03ff]))) "bfiz.c":12 786
\{*andim_ashiftdi_bfiz}
// (nil))
ubfiz x0, x0, 32, 38 // 30 [c=4 l=4] *andim_ashiftdi_bfiz
[Bug c++/71139] [concepts] ill-formed compound-requirement lacking a semicolon not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71139 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-10-04 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini --- Mine.
[Bug testsuite/87486] [9 regression] gcc.target/powerpc/undef-bool-2.c fails starting with r264335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87486 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug tree-optimization/87490] [9 Regression] ICE in expand_builtin_strnlen at gcc/builtins.c:3164
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87490 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug testsuite/87487] New test case gfortran.dg/deferred_character_24.f90 in r264721 fails on big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87487 Rainer Orth changed: What|Removed |Added Target|powerpc64-unknown-linux-gnu |powerpc64-unknown-linux-gnu ||, sparc-sun-solaris2.* Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-04 CC||ro at gcc dot gnu.org Host|powerpc64-unknown-linux-gnu | Target Milestone|--- |9.0 Ever confirmed|0 |1 Build|powerpc64-unknown-linux-gnu | --- Comment #1 from Rainer Orth --- I'm seeing the same on 64-bit Solaris/SPARC.
[Bug c++/85948] poor location info for arguments and format strings (printf format warning)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85948 David Malcolm changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from David Malcolm --- Thanks for filing this; I'm using PR 56856 to track this (and am testing a fix). *** This bug has been marked as a duplicate of bug 56856 ***
[Bug c++/56856] -Wformat warnings don't show location *within* format string in C++ FE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56856 David Malcolm changed: What|Removed |Added CC||jg at jguk dot org --- Comment #9 from David Malcolm --- *** Bug 85948 has been marked as a duplicate of this bug. ***
[Bug c++/87494] hidden visibility constexpr variables left unevaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87494 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Version|unknown |8.2.1 Resolution|--- |INVALID --- Comment #3 from Richard Biener --- Yeah, I think Andrew is right and this is not a bug.
[Bug fortran/87495] Warning: ‘fastcall’ attribute ignored [-Wattributes] for !GCC$ ATTRIBUTES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87495 --- Comment #1 from Richard Biener --- I think you get diagnostics for the procedure pointer and pointer assignment ones which I guess are technically OK?
[Bug bootstrap/87498] Inconsistent behaviour for passing -DNO_ASM and host=none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87498 --- Comment #2 from Richard Biener --- gmp is only built as host module, I guess that somehow doesn't work for a canadian cross where we likely build it as a target module as well by $magic
[Bug lto/87499] error: invalid conversion in gimple call for a nested function with lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87499 --- Comment #1 from Richard Biener --- I think the issue is an inconsistency between what types are considered local and thus we end up duplicating them but not merge them for canonical type compute. I think we have a duplicate for this.
[Bug bootstrap/87498] Inconsistent behaviour for passing -DNO_ASM and host=none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87498 --- Comment #3 from Miro Kropacek --- Fix is easy - just pass --disable-assembly to extra_configure_flags. I guess gcc will have to deal with the 'none' target in the future anyway because it is deprecated in gmp.
[Bug c++/87512] New: Error: the type ‘const auto’ of ‘constexpr’ variable is not literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87512 Bug ID: 87512 Summary: Error: the type ‘const auto’ of ‘constexpr’ variable is not literal Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: officesamurai at gmail dot com Target Milestone: --- Created attachment 44779 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44779&action=edit Preprocessed source The following code fails to compile: == #include template inline constexpr auto IsPtr = std::is_pointer::value; class Foo; class Bar; template void foo(T1, T2); template std::enable_if_t> foo(T, Foo); template <> void foo(Bar, Bar); == The error: == $ g++-8.2.0 -c -std=c++17 test.cpp test.cpp: In instantiation of ‘constexpr const auto IsPtr’: test.cpp:13:18: required by substitution of ‘template std::enable_if_t > foo(T, Foo) [with T = Bar]’ test.cpp:16:23: required from here test.cpp:4:23: error: the type ‘const auto’ of ‘constexpr’ variable ‘IsPtr’ is not literal inline constexpr auto IsPtr = std::is_pointer::value; ^ test.cpp:4:23: error: ‘const auto IsPtr’ has incomplete type == GCC version: == $ g++-8.2.0 -v Using built-in specs. COLLECT_GCC=g++-8.2.0 COLLECT_LTO_WRAPPER=/home/brd/soft/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ./configure --prefix=/home/brd/soft/gcc-8.2.0 Thread model: posix gcc version 8.2.0 (GCC) == The preprocessed source is attached. P.S. 1) Clang is able to compile it. 2) Changing "auto" to "bool" in the definition of IsPtr fixes the error.
[Bug tree-optimization/87505] Vectorizer generates a lot of code for a small loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87505 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||rguenth at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Richard Biener --- Hmm, we compute the loop iterates ((long unsigned int) base_9(D) - (long unsigned int) (int) base_9(D)) + 3 times. You can probably spot the cases of INT_MAX < base < UINT_MAX not iterating at all (i is sign-extended to std::size_t for the comparison) and base > UINT_MAX where it iterates quite a lot (eventually). We have to account for these cases. If you make the suggested adjustment then of course we know the loop always iterates 4 times. Unless I missed something of course.
[Bug c++/87513] New: internal compiler error: in write_expression, at cp/mangle.c:3050
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87513
Bug ID: 87513
Summary: internal compiler error: in write_expression, at
cp/mangle.c:3050
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sergeev917 at gmail dot com
Target Milestone: ---
Created attachment 44780
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44780&action=edit
preprocessed code sample
=== compiler and system information ===
$ g++-8.2.0 -v
Using built-in specs.
COLLECT_GCC=g++-8.2.0
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-8.2.0-r3/work/gcc-8.2.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/8.2.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include/g++-v8
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/python
--enable-languages=c,c++,go,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --disable-nls --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 8.2.0-r3 p1.4'
--disable-esp --enable-libstdcxx-time --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--disable-multilib --with-multilib-list=m64 --disable-altivec
--disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libmudflap --disable-libssp --disable-libmpx --disable-systemtap
--enable-vtable-verify --enable-libvtv --enable-lto --without-isl
--enable-libsanitizer --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 8.2.0 (Gentoo 8.2.0-r3 p1.4)
=== the complete command line that triggers the bug, the compiler output ===
$ g++-8.2.0 -std=c++14 -o /dev/null -c ice_sample_8.2.0.ii
In file included from main.cc:2:
crow/app.h: In instantiation of 'typename std::result_of)(crow::Router,
std::__cxx11::basic_string&&)>::type
crow::Crow::route(std::__cxx11::string&&) [with long unsigned int
Tag = 0; Middlewares = {}]':
main.cc:8:1: required from here
crow/app.h:63:14: internal compiler error: in write_expression, at
cp/mangle.c:3050
auto route(std::string&& rule)
^
0x59167a write_expression
/var/tmp/portage/sys-devel/gcc-8.2.0-r3/work/gcc-8.2.0/gcc/cp/mangle.c:3050
0x65a9af write_expression
/var/tmp/portage/sys-devel/gcc-8.2.0-r3/work/gcc-8.2.0/gcc/cp/mangle.c:3373
0x65876e write_type
/var/tmp/portage/sys-devel/gcc-8.2.0-r3/work/gcc-8.2.0/gcc/cp/mangle.c:2352
0x659d1d write_bare_function_type
/var/tmp/portage/sys-devel/gcc-8.2.0-r3/work/gcc-8.2.0/gcc/cp/mangle.c:2731
0x65d39b write_function_type
/var/tmp/portage/sys-devel/gcc-8.2.0-r3/work/gcc-8.2.0/gcc/cp/mangle.c:2706
0x658244 write_type
/var/tmp/portage/sys-devel/gcc-8.2.0-r3/work/gcc-8.2.0/gcc/cp/mangle.c:2214
0x65d58b write_template_args
/var/tmp/portage/sys-devel/gcc-8.2.0-r3/work/gcc-8.2.0/gcc/cp/mangle.c:2841
0x65d8da write_prefix
/var/tmp/portage/sys-devel/gcc-8.2.0-r3/work/gcc-8.2.0/gcc/cp/mangle.c:1146
0x6574ba write_nested_name
/var/tmp/portage/sys-devel/gcc-8.2.0-r3/work/gcc-8.2.0/gcc/cp/mangle.c:1076
0x658680 write_type
/var/tmp/portage/sys-devel/gcc-8.2.0-r3/work/gcc-8.2.0/gcc/cp/mangle.c:2232
0x659d1d write_bare_function_type
/var/tmp/portage/sys-devel/gcc-8.2.0-r3/work/gcc-8.2.0/gcc/cp/mangle.c:2731
0x65dcf4 mangle_decl_string
/var/tmp/portage/sys-devel/gcc-8.2.0-r3/work/gcc-8.2.0/gcc/cp/mangle.c:3795
0x65df28 get_mangled_id
/var/tmp/portage/sys-devel/gcc-8.2.0-r3/work/gcc-8.2.0/gcc/cp/mangle.c:3817
0x65df28 mangle_decl(tree_node*)
/var/tmp/portage/sys-devel/gcc-8.2.0-r3/work/gcc-8.2.0/gcc/cp/mangle.c:3855
0xdaaf99 decl_assembler_name(tree_node*)
/var/tmp/portage/sys-devel/gcc-8.2.0-r3/work/gcc-8.2.0/gcc/tree.c:687
0x7e0fc5 symbol_table::insert_to_assembler_name_hash(symtab_node*, bool)
/var/tmp/portage/sys-devel/gcc-8.2.0-r3/work/gcc-8.2.0/gcc/symtab.c:174
0x7e1924 symbol_table::symtab_initialize_asm_name_hash()
/var/tmp/portage/sys-devel/gcc-8.2.0-r3/work/gcc-8.2.0/gcc/symtab.c:266
0x7e19b4 symbol_table::symtab_initialize_asm_name_hash()
/var/tmp/portage/sys-devel/gcc-8.2.0-r3/work/gcc-8.2.0/gcc/symtab.c:976
0x7e19b4 symtab_node::get_for_asmname(tree_node const*)
/var/tmp/portage/sys-devel/gcc-8.2.0-r3/work/gcc-8.2.0/gcc/symtab.c:964
0x7f1660 handle_alias_pairs
/var/tmp/portage/sys-devel/gcc-8.2.0-r3/work/gcc-8
[Bug tree-optimization/87505] Vectorizer generates a lot of code for a small loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87505 --- Comment #3 from Richard Biener --- Both making i std::size_t or casting (base + 4) to int "fixes" this.
[Bug c++/87506] [7/8/9 Regression] ICE with inherited constexpr constructor with const argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87506 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/87511] [9 Regression][AArch64] UBFIZ instruction with invalid immediate emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87511 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |9.0
[Bug testsuite/87487] New test case gfortran.dg/deferred_character_24.f90 in r264721 fails on big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87487 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- Created attachment 44781 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44781&action=edit Possible fix Does this do it for you? I am very surprised to run into an endian problem with this. Cheers Paul
[Bug fortran/56789] Handling of contiguous dummy arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #17 from Paul Thomas --- Created attachment 44782 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44782&action=edit "fix" for the PR Ignoring the niceties of the standard for the moment, this "fixes" the problem; or, at least, it runs as intended. Cheers Paul
[Bug fortran/56789] Handling of contiguous dummy arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789 --- Comment #18 from Harald Anlauf --- (In reply to Paul Thomas from comment #12) > (In reply to Harald Anlauf from comment #11) > > (In reply to paul.richard.tho...@gmail.com from comment #10) > > > Even if that were allowed, the standard explicitly disallows the > > > argument association in the testcase: See 5.3.7 of the F2008 standard. > > > > The wording has changed in F2018 DIS, 8.5.7, paragraph 1: > > > > The CONTIGUOUS attribute specifies that an assumed-shape array is > > contiguous, > > that an array pointer can only be pointer associated with a contiguous > > target, > > or that an assumed-rank dummy data object is contiguous. > > > > > > In my interpretation, the testcase is valid under F2018, but invalid in > > F2008. > > Hmmm! The F2018 standard is almost obfusticating about argument association > with contiguous dummies. I will wade through the pertinent sections tonight. > > Paul FWIW: Crayftn, Intel, PGI, NAG all accept the code without complaining and seem to do the packing/unpacking.
[Bug libstdc++/87514] New: std::make_shared could avoid virtual call to _M_get_deleter()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87514
Bug ID: 87514
Summary: std::make_shared could avoid virtual call to
_M_get_deleter()
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
In __shared_ptr(_Sp_make_shared_tag, const _Alloc&, _Args&&...) we do:
// _M_ptr needs to point to the newly constructed object.
// This relies on _Sp_counted_ptr_inplace::_M_get_deleter.
#if __cpp_rtti
void* __p = _M_refcount._M_get_deleter(typeid(__tag));
#else
void* __p = _M_refcount._M_get_deleter(_Sp_make_shared_tag::_S_ti());
#endif
_M_refcount._M_get_deleter does:
void*
_M_get_deleter(const std::type_info& __ti) const noexcept
{ return _M_pi ? _M_pi->_M_get_deleter(__ti) : nullptr; }
which does an indirect virtual call _Sp_counted_ptr_inplace::_M_get_deleter.
In the __shared_ptr(_Sp_make_shared_tag ...) constructor we know the dynamic
type of *_M_refcount._M_pi is definitely _Sp_counted_ptr_inplace and so could
theoretically avoid the dynamic dispatch.
This would require breaking encapsulation to allow __shared_ptr to access the
private __shared_count::_M_pi member. Is it worth it?
It's possible this can already be devirtualized by the compiler, but only when
optimising. If it isn't, then this might help:
@@ -653,9 +652,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
typedef _Sp_counted_ptr_inplace<_Tp, _Alloc, _Lp> _Sp_cp_type;
typename _Sp_cp_type::__allocator_type __a2(__a);
auto __guard = std::__allocate_guarded(__a2);
- _Sp_cp_type* __mem = __guard.get();
- ::new (__mem) _Sp_cp_type(__a, std::forward<_Args>(__args)...);
- _M_pi = __mem;
+ _M_pi = ::new (__guard.get())
+ _Sp_cp_type(__a, std::forward<_Args>(__args)...);
__guard = nullptr;
}
[Bug testsuite/87487] New test case gfortran.dg/deferred_character_24.f90 in r264721 fails on big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87487 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #2 from Paul Thomas --- > Created attachment 44781 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44781&action=edit > Possible fix > > Does this do it for you? As a quick test, I just rebuilt f951 and ran the single testcase: it PASSes now for both 32 and 64-bit. Thanks. Rainer
[Bug c++/87464] Gcc reports hard error instead of SFINAE out the related method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87464 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic --- Comment #4 from Jonathan Wakely --- Adding diagnostic keyword, since the issue is simply that when showing the reason for substitution failure we show an error not a note.
[Bug tree-optimization/85787] malloc_candidate_p fails to detect malloc attribute on nested phis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85787 --- Comment #2 from prathamesh3492 at gcc dot gnu.org --- Author: prathamesh3492 Date: Thu Oct 4 11:06:24 2018 New Revision: 264838 URL: https://gcc.gnu.org/viewcvs?rev=264838&root=gcc&view=rev Log: 2018-10-04 Prathamesh Kulkarni PR tree-optimization/85787 * ipa-pure-const.c (malloc_candidate_p_1): Move most of malloc_candidate_p into this function and add support for detecting multiple phis. (DUMP_AND_RETURN): Move from malloc_candidate_p into top-level macro. testsuite/ * gcc.dg/ipa/propmalloc-4.c: New test. Added: trunk/gcc/testsuite/gcc.dg/ipa/propmalloc-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-pure-const.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/87514] std::make_shared could avoid virtual call to _Sp_counted_ptr_inplace::_M_get_deleter()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87514 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-04 Summary|std::make_shared could |std::make_shared could |avoid virtual call to |avoid virtual call to |_M_get_deleter()|_Sp_counted_ptr_inplace::_M ||_get_deleter() Ever confirmed|0 |1
[Bug libstdc++/87514] std::make_shared could avoid virtual call to _Sp_counted_ptr_inplace::_M_get_deleter()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87514 --- Comment #1 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #0) > In the __shared_ptr(_Sp_make_shared_tag ...) constructor we know the dynamic > type of *_M_refcount._M_pi is definitely _Sp_counted_ptr_inplace and so > could theoretically avoid the dynamic dispatch. > > This would require breaking encapsulation to allow __shared_ptr to access > the private __shared_count::_M_pi member. Is it worth it? If we're going to do that, we might as well avoid the _M_get_deleter kluge entirely. We could just directly access _M_refcount._M_pi->_M_ptr() to get the pointer out, instead of using the _M_get_deleter override as a backchannel.
[Bug c++/87515] New: "no return statement in function returning non-void" miscompiles with optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87515
Bug ID: 87515
Summary: "no return statement in function returning non-void"
miscompiles with optimizations
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jaydee at email dot cz
Target Milestone: ---
Happens with gcc version 8.2.0 (Debian 8.2.0-7), standalone near-minimal
testcase:
#include
using namespace std;
int blam(int x) {
if (x!=0) {
cout << x << " != 0" << endl;
}
}
int main() {
blam(0);
blam(1);
}
Expected behavior: prints 1 != 0, this actually happens without optimizations.
Unexpected behavior happens with optimizations enabled (-O is enough): it
prints nothing.
I realize that the code is not fully valid, but the resulting behavior is
surprising to say the least. Or the warning should be an error instead. We have
found some variants along the same lines in our codebase that print the
equivalent of 0!=0 and/or segfault.
[Bug c++/87515] "no return statement in function returning non-void" miscompiles with optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87515 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Martin Liška --- Started with r254437. The code is invalid and we produce warning for it by default: pr87515.cpp: In function ‘int blam(int)’: pr87515.cpp:8:1: warning: no return statement in function returning non-void [-Wreturn-type] } ^ Please add -Werror=return-type to your flags and you will find all problematic places.
[Bug bootstrap/87516] New: [9 Regression] AArch64 bootstrap ICEs in ipa-fnsummary.c:2492
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87516
Bug ID: 87516
Summary: [9 Regression] AArch64 bootstrap ICEs in
ipa-fnsummary.c:2492
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
typedef __Int16x8_t int16x8_t;
typedef __Uint16x8_t uint16x8_t;
void fn1(uint16x8_t __a) {
__builtin_aarch64_reduc_plus_scal_v8hi((int16x8_t)__a);
}
The above reduced testcase (from the expansion of the vaddvq_u16 aarch64
intrinsic) ICEs on aarch64 at all optimisation levels with:
lex.ii:5:1: internal compiler error: in compute_fn_summary, at
ipa-fnsummary.c:2492
5 | }
| ^
0xbe6adf compute_fn_summary(cgraph_node*, bool)
$SRC/gcc/ipa-fnsummary.c:2492
0xbe6cfb compute_fn_summary_for_current
$SRC/gcc/ipa-fnsummary.c:2502
0xbe6cfb execute
$SRC/gcc/ipa-fnsummary.c:3516
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/87513] internal compiler error: in write_expression, at cp/mangle.c:3050
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87513 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-04 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, I'm reducing that..
[Bug bootstrap/87516] [9 Regression] AArch64 bootstrap ICEs in ipa-fnsummary.c:2492
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87516 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |9.0 Known to fail||9.0
[Bug testsuite/87487] New test case gfortran.dg/deferred_character_24.f90 in r264721 fails on big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87487 --- Comment #4 from paul.richard.thomas at gmail dot com --- Dear Rainer, That's a relief! Thank you for the fast response. I will commit tonight. Paul On Thu, 4 Oct 2018 at 12:04, ro at CeBiTec dot Uni-Bielefeld.DE wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87487 > > --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- > > --- Comment #2 from Paul Thomas --- > > Created attachment 44781 > > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44781&action=edit > > Possible fix > > > > Does this do it for you? > > As a quick test, I just rebuilt f951 and ran the single testcase: it > PASSes now for both 32 and 64-bit. > > Thanks. > Rainer > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug.
[Bug c++/87513] [8/9 Regression] ICE in write_expression, at cp/mangle.c:3050
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87513 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code CC||jason at gcc dot gnu.org Target Milestone|--- |8.3 Summary|internal compiler error: in |[8/9 Regression] ICE in |write_expression, at|write_expression, at |cp/mangle.c:3050|cp/mangle.c:3050 Known to fail||8.2.0, 9.0 --- Comment #2 from Martin Liška --- Started with r251438. Can you please attach pre-processed source file created with GCC 7.3.x ?
[Bug fortran/55735] ICE with deferred-length strings in COMMON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735 --- Comment #4 from Jürgen Reuter --- In the recent trunk (r264725) does _not_ give an ICE anymore, but the code is vetoed as non-standard, as it is for nagfor and ifort. So, should this be closed now?
[Bug c++/87513] [8/9 Regression] ICE in write_expression, at cp/mangle.c:3050
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87513 --- Comment #3 from Alexander Sergeyev --- Created attachment 44783 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44783&action=edit preprocessed code sample (gcc-7.3.0)
[Bug bootstrap/87516] [9 Regression] AArch64 bootstrap ICEs in ipa-fnsummary.c:2492
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87516 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from ktkachov at gcc dot gnu.org --- Turns out it was a local change of mine causing it. Sorry for the noise.
[Bug c++/87494] hidden visibility constexpr variables left unevaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87494 Nathan Froyd changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #4 from Nathan Froyd --- (In reply to Andrew Pinski from comment #2) > I don't think this is techincally a bug. It might be a missed optimization > but not a bug. You still need a definition even for constexpr if used > outside of a constexpr usage IIRC. You can only use `constexpr` on variable definitions, not declarations. So I already have a definition, and I can't imagine where another one should be added. FWIW, clang and MSVC both accept this code without problems.
[Bug c++/87513] [8/9 Regression] ICE in write_expression, at cp/mangle.c:3050
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87513 Martin Liška changed: What|Removed |Added Known to work||7.2.0 --- Comment #4 from Martin Liška --- Thanks!
[Bug target/87517] New: Typo in avx512fintrin.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87517
Bug ID: 87517
Summary: Typo in avx512fintrin.h
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
Target Milestone: ---
Target: i386,x86-64
avx512fintrin.h has
extern __inline __m512d
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
_mm512_mask_fmaddsub_round_pd (__m512d __A, __mmask8 __U, __m512d __B,
__m512d __C, const int __R)
{
return (__m512d) __builtin_ia32_vfmaddsubpd512_mask ((__v8df) __A,
(__v8df) __B,
(__v8df) __C,
(__mmask8) __U, __R);
}
...
#define _mm512_mask_fmaddsub_round_pd(A, U, B, C, R)\
(__m512d)__builtin_ia32_vfmaddpd512_mask(A, B, C, U, R)
This should be
__builtin_ia32_vfmaddsubpd512_mask
[Bug gcov-profile/84107] indirect call profiling broken with multiple DSOs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84107
--- Comment #2 from Richard Biener ---
"Large symbols and symbols that must exist in exactly one instance in the
running program probably should be a part of (nonexistent) libgcov.so.0."
which are those? I expected individual gcov "instances" to live across
dynamic object lifetime. That is, does a shared libgcov fix the case
of dlopen()ing and dlclose()ing shared objects (multiple times)?
--- Comment #3 from Martin Liška ---
Author: marxin
Date: Thu Oct 4 12:41:14 2018
New Revision: 264840
URL: https://gcc.gnu.org/viewcvs?rev=264840&root=gcc&view=rev
Log:
Fix divergence in indirect profiling (PR gcov-profile/84107).
2018-10-04 Martin Liska
PR gcov-profile/84107
* tree-profile.c (init_ic_make_global_vars):
Remove ic_void_ptr_var and ic_gcov_type_ptr_var.
Come up with new ic_tuple* variables. Emit
__gcov_indirect_call{,_topn} variables.
(gimple_gen_ic_profiler): Access the variable
and emit gimple.
(gimple_gen_ic_func_profiler): Access
__gcov_indirect_call.callee field.
(gimple_init_gcov_profiler): Use ptr_type_node.
* value-prof.c (gimple_ic): Use ptr_type_node.
2018-10-04 Martin Liska
PR gcov-profile/84107
* libgcov-profiler.c (__gcov_indirect_call):
Change type to indirect_call_tuple.
(struct indirect_call_tuple): New struct.
(__gcov_indirect_call_topn_profiler): Change type.
(__gcov_indirect_call_profiler_v2): Use the new
variables.
* libgcov.h (struct indirect_call_tuple): New struct
definition.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-profile.c
trunk/gcc/value-prof.c
trunk/libgcc/ChangeLog
trunk/libgcc/libgcov-profiler.c
trunk/libgcc/libgcov.h
[Bug gcov-profile/84107] indirect call profiling broken with multiple DSOs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84107 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- I would like to close this as resolved. Discussion about introduction of libgcov.so happens here: https://gcc.gnu.org/ml/gcc/2018-09/msg00115.html
[Bug c++/87513] [8/9 Regression] ICE in write_expression, at cp/mangle.c:3050
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87513 --- Comment #5 from Alexander Sergeyev --- (In reply to Martin Liška from comment #4) > Thanks! No problems. Let me know if I could do anything else.
[Bug c++/87513] [8/9 Regression] ICE in write_expression, at cp/mangle.c:3050
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87513 --- Comment #6 from Martin Liška --- (In reply to Alexander Sergeyev from comment #5) > (In reply to Martin Liška from comment #4) > > Thanks! > > No problems. Let me know if I could do anything else. Now all you need to do is to be patient and wait for a fix ;)
[Bug c++/87515] "no return statement in function returning non-void" miscompiles with optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87515 --- Comment #2 from Jakub Drnec --- Ok, will use -Werror=return-type , thanks. Looking at the discussion in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43943 this really is not legal code, I merely wasn't expecting the nasal demons to be this vigorous.
[Bug c++/87518] New: namespace and typedef : scope problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87518
Bug ID: 87518
Summary: namespace and typedef : scope problem
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pierreblavy at yahoo dot fr
Target Milestone: ---
Created attachment 44784
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44784&action=edit
test code
Hello.
The following c++ code compiles with 'clang++ -std=c++17 test.cpp' but not with
'g++ -std=c++17 test.cpp'
I don't know who's right between clang and gcc, but I suspect that gcc reads
the 'typedef t t' line backward, and therefore override the first 't' with the
second one.
This bug might be related to bug number 23594
Best regards
--- test.cpp ---
namespace test{
typedef double t;
struct A{
typedef t t;
};
}
int main(int,char**){return 0;}
--- g++ error message ---
g++ -std=c++17 test.cpp
test.cpp:5:16: error: declaration of ‘typedef test::t test::A::t’
[-fpermissive]
typedef t t;
^
test.cpp:2:19: error: changes meaning of ‘t’ from ‘typedef double test::t’
[-fpermissive]
typedef double t;
--- g++ --version ---
g++ (GCC) 8.1.1 20180712 (Red Hat 8.1.1-5)
[Bug c++/87519] New: -Wsign-conversion erroneosly triggered when converting to auto-deduced interger type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87519 Bug ID: 87519 Summary: -Wsign-conversion erroneosly triggered when converting to auto-deduced interger type Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: fefer.ivan at gmail dot com Target Milestone: --- Created attachment 44785 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44785&action=edit Minimal source code that triggers the bug Version and system: gcc version 7.3.0 (Ubuntu 7.3.0-21ubuntu1~16.04) Command line: gcc -v -save-temps -Werror -Wsign-conversion --std=c++17 bug.cpp Full source code and
[Bug c++/87519] -Wsign-conversion erroneosly triggered when converting to auto-deduced interger type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87519 --- Comment #1 from Ivan Fefer --- Created attachment 44786 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44786&action=edit Full stderr of compiler
[Bug c++/87519] -Wsign-conversion erroneosly triggered when converting to auto-deduced interger type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87519 --- Comment #2 from Ivan Fefer --- Created attachment 44787 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44787&action=edit Code after preprocessing
[Bug c++/87519] -Wsign-conversion erroneosly triggered when converting to auto-deduced interger type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87519 --- Comment #3 from Ivan Fefer --- Created attachment 44788 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44788&action=edit Temp compiler file
[Bug c++/87519] -Wsign-conversion erroneosly triggered when converting to auto-deduced interger type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87519
--- Comment #4 from Ivan Fefer ---
Sorry, hit the Submit button too early by accident.
Source code and compiler output are attached.
Bug is -Wsign-conversion warning triggerring:
bug.cpp:5:11: error: conversion to ‘long unsigned int’ from ‘int32_t {aka int}’
may change the sign of the result [-Werror=sign-conversion]
r = r + static_cast(q);
^~~~
in function
void f(uint64_t a, int32_t q) {
auto& r = a;
r = r + static_cast(q);
}
If we replace 'auto& r = a' with 'uint64_t& r = a' warning with disappear.
[Bug c++/87519] -Wsign-conversion erroneosly triggered when converting to auto-deduced interger type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87519 --- Comment #5 from Ivan Fefer --- Same code at Godbolt.org: https://gcc.godbolt.org/
[Bug fortran/64120] [F03] Wrong handling of allocatable character string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64120 --- Comment #10 from Jürgen Reuter --- I think inside the logical function (in the local scope) the length of s has to be printed as the value of the argument x, so 1 and 2, with or without the 'save' attribute.
[Bug c++/87519] -Wsign-conversion erroneosly triggered when converting to auto-deduced interger type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87519 --- Comment #6 from Ivan Fefer --- https://gcc.godbolt.org/z/hOpMyc
[Bug libstdc++/87520] New: [8/9 Regression] ODR violations in std::make_shared when mixing -fno-rtti and -frtti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87520
Bug ID: 87520
Summary: [8/9 Regression] ODR violations in std::make_shared
when mixing -fno-rtti and -frtti
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
cat > main.cc << EOT
#include
extern int f();
// For the purposes of this demo, force a non-weak definition of
// _Sp_counted_ptr_inplace::_M_get_deleter(const type_info&) to be emitted
// in this translation unit:
template class
std::_Sp_counted_ptr_inplace, std::_S_atomic>;
int main()
{
return f();
}
EOT
cat > sp.cc << EOT
#include
int f()
{
return *std::make_shared();
}
EOT
g++ -fno-rtti main.cc -c -g
g++ -frtti sp.cc -c -g
g++ main.o sp.o
./a.out
This crashes:
Segmentation fault (core dumped)
The problem is that the definition of _Sp_counter_ptr_inplace::_M_get_deleter
that the linker chooses was compiled with -fno-rtti but the caller was compiled
with -frtti. The caller passes typeid(_Sp_make_shared_tag) which does not match
the expected value in _M_get_deleter, so a null pointer is returned. That
leaves the new shared_ptr holding a null pointer, so dereferencing it in f()
crashes.
This crash happens for all versions.
A nastier failure happens with gcc-8 and trunk if we swap which object is built
with RTTI and which without:
g++ -frtti main.cc -c -g
g++ -fno-rtti sp.cc -c -g
g++ main.o sp.o
./a.out
This crashes earlier, during construction of the shared_ptr:
Program received signal SIGSEGV, Segmentation fault.
0x004008cb in std::type_info::operator== (this=0x401700
, __arg=...) at
/home/jwakely/gcc/8/include/c++/8.2.1/typeinfo:123
(gdb) bt
#0 0x004008cb in std::type_info::operator== (this=0x401700
, __arg=...) at
/home/jwakely/gcc/8/include/c++/8.2.1/typeinfo:123
#1 0x00400a31 in std::_Sp_counted_ptr_inplace, (__gnu_cxx::_Lock_policy)2>::_M_get_deleter
(this=0x615e70, type_info node=...) at
/home/jwakely/gcc/8/include/c++/8.2.1/bits/shared_ptr_base.h:569
#2 0x00401264 in
std::__shared_count<(__gnu_cxx::_Lock_policy)2>::_M_get_deleter
(this=0x7fffd858, type_info node=...) at
/home/jwakely/gcc/8/include/c++/8.2.1/bits/shared_ptr_base.h:749
#3 0x004010ba in std::__shared_ptr::__shared_ptr>(std::_Sp_make_shared_tag,
std::allocator const&) (this=0x7fffd850, __tag=..., __a=...) at
/home/jwakely/gcc/8/include/c++/8.2.1/bits/shared_ptr_base.h:1329
#4 0x00401055 in
std::shared_ptr::shared_ptr>(std::_Sp_make_shared_tag,
std::allocator const&) (this=0x7fffd850, __tag=..., __a=...) at
/home/jwakely/gcc/8/include/c++/8.2.1/bits/shared_ptr.h:360
#5 0x00400f8a in std::allocate_shared>(std::allocator const&) (__a=...) at
/home/jwakely/gcc/8/include/c++/8.2.1/bits/shared_ptr.h:707
#6 0x00400ed5 in std::make_shared () at
/home/jwakely/gcc/8/include/c++/8.2.1/bits/shared_ptr.h:723
#7 0x00400d80 in f () at sp.cc:5
#8 0x0040089b in main () at main.cc:13
This is due to the fix for PR 80285. The __shared_ptr constructor is built
without RTTI so calls _M_get_deleter(_Sp_make_shared_tag::_S_ti()). The
definition of _M_get_deleter is built with RTTI so expects a real typeinfo
object. When accessing the fake _S_ti() typeinfo object we crash, because it's
an invalid reference that isn't bound to a real typeinfo.
[Bug c++/87513] [8/9 Regression] ICE in write_expression, at cp/mangle.c:3050
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87513
--- Comment #7 from Martin Liška ---
Reduced test-case:
$ cat ice.ii
template < int a > struct b { static constexpr int c = a; };
template < typename > struct d;
template < typename > struct e;
template < typename f, typename g > struct e< f g::* > : b< d< f >::c > {};
template < typename h, typename... i > struct d< h(i...) > : b< true > {};
template < typename > class j;
struct k {
typedef int l;
};
template < bool, bool, typename... > struct m;
template < typename ab, typename n, typename... o >
struct m< false, true, ab, n, o... > : k {};
template < typename ac, typename... i >
struct ad : m< b< false >::c, e< ac >::c, i... > {};
template < typename ac, typename... i >
struct j< ac(i...) > : ad< ac, i... > {};
class p {
public:
p(char *);
};
class q {
public:
template < long > void r();
};
class s {
public:
template < long t >
auto ae(p) -> typename j< decltype (&q::r< t >)(q, p) >::l;
};
using z = s;
void f() {
z ag;
ag.ae< 0 >("");
}
[Bug rtl-optimization/87466] IRA and LRA spill all pseudos that are live across setjmp calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87466 --- Comment #4 from Peter Bergner --- Author: bergner Date: Thu Oct 4 13:36:20 2018 New Revision: 264842 URL: https://gcc.gnu.org/viewcvs?rev=264842&root=gcc&view=rev Log: gcc/ PR rtl-optimization/87466 * target.def (setjmp_preserves_nonvolatile_regs_p): New target hook. * doc/tm.texi.in (TARGET_SETJMP_PRESERVES_NONVOLATILE_REGS_P): New hook. * doc/tm.texi: Regenerate. * ira-lives.c (process_bb_node_lives): Use the new target hook. * lra-lives.c (process_bb_lives): Likewise. * config/rs6000/rs6000.c (TARGET_SETJMP_PRESERVES_NONVOLATILE_REGS_P): Define. gcc/testsuite/ PR rtl-optimization/87466 * gcc.target/powerpc/pr87466.c: New test. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr87466.c Modified: trunk/gcc/config/rs6000/rs6000.c trunk/gcc/doc/tm.texi trunk/gcc/doc/tm.texi.in trunk/gcc/ira-lives.c trunk/gcc/lra-lives.c trunk/gcc/target.def
[Bug rtl-optimization/87466] IRA and LRA spill all pseudos that are live across setjmp calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87466 Peter Bergner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Peter Bergner --- Patch committed to trunk, so fixed.
[Bug c++/87518] namespace and typedef : scope problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87518 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- The standard says: A name N used in a class S shall refer to the same declaration in its context and when re-evaluated in the completed scope of S. No diagnostic is required for a violation of this rule. Before the typedef the name 't' refers to the declaration of test::t, but after the typedef the name 't' refers to the declaration of A::t. Even though the two declarations denote the same type, they are distinct declarations, which violates the rule. Clang is less strict and does not diagnose the violation of the rule. Arguably a special case could be given to allow it when the two declarations refer to the same entity, but since the typedef seems completely pointless anyway I don't see any benefit to adding a special case.
[Bug c++/87518] namespace and typedef : scope problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87518
--- Comment #2 from Jonathan Wakely ---
P.S. it has nothing to do with namespaces:
typedef double t;
struct A{
typedef t t;
};
int main() { }
[Bug c++/87518] namespace and typedef : scope problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87518
--- Comment #3 from Jonathan Wakely ---
Also see [dcl.typedef] paragraphs 3 and 4 in the standard, which has an example
very similar to this:
struct S {
typedef struct A { } A;// OK
typedef struct B B;// OK
typedef A A; // error
};
[Bug libstdc++/87520] [8/9 Regression] ODR violations in std::make_shared when mixing -fno-rtti and -frtti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87520
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-10-04
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
A possible (partial) fix would be:
--- a/libstdc++-v3/include/bits/shared_ptr_base.h
+++ b/libstdc++-v3/include/bits/shared_ptr_base.h
@@ -500,7 +500,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
struct _Sp_make_shared_tag
{
-#if !__cpp_rtti
private:
template
friend class __shared_ptr;
@@ -513,7 +512,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
alignas(type_info) static constexpr _Sp_make_shared_tag __tag;
return reinterpret_cast(__tag);
}
-#endif
};
template
@@ -562,16 +560,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
this->~_Sp_counted_ptr_inplace();
}
- // Sneaky trick so __shared_ptr can get the managed pointer
+ // Sneaky trick so __shared_ptr can get the managed pointer.
virtual void*
- _M_get_deleter(const std::type_info& __ti) noexcept
+ _M_get_deleter(const std::type_info& __ti) noexcept override
{
-#if __cpp_rtti
- if (__ti == typeid(_Sp_make_shared_tag))
-#else
+ // Check for the fake type_info first, so we don't try to access it
+ // as a real type_info object.
if (&__ti == &_Sp_make_shared_tag::_S_ti())
-#endif
return const_cast::type*>(_M_ptr());
+#if __cpp_rtti
+ // Callers compiled with RTTI enabled pass this instead:
+ else if (__ti == typeid(_Sp_make_shared_tag))
+ return const_cast::type*>(_M_ptr());
+#endif
return nullptr;
}
@@ -1323,11 +1324,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
// _M_ptr needs to point to the newly constructed object.
// This relies on _Sp_counted_ptr_inplace::_M_get_deleter.
-#if __cpp_rtti
- void* __p = _M_refcount._M_get_deleter(typeid(__tag));
-#else
void* __p = _M_refcount._M_get_deleter(_Sp_make_shared_tag::_S_ti());
-#endif
_M_ptr = static_cast<_Tp*>(__p);
_M_enable_shared_from_this_with(_M_ptr);
}
This always passes the fake _S_ti() even when rtti is enabled. Inside
_M_get_deleter we check for the fake tag first, and so avoid trying to
dereference it as a real typeinfo object.
Old code already built with rtti could still call the function with
typeid(_Sp_make_shared_tag) and so we still need to check for that (which will
still fail and return a null pointer if the definition of _M_get_deleter is
built without rtti).
A more complete fix would be to avoid using the virtual _M_get_deleter
backchannel entirely, as suggested in PR 87514 (that would need to be done in
addition to the patch above, so that existing callers of the virtual function
will still be able to use it).
[Bug fortran/87495] Warning: ‘fastcall’ attribute ignored [-Wattributes] for !GCC$ ATTRIBUTES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87495 --- Comment #2 from Martin Liška --- No, fails for so simple example as: $ cat use2.f90 elemental real function sin(arg) !GCC$ attributes FASTCALL :: sin real, intent(in) :: arg sin = -42.0 end function program test_overloaded_intrinsic real(4) :: x(3200), y(3200) y = sin(x) print *, y end $ gfortran use2.f90 -c use2.f90:1:0: elemental real function sin(arg) Warning: ‘fastcall’ attribute ignored [-Wattributes]
[Bug lto/87499] error: invalid conversion in gimple call for a nested function with lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87499 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-04 Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- (In reply to Richard Biener from comment #1) > I think the issue is an inconsistency between what types are considered local > and thus we end up duplicating them but not merge them for canonical type > compute. I think we have a duplicate for this. Yes, now I see the reason. I was unable to find a dup.
[Bug c++/56856] -Wformat warnings don't show location *within* format string in C++ FE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56856 David Malcolm changed: What|Removed |Added Keywords||patch Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org --- Comment #10 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00269.html
[Bug ipa/82625] lower-optimization are not inlined with symbol multiversioning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82625 --- Comment #5 from Martin Liška --- Author: marxin Date: Thu Oct 4 14:36:55 2018 New Revision: 264845 URL: https://gcc.gnu.org/viewcvs?rev=264845&root=gcc&view=rev Log: Redirect call within specific target attribute among MV clones (PR ipa/82625). 2018-10-04 Martin Liska PR ipa/82625 * multiple_target.c (redirect_to_specific_clone): New function. (ipa_target_clone): Use it. * tree-inline.c: Fix comment. 2018-10-04 Martin Liska PR ipa/82625 * g++.dg/ext/pr82625.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/pr82625.C Modified: trunk/gcc/ChangeLog trunk/gcc/multiple_target.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c
[Bug ipa/82625] lower-optimization are not inlined with symbol multiversioning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82625 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Liška --- Fixed.
[Bug c/87483] attribute alias accepted on a symbol definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87483 --- Comment #3 from Martin Liška --- Author: marxin Date: Thu Oct 4 14:44:53 2018 New Revision: 264846 URL: https://gcc.gnu.org/viewcvs?rev=264846&root=gcc&view=rev Log: Error about alias attribute with body definition (PR c/87483). 2018-10-04 Martin Liska PR c/87483 * cgraphunit.c (process_function_and_variable_attributes): Warn about a function with alias attribute and a body. 2018-10-04 Martin Liska PR c/87483 * gcc.dg/pr87483.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr87483.c Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/testsuite/ChangeLog
[Bug c/87483] attribute alias accepted on a symbol definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87483 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- Implemented.
[Bug debug/87362] GCC produces with LTO debug info with which gdb is not happy about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87362 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #18 from Romain Geissler --- Hi, Please note that I also hit the original issue in gdb when opening a binary linked with LTO by gcc 8.2.1 20181003: /workdir/src/gdb-8.2/gdb/dwarf2read.c:9715: internal-error: void dw2_add_symbol_to_list(symbol*, pending**): Assertion `(*listhead) == NULL || (SYMBOL_LANGUAGE ((*listhead)->symbol[ 0]) == SYMBOL_LANGUAGE (symbol))' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) [answered Y; input not from terminal] Do yon think this patched applied on trunk shall be backported to gcc 8 ? Cheers, Romain
[Bug libstdc++/87502] Poor code generation for std::string("c-style string")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
Martin Liška changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||marxin at gcc dot gnu.org
--- Comment #1 from Martin Liška ---
(In reply to M Welinder from comment #0)
> Created attachment 44776 [details]
> Preprocessed source code
>
> It appears that gcc is creating quite poor code when "c-style strings"
> are used to construct std::string objects. Ideally, the result ought
> to be just a few move instructions for small strings.
>
>
> Host: Linux x86_64 4.4.140-62-default (OpenSuSE)
>
> Test code:
> ---
> #include
>
> extern void foo (const std::string &);
>
> void
> bar ()
> {
> foo ("abc");
> foo (std::string("abc"));
> }
> ---
>
>
>
> # /usr/local/products/gcc/8.2.0/bin/g++ -std=gnu++1z -S -m32 -O3 ttt.C
> # grep 'call.*construct' ttt.s
> call
> _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPKcEEvT_S
> 8_St20forward_iterator_tag.constprop.18
> call
> _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPKcEEvT_S
> 8_St20forward_iterator_tag.constprop.18
>
> Here gcc generates complete calls to the generic string construction
> even though the strings are constructed from small, known strings.
With -O2 -fdump-ipa-inline says:
function not declared inline and code size would grow
>
> "-std=gnu++1z" is important; "-m32" and "-O3" (as opposed to "-m64" and
> "-O2") are not.
With -O3 more inlining happens.
>
> # /usr/local/products/gcc/8.2.0/bin/g++ -S -m32 -O3 ttt.C
> # grep 'call.*construct' ttt.s
> # (nada)
>
> No calls -- good. In this case gcc generates this fragment:
>
> _Z3barv:
> .LFB1084:
> .cfi_startproc
> .cfi_personality 0,__gxx_personality_v0
> .cfi_lsda 0,.LLSDA1084
> pushl %ebp
> .cfi_def_cfa_offset 8
> .cfi_offset 5, -8
> movl$25185, %edx
> movl%esp, %ebp
> .cfi_def_cfa_register 5
> pushl %edi
> pushl %esi
> .cfi_offset 7, -12
> .cfi_offset 6, -16
> leal-48(%ebp), %esi
> pushl %ebx
> .cfi_offset 3, -20
> leal-40(%ebp), %ebx
> subl$56, %esp
> movl%ebx, -48(%ebp)
> pushl %esi
> movw%dx, -40(%ebp)
> movb$99, -38(%ebp)
> movl$3, -44(%ebp)
> movb$0, -37(%ebp)
> .LEHB6:
> .cfi_escape 0x2e,0x10
> call_Z3fooRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
> [...]
>
> This is better than a call, but not great:
> 1. The string is moved into position in three chunks (25185, 99, 0).
>This probably comes from inlined memcpy of 3 bytes, but the source
>is zero-terminated so rounding the memcpy size up to 4 would have
>been better.
Yes we end up with:
__builtin_memcpy (&D.30710.D.23004._M_local_buf, "abc", 3);
> 2. It's unclear why 25185 is passed through a register.
It's somehow connected to fact that constant are somehow expensive
on x86_64. Jakub can help here..
[Bug testsuite/87486] [9 regression] gcc.target/powerpc/undef-bool-2.c fails starting with r264335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87486
--- Comment #2 from seurer at gcc dot gnu.org ---
Author: seurer
Date: Thu Oct 4 15:05:32 2018
New Revision: 264847
URL: https://gcc.gnu.org/viewcvs?rev=264847&root=gcc&view=rev
Log:
[PATCH, rs6000] Fix expected error output for test case.
r264355 removed some spelling suggestions including for "bool" as used
in this test case.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu and
powerpc64be-unknown-linux-gnu with no regressions. Is this ok for trunk?
2018-10-04 Bill Seurer
PR target/87486
* gcc.target/powerpc/undef-bool-2.c: Fix expected error output.
Index: gcc/testsuite/gcc.target/powerpc/undef-bool-2.c
===
--- gcc/testsuite/gcc.target/powerpc/undef-bool-2.c (revision 264812)
+++ gcc/testsuite/gcc.target/powerpc/undef-bool-2.c (working copy)
@@ -9,7 +9,7 @@
#include
-bool foo (int x) /* { dg-error "unknown type name 'bool'; did you mean
'_Bool'?" } */
+bool foo (int x) /* { dg-error "unknown type name 'bool'" } */
{
return x == 2;
}
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/undef-bool-2.c
[Bug c++/87515] "no return statement in function returning non-void" miscompiles with optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87515 --- Comment #3 from Andrew Pinski --- Note in c++, when there is no return, the code is undefined while in c, it is only undefined if the return value is used.
[Bug libstdc++/87520] [8/9 Regression] ODR violations in std::make_shared when mixing -fno-rtti and -frtti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87520 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=43105, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=87514 --- Comment #2 from Eric Gallager --- Related to bug 43105
[Bug target/87521] New: [C++][ABI] Tail padding not reused for non POD struct with defaulted/deleted special member function as per Itanium ABI on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87521
Bug ID: 87521
Summary: [C++][ABI] Tail padding not reused for non POD struct
with defaulted/deleted special member function as per
Itanium ABI on x86-64
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno.bugs.contact at gmail dot com
Target Milestone: ---
Consider (https://godbolt.org/z/fSnWB1) (On x86-64)
struct Base {
unsigned x;
short y;
~Base() = default; // same with = delete
};
struct Der : Base {
short z;
};
With GCC sizeof(Der) == 12 instead of the expected 8.
The problem here (if I am reading the spec correctly)
is that the defaulted or deleted destructor qualifies
as user-declared, which makes Base a non-POD-struct
*as per C++03* (but not as per C++11),
which means that according to the Itanium ABI the tail padding
of Base should be reused. The same problem exists with the other
special member functions and with = delete instead.
This is not a recent problem and goes back to at least GCC 4.4.7,
which makes me think that this is maybe intended, but clang reuse
the tail padding in these cases which make this an annoying ABI
incompatibility. As an additional data point ICC seems to agree
with GCC on this.
[Bug ipa/86395] add support of -fopt-info-inline in inliner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86395 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|qinzhao at gcc dot gnu.org |dmalcolm at gcc dot gnu.org --- Comment #3 from David Malcolm --- I'm looking at this.
[Bug lto/87522] New: LTO incorrectly merges target specific options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87522
Bug ID: 87522
Summary: LTO incorrectly merges target specific options
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
[hjl@gnu-cfl-1 lto-test-functions]$ cat a.c
char a[32] = {};
void no_avx (void)
{
__builtin_memset(a, 0, sizeof(a));
}
[hjl@gnu-cfl-1 lto-test-functions]$ cat b.c
char b[32] = {};
void avx (void)
{
__builtin_memset(b, 0, sizeof(b));
}
[hjl@gnu-cfl-1 lto-test-functions]$ cat c.c
char c[32] = {};
void sse_only (void)
{
__builtin_memset(c, 0, sizeof(c));
}
[hjl@gnu-cfl-1 lto-test-functions]$ make
cc -O2 -fPIC -flto -g -mno-avx -c -o a.o a.c
cc -O2 -fPIC -flto -g -mavx -c -o b.o b.c
cc -shared -O2 -fPIC -flto -g -o lib1.so a.o b.o
cc -O2 -fPIC -flto -g -c -o c.o c.c
cc -shared -O2 -fPIC -flto -g -o lib2.so c.o b.o
[hjl@gnu-cfl-1 lto-test-functions]$
1100 :
1100: 48 8b 05 d1 2e 00 00mov0x2ed1(%rip),%rax# 3fd8
1107: c5 f9 ef c0 vpxor %xmm0,%xmm0,%xmm0
110b: c5 f8 29 00 vmovaps %xmm0,(%rax)
110f: c5 f8 29 40 10 vmovaps %xmm0,0x10(%rax)
1114: c3 retq
1115: 66 66 2e 0f 1f 84 00 00 00 00 00data16 nopw
%cs:0x0(%rax,%rax,1)
1120 :
1120: 48 8b 05 c1 2e 00 00mov0x2ec1(%rip),%rax# 3fe8
1127: 66 0f ef c0 pxor %xmm0,%xmm0
112b: 0f 29 00movaps %xmm0,(%rax)
112e: 0f 29 40 10 movaps %xmm0,0x10(%rax)
1132: c3 retq
no_avx has no AVX instructions.
1100 :
1100: 48 8b 05 d1 2e 00 00mov0x2ed1(%rip),%rax# 3fd8
1107: c5 f9 ef c0 vpxor %xmm0,%xmm0,%xmm0
110b: c5 f8 29 00 vmovaps %xmm0,(%rax)
110f: c5 f8 29 40 10 vmovaps %xmm0,0x10(%rax)
1114: c3 retq
1115: 66 66 2e 0f 1f 84 00 00 00 00 00data16 nopw
%cs:0x0(%rax,%rax,1)
1120 :
1120: 48 8b 05 c1 2e 00 00mov0x2ec1(%rip),%rax# 3fe8
1127: c5 f9 ef c0 vpxor %xmm0,%xmm0,%xmm0
112b: c5 f8 29 00 vmovaps %xmm0,(%rax)
112f: c5 f8 29 40 10 vmovaps %xmm0,0x10(%rax)
1134: c3 retq
sse_only has AVX instructions.
[Bug target/87522] LTO incorrectly merges target specific options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87522
H.J. Lu changed:
What|Removed |Added
CC||ubizjak at gmail dot com
Component|lto |target
--- Comment #1 from H.J. Lu ---
The problem is
gnu-user.h: "--32 %{!-:%{mavx:-msse2avx}} %{msse2avx:%{!mavx:-msse2avx}}"
LTO is OK. But -msse2avx turns SSE into AVX.
[Bug testsuite/87487] New test case gfortran.dg/deferred_character_24.f90 in r264721 fails on big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87487 --- Comment #5 from seurer at gcc dot gnu.org --- I tried it on a powerpc64 BE machine and it worked there too.
[Bug target/87522] LTO incorrectly merges target specific options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87522 --- Comment #2 from Thiago Macieira --- In the original case, all sources were compiled with -march=westmere, though some files had -mavx added.
[Bug libstdc++/87502] Poor code generation for std::string("c-style string")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502 --- Comment #2 from M Welinder --- Created attachment 44789 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44789&action=edit Proof-on-concept patch This proof-of-concept improves the situation dramatically. I don't know if it is actually correct. This is done, in part, by not discarding the fact that the source is zero-terminated. With this patch I get the code I expect, mostly. For sizes 2 mod 4 I still get the zero termination as a separate movb. The destruction still stinks: the full destructor is inlined instead of the small-string-only version (i.e., a no-op). Evidently gcc cannot see that the string remains a small-string.
[Bug fortran/82995] Segmentation fault passing optional argument to intrinsic sum function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82995
Thomas Koenig changed:
What|Removed |Added
Keywords||wrong-code
Last reconfirmed|2017-11-14 00:00:00 |2018-10-4
--- Comment #7 from Thomas Koenig ---
Part of the library part of this problem is in the following piece of code in
trans-expr.c (5632):
if (e && (fsym == NULL || fsym->attr.optional))
{
/* If an optional argument is itself an optional dummy argument,
check its presence and substitute a null if absent. This is
only needed when passing an array to an elemental procedure
as then array elements are accessed - or no NULL pointer is
allowed and a "1" or "0" should be passed if not present.
...
The comment (and the code which follows) is wrong for intrinsics
with an optional mask argument. Of course, the library would also
have to handle that, but that is easily done with code like
Index: ifunction.m4
===
--- ifunction.m4(Revision 264540)
+++ ifunction.m4(Arbeitskopie)
@@ -210,6 +210,15 @@
index_type mdelta;
int mask_kind;
+ if (mask->base_addr == NULL)
+{
+#ifdef HAVE_BACK_ARG
+ name`'rtype_qual`_'atype_code (retarray, array, pdim, back);
+#else
+ name`'rtype_qual`_'atype_code (retarray, array, pdim);
+#endif
+}
+
dim = (*pdim) - 1;
rank = GFC_DESCRIPTOR_RANK (array) - 1;
(or "if (mask == NULL)", depending on how this works out.
[Bug c++/87523] New: ICE: Closures apparently fail to capture constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87523
Bug ID: 87523
Summary: ICE: Closures apparently fail to capture constexpr
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: williamtnavarre at mail dot com
Target Milestone: ---
Possibly related to PR 86429?
It's not exactly the same because in this test case there is a failure even
though I'm not even demanding that the compiler necessarily consider the the
captured variable constexpr.
This is the full file below. No #include is required to observe the failing
behavior.
From g++ --version: g++ (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
Command: g++ -std=c++17 inp.cpp
===
template
struct my_integer_constant {
constexpr my_integer_constant() {}
constexpr operator T() const { return v; }
constexpr T operator()() const { return v; }
};
template
struct constant_call {
template
static void call(T v, Callback f) {
char dummy[sizeof...(u)] = { ( (v == u) ? (f(my_integer_constant{}), static_cast(0)) : static_cast(0))... };
(void)dummy;
}
};
void f(bool reverse_in, bool other_bool_in) {
auto helper = [&] (auto reverse_t) {
bool constexpr reverse_v = reverse_t;
(void)reverse_v;
constant_call::call(other_bool_in,
[&] (auto newb) {
bool reverse_v_dyn =
reverse_v;
});
};
constant_call::call(reverse_in, [&] (auto reverse_t) {
helper(reverse_t);
});
}
===
Output includes:
./table/src/inp.cpp:23:57: internal compiler error: in tsubst_copy, at
cp/pt.c:14588
bool reverse_v_dyn =
reverse_v;
^
[Bug fortran/82995] Segmentation fault passing optional argument to intrinsic sum function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82995 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #8 from Thomas Koenig --- Let's give this a shot.
[Bug fortran/82995] Segmentation fault passing optional argument to intrinsic sum function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82995 --- Comment #9 from Thomas Koenig --- Created attachment 44790 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44790&action=edit This should take care of the library side... or so I hope.
[Bug middle-end/87524] New: inconsistent handling of attribute aligned between types and variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87524
Bug ID: 87524
Summary: inconsistent handling of attribute aligned between
types and variables
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
When multiple instances of attribute aligned are applied to the declaration of
a variable the most restrictive instance wins.
But when multiple instances of attribute aligned are applied to the definition
of a type it's the last one that wins.
The attribute should have the same effect on all entities it applies to, i.e.,
functions, types, and variables.
$ cat x.c && gcc -S -Wall -fdump-tree-optimized=/dev/stdout x.c
#define A(N) __attribute__ ((aligned (N)))
void f0 (void)
{
A (2) A(4) char c4;
_Static_assert (_Alignof (c4) == 4, "_Alignof (c4) == 4");
}
void g0 (void)
{
A (4) A (2) char c4;
_Static_assert (_Alignof (c4) == 4, "_Alignof (c4) == 4");
}
void f1 (void)
{
typedef A (2) A (4) char C4;
_Static_assert (_Alignof (C4) == 4, "_Alignof (C4) == 4");
}
void g1 (void)
{
typedef A (4) A (2) char C4;
_Static_assert (_Alignof (C4) == 4, "_Alignof (C4) == 4");
}
x.c: In function ‘g1’:
x.c:25:3: error: static assertion failed: "_Alignof (C4) == 4"
25 | _Static_assert (_Alignof (C4) == 4, "_Alignof (C4) == 4");
| ^~
[Bug libstdc++/87502] Poor code generation for std::string("c-style string")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
--- Comment #3 from Marc Glisse ---
(In reply to M Welinder from comment #2)
> The destruction still stinks: the full destructor is inlined instead of
> the small-string-only version (i.e., a no-op). Evidently gcc cannot
> see that the string remains a small-string.
void foo (const std::string &s){
const_cast(s)="some longer string so it needs proper deletion";
}
[Bug c++/87519] -Wsign-conversion -Wconversion explicit cast fails to silence warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87519
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-10-04
CC||manu at gcc dot gnu.org
Summary|-Wsign-conversion |-Wsign-conversion
|erroneosly triggered when |-Wconversion explicit cast
|converting to auto-deduced |fails to silence warning
|interger type |
Ever confirmed|0 |1
--- Comment #7 from Manuel López-Ibáñez ---
Nothing to do with deduced types:
typedef unsigned long int uint64_t ;
void f(unsigned long int a, int q) {
a = a + static_cast(q);
}
[Bug middle-end/63155] [6/7/8 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155 --- Comment #35 from Rogério de Souza Moraes --- Created attachment 44791 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44791&action=edit Small testcase more similar to original environment Hi Richard, this is a new testcase, based on another file in the original environment. It’s quite small (7000 lines, 240 setjmp calls). This code with a little complex but still simplified control structure represents state machine implementation, which is very widely used by our customers. Another new factor is the nested setjmp calls. Of course, original testcase is more complex and takes even more time with more difference. You can run it using the following commands: time gcc -DGCC -DLINUX_C -D_GLIBCXX_USE_CXX11_ABI=0 -m32 -m32 -w -c -O0 -pedantic -fwrapv -mstackrealign -mpreferred-stack-boundary=4 gcc_2nd_synth_pure_c_item.c -o gcc_2nd_synth_pure_c_item.o time gcc -DGCC -DLINUX_C -D_GLIBCXX_USE_CXX11_ABI=0 -m32 -m32 -w -c -O -pedantic -fwrapv -mstackrealign -mpreferred-stack-boundary=4 gcc_2nd_synth_pure_c_item.c -o gcc_2nd_synth_pure_c_item.o Results : GCC: 4.8.5 (From RHEL 7.5) real0m0.349s user0m0.255s sys 0m0.083s real0m0.193s user0m0.163s sys 0m0.023s GCC: 6.3.0 (GCC 6.3.0 with Revision 264523 backported and applied to it) real0m32.235s user0m30.486s sys 0m1.622s real3m34.203s user3m33.726s sys 0m0.292s The performance difference is relevant in this test. Regards, -- Rogerio
[Bug c/87525] New: infinite loop generated for fread() if enabling -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87525 Bug ID: 87525 Summary: infinite loop generated for fread() if enabling -flto Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: taz.007 at zoho dot com Target Milestone: --- Created attachment 44792 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44792&action=edit screenshot of gdb with asm When trying to compile flac with -flto enabled, it seems to generate an infinite loop when the source code is calling fread(); If i remove the -flto flag, the generated code is no longer an infinite loop. You can find in attachment a screenshot of the gdb screen with the faulty code. Notice the loop at address 0xb7d16980 Also attached output of gcc -v -save-temps
[Bug c/87525] infinite loop generated for fread() if enabling -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87525 --- Comment #1 from taz.007 at zoho dot com --- Created attachment 44793 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44793&action=edit text output of gcc -v -save-temps
[Bug c/87525] infinite loop generated for fread() if enabling -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87525 --- Comment #2 from taz.007 at zoho dot com --- Created attachment 44794 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44794&action=edit preprocessed source
[Bug lto/87525] infinite loop generated for fread() if enabling -flto and -D_FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87525 Andrew Pinski changed: What|Removed |Added Summary|infinite loop generated for |infinite loop generated for |fread() if enabling -flto |fread() if enabling -flto ||and -D_FORTIFY_SOURCE=2 --- Comment #3 from Andrew Pinski --- This smells like a GNU extern inline issue.
