[Bug rtl-optimization/89354] [7 Regression] Combine pass yields wrong code with -O2 and -msse2 for 32bit target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89354 Jakub Jelinek changed: What|Removed |Added Summary|[7/8/9 Regression] Combine |[7 Regression] Combine pass |pass yields wrong code with |yields wrong code with -O2 |-O2 and -msse2 for 32bit|and -msse2 for 32bit target |target | --- Comment #6 from Jakub Jelinek --- Fixed for 8.3+ so far.
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 Jakub Jelinek changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #28 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/89278] ICE in gimplify_modify_expr, at gimplify.c:5821
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89278 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed for 8.3+.
[Bug c/89340] [7/8 Regression] ICE in function_and_variable_visibility, at ipa-visibility.c:707
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89340 Jakub Jelinek changed: What|Removed |Added Summary|[7/8/9 Regression] ICE in |[7/8 Regression] ICE in |function_and_variable_visib |function_and_variable_visib |ility, at |ility, at |ipa-visibility.c:707|ipa-visibility.c:707 --- Comment #6 from Jakub Jelinek --- Fixed on the trunk. Not really sure if this should be backported, for the release branches it might be better to silently ignore the weak flag.
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #27 from Jakub Jelinek --- Author: jakub Date: Fri Feb 15 07:52:50 2019 New Revision: 268930 URL: https://gcc.gnu.org/viewcvs?rev=268930=gcc=rev Log: PR other/69006 PR testsuite/88920 * lib/gcc-dg.exp: If llvm_binutils effective target, set allow_blank_lines to 2 during initialization. (dg-allow-blank-lines-in-output): Set allow_blank_lines to 1 only if it was previously zero. (gcc-dg-prune): Don't check for llvm_binutils effective target here. Clear allow_blank_lines afterwards whenever it was 1. * gdc.test/gdc-test.exp (dmd2dg): Don't call dg-allow-blank-lines-in-output here. (gdc-do-test): Set allow_blank_lines to 3 if it is 0 before running the tests and restore it back at the end. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gdc.test/gdc-test.exp trunk/gcc/testsuite/lib/gcc-dg.exp
[Bug other/69006] [6 Regression] Extraneous newline emitted between error messages in GCC 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69006 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Fri Feb 15 07:52:50 2019 New Revision: 268930 URL: https://gcc.gnu.org/viewcvs?rev=268930=gcc=rev Log: PR other/69006 PR testsuite/88920 * lib/gcc-dg.exp: If llvm_binutils effective target, set allow_blank_lines to 2 during initialization. (dg-allow-blank-lines-in-output): Set allow_blank_lines to 1 only if it was previously zero. (gcc-dg-prune): Don't check for llvm_binutils effective target here. Clear allow_blank_lines afterwards whenever it was 1. * gdc.test/gdc-test.exp (dmd2dg): Don't call dg-allow-blank-lines-in-output here. (gdc-do-test): Set allow_blank_lines to 3 if it is 0 before running the tests and restore it back at the end. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gdc.test/gdc-test.exp trunk/gcc/testsuite/lib/gcc-dg.exp
[Bug other/89342] ICE in maybe_default_option, at opts.c:347
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89342 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.3 --- Comment #4 from Jakub Jelinek --- Fixed for 8.3+.
[Bug tree-optimization/89278] ICE in gimplify_modify_expr, at gimplify.c:5821
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89278 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Fri Feb 15 07:50:26 2019 New Revision: 268928 URL: https://gcc.gnu.org/viewcvs?rev=268928=gcc=rev Log: PR tree-optimization/89278 * tree-loop-distribution.c: Include tree-eh.h. (generate_memset_builtin, generate_memcpy_builtin): Call rewrite_to_non_trapping_overflow on builtin->size before passing it to force_gimple_operand_gsi. * gcc.dg/pr89278.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr89278.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-loop-distribution.c
[Bug target/89355] Unnecessary ENDBR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89355
--- Comment #2 from 刘袋鼠 ---
(In reply to H.J. Lu from comment #0)
> [hjl@gnu-cfl-2 gcc]$ cat x.i
> int
> test (int* val)
> {
> int status = 99;
>
> if((val == 0))
> {
> status = 22;
> goto end;
> }
>
> extern int x;
> *val = x;
>
> status = 0;
> end:
> return status;
> }
>
> [hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S -O2 -fcf-protection x.i
> [hjl@gnu-cfl-2 gcc]$ cat x.s
> .file "x.i"
> .text
> .p2align 4
> .globl test
> .type test, @function
> test:
> .LFB0:
> .cfi_startproc
> endbr64
> testq %rdi, %rdi
> je .L3
> movlx(%rip), %eax
> movl%eax, (%rdi)
> xorl%eax, %eax
> ret
> .p2align 4,,10
> .p2align 3
> .L3:
> .L2:
> endbr64 <<< Why is ENDBR here? There is no indirect branch.
> movl$22, %eax
> ret
> .cfi_endproc
> .LFE0:
> .size test, .-test
> .ident "GCC: (GNU) 9.0.1 20190214 (experimental)"
> .section.note.GNU-stack,"",@progbits
> .section.note.gnu.property,"a"
> .align 8
> .long1f - 0f
> .long4f - 1f
> .long5
> 0:
> .string "GNU"
> 1:
> .align 8
> .long0xc002
> .long3f - 2f
> 2:
> .long0x3
> 3:
> .align 8
> 4:
> [hjl@gnu-cfl-2 gcc]$
I investigate the second endbr64 in the upper case:
for dump x.i.312r.cet
(code_label 24 27 23 4 3 (nil) [1 uses])
(note 23 24 13 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(note 13 23 39 4 ("end") NOTE_INSN_DELETED_LABEL 2)
(insn 39 13 5 4 (unspec_volatile [
(const_int 0 [0])
] UNSPECV_NOP_ENDBR) -1
(nil))
(note 13 23 39 4 ("end") NOTE_INSN_DELETED_LABEL 2)
will enter following branch which emit endbr64
for gcc source code:
if ((LABEL_P (insn) && LABEL_PRESERVE_P (insn))
|| (NOTE_P (insn)
&& NOTE_KIND (insn) == NOTE_INSN_DELETED_LABEL))
/* TODO. Check /s bit also. */
{
cet_eb = gen_nop_endbr ();
emit_insn_after (cet_eb, insn);
continue;
}
Following patch would fix this problem:
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 12bc7926f86..2282816ae19 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -2734,9 +2734,10 @@ rest_of_insert_endbranch (void)
continue;
}
- if ((LABEL_P (insn) && LABEL_PRESERVE_P (insn))
+ if ((LABEL_P (insn)
|| (NOTE_P (insn)
&& NOTE_KIND (insn) == NOTE_INSN_DELETED_LABEL))
+ && LABEL_PRESERVE_P (insn))
/* TODO. Check /s bit also. */
{
cet_eb = gen_nop_endbr ();
[Bug target/89355] Unnecessary ENDBR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89355
--- Comment #1 from 刘袋鼠 ---
(In reply to H.J. Lu from comment #0)
> [hjl@gnu-cfl-2 gcc]$ cat x.i
> int
> test (int* val)
> {
> int status = 99;
>
> if((val == 0))
> {
> status = 22;
> goto end;
> }
>
> extern int x;
> *val = x;
>
> status = 0;
> end:
> return status;
> }
>
> [hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S -O2 -fcf-protection x.i
> [hjl@gnu-cfl-2 gcc]$ cat x.s
> .file "x.i"
> .text
> .p2align 4
> .globl test
> .type test, @function
> test:
> .LFB0:
> .cfi_startproc
> endbr64
> testq %rdi, %rdi
> je .L3
> movlx(%rip), %eax
> movl%eax, (%rdi)
> xorl%eax, %eax
> ret
> .p2align 4,,10
> .p2align 3
> .L3:
> .L2:
> endbr64 <<< Why is ENDBR here? There is no indirect branch.
> movl$22, %eax
> ret
> .cfi_endproc
> .LFE0:
> .size test, .-test
> .ident "GCC: (GNU) 9.0.1 20190214 (experimental)"
> .section.note.GNU-stack,"",@progbits
> .section.note.gnu.property,"a"
> .align 8
> .long1f - 0f
> .long4f - 1f
> .long5
> 0:
> .string "GNU"
> 1:
> .align 8
> .long0xc002
> .long3f - 2f
> 2:
> .long0x3
> 3:
> .align 8
> 4:
> [hjl@gnu-cfl-2 gcc]$
I investigate the second endbr64 in the upper case:
for dump x.i.312r.cet
(code_label 24 27 23 4 3 (nil) [1 uses])
(note 23 24 13 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(note 13 23 39 4 ("end") NOTE_INSN_DELETED_LABEL 2)
(insn 39 13 5 4 (unspec_volatile [
(const_int 0 [0])
] UNSPECV_NOP_ENDBR) -1
(nil))
for gcc source code:
if ((LABEL_P (insn) && LABEL_PRESERVE_P (insn))
|| (NOTE_P (insn)
&& NOTE_KIND (insn) == NOTE_INSN_DELETED_LABEL))
/* TODO. Check /s bit also. */
{
cet_eb = gen_nop_endbr ();
emit_insn_after (cet_eb, insn);
continue;
}
[Bug tree-optimization/89278] ICE in gimplify_modify_expr, at gimplify.c:5821
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89278 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Fri Feb 15 07:39:45 2019 New Revision: 268927 URL: https://gcc.gnu.org/viewcvs?rev=268927=gcc=rev Log: PR tree-optimization/89278 * tree-loop-distribution.c: Include tree-eh.h. (generate_memset_builtin, generate_memcpy_builtin): Call rewrite_to_non_trapping_overflow on builtin->size before passing it to force_gimple_operand_gsi. * gcc.dg/pr89278.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr89278.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-loop-distribution.c
[Bug c/89340] [7/8/9 Regression] ICE in function_and_variable_visibility, at ipa-visibility.c:707
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89340 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Fri Feb 15 07:38:09 2019 New Revision: 268926 URL: https://gcc.gnu.org/viewcvs?rev=268926=gcc=rev Log: PR c/89340 * c-decl.c (start_function): Clear TREE_PUBLIC on nested functions before c_decl_attributes rather than after it. * gcc.dg/pr89340.c: New test. * gcc.dg/torture/pr57036-2.c (jpgDecode_convert): Expect a warning that leaf attribute on nested function is useless. Added: trunk/gcc/testsuite/gcc.dg/pr89340.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/pr57036-2.c
[Bug other/89342] ICE in maybe_default_option, at opts.c:347
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89342 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Fri Feb 15 07:36:23 2019 New Revision: 268925 URL: https://gcc.gnu.org/viewcvs?rev=268925=gcc=rev Log: PR other/89342 * optc-save-gen.awk: Handle optimize_fast like optimize_size or optimize_debug. * opth-gen.awk: Likewise. * gcc.dg/pr89342.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr89342.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/optc-save-gen.awk branches/gcc-8-branch/gcc/opth-gen.awk branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug other/89342] ICE in maybe_default_option, at opts.c:347
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89342 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Fri Feb 15 07:17:24 2019 New Revision: 268924 URL: https://gcc.gnu.org/viewcvs?rev=268924=gcc=rev Log: PR other/89342 * optc-save-gen.awk: Handle optimize_fast like optimize_size or optimize_debug. * opth-gen.awk: Likewise. * gcc.dg/pr89342.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr89342.c Modified: trunk/gcc/ChangeLog trunk/gcc/optc-save-gen.awk trunk/gcc/opth-gen.awk trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/88835] overly aggressive -Werror=format-overflow for printf since r265648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #13 from Eric Gallager --- (In reply to Martin Sebor from comment #10) > I've built the top of binutils-gdb with the patch referenced in comment #8 > applied and with -Wformat-overflow=2 and -Wformat-truncation=2 and got the > following breakdown: > > DiagnosticCount UniqueFiles > -Wformat-overflow= 19 19 10 > -Wformat-truncation= 12 127 > -Wconflicts-sr777 > -Wmaybe-uninitialized 333 > -Wstringop-truncation 222 > -Wconflicts-rr222 > -Wsign-compare111 > -Wother 111 Tangent, but -Wconflicts-sr, -Wconflicts-rr, and -Wother are from bison, not gcc, so you might want to update whatever tool you use to generate these pretty tables to filter them out
[Bug tree-optimization/89350] [9 Regression] Wrong -Wstringop-overflow= warning since r261518
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89350 --- Comment #2 from Eric Gallager --- (In reply to Martin Sebor from comment #1) > > The test case makes the tacit assumption that argc is necessarily > non-negative. That makes sense for the argc argument to main but not in > other situations. Would it be possible to propose an update to the C standard that allows the argc argument to main to be unsigned? Could GCC start accepting unsigned argc as an extension so that -Wmain allows it?
[Bug tree-optimization/85316] [meta-bug] VRP range propagation missed cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 --- Comment #2 from Eric Gallager --- There's probably a lot more bugs that should fall under this meta-bug than currently do; I'll leave finding them all for another day though (or for someone else to do)
[Bug c++/89356] [9 Regression] sorry, unimplemented: mangling implicit_conv_expr in nodejs8 package since r268321
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89356
--- Comment #4 from Marek Polacek ---
reshape_init turns {NON_LVALUE_EXPR <2>} into NON_LVALUE_EXPR <2> and then the
mangled name misses "tlE".
[Bug c++/89356] [9 Regression] sorry, unimplemented: mangling implicit_conv_expr in nodejs8 package since r268321
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89356
--- Comment #3 from Marek Polacek ---
That revision also changes mangling of fn from
decltype (unsigned short{2u}+((int)(3))) fn()
to
decltype ((2u)+((int)(3))) fn()
template
auto fn () -> decltype(unsigned{2u} + (T)3) { return 42; }
template auto fn() -> decltype(unsigned{2u} + (int)3);
[Bug fortran/70149] [F08] Character pointer initialization causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70149 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING --- Comment #13 from Dominique d'Humieres --- > Has this gone away? I seem to have applied what I believe to be > the right patch as fallout from another PR. Any answer to this question?
[Bug go/89168] FAIL: cmd/go/internal/load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89168 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Ian Lance Taylor --- Fixed.
[Bug tree-optimization/88835] overly aggressive -Werror=format-overflow for printf since r265648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835 --- Comment #12 from Mark Wielaard --- (In reply to Martin Sebor from comment #11) > Ah, but you mentioned elfutilts, not binutils. I've now downloaded and > built elfutils-0.175. It took a bit more effort because --disable-werror > doesn't work there but once I got past that I just got the three > -Wformat-truncation instances below: > > DiagnosticCount UniqueFiles > -Wformat-truncation= 332 > > -Wformat-truncation Instances: > /src/elfutils-0.175/src/ar.c:1468 > /src/elfutils-0.175/src/ar.c:859 > /src/elfutils-0.175/src/arlib.c:63 I am not seeing these, but they might have been fixed in git. We like to keep the code warning free since we always build with -Werror. > I'm probably not using the same sources as you, but shouldn't I be seeing at > least some of the warnings? (I couldn't find an easy way build the top of > trunk -- there's no configure script.) I am using git master. git://sourceware.org/git/elfutils.git See the README for build instructions: To build a git checkout do: autoreconf -i -f && \ ./configure --enable-maintainer-mode && \ make && make check Note that the warning/error only occurs on 32bit systems, like these fedora koji arm32 and i686 builds: https://koji.fedoraproject.org/koji/taskinfo?taskID=32816136 To get the same on a 64bit system build with CFLAGS="-g -O2 -m32"
[Bug go/89168] FAIL: cmd/go/internal/load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89168 --- Comment #1 from ian at gcc dot gnu.org --- Author: ian Date: Fri Feb 15 00:36:50 2019 New Revision: 268922 URL: https://gcc.gnu.org/viewcvs?rev=268922=gcc=rev Log: PR go/89168 libgo: change gotest to run examples with output Change the gotest script to act like "go test" and run examples that have "output" comments. This is not done with full generality, but just enough to run the libgo tests. Other packages should be tested with "go test" as usual. While we're here clean up some old bits of gotest, and only run TestXXX functions that are actually in *_test.go files. The latter change should fix https://gcc.gnu.org/PR89168. Reviewed-on: https://go-review.googlesource.com/c/162139 Modified: trunk/gcc/go/gofrontend/MERGE trunk/libgo/go/runtime/example_test.go trunk/libgo/testsuite/gotest
[Bug tree-optimization/88835] overly aggressive -Werror=format-overflow for printf since r265648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835
--- Comment #11 from Martin Sebor ---
Ah, but you mentioned elfutilts, not binutils. I've now downloaded and built
elfutils-0.175. It took a bit more effort because --disable-werror doesn't
work there but once I got past that I just got the three -Wformat-truncation
instances below:
DiagnosticCount UniqueFiles
-Wformat-truncation= 332
-Wformat-truncation Instances:
/src/elfutils-0.175/src/ar.c:1468
/src/elfutils-0.175/src/ar.c:859
/src/elfutils-0.175/src/arlib.c:63
The code at line 10167 in readelf.c looks like this:
static void
print_debug_str_offsets_section (Dwfl_Module *dwflmod __attribute__ ((unused)),
Ebl *ebl,
GElf_Ehdr *ehdr __attribute__ ((unused)),
Elf_Scn *scn, GElf_Shdr *shdr, Dwarf *dbg)
{
printf (gettext ("\
\nDWARF section [%2zu] '%s' at offset %#" PRIx64 ":\n"),
elf_ndxscn (scn), section_name (ebl, shdr),
(uint64_t) shdr->sh_offset);
I'm probably not using the same sources as you, but shouldn't I be seeing at
least some of the warnings? (I couldn't find an easy way build the top of
trunk -- there's no configure script.)
[Bug tree-optimization/88835] overly aggressive -Werror=format-overflow for printf since r265648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835 --- Comment #10 from Martin Sebor --- I've built the top of binutils-gdb with the patch referenced in comment #8 applied and with -Wformat-overflow=2 and -Wformat-truncation=2 and got the following breakdown: DiagnosticCount UniqueFiles -Wformat-overflow= 19 19 10 -Wformat-truncation= 12 127 -Wconflicts-sr777 -Wmaybe-uninitialized 333 -Wstringop-truncation 222 -Wconflicts-rr222 -Wsign-compare111 -Wother 111 The -Wformat-overflow warnings are: /src/binutils-gdb/gas/macro.c:386:18: warning: ‘sprintf’ may write a terminating nul past the end of the destination [-Wformat-overflow=] /src/binutils-gdb/binutils/arsup.c:158:20: warning: ‘%.*s’ directive output between 0 and 2147483647 bytes may exceed minimum required size of 4095 [-Wformat-overflow=] /src/binutils-gdb/binutils/wrstabs.c:426:21: warning: ‘sprintf’ may write a terminating nul past the end of the destination [-Wformat-overflow=] /src/binutils-gdb/binutils/wrstabs.c:739:27: warning: ‘%u’ directive writing between 1 and 10 bytes into a region of size between 7 and 45 [-Wformat-overflow=] /src/binutils-gdb/binutils/wrstabs.c:620:26: warning: ‘%ld’ directive writing between 1 and 20 bytes into a region of size between 19 and 38 [-Wformat-overflow=] /src/binutils-gdb/binutils/wrstabs.c:595:26: warning: ‘%ld’ directive writing between 1 and 20 bytes into a region of size between 19 and 38 [-Wformat-overflow=] eelf_iamcu.c:635:25: warning: ‘%.*s’ directive output between 0 and 2147483647 bytes may exceed minimum required size of 4095 [-Wformat-overflow=] eelf_iamcu.c:628:25: warning: ‘%.*s’ directive output between 0 and 2147483647 bytes may exceed minimum required size of 4095 [-Wformat-overflow=] eelf_x86_64.c:638:25: warning: ‘%.*s’ directive output between 0 and 2147483647 bytes may exceed minimum required size of 4095 [-Wformat-overflow=] eelf_x86_64.c:631:25: warning: ‘%.*s’ directive output between 0 and 2147483647 bytes may exceed minimum required size of 4095 [-Wformat-overflow=] eelf_i386.c:638:25: warning: ‘%.*s’ directive output between 0 and 2147483647 bytes may exceed minimum required size of 4095 [-Wformat-overflow=] eelf_i386.c:631:25: warning: ‘%.*s’ directive output between 0 and 2147483647 bytes may exceed minimum required size of 4095 [-Wformat-overflow=] eelf32_x86_64.c:638:25: warning: ‘%.*s’ directive output between 0 and 2147483647 bytes may exceed minimum required size of 4095 [-Wformat-overflow=] eelf32_x86_64.c:631:25: warning: ‘%.*s’ directive output between 0 and 2147483647 bytes may exceed minimum required size of 4095 [-Wformat-overflow=] eelf_k1om.c:638:25: warning: ‘%.*s’ directive output between 0 and 2147483647 bytes may exceed minimum required size of 4095 [-Wformat-overflow=] eelf_k1om.c:631:25: warning: ‘%.*s’ directive output between 0 and 2147483647 bytes may exceed minimum required size of 4095 [-Wformat-overflow=] eelf_l1om.c:638:25: warning: ‘%.*s’ directive output between 0 and 2147483647 bytes may exceed minimum required size of 4095 [-Wformat-overflow=] eelf_l1om.c:631:25: warning: ‘%.*s’ directive output between 0 and 2147483647 bytes may exceed minimum required size of 4095 [-Wformat-overflow=] /src/binutils-gdb/gdb/gdbserver/remote-utils.c:1188:21: warning: ‘%s’ directive output between 0 and 8191 bytes may exceed minimum required size of 4095 [-Wformat-overflow=] None for readelf.c. I think they are all for sprintf (and not printf or fprintf), so I'm not sure where the ones you are seeing are coming from.
[Bug c++/89356] [9 Regression] sorry, unimplemented: mangling implicit_conv_expr in nodejs8 package since r268321
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89356
--- Comment #2 from Marek Polacek ---
A similar testcase
template auto fn () -> decltype(unsigned{0} + T(1));
auto e = fn();
[Bug tree-optimization/89350] [9 Regression] Wrong -Wstringop-overflow= warning since r261518
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89350 --- Comment #1 from Martin Sebor --- The -Wstringop-overflow warning is a consequence of pointer offsets being treated as unsigned integers, argc being signed, and the object size computation returning scalars rather than ranges. In the first test case (with argc + 0): [local count: 354334802]: _1 = (sizetype) argc_5(D); _2 = -_1; dst_7 = [(void *) + 128B] + _2; src.0_3 = src; __builtin_memcpy (dst_7, src.0_3, _1); When computing the size of dst_7 the compute_objsize() function determines the offset _2 to be in the range [1, SIZE_MAX] and doesn't consider the fact that the upper half of the range represents negative values. As a result, it determines the size to be zero. The number of bytes to write (i.e., (size_t)(argc + 1) is [1, SIZE_MAX]). The test case makes the tacit assumption that argc is necessarily non-negative. That makes sense for the argc argument to main but not in other situations. Changing the if condition to make the assumption explicit 'if (argc > 0)' eliminates the warning. This makes range of the offset [-INT_MAX, -1], and because compute_objsize() doesn't handle negative offsets, it fails to determine the size. There's a comment indicating that is not a feature but a known limitation: /* Ignore negative offsets for now. For others, use the lower bound as the most optimistic estimate of the (remaining)size. */ If I recall I did that not because negative offsets cannot be handled better but to keep the code simple. Either way, with negative offsets handled the warning will not be issued. The missing -Wstringop-overflow in the second test case (with argc + 1): [local count: 354334802]: _1 = (sizetype) argc_7(D); _2 = -_1; dst_9 = [(void *) + 128B] + _2; _3 = argc_7(D) + 1; _4 = (long unsigned int) _3; src.0_5 = src; __builtin_memcpy (dst_9, src.0_5, _4); is due to the number of bytes to write is [0, INT_MAX] so the warning doesn't trigger. The bogus warning can be avoided in the first case simply by punting on offsets that could be in the negative range, but almost certainly not without some false negatives. I'm not sure it's necessarily a good tradeoff (I don't know that it isn't either). Is this code representative of some wide-spread idiom? A more robust solution, one that gets rid of the false positives without as many false negatives, will involve changing compute_objsize() to return a range of sizes rather than a constant. But that will have to wait for GCC 10.
[Bug middle-end/70090] add non-constant variant of __builtin_object_size for _FORTIFY_SOURCE and -fsanitize=object-size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70090 --- Comment #2 from Daniel Micay --- This has now been implemented in Clang as __builtin_dynamic_object_size. There's a thread on the GCC mailing list about it at https://www.mail-archive.com/gcc@gcc.gnu.org/msg87230.html.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 89036, which changed state. Bug 89036 Summary: [8 Regression] ICE if destructor has a requires https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89036 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/89036] [8 Regression] ICE if destructor has a requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89036 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from David Malcolm --- Fixed on gcc-8-branch by r268916; marking as FIXED.
[Bug c++/89036] [8 Regression] ICE if destructor has a requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89036
--- Comment #7 from David Malcolm ---
Author: dmalcolm
Date: Thu Feb 14 23:17:51 2019
New Revision: 268916
URL: https://gcc.gnu.org/viewcvs?rev=268916=gcc=rev
Log:
C++ concepts: fix ICE with requires on dtors (PR c++/89036)
PR c++/89036 reports an ICE due to this assertion failing
1136 /* A class should never have more than one destructor. */
1137 gcc_assert (!current_fns || via_using || !DECL_DESTRUCTOR_P
(method));
on this template with a pair of dtors, with
mutually exclusive "requires" clauses:
template
struct Y {
~Y() requires(true) = default;
~Y() requires(false) {}
};
Nathan introduced this assertion as part of:
ca9219bf18c68a001d62ecb981bc9176b0feaf12 (aka r251340):
2017-08-24 Nathan Sidwell
Conversion operators kept on single overload set
which, amongst other changes to add_method had this:
/* A class should never have more than one destructor. */
- if (current_fns && DECL_MAYBE_IN_CHARGE_DESTRUCTOR_P (method))
-return false;
+ gcc_assert (!current_fns || !DECL_DESTRUCTOR_P (method));
The following patch drops the assertion.
gcc/cp/ChangeLog:
2019-02-13 David Malcolm
Backport of r268847 from trunk.
PR c++/89036
* class.c (add_method): Drop destructor assertion.
gcc/testsuite/ChangeLog:
2019-02-13 David Malcolm
Backport of r268847 from trunk.
PR c++/89036
* g++.dg/concepts/pr89036.C: New test.
Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/concepts/pr89036.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/class.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c++/88795] ICE on class-template argument deduction if non-type parameter has indirection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88795 --- Comment #6 from David Malcolm --- Author: dmalcolm Date: Thu Feb 14 23:14:56 2019 New Revision: 268915 URL: https://gcc.gnu.org/viewcvs?rev=268915=gcc=rev Log: Fix ICE on class-template argument deduction (PR c++/88795) PR c++/88795 reports an ICE building a function_type for a deduction guide when the substitution into the function signature fails, due to an error_mark_node being returned from tsubst_arg_types but not being checked for. This error_mark_node gets used as the TYPE_ARG_TYPES, leading to ICEs in various places that assume this is a TREE_LIST. This patch checks the result of tsubst_arg_types and propagates the failure if it returns error_mark_node. It also adds an assertion to build_function_type, to fail faster if passed in error_mark_node. gcc/cp/ChangeLog: Backport of r267957 from trunk. 2019-01-15 David Malcolm PR c++/88795 * pt.c (build_deduction_guide): Bail out if tsubst_arg_types fails. gcc/testsuite/ChangeLog: Backport of r267957 from trunk. 2019-01-15 David Malcolm PR c++/88795 * g++.dg/template/pr88795.C: New test. gcc/ChangeLog: Backport of r267957 from trunk. 2019-01-15 David Malcolm PR c++/88795 * tree.c (build_function_type): Assert that arg_types is not error_mark_node. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/template/pr88795.C Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/pt.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree.c
[Bug rtl-optimization/89354] [7/8/9 Regression] Combine pass yields wrong code with -O2 and -msse2 for 32bit target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89354 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Thu Feb 14 23:12:26 2019 New Revision: 268914 URL: https://gcc.gnu.org/viewcvs?rev=268914=gcc=rev Log: PR rtl-optimization/89354 * combine.c (make_extraction): Punt if extraction_mode is narrower than len bits. * gcc.dg/pr89354.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr89354.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/combine.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/89354] [7/8/9 Regression] Combine pass yields wrong code with -O2 and -msse2 for 32bit target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89354 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Thu Feb 14 23:10:47 2019 New Revision: 268913 URL: https://gcc.gnu.org/viewcvs?rev=268913=gcc=rev Log: PR rtl-optimization/89354 * combine.c (make_extraction): Punt if extraction_mode is narrower than len bits. * gcc.dg/pr89354.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr89354.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog
[Bug c++/86329] Bogus fix-it hint: note: suggested alternative: '._72'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86329
--- Comment #6 from David Malcolm ---
Author: dmalcolm
Date: Thu Feb 14 23:02:45 2019
New Revision: 268909
URL: https://gcc.gnu.org/viewcvs?rev=268909=gcc=rev
Log:
C++: don't offer bogus "._0" suggestions (PR c++/86329)
PR c++/86329 reports that the C++ frontend can offer bogus suggestions like:
#include
int compare()
{
return __n1 - __n2;
}
suggested.cc: In function 'int compare()':
suggested.cc:5:10: error: '__n1' was not declared in this scope
return __n1 - __n2;
^~~~
suggested.cc:5:10: note: suggested alternative: '._61'
return __n1 - __n2;
^~~~
._61
suggested.cc:5:17: error: '__n2' was not declared in this scope
return __n1 - __n2;
^~~~
suggested.cc:5:17: note: suggested alternative: '._72'
return __n1 - __n2;
^~~~
._72
The dot-prefixed names are an implementation detail of how we implement
anonymous enums found in the header files, generated via
anon_aggrname_format in make_anon_name.
This patch uses anon_aggrname_p to filter them out when considering
which names to suggest.
gcc/cp/ChangeLog:
Backport of r262199 from trunk.
2018-06-27 David Malcolm
PR c++/86329
* name-lookup.c (consider_binding_level): Filter out names that
match anon_aggrname_p.
gcc/testsuite/ChangeLog:
Backport of r262199 from trunk.
2018-06-27 David Malcolm
PR c++/86329
* g++.dg/lookup/pr86329.C: New test.
Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/lookup/pr86329.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/name-lookup.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/89337] Bogus "exceeds maximum object size" on unreachable code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89337
--- Comment #9 from Martin Sebor ---
The warning is very simple: it just looks for excessive sizes in calls emitted
in the optimized IL. When the call is there (either because it's in the source
code as is or because it's been synthesized by GCC based on the invariants it
can infer from the code) it triggers. It runs after all high-level
optimizations, including DCE, and assumes that if the statement is in the IL it
is reachable. Compiling the test case with -fdump-tree-optimized=/dev/stdout
shows the GIMPLE the warning works with:
[local count: 233860936]:
# iftmp.6_113 = PHI
memset (iftmp.6_113, 0, 18446744073709551613);
I think the issue can essentially be reduced to the following:
$ cat z.c && gcc -O2 -S -fdump-tree-optimized=/dev/stdout z.c
void f (char *d, const char *s)
{
if (__builtin_strstr (s, "ABC"))
{
__SIZE_TYPE__ n = __builtin_strlen (s) - 3;
if (n > __builtin_strlen (s)) // cannot be true
__builtin_memset (d, 0, n - __builtin_strlen (s));
}
}
;; Function f (f, funcdef_no=0, decl_uid=1907, cgraph_uid=1, symbol_order=0)
Removing basic block 6
Removing basic block 7
f (char * d, const char * s)
{
char * _1;
long unsigned int _2;
[local count: 1073741824]:
_1 = __builtin_strstr (s_5(D), "ABC");
if (_1 != 0B)
goto ; [70.00%]
else
goto ; [30.00%]
[local count: 751619278]:
_2 = __builtin_strlen (s_5(D));
if (_2 <= 2)
goto ; [33.00%]
else
goto ; [67.00%]
[local count: 248034361]:
__builtin_memset (d_6(D), 0, 18446744073709551613); [tail call]
[local count: 1073741824]:
return;
}
z.c: In function ‘f’:
z.c:8:9: warning: ‘__builtin_memset’ specified size 18446744073709551613
exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
8 | __builtin_memset (d, 0, n - __builtin_strlen (s));
| ^
GCC doesn't have the smarts to figure out that when s contains a substring of
length 3 then strlen(s) must be at least 3. As a result, it doesn't eliminate
the memset call in the function and the warning triggers. Suppose we teach GCC
how to figure this out from the strstr call (which might be a useful
optimization) and then someone comes along with a test case that uses strspn()
instead of strstr(). We can also teach GCC about strstr() but then someone
else might use regcomp() or some user-defined function that we won't have
access to. At some point we'll have to call it good enough.
It's helpful to keep in mind that no control flow or data flow-based warning is
free of false positives (or negatives), either in GCC or in any static
analyzer. Analyzing only provably reachable code would mean not diagnosing
bugs in translation units without main because we cannot prove that they're
ever called. Similarly, at the function level, it would mean not diagnosing
bugs in conditional statements unless the conditions could be proven to be true
at compile time. That would make not only the false positive rate nearly zero,
it would also make the true positive rate nearly zero. In effect, it would make
the diagnostics virtually useless, able to detect only bugs in the simplest
code. If you find a non-zero rate of false positives unacceptable then my
suggestion is to turn warnings off. Not just this one but all others as most
have some false positives, including the front-ends ones that have no notion of
reachability. Otherwise, if you accept that some false positives are
unavoidable and worth the checking GCC does, then until the strstr optimization
above is implemented, I would recommend to make use of __builtin_unreachable():
void trim_asterisk(seastar::sstring ) {
if (name.find("ABC") != seastar::sstring::npos) {
if (name.length () < 3)
__builtin_unreachable ();
name.resize(name.length() - 3);
}
}
Chances are that besides avoiding the warning it will also improve the quality
of the object code. When hidden behind a well-named macro it might also
improve readability.
[Bug c++/85515] Bogus suggestions from "GCC's leaky abstractions"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85515 --- Comment #7 from David Malcolm --- Author: dmalcolm Date: Thu Feb 14 22:57:34 2019 New Revision: 268908 URL: https://gcc.gnu.org/viewcvs?rev=268908=gcc=rev Log: Don't offer suggestions for compiler-generated variables (PR c++/85515) gcc/cp/ChangeLog: Backport of r259720 from trunk. 2018-04-27 David Malcolm PR c++/85515 * name-lookup.c (consider_binding_level): Skip compiler-generated variables. * search.c (lookup_field_fuzzy_info::fuzzy_lookup_field): Flatten nested if statements into a series of rejection tests. Reject lambda-ignored entities as suggestions. gcc/testsuite/ChangeLog: Backport of r259720 from trunk. 2018-04-27 David Malcolm PR c++/85515 * g++.dg/pr85515-1.C: New test. * g++.dg/pr85515-2.C: New test. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/pr85515-1.C branches/gcc-8-branch/gcc/testsuite/g++.dg/pr85515-2.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/name-lookup.c branches/gcc-8-branch/gcc/cp/search.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/88835] overly aggressive -Werror=format-overflow for printf since r265648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835
--- Comment #9 from Mark Wielaard ---
(In reply to Martin Sebor from comment #8)
> The patch I posted for the related pr88993 also relaxes this warning for
> printf and fprintf: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00224.html
>
> Like in the case of pr88993, the warning is by design and (in my view) makes
> sense for sprintf but it's not very useful for the other functions where
> very little code worries about exceeding these limits (or even cares about
> the functions failing as they can for many other reasons).
I tried that patch, but it does not fix this issue. This case now triggers the
following warning, which isn't guarded by is_string_func:
/* The directive output or either causes or may cause the total
length of output to exceed INT_MAX bytes. */
if (likelyximax && fmtres.range.min == fmtres.range.max)
warned = fmtwarn (dirloc, argloc, NULL, info.warnopt (),
"%<%.*s%> directive output of %wu bytes causes "
"result to exceed %", dirlen,
target_to_host (hostdir, sizeof hostdir, dir.beg),
fmtres.range.min);
So with that patch we get:
/home/mark/src/elfutils/src/readelf.c: In function ‘print_debug_str_section’:
/home/mark/src/elfutils/src/readelf.c:10167:15: error: ‘] "’ directive output
of 4 bytes causes result to exceed ‘INT_MAX’ [-Werror=format-overflow=]
10167 | printf (" [%*" PRIx64 "] \"%s\"\n", digits, (uint64_t) offset,
str);
| ^~
/home/mark/src/elfutils/src/readelf.c:10167:30: note: format string is defined
here
10167 | printf (" [%*" PRIx64 "] \"%s\"\n", digits, (uint64_t) offset,
str);
| ^
cc1: all warnings being treated as errors
Which is actually more mysterious than the previous warning (without the patch
as shown in description).
[Bug fortran/89077] ICE using * as len specifier for character parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89077
--- Comment #16 from Harald Anlauf ---
Regarding the unwanted padding with \0, the following patch seems to
solve the issue with transfer.
Index: decl.c
===
--- decl.c (revision 268897)
+++ decl.c (working copy)
@@ -1754,6 +1754,12 @@
free (expr->value.character.string);
expr->value.character.string = s;
expr->value.character.length = len;
+ if (expr->representation.length)
+ {
+ expr->representation.length = 0;
+ free (expr->representation.string);
+ expr->representation.string = NULL;
+ }
}
}
Testcase:
character(8) ,parameter :: s = transfer ('ab', 'cd')
character(8) ,parameter :: t = 2Hxy
print *, "'", s, "'"
print *, "'", t, "'"
end
./a.out | cat -v
'ab '
'xy '
[Bug fortran/88248] [F18] Bogus warning about obsolescent feature: Labeled DO statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88248 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Dominique d'Humieres --- > Fixed. So closing!
[Bug fortran/81552] -finit-integer=n is restricted to 32-bit INTEGER.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81552 Janne Blomqvist changed: What|Removed |Added Status|WAITING |RESOLVED CC||jb at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Janne Blomqvist --- Fixed on trunk, closing. The patch uses strtol() since that is in C89 and thus available everywhere. This close to the GCC 9 release I didn't want to risk breaking some targets I don't have a GCC development environment setup on. strtoll and int64_t are in C99 and with some GCC headers and libiberty they should be available everywhere, which would make this patch work on 32-bit and LLP64 (e.g. win64) targets. If anyone is interested in pursuing this I suggest reopening this bug report and submitting a patch when GCC is in stage 1.
[Bug fortran/81552] -finit-integer=n is restricted to 32-bit INTEGER.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81552 --- Comment #5 from Janne Blomqvist --- Author: jb Date: Thu Feb 14 21:33:29 2019 New Revision: 268906 URL: https://gcc.gnu.org/viewcvs?rev=268906=gcc=rev Log: PR 81552 Improve and document -flag-init-integer Make the option handling code parse the -flag-init-integer value as a C long type, allowing a larger range on systems where long is a larger type than int. Document the behavior. Regtested on x86_64-pc-linux-gnu, committed as obvious. 2019-02-14 Janne Blomqvist PR fortran/81552 * gfortran.h (gfc_option_t): Make flag_init_integer_value a long. * options.c (gfc_handle_option): Use strtol instead of atoi. * invoke.texi: Document -finit-integer behavior in more detail Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/options.c
[Bug go/89321] cross build with riscv64 gccgo compilation failed due to assert in constructor_expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89321 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Ian Lance Taylor --- Should be fixed.
[Bug go/89321] cross build with riscv64 gccgo compilation failed due to assert in constructor_expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89321 --- Comment #7 from ian at gcc dot gnu.org --- Author: ian Date: Thu Feb 14 21:07:13 2019 New Revision: 268904 URL: https://gcc.gnu.org/viewcvs?rev=268904=gcc=rev Log: PR go/89321 compiler: copy has_padding field from converted struct Test case is https://golang.org/cl/162617. Fixes https://gcc.gnu.org/PR89321 Reviewed-on: https://go-review.googlesource.com/c/162618 Modified: trunk/gcc/go/gofrontend/MERGE trunk/gcc/go/gofrontend/types.cc
[Bug lto/89358] Combining -std=c++14 and -std=c++17 objects gives ODR warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-14 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Confirmed. I can't see any difference between std::less in C++14 and C++17, so I have no idea what the ODR violation is supposed to be.
[Bug lto/89358] New: Combining -std=c++14 and -std=c++17 objects gives ODR warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358
Bug ID: 89358
Summary: Combining -std=c++14 and -std=c++17 objects gives ODR
warnings
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
CC: marxin at gcc dot gnu.org
Target Milestone: ---
When object modules compiled with -std=c+14 and -std=c++17 are linked together
with -flto there can be warnings about ODR violations in standard library
headers
Example:
-- main.cpp --
#include
extern void test();
int main()
{
std::map m;
test();
}
-- test.cpp --
#include
void test()
{
std::map m;
}
-- ends --
g++ -flto -std=c++17 -c main.cpp
g++ -flto -std=c++14 -c test.cpp
g++ -flto main.o test.o
-- output --
/usr/share/gcc-trunk/include/c++/9.0.0/bits/stl_function.h:381:12: note: type
'struct less' itself violates the C++ One Definition Rule
381 | struct less : public binary_function<_Tp, _Tp, bool>
|^
/usr/share/gcc-trunk/include/c++/9.0.0/bits/stl_tree.h:684:9: note: type
'struct _Rb_tree_impl' itself violates the C++ One Definition Rule
684 | struct _Rb_tree_impl
| ^
/usr/share/gcc-trunk/include/c++/9.0.0/bits/stl_map.h:100:11: note: type
'struct _Rep_type' itself violates the C++ One Definition Rule
100 | class map
| ^
With gcc trunk from 2019-01-19 on Cygwin.
Almost identical messages appear on RHEL with devtools-7 and with gcc 7.30 on
WSL
[Bug fortran/88248] [F18] Bogus warning about obsolescent feature: Labeled DO statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88248 --- Comment #9 from Harald Anlauf --- Fixed.
[Bug fortran/88248] [F18] Bogus warning about obsolescent feature: Labeled DO statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88248 --- Comment #8 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Thu Feb 14 20:24:54 2019 New Revision: 268895 URL: https://gcc.gnu.org/viewcvs?rev=268895=gcc=rev Log: 2019-02-14 Harald Anlauf PR fortran/88248 * symbol.c: Move check for labeled DO statement from gfc_define_st_label to gfc_reference_st_label. PR fortran/88248 * gfortran.dg/pr88248.f90: New test. * gfortran.dg/f2018_obs.f90: Updated test. Added: trunk/gcc/testsuite/gfortran.dg/pr88248.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/f2018_obs.f90
[Bug rtl-optimization/85805] [7/8 Regression] Wrong code for 64 bit comparisons on avr-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85805 --- Comment #14 from Segher Boessenkool --- I backported it anyway.
[Bug target/88892] [8 Regression] Double-to-float conversion uses wrong rounding mode when followed by memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #17 from Segher Boessenkool --- Fixed on trunk and for 8.3.
[Bug fortran/71880] pointer to allocatable character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71880 Dominique d'Humieres changed: What|Removed |Added CC||clange001 at gmail dot com --- Comment #12 from Dominique d'Humieres --- *** Bug 89352 has been marked as a duplicate of this bug. ***
[Bug fortran/68241] [meta-bug] [F03] Deferred-length character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 Bug 68241 depends on bug 89352, which changed state. Bug 89352 Summary: Deferred length character array pointer error https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89352 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug fortran/89352] Deferred length character array pointer error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89352 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||pault at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Dominique d'Humieres --- I think it is a duplicate of pr71880. I don't know how to read Paul's comment: > I am trying to build up the intestinal fortitude to go back through > some of the recent fixes and apply them to 8-branch. *** This bug has been marked as a duplicate of bug 71880 ***
[Bug ada/89349] raised STORAGE_ERROR : stack overflow or erroneous memory access when building GCC 8 branch with GCC master
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89349 --- Comment #6 from Eric Botcazou --- > My reproducer described in the first comment was: > 1) build gcc trunk w/o bootstrap and install it > 2) use the compiler and build gcc-8 branch w/o bootstrap > 3) Ada FE is successfully built, but Ada runtime build fails (with gcc-8 Ada > FE) Sure, but the question is what happens if remove --disable-bootstrap from the configure line you posted?
[Bug target/87149] ICE in extract_insn, at recog.c:2305 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87149 --- Comment #13 from Segher Boessenkool --- Author: segher Date: Thu Feb 14 19:03:54 2019 New Revision: 268890 URL: https://gcc.gnu.org/viewcvs?rev=268890=gcc=rev Log: Backport from trunk 2018-08-31 Segher Boessenkool PR target/86684 PR target/87149 * config/rs6000/rs6000.md (lrounddi2): Gate on TARGET_FPRND. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/rs6000/rs6000.md
[Bug target/86684] ICE in extract_insn, at recog.c:2304 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86684 --- Comment #15 from Segher Boessenkool --- Author: segher Date: Thu Feb 14 19:03:54 2019 New Revision: 268890 URL: https://gcc.gnu.org/viewcvs?rev=268890=gcc=rev Log: Backport from trunk 2018-08-31 Segher Boessenkool PR target/86684 PR target/87149 * config/rs6000/rs6000.md (lrounddi2): Gate on TARGET_FPRND. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/rs6000/rs6000.md
[Bug target/88892] [8 Regression] Double-to-float conversion uses wrong rounding mode when followed by memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892 --- Comment #16 from Segher Boessenkool --- Author: segher Date: Thu Feb 14 18:57:54 2019 New Revision: 268889 URL: https://gcc.gnu.org/viewcvs?rev=268889=gcc=rev Log: Backport from trunk 2019-01-18 Segher Boessenkool PR target/88892 * config/rs6000/rs6000.md (*movsi_from_df): Allow only register operands. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/rs6000/rs6000.md
[Bug target/88145] ICE: unrecognizable insn (mffs) targeting 32-bit BE FPU-less powerpc CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88145 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||segher at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Segher Boessenkool --- This doesn't backport to 8. Closing as fixed.
[Bug rtl-optimization/85805] [7/8 Regression] Wrong code for 64 bit comparisons on avr-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85805 --- Comment #13 from Segher Boessenkool --- Author: segher Date: Thu Feb 14 18:46:18 2019 New Revision: 26 URL: https://gcc.gnu.org/viewcvs?rev=26=gcc=rev Log: Backport from trunk 2018-07-26 Segher Boessenkool PR rtl-optimization/85805 * combine.c (reg_nonzero_bits_for_combine): Only use the last set value for hard registers if that was written in the same mode. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/combine.c
[Bug rtl-optimization/89313] [9 Regression] ICE in process_alt_operands, at lra-constraints.c:2962
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89313
--- Comment #5 from Peter Bergner ---
I'm testing a patch that gives a better error message and eliminates the ICE:
[bergner@dagger1 PR89313]$ cat pr89313.i
long f;
long g (void)
{
register long z asm ("rax");
asm ("foo %0, %1, %2" : "=" (z) : "r" (f), "0" (f));
return z;
}
[bergner@dagger1 PR89313]$
/home/bergner/gcc/build/gcc-fsf-mainline-pr89313-debug/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-pr89313-debug/gcc -O2 -S pr89313.i
pr89313.i: In function ‘g’:
pr89313.i:5:3: error: incompatible constraint usage for input operands when
paired with an early clobber operand
5 | asm ("foo %0, %1, %2" : "=" (z) : "r" (f), "0" (f));
| ^~~
[bergner@dagger1 PR89313]$
[Bug ada/89349] raised STORAGE_ERROR : stack overflow or erroneous memory access when building GCC 8 branch with GCC master
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89349 --- Comment #5 from Martin Liška --- (In reply to Eric Botcazou from comment #2) > What happens without --disable-bootstrap? My reproducer described in the first comment was: 1) build gcc trunk w/o bootstrap and install it 2) use the compiler and build gcc-8 branch w/o bootstrap 3) Ada FE is successfully built, but Ada runtime build fails (with gcc-8 Ada FE)
[Bug ada/89349] raised STORAGE_ERROR : stack overflow or erroneous memory access when building GCC 8 branch with GCC master
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89349 --- Comment #4 from Martin Liška --- (In reply to Jakub Jelinek from comment #3) > I thought that typically you can't build older gcc with newer gcc when using > ada, at least I remember seeing issues with gcc 7 built with gcc 8 too when > ada is enabled. In openSUSE, we currently build gcc7 with gcc8 and it's fine: https://build.opensuse.org/package/show/devel:gcc/gcc7 I saw failing gcc8 package being built with gcc9. Note that the gcc8 package is using normal bootstrap.
[Bug fortran/89352] Deferred length character array pointer error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89352 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- The code works as expected with gfortran from trunk. Whether the patch that fixed the bud will be back ported remains to be detemined.
[Bug d/87864] libdruntime doesn't link with /bin/ld before Solaris 11.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87864 Rainer Orth changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Rainer Orth --- Fixed for GCC 9.1.
[Bug c++/78147] The -Wshadow warning is too aggressive with constructor parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78147 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=72789 --- Comment #4 from Eric Gallager --- (In reply to Martin Sebor from comment #1) > Confirmed. Paul, please post your patch to gcc-patches. Personally, I > think providing it under Clang's -Wunused-private-field for compatibility > would be preferable to disabling the warning altogether. > For reference, the bug to add -Wunused-private-field is bug 72789, btw.
[Bug d/87864] libdruntime doesn't link with /bin/ld before Solaris 11.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87864
--- Comment #10 from Rainer Orth ---
Author: ro
Date: Thu Feb 14 17:47:49 2019
New Revision: 268886
URL: https://gcc.gnu.org/viewcvs?rev=268886=gcc=rev
Log:
Provide __start_minfo/__stop_minfo for linkers that don't (PR d/87864)
libphobos:
PR d/87864
* configure.ac (DRTSTUFF_SPEC): New variable.
Substitute it.
* libdruntime/m4/druntime/os.m4 (DRUNTIME_OS_MINFO_BRACKETING):
New automake conditional.
* configure: Regenerate.
* libdruntime/gcc/drtstuff.c: New file.
* libdruntime/Makefile.am [!DRUNTIME_OS_MINFO_BRACKETING]
(DRTSTUFF, toolexeclib_DATA): New variables.
(gcc/drtbegin.lo, gcc/drtend.lo): New rules.
(libgdruntime_la_LDFLAGS): Use -Wc instead of -Xcompiler.
Add -dstartfiles -B../src -Bgcc.
(libgdruntime_la_DEPENDENCIES): New variable.
(unittest_static_LDFLAGS): Use -Wc instead of -Xcompiler.
(libgdruntime_t_la_LDFLAGS): Likewise.
(unittest_LDFLAGS): Likewise.
* src/Makefile.am (libgphobos_la_LDFLAGS): Use -Wc instead of
-Xcompiler.
Add -dstartfiles -B../libdruntime/gcc.
(unittest_static_LDFLAGS): Use -Wc instead of -Xcompiler.
(libgphobos_t_la_LDFLAGS): Likewise.
(unittest_LDFLAGS): Likewise.
* libdruntime/Makefile.in, src/Makefile.in: Regenerate.
* Makefile.in, testsuite/Makefile.in: Regenerate.
* libdruntime/rt/sections_elf_shared.d (Minfo_Bracketing): Don't
assert.
* libdruntime/gcc/config.d.in (Minfo_Bracketing): Remove.
* src/drtstuff.spec: New file.
* src/libgphobos.spec.in (DRTSTUFF_SPEC): Substitute.
(*lib): Only pass SPEC_PHOBOS_DEPS without -debuglib, -defaultlib,
-nophoboslib.
* testsuite/testsuite_flags.in <--gdcldflags> (GDCLDFLAGS): Add
-B${BUILD_DIR}/libdruntime/gcc.
gcc/d:
PR d/87864
* lang.opt (dstartfiles): New option.
* d-spec.cc (need_spec): New variable.
(lang_specific_driver) : Enable need_spec.
(lang_specific_pre_link): Also load libgphobos.spec if need_spec.
gcc/testsuite:
PR d/87864
* lib/gdc.exp (gdc_link_flags): Add path to drtbegin.o/drtend.o if
present.
Added:
trunk/libphobos/libdruntime/gcc/drtstuff.c
trunk/libphobos/src/drtstuff.spec
Modified:
trunk/gcc/d/ChangeLog
trunk/gcc/d/d-spec.cc
trunk/gcc/d/lang.opt
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/gdc.exp
trunk/libphobos/ChangeLog
trunk/libphobos/configure (contents, props changed)
trunk/libphobos/configure.ac
trunk/libphobos/libdruntime/Makefile.am
trunk/libphobos/libdruntime/Makefile.in
trunk/libphobos/libdruntime/gcc/config.d.in
trunk/libphobos/libdruntime/rt/sections_elf_shared.d
trunk/libphobos/m4/druntime/os.m4
trunk/libphobos/src/Makefile.am
trunk/libphobos/src/Makefile.in
trunk/libphobos/src/libgphobos.spec.in
trunk/libphobos/testsuite/testsuite_flags.in (contents, props changed)
[Bug middle-end/89337] Bogus "exceeds maximum object size" on unreachable code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89337 Rafael Avila de Espindola changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE |--- --- Comment #8 from Rafael Avila de Espindola --- The previous testcase passes on trunk, but the original doesn't. The original has a "if (boost::algorithm::ends_with(name, "%2A"))" instead of a direct "if(name.size() > 3)". The reduced testcase uses a find to avoid boost::algorithm and keep the testcase size sane. In the end it seems that gcc is doing an heroic effort to understand the code and issue an warning if it can't prove that the bogus memset is not reached. I don't think that is workable in practice (for sure not in theory): There is always something that is obvious to the developer but not to gcc. IMHO gcc should be issuing warnings only when it shows that a statement can be reached, not when it fails to show the statement cannot be reached.
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 89337, which changed state. Bug 89337 Summary: Bogus "exceeds maximum object size" on unreachable code https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89337 What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE |---
[Bug sanitizer/89308] [8 only] The sanitizers do no longer work on GCC 8 with newer kernels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89308 --- Comment #8 from seurer at gcc dot gnu.org --- This is the way it came from upstream (llvm) and the solution for powerpc64 was copied from what aarch64 did before. What is really needed is a workable solution from whoever does sanitizer development that works despite the huge ranges of addresses that ASLR now uses.
[Bug middle-end/89337] Bogus "exceeds maximum object size" on unreachable code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89337 Rafael Avila de Espindola changed: What|Removed |Added Attachment #45710|0 |1 is obsolete|| --- Comment #7 from Rafael Avila de Espindola --- Created attachment 45726 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45726=edit testcase that fails on trunk
[Bug ipa/89330] IPA inliner touches released cgraph_edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89330 --- Comment #5 from Jan Hubicka --- > Let me see if I can add the respective usefulness test to the code > deciding to speculate. I see, it is mine, sorry for blaming you :) One alternative would be also to put the indirect part of pseculative edge to the vector and lookup the direct one if speculation survives. But checking prior creation should work too. Thanks for looking into this!
[Bug sanitizer/89308] [8 only] The sanitizers do no longer work on GCC 8 with newer kernels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89308 --- Comment #7 from Jakub Jelinek --- Still, a reexec is costly and might break some programs. If the ASLR makes problems only sometimes, it might be better to try to map stuff it wants and if that fails, before reporting failure try this CheckASLR.
[Bug target/88850] [9 Regression] Hard register coming out of expand causing reload to fail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88850 --- Comment #11 from Tamar Christina --- Author: tnfchris Date: Thu Feb 14 17:17:20 2019 New Revision: 268884 URL: https://gcc.gnu.org/viewcvs?rev=268884=gcc=rev Log: Arm: Add HF modes to ANY iterators The iterator ANY64 are used in various general split patterns and is supposed to contain all 64 bit modes. For some reason the pattern has HI but not HF. This adds HF so that general 64 bit splits are generated for these modes as well. These are required by various split patterns that expect them to be there. gcc/ChangeLog: PR target/88850 * config/arm/iterators.md (ANY64): Add V4HF. gcc/testsuite/ChangeLog: PR target/88850 * gcc.target/arm/pr88850-2.c: New test. * lib/target-supports.exp (check_effective_target_arm_neon_softfp_fp16_ok_nocache, check_effective_target_arm_neon_softfp_fp16_ok, add_options_for_arm_neon_softfp_fp16): New. Added: trunk/gcc/testsuite/gcc.target/arm/pr88850-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/iterators.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-supports.exp
[Bug sanitizer/89308] [8 only] The sanitizers do no longer work on GCC 8 with newer kernels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89308 --- Comment #6 from seurer at gcc dot gnu.org --- I think it only comes out if you specify the verbose sanitizer option on the compilation. If I can remember how to specify that I will try it.
[Bug ada/89349] raised STORAGE_ERROR : stack overflow or erroneous memory access when building GCC 8 branch with GCC master
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89349 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- I thought that typically you can't build older gcc with newer gcc when using ada, at least I remember seeing issues with gcc 7 built with gcc 8 too when ada is enabled.
[Bug ipa/89330] IPA inliner touches released cgraph_edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89330 Martin Jambor changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #4 from Martin Jambor --- The indirect inlining thingy was indeed written by me, that is true, but that was before speculative inlining was creating and disposing of edges at difficult to predict times. What happens is that: 1. In the course of inlining an edge, we call ipa_propagate_indirect_call_infos to adjust jump functions and to add newly discovered direct edges to new_edges vector so that they can be added to the heap later. 2. The speculation code in try_make_edge_direct_virtual_call decides to create speculation, so a new speculative edge is created and added to the vector. 3. Immediately after calling ipa_propagate_indirect_call_infos, check_speculations is called, which finds the edge !speculation_useful_p and removes it. But the edge already is in the vector. Let me see if I can add the respective usefulness test to the code deciding to speculate.
[Bug sanitizer/89308] [8 only] The sanitizers do no longer work on GCC 8 with newer kernels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89308 --- Comment #5 from Jakub Jelinek --- Ugh, does this mean if ASLR is enabled you get "WARNING: Program is being run with address space layout " "randomization (ASLR) enabled which prevents the thread and " "memory sanitizers from working on powerpc64le.\n" "ASLR will be disabled and the program re-executed.\n" message from every -fsanitize=address/-fsanitize=thread linked program? If so, that is extremely nasty. Couldn't that be done only if you determine the areas you need to mmap the shadow etc. memory can't be mapped? Of course, that applies to trunk as well as possible backport.
[Bug sanitizer/89308] [8 only] The sanitizers do no longer work on GCC 8 with newer kernels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89308 --- Comment #4 from seurer at gcc dot gnu.org --- The above patch pulls in just enough of the changes from trunk to disable ASLR for powerpc64 while leaving things alone for everyone else.
[Bug sanitizer/89308] [8 only] The sanitizers do no longer work on GCC 8 with newer kernels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89308 --- Comment #3 from seurer at gcc dot gnu.org --- Created attachment 45725 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45725=edit Patch to disable ALSR for asan/tsan on powerpc64
[Bug rtl-optimization/89354] [7/8/9 Regression] Combine pass yields wrong code with -O2 and -msse2 for 32bit target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89354 --- Comment #3 from Jakub Jelinek --- Created attachment 45724 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45724=edit gcc9-pr89354.patch Untested fix. I think the bug is in make_extraction, which for VOIDmode, (mem:DI ...), 0, NULL_RTX, 33, 1, 1, 0 arguments returns strangely (for 32-bit target) (zero_extract:SI (mem:DI ...) (const_int 33) (const_int 0)). That looks bogus to me, because those 33 bits can't fit into SImode. Then make_field_assignment does: assign = make_extraction (VOIDmode, dest, pos, NULL_RTX, len, 1, 1, 0); if (assign == 0) return x; machine_mode new_mode = (GET_CODE (assign) == STRICT_LOW_PART ? GET_MODE (XEXP (assign, 0)) : GET_MODE (assign)); which sets new_mode to SImode too, and src = canon_reg_for_combine (simplify_shift_const (NULL_RTX, LSHIFTRT, src_mode, other, pos), dest); src = force_to_mode (src, new_mode, len >= HOST_BITS_PER_WIDE_INT ? HOST_WIDE_INT_M1U : (HOST_WIDE_INT_1U << len) - 1, 0); other is (const_int 0x1) and as pos is 0, the first call just returns the same constant, but force_to_mode turns it into const0_rtx, which is where we lose the |= 0x1ULL.
[Bug ada/89349] raised STORAGE_ERROR : stack overflow or erroneous memory access when building GCC 8 branch with GCC master
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89349 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-02-14 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Eric Botcazou --- What happens without --disable-bootstrap?
[Bug target/89357] New: alignas for automatic variables with alignment greater than 16 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89357
Bug ID: 89357
Summary: alignas for automatic variables with alignment greater
than 16 fails
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kretz at kde dot org
Target Milestone: ---
Target: aarch64-*-*, arm-*-*
Test case (cf. https://godbolt.org/z/ubJge4):
void g(int &);
auto f0() {
__attribute__((aligned(128))) int x;
g(x);
}
auto f1() {
alignas(128) int x;
g(x);
}
In f0, x is aligned on 128 Bytes, in f1 it is aligned on 16 Bytes. GCC emits
the warning "requested alignment 128 is larger than 16 [-Wattributes]". The
warning is not helpful as it only states an obvious fact (128 > 16). In any
case, it is unclear why the alignment is rejected in the first place.
http://eel.is/c++draft/dcl.align#2.2 says "[...] the implementation does not
support that alignment in the context of the declaration, the program is
ill-formed". Thus, compiling with alignment of 16 is non-conforming. If the
alignment is unsupported this needs to be a error.
My preferred solution would be to just align x in f1 to 128 Bytes. Why should
alignas and the aligned attribute behave differently?
On x86, power, mips, and msp430 (tested on Compiler Explorer) f0 and f1 are
equivalent.
[Bug lto/89335] [9 Regression] ICE with LTO -Wsuggest-final-methods: ICE during IPA pass devirt in types_same_for_odr, at ipa-devirt.c:391
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89335 Jan Hubicka changed: What|Removed |Added Depends on||87089 --- Comment #2 from Jan Hubicka --- I think it is also caused by fact that the virtual destructor has no DECL_VIRTUAL flag. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87089 [Bug 87089] [9 regression] tree check: expected class 'type', have 'declaration' (namespace_decl) in type_with_linkage_p, at ipa-utils.h
[Bug c/89341] [7/8/9 Regression] ICE in get, at cgraph.h:1332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89341
--- Comment #5 from David Malcolm ---
Both decls of "foo" are using the same FUNCTION_DECL.
node->alias is set in varasm.c: assemble_alias here:
5991cgraph_node::get_create (decl)->alias = true;
when processing the second decl of "foo" here:
void foo ();
since the FUNCTION_DECL for "foo" has an "alias" attribute, given to it by
handle_weakref_attribute when parsing the first decl of here:
__attribute__((weakref("bar")))
static void foo () { }
[Bug rtl-optimization/89354] [7/8/9 Regression] Combine pass yields wrong code with -O2 and -msse2 for 32bit target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89354 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
[Bug c++/89356] [9 Regression] sorry, unimplemented: mangling implicit_conv_expr in nodejs8 package since r268321
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89356 Marek Polacek changed: What|Removed |Added Priority|P3 |P1
[Bug c++/89356] [9 Regression] sorry, unimplemented: mangling implicit_conv_expr in nodejs8 package since r268321
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89356 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Amusingly, we already handle 3440 /* Strip a conversion added by convert_nontype_argument. */ 3441 if (TREE_CODE (node) == IMPLICIT_CONV_EXPR) 3442 node = TREE_OPERAND (node, 0); in write_template_arg.
[Bug c/89341] [7/8/9 Regression] ICE in get, at cgraph.h:1332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89341
--- Comment #4 from David Malcolm ---
The -Wattributes warning would be emitted here in cgraphunit.c:
process_function_and_variable_attributes:
777 if (lookup_attribute ("weakref", DECL_ATTRIBUTES (decl))
778 && (node->definition && !node->alias))
779 {
780 warning_at (DECL_SOURCE_LOCATION (node->decl),
OPT_Wattributes,
781 "% attribute ignored"
782 " because function is defined");
783 DECL_WEAK (decl) = 0;
784 DECL_ATTRIBUTES (decl) = remove_attribute ("weakref",
785 DECL_ATTRIBUTES
(decl));
786 }
but the alias stops the clause from firing:
(gdb) p node
$3 =
(gdb) p node->definition
$4 = 1
(gdb) p node->alias
$5 = 1
The alias exclusion was added to the warning in r174952 (aka
c70f46b057cd12973d33c01c8fa0da5c14ba3944) by Honza:
@@ -880,7 +977,7 @@ process_function_and_variable_attributes (struct
cgraph_node *first,
cgraph_mark_needed_node (node);
}
if (lookup_attribute ("weakref", DECL_ATTRIBUTES (decl))
- && node->local.finalized)
+ && (node->local.finalized && !node->alias))
{
warning_at (DECL_SOURCE_LOCATION (node->decl), OPT_Wattributes,
"% attribute ignored"
[Bug c++/89356] [9 Regression] sorry, unimplemented: mangling implicit_conv_expr in nodejs8 package since r268321
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89356 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||8.2.0 Keywords||ice-on-valid-code Last reconfirmed||2019-02-14 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |9.0 Known to fail||9.0
[Bug c++/89356] New: [9 Regression] sorry, unimplemented: mangling implicit_conv_expr in nodejs8 package since r268321
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89356
Bug ID: 89356
Summary: [9 Regression] sorry, unimplemented: mangling
implicit_conv_expr in nodejs8 package since r268321
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Starting from the revision I see:
$ cat sorry.ii
typedef unsigned a;
template struct h {};
template auto c(b f) -> h;
typedef char byte;
enum d : byte;
d g(byte);
h e = c<6>(g);
$ g++ sorry.ii -c
sorry.ii: In instantiation of ‘h c(b) [with
int = 6; b = d (*)(char)]’:
sorry.ii:3:30: sorry, unimplemented: mangling implicit_conv_expr
3 | template auto c(b f) -> h;
|
[Bug rtl-optimization/89354] [7/8/9 Regression] Combine pass yields wrong code with -O2 and -msse2 for 32bit target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89354 --- Comment #2 from Jakub Jelinek --- -mno-stv also cures it.
[Bug rtl-optimization/89354] [7/8/9 Regression] Combine pass yields wrong code with -O2 and -msse2 for 32bit target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89354
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-02-14
CC||jakub at gcc dot gnu.org
Target Milestone|--- |7.5
Summary|Combine pass yields wrong |[7/8/9 Regression] Combine
|code with -O2 and -msse2|pass yields wrong code with
|for 32bit target|-O2 and -msse2 for 32bit
||target
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Started with r228231, will have a look.
Slightly simplified testcase:
static unsigned long long q = 0;
__attribute__((noipa)) static void
bar (void)
{
q = (q & ~0x1ULL) | 0x1ULL;
}
int
main ()
{
__asm volatile ("" : "+m" (q));
bar ();
if (q != 0x1ULL)
__builtin_abort ();
return 0;
}
[Bug lto/88677] [9 Regression] Divergence in -O2 and -O2 -flto early opts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88677 Jan Hubicka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Jan Hubicka --- Fixed.
[Bug lto/88677] [9 Regression] Divergence in -O2 and -O2 -flto early opts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88677 --- Comment #16 from Jan Hubicka --- Author: hubicka Date: Thu Feb 14 14:49:03 2019 New Revision: 268880 URL: https://gcc.gnu.org/viewcvs?rev=268880=gcc=rev Log: PR lto/88677 Fix PR number. Modified: trunk/gcc/ChangeLog
[Bug target/89355] New: Unnecessary ENDBR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89355
Bug ID: 89355
Summary: Unnecessary ENDBR
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: crazylht at gmail dot com, xuepeng.guo at intel dot com
Target Milestone: ---
Target: i386,x86-64
[hjl@gnu-cfl-2 gcc]$ cat x.i
int
test (int* val)
{
int status = 99;
if((val == 0))
{
status = 22;
goto end;
}
extern int x;
*val = x;
status = 0;
end:
return status;
}
[hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S -O2 -fcf-protection x.i
[hjl@gnu-cfl-2 gcc]$ cat x.s
.file "x.i"
.text
.p2align 4
.globl test
.type test, @function
test:
.LFB0:
.cfi_startproc
endbr64
testq %rdi, %rdi
je .L3
movlx(%rip), %eax
movl%eax, (%rdi)
xorl%eax, %eax
ret
.p2align 4,,10
.p2align 3
.L3:
.L2:
endbr64 <<< Why is ENDBR here? There is no indirect branch.
movl$22, %eax
ret
.cfi_endproc
.LFE0:
.size test, .-test
.ident "GCC: (GNU) 9.0.1 20190214 (experimental)"
.section.note.GNU-stack,"",@progbits
.section.note.gnu.property,"a"
.align 8
.long1f - 0f
.long4f - 1f
.long5
0:
.string "GNU"
1:
.align 8
.long0xc002
.long3f - 2f
2:
.long0x3
3:
.align 8
4:
[hjl@gnu-cfl-2 gcc]$
[Bug gcov-profile/89307] -fprofile-generate binary may be too slow in multithreaded environment due to cache-line conflicts on counters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89307 --- Comment #6 from Jan Hubicka --- > Ah now, it's really doing sampling. I guess it can lead to quite some profile > inconsistencies.. Yep, it is not coolest solution. I would not worry too much about precision loss unless you get some weird interference between the sampling counter and actual program behaviour. Adding conditionals everywhere is not very good and I am not sure how well CPU will predict such branches. Honza
[Bug fortran/72715] ICE in gfc_trans_omp_do, at fortran/trans-openmp.c:3164
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72715 Thomas Schwinge changed: What|Removed |Added Keywords|ice-on-invalid-code, openmp |openacc Status|NEW |ASSIGNED Last reconfirmed|2016-07-27 00:00:00 |2019-2-14 CC||burnus at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot gnu.org --- Comment #5 from Thomas Schwinge --- Thanks for the report (Gerhard), and patch (Cesar); ICE addressed in trunk r268875, like done for OpenMP in PR60127, trunk r210331.
[Bug rtl-optimization/89354] New: Combine pass yields wrong code with -O2 and -msse2 for 32bit target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89354
Bug ID: 89354
Summary: Combine pass yields wrong code with -O2 and -msse2 for
32bit target
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: d.sukhonin at gmail dot com
Target Milestone: ---
Created attachment 45723
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45723=edit
Proposed patch for gcc 6.3 including a test
There is a problem with compiling this code (options -O2 -msse2 -m32):
$ gcc-6 -m32 -O2 -msse2 /src/gcc/gcc/testsuite/gcc.target/i386/sse2-extz_di.c
&& ./a.out
Aborted
#define BIT33 0x1ULL
#include
static uint64_t const MASK33 = (1ULL << 33) - 1;
static uint64_t qword = 0;
static uint64_t
get_low33 (void)
{
return qword & MASK33;
}
static void
__attribute__((noinline))
set_bit33 (void)
{
qword = (qword & ~MASK33) | BIT33;
}
static void
main (int, char**)
{
set_bit33 ();
if (get_low33 () != BIT33))
abort ();
}
Investigation showed, that during combine pass for set_bit33 function wrong RTL
is yielded: the second operand of ior is truncated into dword, i.e. 0, and the
bit 33 is never switched on.
I have a fix attached. It does not allow narrowing while matching zero_extract
insn.
That is, before the fix the optimizer was dealing with this RTL inst (Note,
zero_extract:SI):
Trying 5, 6, 7 -> 8:
Failed to match this instruction:
(set (zero_extract:SI (mem/c:DI (plus:SI (reg:SI 87)
(const:SI (unspec:SI [
(symbol_ref:SI ("qword") [flags 0x2] )
] UNSPEC_GOTOFF))) [3 qword+0 S8 A64])
(const_int 33 [0x21])
(const_int 0 [0]))
(const_int 0 [0]))
Now zero_extract has DI mode because the inner instruction mem has larger, DI,
mode size:
Trying 5, 6, 7 -> 8:
Failed to match this instruction:
(set (zero_extract:DI (mem/c:DI (symbol_ref:SI ("qword") [flags 0x2] ) [3 qword+0 S8 A64])
(const_int 33 [0x21])
(const_int 0 [0]))
(const_int 4294967296 [0x1]))
References:
* get_best_reg_extraction_insn is called here
https://github.com/gcc-mirror/gcc/blob/master/gcc/combine.c#L7819
* zero_extract is tried out
https://github.com/gcc-mirror/gcc/blob/master/gcc/combine.c#L7983
$ gcc-6 -v
Using built-in specs.
COLLECT_GCC=gcc-6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18+deb9u1'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
It is reproduced on all versions >= 6.3.
I didn't test on older ones.
[Bug rtl-optimization/89242] [7/8 Regression] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 7 should be 5, not 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89242 --- Comment #5 from Martin Liška --- Author: marxin Date: Thu Feb 14 13:57:52 2019 New Revision: 268876 URL: https://gcc.gnu.org/viewcvs?rev=268876=gcc=rev Log: Backport r268873 2019-02-14 Martin Liska Backport from mainline 2019-02-14 Martin Liska PR rtl-optimization/89242 * dce.c (delete_unmarked_insns): Call free_dominance_info we process a transformation. 2019-02-14 Martin Liska Backport from mainline 2019-02-14 Martin Liska PR rtl-optimization/89242 * g++.dg/pr89242.C: New test. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/dce.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/89351] internal compiler error: in exact_div, at poly-int.h:2139
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89351
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||rth at gcc dot gnu.org,
||torvald at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Cleaned up testcase with -fgnu-tm:
struct S { int a : 5; unsigned b : 7; } c[1][1];
void
foo (int x)
{
}
void
bar (void)
{
__transaction_relaxed {
foo (c[0][1].b);
}
}
Seems the TM code can't deal with bitfields properly:
_15 = __builtin__ITM_RU1 ([0][1].b);
taking address of a bitfield is invalid. Dunno what exactly it should do,
perhaps tak address of the DECL_BIT_FIELD_REPRESENTATIVE and read the
DECL_BIT_FIELD_REPRESENTATIVE instead and then BIT_FIELD_REF or something
similar out of this? And similarly deal somehow with the stores to bitfields
(that is actually a read modify write cycle that likely would need to be
exposed.
That said, -fgnu-tm is pretty much unmaintained for years, so maybe best would
be to remove that support (e.g. I believe it doesn't handle internal functions
at all, which appear commonly in the IL these days, doesn't handle various
builtins correctly, etc.).
