[Bug c++/91806] New: error: expansion pattern ‘()’ contains no parameter packs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91806
Bug ID: 91806
Summary: error: expansion pattern ‘()’ contains no
parameter packs
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: unixod at gmail dot com
Target Milestone: ---
Hi,
The following code:
template
void foo()
{
std::vector {
[]() {
using U = T;
return sizeof(U); // If replace U with T then code compiles.
}()...
};
}
triggers a compilation error:
error: expansion pattern ‘()’ contains no parameter packs
The aforementioned example is synthetic, in the real code where I encountered
this problem, the fix had required to move a lambda to a separate function.
The nature of this bug seems very similar to those posted in Bug 86859 and Bug
87001, but I'm unsure.
[Bug tree-optimization/91776] `-fsplit-paths` generates slower code on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91776 --- Comment #2 from yhr-_-yhr at qq dot com --- > I think it's BM2837, ie. Cortex-A53. Or did you mean a different Pi? oops you're right, I just got this pointed out when I showed this post to my friend. I just copied it from `cat /proc/cpuinfo`. > Can you try using -mno-strict-it on your examples and see whether that helps? Did you mean -mno-restrict-it? I followed gcc's correction info. (4) pi@rpi:~/Desktop $ gcc -v -save-temps -Wall -march=native -mtune=native -mno-restrict-it -o fibmod -O2 -fsplit-paths fibmod.c [...] pi@rpi:~/Desktop $ ./fibmod ~ 129358055 loop/s ~ 144338387 loop/s ~ 143361058 loop/s ~ 143191701 loop/s ~ 143414626 loop/s ~ 143312006 loop/s ^C [fibmod.S] .L7: mov r1, #0 mov r2, #1 mov r0, r1 b .L5 .L13: sub r3, r3, r10 cmp r2, #0 cmpeq r3, #1 beq .L4 .L3: mov r0, r2 mov r2, r3 .L5: add r3, r0, r2 add r1, r1, #1 cmp r10, r3 bls .L13 cmp r3, #1 cmpeq r2, #0 bne .L3 .L4: addsr4, r4, r1 adc r5, r5, #0 subsr6, r4, ip sbc r7, r5, lr cmp r7, r9 cmpeq r6, r8 bls .L6 bl clock mov r1, r7 str r0, [sp] mov r0, r6 bl __aeabi_ul2d ldr r3, [sp] vmovd6, r0, r1 ldr r0, [sp, #4] sub r2, r3, fp vmovs14, r2 @ int mov fp, r3 vcvt.f64.s32d7, s14 vdiv.f64d6, d6, d7 vmul.f64d7, d6, d8 vmovr2, r3, d7 bl printf mov ip, r4 mov lr, r5 .L6: add r10, r10, #1 b .L7 (5) pi@rpi:~/Desktop $ gcc -v -save-temps -Wall -march=native -mtune=native -mno-restrict-it -o fibmod -O2 fibmod.c [...] pi@rpi:~/Desktop $ ./fibmod ~ 277312518 loop/s ~ 279153709 loop/s ~ 278075227 loop/s ~ 277919398 loop/s ~ 277167351 loop/s ~ 278028104 loop/s ~ 278017452 loop/s ^C [fibmod.S] .L5: mov r1, #0 mov r2, #1 mov r0, r1 .L3: add r3, r0, r2 add r1, r1, #1 cmp r10, r3 mov r0, r2 subls r3, r3, r10 cmp r3, #1 cmpeq r2, #0 mov r2, r3 bne .L3 addsr4, r4, r1 adc r5, r5, #0 subsr6, r4, ip sbc r7, r5, lr cmp r7, r9 cmpeq r6, r8 bls .L4 bl clock mov r1, r7 str r0, [sp] mov r0, r6 bl __aeabi_ul2d ldr r3, [sp] vmovd6, r0, r1 ldr r0, [sp, #4] sub r2, r3, fp vmovs14, r2 @ int mov fp, r3 vcvt.f64.s32d7, s14 vdiv.f64d6, d6, d7 vmul.f64d7, d6, d8 vmovr2, r3, d7 bl printf mov ip, r4 mov lr, r5 .L4: add r10, r10, #1 b .L5 I also checked the two fibmod.S without `-mno-restrict-it` but it seems to be no difference. Oh but I found another that actually makes a little (~7%) difference.. without `-march=native -mtune=native` (6) pi@rpi:~/Desktop $ gcc -v -save-temps -Wall -mno-restrict-it -o fibmod -O2 -fsplit-paths fibmod.c [...] pi@rpi:~/Desktop $ ./fibmod ~ 140006573 loop/s ~ 153067683 loop/s ~ 153172437 loop/s ~ 152992126 loop/s ~ 153133548 loop/s ^C [fibmod.S] .L7: mov r1, #0 mov r0, r1 @ here mov r2, #1 @ here b .L5 .L13: sub r3, r3, r10 cmp r2, #0 cmpeq r3, #1 beq .L4 .L3: mov r0, r2 mov r2, r3 .L5: add r3, r0, r2 cmp r10, r3 @ here add r1, r1, #1 @ here bls .L13 cmp r3, #1 cmpeq r2, #0 bne .L3 .L4: addsr4, r4, r1 adc r5, r5, #0 subsr6, r4, ip sbc r7, r5, lr cmp r7, r9 cmpeq r6, r8 bls .L6 bl clock mov r1, r7 str r0, [sp, #4] mov r0, r6 bl __aeabi_ul2d ldr r3, [sp, #4] sub r2, r3, fp mov fp, r3 vmovs14, r2 @ int vcvt.f64.s32d7, s14 vmovd6, r0, r1 ldr r0, .L14+16 vdiv.f64d6, d6, d7 vmul.f64d7, d6, d8 vmovr2, r3, d7 bl printf mov ip, r4 mov lr, r5 .L6: add r10, r10, #1 b .L7 with neither `-fsplit-paths` nor `-march=native -mtune=native` the speed is identical to (5).
[Bug target/89557] [7/8/9/10 regression] 4*movq to 2*movaps IPC performance regression on znver1 with -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89557 --- Comment #10 from Eric Gallager --- (In reply to Jan Ziak (http://atom-symbol.net) from comment #9) > (In reply to Richard Biener from comment #5) > > Please provide a compilable testcase. > > Done some time ago. Please change the status of this bug from WAITING to > some other status. I had to modify the Makefile a bit (i.e. rename compiler executables, tweak flags, specify shell) to get it to work on my system, and once I did, this is the output I got: $ /opt/local/libexec/gnubin/make rm -f a?-?.? g++-mp-7 -O0 -g -Wall -Werror -Wswitch-enum -o a0-7.4 a.cc /var/folders/2V/2VxMt4WCF5avqTEcHvhx9k+++TI/-Tmp-//ccD198h7.s:3:11: warning: section "__textcoal_nt" is deprecated .section __TEXT,__textcoal_nt,coalesced,pure_instructions ^ ~ /var/folders/2V/2VxMt4WCF5avqTEcHvhx9k+++TI/-Tmp-//ccD198h7.s:3:11: note: change section name to "__text" .section __TEXT,__textcoal_nt,coalesced,pure_instructions ^ ~ g++-mp-7 -Og -g -Wall -Werror -Wswitch-enum -o ag-7.4 a.cc g++-mp-7 -O1 -g -Wall -Werror -Wswitch-enum -o a1-7.4 a.cc g++-mp-8 -O0 -g -Wall -Werror -Wswitch-enum -o a0-8.3 a.cc /var/folders/2V/2VxMt4WCF5avqTEcHvhx9k+++TI/-Tmp-//ccnY2JQT.s:3:11: warning: section "__textcoal_nt" is deprecated .section __TEXT,__textcoal_nt,coalesced,pure_instructions ^ ~ /var/folders/2V/2VxMt4WCF5avqTEcHvhx9k+++TI/-Tmp-//ccnY2JQT.s:3:11: note: change section name to "__text" .section __TEXT,__textcoal_nt,coalesced,pure_instructions ^ ~ g++-mp-8 -Og -g -Wall -Werror -Wswitch-enum -o ag-8.3 a.cc g++-mp-8 -O1 -g -Wall -Werror -Wswitch-enum -o a1-8.3 a.cc g++-mp-8 -O3 -g -Wall -Werror -Wswitch-enum -o a3-8.3 a.cc g++-mp-7 -Og -g -Wall -Werror -Wswitch-enum -march=native -o ag-7.4n a.cc g++-mp-8 -Og -g -Wall -Werror -Wswitch-enum -march=native -o ag-8.3n a.cc /usr/bin/time ./a0-7.4 |& egrep -o [0-9]+.*user 1.48 real 1.26 user /usr/bin/time ./ag-7.4 |& egrep -o [0-9]+.*user 0.61 real 0.59 user /usr/bin/time ./a1-7.4 |& egrep -o [0-9]+.*user 0.57 real 0.55 user /usr/bin/time ./a0-8.3 |& egrep -o [0-9]+.*user 1.27 real 1.21 user /usr/bin/time ./ag-8.3 |& egrep -o [0-9]+.*user 0.60 real 0.59 user /usr/bin/time ./a1-8.3 |& egrep -o [0-9]+.*user 0.60 real 0.59 user /usr/bin/time ./a3-8.3 |& egrep -o [0-9]+.*user 0.45 real 0.43 user /usr/bin/time ./ag-7.4n |& egrep -o [0-9]+.*user 0.60 real 0.59 user /usr/bin/time ./ag-8.3n |& egrep -o [0-9]+.*user 0.61 real 0.59 user $ So, uh, I'm not sure if that's a confirmation, but it's an extra data point.
[Bug bootstrap/58427] xgcc target compilation depends on installed libgcc_s.so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58427 --- Comment #2 from Eric Gallager --- (In reply to Rose Garcia from comment #1) > related binutils bugreport: > https://sourceware.org/bugzilla/show_bug.cgi?id=12549#c18 That binutils issue has been fixed; is there anything left for GCC to do?
[Bug target/52593] Builtin sqrt on x86 is not correctly rounded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52593 --- Comment #11 from Eric Gallager --- (In reply to David Heidelberger (okias) from comment #10) > fixed in glibc so... what still needs to be done from GCC's side then?
[Bug tree-optimization/18501] [7/8/9/10 Regression] Missing 'used uninitialized' warning (CCP)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 Eric Gallager changed: What|Removed |Added CC||vlad at ispras dot ru --- Comment #90 from Eric Gallager --- At Cauldron, Vladislav Ivanishin said in his lightning talk that ISP RAS has a patch to fix this.
[Bug go/91763] [10 regression] go.go-torture/execute/printnil.go FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91763 --- Comment #2 from Ian Lance Taylor --- I see now the fact that we are using exceptions is already being passed. The problem seems to be that flag_exceptions is set when we read an exception region from an input function, by lto_init_eh. But before we read any of the input functions, lto_main has already called symtab->compile which has called (*debug_hooks->assembly_start) which has checked flag_exceptions when deciding whether to emit a .cfi_sections directive. So although flag_exceptions does get set, it gets set too late to fix this problem.
[Bug c++/30277] bit-field: wrong overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30277 John David Anglin changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #8 from John David Anglin --- Also seen on hppa-unknown-linux-gnu.
[Bug go/91763] [10 regression] go.go-torture/execute/printnil.go FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91763 --- Comment #1 from Ian Lance Taylor --- I can recreate this on sparc-sun-solaris2.11 using gas.2.30. It works using the native assembler. I'm using the native linker. It works if I #ifdef out these lines in lto-opts.c: #if 0 /* If debug info is enabled append -g. */ if (debug_info_level > DINFO_LEVEL_NONE) append_to_collect_gcc_options (_obstack, _p, "-g"); #endif The failure is that the stack unwinder is unable to find any exception frame information. Working executable: > readelf -S --wide foo | grep eh [ 2] .eh_frame_hdr PROGBITS00010108 000108 000174 00 A 0 0 4 [61] .eh_frame PROGBITS00025120 005120 000460 00 WA 0 0 4 Failing executable: [ 2] .eh_frame_hdr PROGBITS00010108 000108 1c 00 A 0 0 4 [61] .eh_frame PROGBITS00024fc8 004fc8 44 00 WA 0 0 4 Looking at foo.ltrans0.ltrans.o; working case: [113] .eh_frame PROGBITS 0016f4 00041c 00 WA 0 0 4 [114] .rela.eh_frameRELA 004198 000204 0c I 115 113 4 Failing case has no eh sections at all in foo.ltrans0.ltrans.o. The failing case has 10 .debug and .rela.debug sections. The working case has no such sections. So somehow in the failing case we are getting debug sections and no eh sections. In the working case we are getting eh sections and no debug sections. Looking at foo.ltrans0.s, the only change in .cfi directives is that in the failing case there is a ".cfi_sections .debug_frame" directive. That directive tells gas to emit frame information into .debug_frame but not .eh_frame. So the problem is from these lines in dwarf2out_assembly_start: if (HAVE_GAS_CFI_SECTIONS_DIRECTIVE && dwarf2out_do_cfi_asm () && !dwarf2out_do_eh_frame ()) fprintf (asm_out_file, "\t.cfi_sections\t.debug_frame\n"); The fix may be to also pass -fexceptions/-funwind-tables/-fnon-call-exceptions to lto. I'll give that a try.
[Bug target/91769] [9/10 regression] wrong code with -O2 on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91769 --- Comment #5 from Aurelien Jarno --- (In reply to Dragan Mladjenovic from comment #4) > Hi, > > This fix is propbably nothing more than: Thanks for the fix. I have just tried it and I confirm it fixes the issue. Note that when backporting it to the 9 branch, it might be a good idea to also backport r273174.
[Bug target/58442] bootstrapping vax crashes on NetBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=58901 Resolution|--- |FIXED --- Comment #13 from Eric Gallager --- (In reply to coypu from comment #12) > I think this ticket can be closed. > all the vax code with mode_dependent_address_p already checks that it's > MEM_P like suggested by matt thomas. > > > I can almost complete a build with the patch in #58901, with the other > unfixed bug being in binutils rather than GCC :-) ok, closing then
[Bug preprocessor/49973] Column numbers count multibyte characters as multiple columns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973 --- Comment #17 from joseph at codesourcery dot com --- On Tue, 17 Sep 2019, lhyatt at gmail dot com wrote: > In any case, the underlying source of wcwidth() could easily be changed as a > drop-in replacement so I guess it can also be decided later. The use of > mbrtowc() is the bigger problem, since this converts from the user's locale > and > it needs to convert from what -finput-charset asked for (or else UTF-8) > instead. If __STDC_ISO_10646__ is defined, wchar_t is Unicode and so local code converting from UTF-8 to wchar_t can be used (together with wcwidth from libc if available). If __STDC_ISO_10646__ is not defined, the encoding of wchar_t is unknown. Maybe in that case it's best to avoid libc's wcwidth (if any) and just use a local implementation of wcwidth on the results of converting UTF-8 to Unicode code points.
[Bug preprocessor/49973] Column numbers count multibyte characters as multiple columns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973 --- Comment #16 from Lewis Hyatt --- Thank you both for the feedback so far. Regarding the use of wcwidth(), one thing I noticed is that glibc has a much different result than gnulib does, say for instance emojis return width 2 in the former rather than 1. (Which seems better based on what I can tell.) It seems that glibc has undergone a fair amount of tweaking to match what applications expect and so what it provides is not coming directly from parsing the Unicode specs, although that's probably the bulk of it. But I wonder, perhaps this is a sign that it might be better to just make use of glibc and not try to add in a third implementation to the mix? In any case, the underlying source of wcwidth() could easily be changed as a drop-in replacement so I guess it can also be decided later. The use of mbrtowc() is the bigger problem, since this converts from the user's locale and it needs to convert from what -finput-charset asked for (or else UTF-8) instead. I have a more or less fully-baked patch at this point, that fixes up all diagnostics that I am aware of (changes mostly in diagnostic.c and diagnostic-show-locus.c) to be multi-byte aware. That includes column numbers, carets, annotations, notes, fixit hints, etc. The patch still ignores the input-charset issue and uses mbrtowc(), so that is the last thing for me to add before I think it is worth sharing. I was wondering if I could get some advice as to where to start here please? It seems that basically location_get_source_line() in input.c needs to return the lines converted to UTF-8, since all parsing has been working with the lines in this form, and all the byte offsets they populated rich_locations with, etc, are relative to the converted data too. I am not sure what's the correct way though for location_get_source_line() to know the value of the -finput-charset option. Typically this is inspected from a cpp_reader object, but none is available in the context where this runs, that I understand anyway. It seems that in order to make use of the existing conversion machinery in libcpp/charset.c, I need to have a cpp_reader instance available too. Appreciate any suggestions here. Thanks! -Lewis
[Bug libstdc++/91805] New: Data race in std::locale::classic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91805 Bug ID: 91805 Summary: Data race in std::locale::classic Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: chris at clearwater dot dev Target Milestone: --- Created attachment 46894 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46894=edit Fixes data race std::locale::classic() uses gthread_once to initialize the classic locale impl in a thread-safe manner but then uses placement new without any synchronization to construct a locale into static global aligned storage. This is a data race as you can end up with multiple threads all racing to write to the same memory location. I suggest the attached fix which moves the placement new into the ghtread_once block and then simply reinterpret_casts the global static aligned storage in std::locale::classic(). This should be fine as the constructor is just storing a pointer the the impl and the destructor is never called.
[Bug target/91779] Unbalanced stack manipulation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91779 Andreas Schwab changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #12 from Andreas Schwab --- Ok, I was fooled by the extra insns for stack alignment.
[Bug c++/91803] statement-expressions are not allowed in template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91803 --- Comment #2 from Bernd Edlinger --- (In reply to Marek Polacek from comment #1) > I do not think that is a bug in the compiler; after all, the error message > says that is not valid. Yes, usually that would not make sense, but __typeof() alone can handle those statement-expressions just fine, but not when in an argument list, that is strange. So maybe a feature request, not a bug report.
[Bug c++/91803] statement-expressions are not allowed in template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91803 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- I do not think that is a bug in the compiler; after all, the error message says that is not valid.
[Bug target/91779] Unbalanced stack manipulation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91779
--- Comment #11 from Uroš Bizjak ---
Also:
Breakpoint 1, 0x08049268 in main ()
(gdb) ni
Char f(Char,double,Char):({'A'},0.2,{'C'})->{'B'}
0x0804926b in main ()
(gdb) p $sp
$5 = (void *) 0xce80
(gdb) set $sp = 0xce74
(gdb) c
Continuing.
Char f(Char,double,Char):({'A'},0.2,{'C'})->{'B'}
[Inferior 1 (process 7985) exited normally]
[Bug target/91804] New: [10 regression] r265398 breaks gcc.target/powerpc/vec-rlmi-rlnm.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91804 Bug ID: 91804 Summary: [10 regression] r265398 breaks gcc.target/powerpc/vec-rlmi-rlnm.c Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/vec-rlmi-rlnm.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O2 -mcpu=power9 -ffat-lto-objects -fno-ident -S -o vec-rlmi-rlnm.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/vec-rlmi-rlnm.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O2 -mcpu=power9 -ffat-lto-objects -fno-ident -S -o vec-rlmi-rlnm.s PASS: gcc.target/powerpc/vec-rlmi-rlnm.c (test for excess errors) PASS: gcc.target/powerpc/vec-rlmi-rlnm.c scan-assembler-times vrlwmi 1 PASS: gcc.target/powerpc/vec-rlmi-rlnm.c scan-assembler-times vrldmi 1 PASS: gcc.target/powerpc/vec-rlmi-rlnm.c scan-assembler-times splt 2 PASS: gcc.target/powerpc/vec-rlmi-rlnm.c scan-assembler-times vextsb2d 1 PASS: gcc.target/powerpc/vec-rlmi-rlnm.c scan-assembler-times vslw 1 PASS: gcc.target/powerpc/vec-rlmi-rlnm.c scan-assembler-times vsld 1 gcc.target/powerpc/vec-rlmi-rlnm.c: xxlor found 3 times FAIL: gcc.target/powerpc/vec-rlmi-rlnm.c scan-assembler-times xxlor 2 PASS: gcc.target/powerpc/vec-rlmi-rlnm.c scan-assembler-times vrlwnm 2 PASS: gcc.target/powerpc/vec-rlmi-rlnm.c scan-assembler-times vrldnm 2 Note the extra xxlor with r265397: rlnm_test_2: .LFB5: .cfi_startproc xxspltib 32,8 vextsb2d 0,0 vsld 3,3,0 xxlor 35,35,36 vrldnm 2,2,3 blr with r265398: rlnm_test_2: .LFB5: .cfi_startproc xxspltib 0,8 xxlor 32,0,0 vextsb2d 0,0 vsld 3,3,0 xxlor 35,35,36 vrldnm 2,2,3 blr
[Bug target/91779] Unbalanced stack manipulation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91779
--- Comment #10 from Uroš Bizjak ---
(In reply to Andreas Schwab from comment #9)
> Created attachment 46893 [details]
> libfi.so.7
This attached library has exactly the same problem.
Put a breakpoint at:
0x08049265 <+341>: pushl -0x60(%ebp)
* 0x08049268 <+344>: call *-0x54(%ebp)
0x0804926b <+347>: movzbl -0x59(%ebp),%eax
then:
Breakpoint 1, 0x08049268 in main ()
(gdb) p $sp
$1 = (void *) 0xce60
(gdb) ni
Char f(Char,double,Char):({'A'},0.2,{'C'})->{'B'}
0x0804926b in main ()
(gdb) p $sp
$2 = (void *) 0xce80
The called STDCALL function should adjust stack by 0x14 here, this is what
compiler claims:
(call_insn 115 114 116 7 (parallel [
(call (mem:QI (mem/f/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -84 [0xffac])) [23
callback_code+0 S4 A32]) [0 *callback_code.865_10 S1 A8])
(const_int 32 [0x20]))
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int 20 [0x14])))
]) "../../testsuite/libffi.bhaible/test-callback.c":2325:13 673
{*call_pop}
(expr_list:REG_ARGS_SIZE (const_int 12 [0xc])
(expr_list:REG_CALL_DECL (nil)
(nil)))
(nil))
[Bug target/91779] Unbalanced stack manipulation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91779 Andreas Schwab changed: What|Removed |Added Attachment #46892|0 |1 is obsolete|| --- Comment #9 from Andreas Schwab --- Created attachment 46893 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46893=edit libfi.so.7
[Bug target/91779] Unbalanced stack manipulation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91779 Andreas Schwab changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2019-09-17 Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #8 from Andreas Schwab --- Nope, don't use a broken libffi.
[Bug c++/91803] New: statement-expressions are not allowed in template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91803
Bug ID: 91803
Summary: statement-expressions are not allowed in template
arguments
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
I wanted to use something like __typeof(ORIGINAL_REGNO(rtl)) in a template
argument, but it does not work, I wonder if that is a bug.
$ cat test.cc
template
X identity(X x)
{ return x; }
#define IDENTITY(X) __extension__ \
({ __typeof(X) const x = (X); x; })
int
main()
{
/* error: statement-expressions are not allowed
outside functions nor in template-argument lists */
if (identity<__typeof(IDENTITY(0))>(1) != 1);
__builtin_abort();
/* but this works! */
if (identity<__typeof(identity<__typeof(0)>(0))>(1) != 1)
__builtin_abort();
}
$ g++ test.cc
test.cc: In function 'int main()':
test.cc:6:1: error: statement-expressions are not allowed outside functions nor
in template-argument lists
6 | ({ __typeof(X) const x = (X); x; })
| ^
test.cc:13:25: note: in expansion of macro 'IDENTITY'
13 | if (identity<__typeof(IDENTITY(0))>(1) != 1);
| ^~~~
test.cc:13:40: error: no matching function for call to 'identity< >(int)'
13 | if (identity<__typeof(IDENTITY(0))>(1) != 1);
|^
test.cc:2:3: note: candidate: 'template X identity(X)'
2 | X identity(X x)
| ^~~~
test.cc:2:3: note: template argument deduction/substitution failed:
test.cc:13:40: error: template argument 1 is invalid
13 | if (identity<__typeof(IDENTITY(0))>(1) != 1);
|^
[Bug go/91781] [10 regression] r275691 breaks go test "reflect"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91781 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Ian Lance Taylor --- Thanks for reporting this. It should be fixed. (To Andreas's point, there is already Go closure support in libffi for PPC64.)
[Bug go/91781] [10 regression] r275691 breaks go test "reflect"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91781 --- Comment #5 from ian at gcc dot gnu.org --- Author: ian Date: Tue Sep 17 20:24:00 2019 New Revision: 275813 URL: https://gcc.gnu.org/viewcvs?rev=275813=gcc=rev Log: PR go/91781 reflect: promote integer closure return to full word The libffi library expects an integer return type to be promoted to a full word. Implement that when returning from a closure written in Go. This only matters on big-endian systems when returning an integer smaller than the pointer size, which is why we didn't notice it until now. Fixes https://gcc.gnu.org/PR91781. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/195858 Modified: trunk/gcc/go/gofrontend/MERGE trunk/libgo/go/reflect/makefunc_ffi.go trunk/libgo/go/reflect/makefunc_ffi_c.c trunk/libgo/runtime/go-reflect-call.c
[Bug c++/91791] ICE when throwing exception in a ternary expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91791 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Marek Polacek --- Yes. *** This bug has been marked as a duplicate of bug 90393 ***
[Bug c++/90393] [9/10 Regression] ICE in return statement with a conditional operator, one of the second and third arguments is throw, and the other is a const variable of a class with a nontrivial co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90393 Marek Polacek changed: What|Removed |Added CC||tonvandenheuvel at gmail dot com --- Comment #13 from Marek Polacek --- *** Bug 91791 has been marked as a duplicate of this bug. ***
[Bug fortran/87980] ICE in gfc_conv_descriptor_data_get, at fortran/trans-array.c for assignment on allocatable polymorphic variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87980 --- Comment #6 from G. Steinmetz --- Variants that actually compile : $ cat z3.f90 # with a scalar, x(:) -> x module m type t contains procedure :: f => g end type contains subroutine g (z, x) class(t) :: z class(t), optional :: x end subroutine s (z, x) class(t) :: z class(t), optional :: x if ( present(x) ) call z%f(x) end end $ cat z4.f90 # without optional module m type t contains procedure :: f => g end type contains subroutine g (z, x) class(t) :: z class(t), optional :: x end subroutine s (z, x) class(t) :: z class(t) :: x(:) call z%f(x(1)) end end
[Bug testsuite/91797] [10 regression] r273240 breaks test case gcc.target/powerpc/pr68805.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91797 Segher Boessenkool changed: What|Removed |Added Target|powerpc64le-unknown-linux-g |powerpc64le-*-* |nu | Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-09-17 Host|powerpc64le-unknown-linux-g | |nu | Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org Ever confirmed|0 |1 Build|powerpc64le-unknown-linux-g | |nu | --- Comment #2 from Segher Boessenkool --- Confirmed. Only happens on LE. I'll have a look.
[Bug fortran/91300] Wrong runtime error message with allocate and errmsg=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300 --- Comment #5 from G. Steinmetz --- Please ignore comment 4, wrong PR ...
[Bug fortran/91802] New: ICE in mio_name_expr_t, at fortran/module.c:2141
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91802 Bug ID: 91802 Summary: ICE in mio_name_expr_t, at fortran/module.c:2141 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Since gfortran is supporting 15 dimensions : (up to gcc-7 change sources to use 7+1 dims) $ cat z0.f90 module m real :: x(1,2,1,2,1,2,1,2)[1,2,1,2,1,2,1,*] end $ gfortran-10-20190915 -c z0.f90 -fcoarray=single z0.f90:2:44: 2 |real :: x(1,2,1,2,1,2,1,2)[1,2,1,2,1,2,1,*] |1 Error: Array specification at (1) has more than 15 dimensions $ cat z1.f90 module m real :: x dimension :: x(1,2,1,2,1,2,1,2) codimension :: x[1,2,1,2,1,2,1,*] end $ gfortran-10-20190915 -c z1.f90 -fcoarray=single f951: internal compiler error: Segmentation fault 0xb3e54f crash_signal ../../gcc/toplev.c:326 0x65a11c mio_name_expr_t ../../gcc/fortran/module.c:2141 0x65a11c mio_expr ../../gcc/fortran/module.c:3549 0x65ac40 mio_array_spec ../../gcc/fortran/module.c:2743 0x65be90 mio_symbol ../../gcc/fortran/module.c:4424 0x65c1cd write_symbol ../../gcc/fortran/module.c:5749 0x65c332 write_symbol0 ../../gcc/fortran/module.c:5789 0x65eeb4 write_module ../../gcc/fortran/module.c:6131 0x65eeb4 dump_module ../../gcc/fortran/module.c:6261 0x65f27d gfc_dump_module(char const*, int) ../../gcc/fortran/module.c:6318 0x677b66 gfc_parse_file() ../../gcc/fortran/parse.c:6404 0x6c1a0f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/91300] Wrong runtime error message with allocate and errmsg=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300 G. Steinmetz changed: What|Removed |Added CC||gs...@t-online.de --- Comment #4 from G. Steinmetz --- Variants that actually compile : $ cat z3.f90 # with a scalar, x(:) -> x module m type t contains procedure :: f => g end type contains subroutine g (z, x) class(t) :: z class(t), optional :: x end subroutine s (z, x) class(t) :: z class(t), optional :: x if ( present(x) ) call z%f(x) end end $ cat z4.f90 # without optional module m type t contains procedure :: f => g end type contains subroutine g (z, x) class(t) :: z class(t), optional :: x end subroutine s (z, x) class(t) :: z class(t) :: x(:) call z%f(x(1)) end end
[Bug fortran/87980] ICE in gfc_conv_descriptor_data_get, at fortran/trans-array.c for assignment on allocatable polymorphic variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87980 G. Steinmetz changed: What|Removed |Added CC||gs...@t-online.de --- Comment #5 from G. Steinmetz --- Some possible simplifications (z1/z2) : $ cat z1.f90 module m type t contains procedure :: f => g end type contains subroutine g (z, x) class(t) :: z class(t), optional :: x end subroutine s (z, x) class(t) :: z class(t), optional :: x(:) if ( present(x) ) call z%f(x(1)) end end $ cat z2.f90 module m type t contains procedure :: f => g end type contains subroutine g (z, x) class(t) :: z class(t), optional :: x end subroutine s (z, x) class(t) :: z class(t), optional :: x(1) if ( present(x) ) call z%f(x(1)) end end $ gfortran-10-20190915 -c z1.f90 z1.f90:14:0: 14 | if ( present(x) ) call z%f(x(1)) | internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:145 0x6ca048 gfc_conv_descriptor_data_get(tree_node*) ../../gcc/fortran/trans-array.c:145 0x6f6669 gfc_conv_class_to_class(gfc_se*, gfc_expr*, gfc_typespec, bool, bool, bool, bool) ../../gcc/fortran/trans-expr.c:1163 0x6ffe24 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../gcc/fortran/trans-expr.c:5861 0x732988 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool) ../../gcc/fortran/trans-stmt.c:406 0x6c5341 trans_code ../../gcc/fortran/trans.c:1920 0x72eee3 gfc_trans_if_1 ../../gcc/fortran/trans-stmt.c:1448 0x7367fa gfc_trans_if(gfc_code*) ../../gcc/fortran/trans-stmt.c:1479 0x6c5097 trans_code ../../gcc/fortran/trans.c:1940 0x6edd14 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6781 0x6c8d89 gfc_generate_module_code(gfc_namespace*) ../../gcc/fortran/trans.c:2250 0x6776c1 translate_all_program_units ../../gcc/fortran/parse.c:6241 0x6776c1 gfc_parse_file() ../../gcc/fortran/parse.c:6493 0x6c1a0f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/91801] New: ICE in gfc_simplify_reshape, at fortran/simplify.c:6733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91801 Bug ID: 91801 Summary: ICE in gfc_simplify_reshape, at fortran/simplify.c:6733 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Follow-up of pr91565, using order with values < 1 or > n (with n = size of SHAPE). $ cat z1.f90 program p integer, parameter :: a(2) = [2,0] print *, reshape([1,2,3,4,5,6], [2,3], order=a) end $ cat z2.f90 program p integer, parameter :: a(2) = [2,3] print *, reshape([1,2,3,4,5,6], [2,3], order=a) end $ gfortran-10-20190915 -c z1.f90 f951: internal compiler error: in gfc_simplify_reshape, at fortran/simplify.c:6733 0x6a8eae gfc_simplify_reshape(gfc_expr*, gfc_expr*, gfc_expr*, gfc_expr*) ../../gcc/fortran/simplify.c:6733 0x62fdcb do_simplify ../../gcc/fortran/intrinsic.c:4566 0x63a45e gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc/fortran/intrinsic.c:4941 0x691c41 resolve_unknown_f ../../gcc/fortran/resolve.c:2894 0x691c41 resolve_function ../../gcc/fortran/resolve.c:3231 0x68e065 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:6952 0x68784c gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:6919 0x68784c gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11594 0x6964bf gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:10638 0x686628 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11584 0x688ed7 resolve_codes ../../gcc/fortran/resolve.c:17105 0x688f9e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17140 0x6774ac resolve_all_program_units ../../gcc/fortran/parse.c:6193 0x6774ac gfc_parse_file() ../../gcc/fortran/parse.c:6440 0x6c1a0f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/91800] New: ICE in gfc_code2string(): Bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91800
Bug ID: 91800
Summary: ICE in gfc_code2string(): Bad code
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Applying an old feature (z0.f90) to a new one (z1.f90) :
$ cat z0.f90
program p
integer :: n = 4habcd
print *, n
print *, transfer('abcd', 1)
end
$ gfortran-10-20190915 z0.f90
z0.f90:2:17:
2 |integer :: n = 4habcd
| 1
Warning: Extension: Conversion from HOLLERITH to INTEGER(4) at (1)
z0.f90:2:20:
2 |integer :: n = 4habcd
|1
Warning: Legacy Extension: Hollerith constant at (1)
$ ./a.out
1684234849
1684234849
$ cat z1.f90
module m
type t(n)
integer, len :: n = 4habcd
end type
end
$ gfortran-10-20190915 -c z1.f90
z1.f90:3:28:
3 | integer, len :: n = 4habcd
|1
Warning: Legacy Extension: Hollerith constant at (1)
f951: internal compiler error: gfc_code2string(): Bad code
0x61c371 gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1363
0x655014 gfc_code2string(mstring const*, int)
../../gcc/fortran/misc.c:202
0x6569fb mio_name
../../gcc/fortran/module.c:1742
0x65a934 mio_name_bt
../../gcc/fortran/module.c:2140
0x65a934 mio_typespec
../../gcc/fortran/module.c:2641
0x65a130 mio_expr
../../gcc/fortran/module.c:3568
0x65addc mio_component
../../gcc/fortran/module.c:2918
0x65bd6a mio_component_list
../../gcc/fortran/module.c:2939
0x65bd6a mio_symbol
../../gcc/fortran/module.c:4398
0x65c1cd write_symbol
../../gcc/fortran/module.c:5749
0x65c332 write_symbol0
../../gcc/fortran/module.c:5789
0x65c2a8 write_symbol0
../../gcc/fortran/module.c:5768
0x65eeb4 write_module
../../gcc/fortran/module.c:6131
0x65eeb4 dump_module
../../gcc/fortran/module.c:6261
0x65f27d gfc_dump_module(char const*, int)
../../gcc/fortran/module.c:6318
0x677b66 gfc_parse_file()
../../gcc/fortran/parse.c:6404
0x6c1a0f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204
[Bug testsuite/91799] [10 regression] r273245 breaks test case gcc.target/powerpc/pr88233.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91799 seurer at gcc dot gnu.org changed: What|Removed |Added Target||powerpc64le-unknown-linux-g ||nu CC||segher at gcc dot gnu.org Host||powerpc64le-unknown-linux-g ||nu Build||powerpc64le-unknown-linux-g ||nu --- Comment #1 from seurer at gcc dot gnu.org --- Note: tests run on power8
[Bug testsuite/91799] New: [10 regression] r273245 breaks test case gcc.target/powerpc/pr88233.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91799
Bug ID: 91799
Summary: [10 regression] r273245 breaks test case
gcc.target/powerpc/pr88233.c
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
make -k check-gcc RUNTESTFLAGS=powerpc.exp=gcc.target/powerpc/pr88233.c
Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/pr88233.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O2 -mcpu=power8 -ffat-lto-objects -fno-ident -S -o
pr88233.s(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/pr88233.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O2 -mcpu=power8 -ffat-lto-objects -fno-ident -S -o
pr88233.s
PASS: gcc.target/powerpc/pr88233.c (test for excess errors)
PASS: gcc.target/powerpc/pr88233.c scan-assembler-not \\mmtvsr
gcc.target/powerpc/pr88233.c: \\mlxvd2x\\M found 0 times
FAIL: gcc.target/powerpc/pr88233.c scan-assembler-times \\mlxvd2x\\M 1
gcc.target/powerpc/pr88233.c: \\mstxvd2x\\M found 0 times
FAIL: gcc.target/powerpc/pr88233.c scan-assembler-times \\mstxvd2x\\M 1
Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/ vmx_hw_available101572.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -mno-vsx -lm -o vmx_hw_available101572.exe
(timeout = 300)
Is this test case set up properly?
r273245 | segher | 2019-07-08 15:38:46 -0500 (Mon, 08 Jul 2019) | 10 lines
rs6000: Add testcase for PR88233
This testcase tests that with -mcpu=power8 we do not generate any
mtvsr* instructions, and we do the copy with {l,st}xvd2x.
The code it generates:
.cfi_startproc
lfd 2,8(3)
lfd 1,0(3)
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.cfi_endproc
[Bug testsuite/91797] [10 regression] r273240 breaks test case gcc.target/powerpc/pr68805.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91797 --- Comment #1 from seurer at gcc dot gnu.org --- This also affects gcc.target/powerpc/pr87507.c FAIL: gcc.target/powerpc/pr87507.c scan-assembler-times \\mstd\\M 4 FAIL: gcc.target/powerpc/pr87507.c scan-assembler-not \\mld\\M
[Bug target/91769] [9/10 regression] wrong code with -O2 on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91769
--- Comment #4 from Dragan Mladjenovic ---
Hi,
This fix is propbably nothing more than:
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -4862,7 +4862,7 @@ mips_split_move (rtx dest, rtx src, enum mips_split_type
split_type, rtx insn_)
{
rtx tmp = XEXP (src, 0);
mips_classify_address (, tmp, GET_MODE (tmp), true);
- if (addr.reg && REGNO (addr.reg) != REGNO (dest))
+ if (addr.reg && !reg_overlap_mentioned_p (dest, addr.reg))
validate_change (next, _SRC (set), src, false);
}
else
But I have to regtest it before posting it on the mailing list. There are more
bug reports that are potentialy relate to this particular piece of code, so I
have to check them too.
[Bug target/91779] Unbalanced stack manipulation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91779 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #7 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #6) > The indirectly called function is: > > ffi_closure_STDCALL () from ./libffi.so.7 > > So, the above function misaligns the stack. Not our problem.
[Bug target/91779] Unbalanced stack manipulation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91779
--- Comment #6 from Uroš Bizjak ---
Some debugging & tracing throug main shows the following:
There is an indirect call where we enter with stack pointer 0xce60, and
return with a stack pointer of 0xce80. Later, pushl misaligns the stack
pointer to 0xce7c.
movzbl C1@GOTOFF(%ebx), %eax # 111 [c=9 l=7] *movqi_internal/4
pushl 4+d2@GOTOFF(%ebx) # 166 [c=9 l=6] *pushsi2
pushl d2@GOTOFF(%ebx) # 167 [c=9 l=6] *pushsi2
pushl %eax# 112 [c=4 l=1] *pushqi2
pushl -96(%ebp) # 113 [c=8 l=3] *pushsi2
ce60call*-84(%ebp) # 115 [c=4 l=3] *call_pop
ce80movzbl -89(%ebp), %eax # 116 [c=8 l=4] *movqi_internal/4
pushl %edi# 118 [c=4 l=1] *pushsi2
ce7cmovb%al, -96(%ebp) # 157 [c=4 l=3] *movqi_internal/8
callffi_closure_free@PLT# 120 [c=0 l=5] *call
ce7cmovsbl -96(%ebp), %eax # 122 [c=12 l=4] extendqisi2
The offending indirect call is defined as:
(call_insn 115 114 116 7 (parallel [
(call (mem:QI (mem/f/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -84 [0xffac])) [23
callback_code+0 S4 A32]) [0 *callback_code.865_10 S1 A8])
(const_int 32 [0x20]))
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int 20 [0x14])))
]) "../../testsuite/libffi.bhaible/test-callback.c":2325:13 673
{*call_pop}
(expr_list:REG_ARGS_SIZE (const_int 12 [0xc])
(expr_list:REG_CALL_DECL (nil)
(nil)))
(nil))
So, the function should pop 20 bytes from the stack, which is not the case.
According to the debug session, it pops 32 bytes.
The indirectly called function is:
ffi_closure_STDCALL () from ./libffi.so.7
So, the above function misaligns the stack.
[Bug preprocessor/49973] Column numbers count multibyte characters as multiple columns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973 --- Comment #15 from Manuel López-Ibáñez --- (In reply to Lewis Hyatt from comment #13) > I have one other question though. This quick attempt uses wchar.h, namely > the mbrtowc() and wcwidth() functions. Firstly, it seems unfortunate to > introduce a dependency on those, which may be problematic for Windows, etc. Apart from Joseph suggestion, in a more general sense, there is no issue with introducing a dependency on gnulib. It is a long-term goal to replace parts of libiberty with gnulib: https://gcc.gnu.org/wiki/replacelibibertywithgnulib
[Bug tree-optimization/91758] [9 Regression] Clang fails to pass validation after r261089
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91758 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID --- Comment #7 from Martin Liška --- I've got it. It's a usage of an uninitialize member variable in a class: https://bugs.llvm.org/show_bug.cgi?id=40547#c38
[Bug driver/91794] exception and unwind state is not carried to LTO but controls EH vs debug frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91794 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-17 Ever confirmed|0 |1 --- Comment #5 from Eric Botcazou --- > Eric - was the intent of the PR81351 fix that the dwarf2out_do_eh_frame () > works per function? No, dwarf2out_do_eh_frame is global but whether the CFI for EH is emitted is decided on a per-function basis in the end, see my explanation in: https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00771.html
[Bug tree-optimization/91758] Clang fails to pass validation after r261089
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91758 --- Comment #6 from Martin Liška --- > @Eric, @Jakub, @Richard: Aren't we missing something similar with the store > merging of bool:1 bit fields? > I can see the cast to 'unsigned char' from 'bool' in GIMPLE. Both should be > 1B and > so that we maybe encorporate random bits? I made a wrong assumption, one can't have value of boolean type different from 0/1. Otherwise, it will be an UBSAN: snippet2.c:34:18: runtime error: load of value 255, which is not a valid value for type 'bool'
[Bug c++/91798] New: Compiler rejects code due to template specialization of auto parameter value.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91798
Bug ID: 91798
Summary: Compiler rejects code due to template specialization
of auto parameter value.
Product: gcc
Version: 8.1.0
URL: https://wandbox.org/permlink/YuXR4WMYflBZTW4m
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: 94sarkar.anirban at gmail dot com
Target Milestone: ---
G++ rejects the following code that runs fine on Clang and MSVC.
//Get type parameter at given index.
template
struct param;
template
struct param
{
static_assert(i > 0, "Index into parameter pack cannot be negative!");
using type = typename param::type;
};
template
struct param<0, t, ts...>
{
using type = t;
};
int main()
{
typename param<0u, char, int, float>::type x = 'a';
static_cast(x);
}
// end example
When compiled with "g++ example.cpp -Wall -Wextra -std=c++17 -pedantic-errors",
the compiler outputs:
example.cpp: In instantiation of 'struct param<0, char, int, float>':
example.cpp:21:41: required from here
example.cpp:8:21: error: static assertion failed: Index into parameter pack
cannot be negative!
static_assert(i > 0, "Index into parameter pack cannot be negative!");
~~^~~
example.cpp: In instantiation of 'struct param<4294967294, float>':
example.cpp:10:52: recursively required from 'struct param<4294967295, int,
float>'
example.cpp:10:52: required from 'struct param<0, char, int, float>'
example.cpp:21:41: required from here
example.cpp:10:52: error: invalid use of incomplete type 'struct
param<4294967293>'
using type = typename param::type;
^
example.cpp:3:8: note: declaration of 'struct param<4294967293>'
struct param;
^
example.cpp: In function 'int main()':
example.cpp:21:43: error: invalid combination of multiple type-specifiers
typename param<0u, char, int, float>::type x = 'a';
^~~~
I use a G++ build of MinGW-W64 whose build options from "g++ -v" are:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=D:/Software\ Development\
Kits/C++/MinGW/bin/../libexec/gcc/
x86_64-w64-mingw32/8.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-8.1.0/configure --host=x86_64-w64-mingw32
--bu
ild=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64
--with-sysr
oot=/c/mingw810/x86_64-810-win32-seh-rt_v6-rev0/mingw64 --enable-shared
--enable
-static --disable-multilib --enable-languages=c,c++,fortran,lto
--enable-libstdc
xx-time=yes --enable-threads=win32 --enable-libgomp --enable-libatomic
--enable-
lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string
--
enable-version-specific-runtime-libs --disable-libstdcxx-pch
--disable-libstdcxx
-debug --enable-bootstrap --disable-rpath --disable-win32-registry
--disable-nls
--disable-werror --disable-symvers --with-gnu-as --with-gnu-ld
--with-arch=noco
na --with-tune=core2 --with-libiconv --with-system-zlib
--with-gmp=/c/mingw810/p
rerequisites/x86_64-w64-mingw32-static
--with-mpfr=/c/mingw810/prerequisites/x86
_64-w64-mingw32-static
--with-mpc=/c/mingw810/prerequisites/x86_64-w64-mingw32-s
tatic --with-isl=/c/mingw810/prerequisites/x86_64-w64-mingw32-static
--with-pkgv
ersion='x86_64-win32-seh-rev0, Built by MinGW-W64 project'
--with-bugurl=https:/
/sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -fno-ident
-I/c/mingw810/x
86_64-810-win32-seh-rt_v6-rev0/mingw64/opt/include
-I/c/mingw810/prerequisites/x
86_64-zlib-static/include
-I/c/mingw810/prerequisites/x86_64-w64-mingw32-static/
include' CXXFLAGS='-O2 -pipe -fno-ident
-I/c/mingw810/x86_64-810-win32-seh-rt_v6
-rev0/mingw64/opt/include
-I/c/mingw810/prerequisites/x86_64-zlib-static/include
-I/c/mingw810/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS='
-I/c/
mingw810/x86_64-810-win32-seh-rt_v6-rev0/mingw64/opt/include
-I/c/mingw810/prere
quisites/x86_64-zlib-static/include
-I/c/mingw810/prerequisites/x86_64-w64-mingw
32-static/include' LDFLAGS='-pipe -fno-ident
-L/c/mingw810/x86_64-810-win32-seh-
rt_v6-rev0/mingw64/opt/lib -L/c/mingw810/prerequisites/x86_64-zlib-static/lib
-L
/c/mingw810/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: win32
gcc version 8.1.0 (x86_64-win32-seh-rev0, Built by MinGW-W64 project)
The same error is reported on all versions of GCC above 7.3.0 as present on
https://wandbox.org/.
[Bug testsuite/91797] New: [10 regression] r273240 breaks test case gcc.target/powerpc/pr68805.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91797 Bug ID: 91797 Summary: [10 regression] r273240 breaks test case gcc.target/powerpc/pr68805.c Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- make -k check-gcc RUNTESTFLAGS=powerpc.exp=gcc.target/powerpc/pr68805.c Executing on host: /home/seurer/gcc/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/build/gcc-test/gcc/ /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/pr68805.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O2 -mdejagnu-cpu=power8 -ffat-lto-objects -fno-ident -S -o pr68805.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/build/gcc-test/gcc/ /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/pr68805.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O2 -mdejagnu-cpu=power8 -ffat-lto-objects -fno-ident -S -o pr68805.s PASS: gcc.target/powerpc/pr68805.c (test for excess errors) gcc.target/powerpc/pr68805.c: \\mld\\M found 0 times FAIL: gcc.target/powerpc/pr68805.c scan-assembler-times \\mld\\M 2 gcc.target/powerpc/pr68805.c: \\mstd\\M found 0 times FAIL: gcc.target/powerpc/pr68805.c scan-assembler-times \\mstd\\M 2 PASS: gcc.target/powerpc/pr68805.c scan-assembler-not xxpermdi The difference is, r273239: ld 10,0(4) ld 9,8(4) std 10,0(3) std 9,8(3) blr r273240: lxvd2x 0,0,4 stxvd2x 0,0,3 blr
[Bug middle-end/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91708 --- Comment #18 from Wilco --- (In reply to Richard Earnshaw from comment #17) > So do we have a testcase that shows the problem on older compilers? Yes, the same testcase shows the same incorrect substitution in older compilers. I tried GCC9, but the MEM to MEM change dates back much further.
[Bug target/91779] Unbalanced stack manipulation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91779 --- Comment #5 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #4) > Please note (reg 116), which is kept alive all the way to (insn 127), where > it is pushed on stack. ... all the way to (insn 125), ...
[Bug target/91779] Unbalanced stack manipulation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91779
--- Comment #4 from Uroš Bizjak ---
As explained in the #Comment 0, we have the following situation in main:
leal.LC164@GOTOFF(%ebx), %eax # 32[c=5 l=6] *leasi
pushl %eax# 33[c=4 l=1] *pushsi2
pushl (%esi) # 35[c=4 l=2] *pushsi2
movl%eax, -100(%ebp)# 159 [c=4 l=3] *movsi_internal/1
call_fprintf# 36[c=9 l=5] *call_value
...
pushl %eax# 123 [c=4 l=1] *pushsi2
pushl -100(%ebp) # 125 [c=8 l=3] *pushsi2
pushl (%esi) # 127 [c=4 l=2] *pushsi2
call_fprintf# 128 [c=9 l=5] *call_value
where (insn 159) pushes value on the stack, which is later read in (insn 125).
Before LRA, we have the following sequence:
_.ira:
(insn 32 31 33 2 (set (reg/f:SI 116)
(plus:SI (reg:SI 82)
(const:SI (unspec:SI [
(symbol_ref/f:SI ("*.LC164") [flags 0x2] )
] UNSPEC_GOTOFF
"../../testsuite/libffi.bhaible/test-callback.c":2310:5 186 {*leasi}
(expr_list:REG_EQUIV (symbol_ref/f:SI ("*.LC164") [flags 0x2] )
(nil)))
(insn 33 32 35 2 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [2 S4 A32])
(reg/f:SI 116)) "../../testsuite/libffi.bhaible/test-callback.c":2310:5
43 {*pushsi2}
(expr_list:REG_ARGS_SIZE (const_int 28 [0x1c])
(nil)))
(insn 35 33 36 2 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [3 S4 A32])
(mem/f/c:SI (reg/f:SI 109) [3 out+0 S4 A32]))
"../../testsuite/libffi.bhaible/test-callback.c":2310:5 43 {*pushsi2}
(expr_list:REG_ARGS_SIZE (const_int 32 [0x20])
(nil)))
(call_insn 36 35 37 2 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:SI ("_fprintf") [flags 0x3] ) [0 _fprintf S1 A8])
(const_int 32 [0x20])))
"../../testsuite/libffi.bhaible/test-callback.c":2310:5 676 {*call_value}
(expr_list:REG_UNUSED (reg:SI 0 ax)
(expr_list:REG_CALL_DECL (symbol_ref:SI ("_fprintf") [flags 0x3]
)
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil
(nil))
...
(insn 123 122 125 6 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [1 S4 A32])
(reg:SI 136 [ Cr ]))
"../../testsuite/libffi.bhaible/test-callback.c":2328:5 43 {*pushsi2}
(expr_list:REG_DEAD (reg:SI 136 [ Cr ])
(expr_list:REG_ARGS_SIZE (const_int 8 [0x8])
(nil
(insn 125 123 127 6 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [2 S4 A32])
(reg/f:SI 116)) "../../testsuite/libffi.bhaible/test-callback.c":2328:5
43 {*pushsi2}
(expr_list:REG_DEAD (reg/f:SI 116)
(expr_list:REG_ARGS_SIZE (const_int 12 [0xc])
(nil
(insn 127 125 128 6 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [3 S4 A32])
(mem/f/c:SI (reg/f:SI 109) [3 out+0 S4 A32]))
"../../testsuite/libffi.bhaible/test-callback.c":2328:5 43 {*pushsi2}
(expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil)))
(call_insn 128 127 129 6 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:SI ("_fprintf") [flags 0x3] ) [0 _fprintf S1 A8])
(const_int 16 [0x10])))
"../../testsuite/libffi.bhaible/test-callback.c":2328:5 676 {*call_value}
(expr_list:REG_UNUSED (reg:SI 0 ax)
(expr_list:REG_CALL_DECL (symbol_ref:SI ("_fprintf") [flags 0x3]
)
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil
(nil))
Please note (reg 116), which is kept alive all the way to (insn 127), where it
is pushed on stack.
LRA pass stores the value in (reg 116) to a frame with:
(insn 159 32 33 2 (set (mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -100 [0xff9c])) [35 %sfp+-76 S4 A32])
(reg/f:SI 0 ax [116]))
"../../testsuite/libffi.bhaible/test-callback.c":2310:5 67 {*movsi_internal}
(nil))
and substitutes (reg 116) in (insn 125) with a new memory location:
(insn 125 123 127 7 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [2 S4 A32])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -100 [0xff9c])) [35 %sfp+-76 S4 A32]))
"../../testsuite/libffi.bhaible/test-callback.c":2328:5 43 {*pushsi2}
(expr_list:REG_ARGS_SIZE (const_int 12 [0xc])
(nil)))
The frame is correctly constructed using:
subl$100, %esp # 185 [c=4 l=3]
pro_epilogue_adjust_stack_si_add/0
It looks to me that LRA creates too small frame, perhpas it doesn't account for
preceeding (insn 123) for some reason.
[Bug target/91269] [9/10 regression] unaligned floating-point register with -mcpu=niagara4 -fcall-used-g6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91269 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #11 from Eric Botcazou --- Investigating.
[Bug target/91269] [9/10 regression] unaligned floating-point register with -mcpu=niagara4 -fcall-used-g6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91269 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-17 CC||ebotcazou at gcc dot gnu.org Known to work||7.4.0, 8.3.0 Target Milestone|--- |9.3 Summary|sparc64-gcc fails to build |[9/10 regression] unaligned |glibc (-fcall-used-g6) on |floating-point register |niagara4: Assembler |with -mcpu=niagara4 |messages: Error: Illegal|-fcall-used-g6 |operands| Ever confirmed|0 |1 Known to fail||10.0, 9.1.0, 9.2.0 --- Comment #10 from Eric Botcazou --- I can reproduce.
[Bug target/91779] Unbalanced stack manipulation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91779
--- Comment #3 from Uroš Bizjak ---
The test needs -fpie and attached libffi.so.7 (plus a symbolic link from
libffi.so to libffi.so.7).
$gcc -O2 -m32 -fpie -L. -lffi pr91779.i
$ LD_LIBRARY_PATH=. ./a.out
Char f(Char,double,Char):({'A'},0.2,{'C'})->{'B'}
Segmentation fault
[Bug target/91779] Unbalanced stack manipulation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91779 --- Comment #2 from Uroš Bizjak --- Created attachment 46892 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46892=edit libffi.so.7 Needed shared library to run the test.
[Bug c++/91791] ICE when throwing exception in a ternary expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91791 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #1 from ensadc at mailnesia dot com --- Duplicate of PR 90393?
[Bug tree-optimization/91758] Clang fails to pass validation after r261089
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91758
Martin Liška changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Martin Liška ---
Ok, so without changed source file I see optimized dump changed from:
D.1259546.PaddingInReg = SR.6329_147;
D.1259546.IndirectByVal = SR.6330_121;
D.1259546.IndirectRealign = SR.6331_117;
D.1259546.SRetAfterThis = SR.6332_29;
D.1259546.InReg = SR.6333_124;
D.1259546.CanBeFlattened = SR.6334_129;
MEM[base: __for_begin_145, offset: 8B] = MEM[(struct ABIArgInfo
*)];
into:
_139 = (unsigned char) SR.6329_147;
_49 = (unsigned char) SR.6330_121;
_137 = _49 << 2;
_34 = _137 | _139;
_382 = (unsigned char) SR.6331_117;
_381 = _382 << 3;
_357 = _381 | _34;
_380 = (unsigned char) SR.6332_29;
_377 = _380 << 4;
_376 = _377 | _357;
_375 = (unsigned char) SR.6333_124;
_397 = _375 << 5;
_401 = _397 | _376;
_181 = (unsigned char) SR.6334_129;
_364 = _181 << 6;
_118 = _364 | _401;
_131 = MEM[(struct ABIArgInfo *) + 21B];
_363 = _131 & 130;
_366 = _118 & 125;
_69 = _363 | _366;
MEM[(struct ABIArgInfo *) + 21B] = _69;
MEM[base: __for_begin_145, offset: 8B] = MEM[(struct ABIArgInfo
*)];
which eventually ends up with something like:
addq$32, %rbx #, ivtmp.6357
movzbl 43(%rsp), %ecx # %sfp, SR.6331
movq24(%rsp), %xmm0 # %sfp, tmp336
movl%r15d, -8(%rbx) # SR.6327, MEM[base: __for_begin_145, offset:
8B]
leal0(,%rdi,4), %edx#, tmp337
# /tmp/llvm-project/clang/lib/CodeGen/TargetInfo.cpp:7572:
__builtin_printf ("after: I.info: %d\n", I.info.getInReg ());
leaq.LC156(%rip), %rdi #,
# /tmp/llvm-project/clang/lib/CodeGen/TargetInfo.cpp:7571: I.info =
classifyArgumentType(I.type, State);
movl%r15d, 80(%rsp) # SR.6327, MEM[(struct ABIArgInfo *)
+ 16B]
sall$3, %ecx#, tmp339
orl %r14d, %edx # SR.6329, tmp338
movhps 8(%rsp), %xmm0 # %sfp, tmp336
orl %ecx, %edx # tmp339, tmp340
movzbl 42(%rsp), %ecx # %sfp, tmp341
movups %xmm0, -24(%rbx)# tmp336, MEM[base: __for_begin_145,
offset: 8B]
movaps %xmm0, 64(%rsp) # tmp336, MEM[(struct ABIArgInfo *)]
sall$4, %ecx#, tmp341
orl %ecx, %edx # tmp341, tmp342
orl %eax, %edx # tmp343, tmp344
movl%ebp, %eax # SR.6334, tmp345
sall$6, %eax#, tmp345
orl %eax, %edx # tmp345, tmp346
movzbl 85(%rsp), %eax # MEM[(struct ABIArgInfo *) + 21B],
tmp348
andl$125, %edx #, tmp347
andl$-126, %eax #, tmp348
orl %eax, %edx # tmp348, tmp350
# /tmp/llvm-project/clang/lib/CodeGen/TargetInfo.cpp:7572:
__builtin_printf ("after: I.info: %d\n", I.info.getInReg ());
xorl%eax, %eax #
# /tmp/llvm-project/clang/lib/CodeGen/TargetInfo.cpp:7571: I.info =
classifyArgumentType(I.type, State);
movb%dl, 85(%rsp) # tmp350, MEM[(struct ABIArgInfo *) +
21B]
and the problem is that we load:
0x2776490 <(anonymous
namespace)::LanaiABIInfo::computeInfo(clang::CodeGen::CGFunctionInfo&)
const+400> movzbl 0x2b(%rsp),%ecx
with the following value:
(gdb) p /t $ecx
$1 = 0111
and then we or (0111 << 3) into %edx and so that we end up with the 6th bit
set.
That is the InReg field.
Looking at the corresponding ASM code without the store-merging, there are
quite some
andl$1, %esi#, tmp329
...
andl$1, %ecx#, tmp347
and so on.
@Eric, @Jakub, @Richard: Aren't we missing something similar with the store
merging of bool:1 bit fields?
I can see the cast to 'unsigned char' from 'bool' in GIMPLE. Both should be 1B
and
so that we maybe encorporate random bits?
je suis en ligne mtn SARA.
Bonjour Retrouvez-moi sur la page je suis mtn en ligne, mon login: CAT015> http://bit.ly/2mj0FBr
[Bug libgcc/91737] On Alpine Linux (libmusl) a statically linked C++ program which throws the first exception in two threads at the same time can busy spin on shutdown after main().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91737 nsz at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2019-09-17 CC||nsz at gcc dot gnu.org Resolution|MOVED |--- Ever confirmed|0 |1 --- Comment #5 from nsz at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #1) > Glibc has a similar bug and been discussed how to fix it. > The way Glibc is going to fix it (though it has not yet) is that > libpthread.a will be really just include one object file which includes all > of the pthread library. citation needed. the plan in glibc is to provide a "is single threaded" api. https://sourceware.org/ml/libc-alpha/2019-08/msg00438.html once that's in then in principle any library (like libstdc++) can do single thread optimizations without hacks. (another glibc plan is to move libpthread.so into libc.so so there are no awkward internal abis between them and then avoiding pthread dependency is no longer relevant.) i think that should work for the unwinder in libgcc too. on the musl side, we want to disable this hack before that happens, it's better to not do any single thread optimizations than silently breaking things. so the right fix is something equivalent to https://gcc.gnu.org/viewcvs/gcc?view=revision=222329 i.e. libgcc should be compiled with GTHREAD_USE_WEAK=0 on *musl*.
[Bug libgcc/91737] On Alpine Linux (libmusl) a statically linked C++ program which throws the first exception in two threads at the same time can busy spin on shutdown after main().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91737 --- Comment #4 from Rich Felker --- The corresponding fixes for libgfortran and libstdc++ were made back in 2015. >From the converted repo mirror I use, it looks like this was svn revision 222329 but I may be mistaken (really looking forward to official move to git...). I was aware of this because we used to have the patch in the musl-cross-make patchset and it was removed at some point because it was upstreamed. It looks like it was just overlooked that libgcc[_eh] also had this kind of weak reference use, or maybe the use was introduced later and not noticed.
[Bug middle-end/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91708 --- Comment #17 from Richard Earnshaw --- So do we have a testcase that shows the problem on older compilers?
[Bug middle-end/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91708 --- Comment #16 from Wilco --- (In reply to Richard Earnshaw from comment #15) > So is this now fixed? On trunk yes. This is quite a nasty alias bug in CSE, so it will need to be backported.
[Bug libgcc/91737] On Alpine Linux (libmusl) a statically linked C++ program which throws the first exception in two threads at the same time can busy spin on shutdown after main().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91737 --- Comment #3 from Rich Felker --- Please reopen. (I thought I could, but apparently I can't...?) RESOLVED/MOVED makes no sense. It should either be opened or CLOSED/WONTFIX if the latter is really going to be gcc's position on this issue.
[Bug middle-end/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91708 --- Comment #15 from Richard Earnshaw --- So is this now fixed?
[Bug libgcc/91737] On Alpine Linux (libmusl) a statically linked C++ program which throws the first exception in two threads at the same time can busy spin on shutdown after main().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91737 Rich Felker changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #2 from Rich Felker --- This is absolutely a bug in libgcc, not musl. Weak references are not a valid way to determine if a program is multithreaded. Some distros build all of glibc's libpthread.a as a single object file to *work around* bugs in libgcc and other software, which largely defeats the purpose of static linking and is not an option for musl. If gcc refuses to fix this we can ship patches, but I'd rather get it fixed correctly.
[Bug lto/91772] [8/9 Regression] ICE in add_dwarf_attr, at dwarf2out.c:4412 since r259749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91772 --- Comment #6 from Richard Biener --- Author: rguenth Date: Tue Sep 17 13:52:20 2019 New Revision: 275804 URL: https://gcc.gnu.org/viewcvs?rev=275804=gcc=rev Log: 2019-09-17 Richard Biener PR debug/91772 * dwarf2out.c (dwarf2out_late_global_decl): If early dwarf was missing generate locations only once. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug lto/91772] [8/9 Regression] ICE in add_dwarf_attr, at dwarf2out.c:4412 since r259749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91772 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||10.0 Summary|[8/9/10 Regression] ICE in |[8/9 Regression] ICE in |add_dwarf_attr, at |add_dwarf_attr, at |dwarf2out.c:4412 since |dwarf2out.c:4412 since |r259749 |r259749 Known to fail|10.0| --- Comment #5 from Richard Biener --- Fixed on trunk sofar.
[Bug driver/91794] exception and unwind state is not carried to LTO but controls EH vs debug frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91794 --- Comment #4 from Richard Biener --- Created attachment 46891 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46891=edit fixed patch
[Bug driver/91794] exception and unwind state is not carried to LTO but controls EH vs debug frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91794 --- Comment #3 from Richard Biener --- Created attachment 46890 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46890=edit patch for lto-wrapper This instead makes lto-wrapper append -funwind-tables when one CU had that enabled.
[Bug tree-optimization/91758] Clang fails to pass validation after r261089
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91758 --- Comment #4 from Martin Liška --- So no, the affective change is: D.1259546.IndirectRealign = SR.6335_125; D.1259546.InReg = SR.6336_130; _163 = (unsigned char) SR.6335_125; _50 = (unsigned char) SR.6336_130; _140 = _50 << 1; _34 = _140 | _163; _383 = MEM[(struct ABIArgInfo *) + 27B]; _382 = _383 & 252; _358 = _34 & 3; _381 = _382 | _358; MEM[(struct ABIArgInfo *) + 27B] = _381; which is also fine from store-merging point of view.
[Bug tree-optimization/91758] Clang fails to pass validation after r261089
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91758
--- Comment #3 from Martin Liška ---
So that's what I have:
1) reduced LLVM test-case:
$ cat /tmp/llvm-project/clang/test/CodeGen/lanai-regparm.c
void f2(int a) __attribute((regparm(0)));
void f0() {
f2(1);
}
2) I applied the following local patch to make the change smaller:
diff --git a/clang/include/clang/CodeGen/CGFunctionInfo.h
b/clang/include/clang/CodeGen/CGFunctionInfo.h
index 1f81072e23d..ef7f7410c9b 100644
--- a/clang/include/clang/CodeGen/CGFunctionInfo.h
+++ b/clang/include/clang/CodeGen/CGFunctionInfo.h
@@ -87,14 +87,14 @@ private:
unsigned AllocaFieldIndex; // isInAlloca()
};
Kind TheKind;
- bool PaddingInReg : 1;
- bool InAllocaSRet : 1;// isInAlloca()
- bool IndirectByVal : 1; // isIndirect()
- bool IndirectRealign : 1; // isIndirect()
- bool SRetAfterThis : 1; // isIndirect()
+ bool PaddingInReg;
+ bool InAllocaSRet;// isInAlloca()
+ bool IndirectByVal; // isIndirect()
+ bool CanBeFlattened; // isDirect()
+ bool SignExt ; // isExtend()
+ bool SRetAfterThis ; // isIndirect()
+ bool IndirectRealign: 1; // isIndirect()
bool InReg : 1; // isDirect() || isExtend() || isIndirect()
- bool CanBeFlattened: 1; // isDirect()
- bool SignExt : 1; // isExtend()
bool canHavePaddingType() const {
return isDirect() || isExtend() || isIndirect() || isExpand();
diff --git a/clang/lib/CodeGen/TargetInfo.cpp
b/clang/lib/CodeGen/TargetInfo.cpp
index f2696a33cfb..b115d9da145 100644
--- a/clang/lib/CodeGen/TargetInfo.cpp
+++ b/clang/lib/CodeGen/TargetInfo.cpp
@@ -7567,7 +7567,10 @@ public:
if (!getCXXABI().classifyReturnType(FI))
FI.getReturnInfo() = classifyReturnType(FI.getReturnType());
for (auto : FI.arguments())
+{
I.info = classifyArgumentType(I.type, State);
+ __builtin_printf ("after: I.info: %d\n", I.info.getInReg ());
+}
}
ABIArgInfo getIndirectResult(QualType Ty, bool ByVal, CCState ) const;
@@ -7658,7 +7661,9 @@ ABIArgInfo LanaiABIInfo::classifyArgumentType(QualType
Ty,
}
if (InReg)
return ABIArgInfo::getDirectInReg();
- return ABIArgInfo::getDirect();
+ ABIArgInfo ret = ABIArgInfo::getDirect();
+ __builtin_printf ("before: %d\n", ret.getInReg ());
+ return ret;
}
namespace {
3) I see the problematic file is:
/tmp/llvm-project/clang/lib/CodeGen/TargetInfo.cpp
4) I took the patch from r261089 and applied it to r255894 and it still fails
5) apparently one needs -O3 to expose the issue
6) If I add following dbg_cnt:
diff --git a/gcc/dbgcnt.def b/gcc/dbgcnt.def
index 0421fae7bc0..3830666dc6c 100644
--- a/gcc/dbgcnt.def
+++ b/gcc/dbgcnt.def
@@ -195,3 +195,4 @@ DEBUG_COUNTER (tree_sra)
DEBUG_COUNTER (vect_loop)
DEBUG_COUNTER (vect_slp)
DEBUG_COUNTER (dom_unreachable_edges)
+DEBUG_COUNTER (store_merging)
diff --git a/gcc/gimple-ssa-store-merging.c b/gcc/gimple-ssa-store-merging.c
index 3c63e75fcf6..2369fd4bf5d 100644
--- a/gcc/gimple-ssa-store-merging.c
+++ b/gcc/gimple-ssa-store-merging.c
@@ -166,6 +166,7 @@
#include "rtl.h"
#include "expr.h" /* For get_bit_range. */
#include "optabs-tree.h"
+#include "dbgcnt.h"
#include "selftest.h"
/* The maximum size (in bits) of the stores this pass should generate. */
@@ -3898,7 +3899,8 @@ imm_store_chain_info::output_merged_stores ()
bool ret = false;
FOR_EACH_VEC_ELT (m_merged_store_groups, i, merged_store)
{
- if (output_merged_store (merged_store))
+ if (dbg_cnt (store_merging)
+ && output_merged_store (merged_store))
{
unsigned int j;
store_immediate_info *store;
I can bisect that to one store merging transformation:
before:
MEM[(struct SmallVectorBase *)].Size = 0;
MEM[(struct SmallVectorBase *)].Capacity = 3;
after:
MEM[(unsigned int *) + 8B] = 12884901888;
if (SizeInRegs_144 > 3)
The transformation looks fine to me and it must be an issue in RTL, because
this is the only difference I see in tree optimized dump file.
The change happens in {anonymous}::ARCABIInfo::computeInfo (const struct
ARCABIInfo * const this, struct CGFunctionInfo & FI)
function. And the valgrind also points to the same function:
valgrind /tmp/llvm-project/build/bin/clang -cc1 -triple lanai-unknown-unknown
-mregparm 4 /tmp/llvm-project/clang/test/CodeGen/lanai-regparm.c -emit-llvm
==766== Memcheck, a memory error detector
==766== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==766== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==766== Command: /tmp/llvm-project/build/bin/clang -cc1 -triple
lanai-unknown-unknown -mregparm 4
/tmp/llvm-project/clang/test/CodeGen/lanai-regparm.c -emit-llvm
==766==
before: 0
==766== Conditional jump or move depends on uninitialised value(s)
==766==at 0x7295287: __vfprintf_internal (vfprintf-internal.c:1644)
==766==by 0x7280C7A: printf (printf.c:33)
==766==by 0x2776A28: (anonymous
[Bug target/91796] New: Sub-optimal YMM register allocation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91796
Bug ID: 91796
Summary: Sub-optimal YMM register allocation.
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
The following code when compiled with `g++ -O3 -mavx2 -std=c++11`
__m256d copysign2_pd(__m256d from, __m256d to) {
auto a = _mm256_castpd_si256(from);
auto avx_signbit =
_mm256_castsi256_pd(_mm256_slli_epi64(_mm256_cmpeq_epi64(a, a), 63));
return _mm256_or_pd(_mm256_and_pd(avx_signbit, from),
_mm256_andnot_pd(avx_signbit, to)); // (avx_signbit & from) | (~avx_signbit &
to)
}
Generates the following assembly:
copysign2_pd(double __vector(4), double __vector(4)):
vmovapd ymm2, ymm0
vmovapd ymm0, YMMWORD PTR .LC3[rip]
vandnpd ymm1, ymm0, ymm1
vandpd ymm0, ymm0, ymm2
vorpd ymm0, ymm0, ymm1
ret
.LC3:
.long 0
.long -2147483648
.long 0
.long -2147483648
.long 0
.long -2147483648
.long 0
.long -2147483648
In the assembly instruction `vmovapd ymm2, ymm0` is unnecessary. It can instead
load constant .LC3 directly into ymm2. The expected code is:
copysign2_pd(double __vector(4), double __vector(4)):
vmovapd ymm2, YMMWORD PTR .LC3[rip]
vandnpd ymm1, ymm2, ymm1
vandpd ymm0, ymm2, ymm0
vorpd ymm0, ymm0, ymm1
ret
[Bug ipa/91089] IPA-cp does not setup proper cost model for switch default case in function versioning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91089 --- Comment #3 from fxue at gcc dot gnu.org --- Author: fxue Date: Tue Sep 17 12:30:08 2019 New Revision: 275802 URL: https://gcc.gnu.org/viewcvs?rev=275802=gcc=rev Log: PR ipa/91089 - Setup predicate for switch default case in IPA 2019-09-17 Feng Xue PR ipa/91089 * doc/invoke.texi (ipa-max-switch-predicate-bounds): Document new option. * params.def (PARAM_IPA_MAX_SWITCH_PREDICATE_BOUNDS): New. * ipa-fnsummary.c (set_switch_stmt_execution_predicate): Add predicate for switch default case using range analysis information. 2019-09-17 Feng Xue PR ipa/91089 * gcc.dg/ipa/pr91089.c: New test. Added: trunk/gcc/testsuite/gcc.dg/ipa/pr91089.c Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi trunk/gcc/ipa-fnsummary.c trunk/gcc/params.def trunk/gcc/testsuite/ChangeLog
[Bug c++/30277] bit-field: wrong overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30277 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #7 from Rainer Orth --- The new testcase FAILs on 32-bit targets (seen on i386-pc-solaris2.11 and sparc-sun-solaris2.11, and many more on gcc-testresults): +FAIL: g++.dg/expr/bitfield14.C -std=c++14 (test for excess errors) +FAIL: g++.dg/expr/bitfield14.C -std=c++17 (test for excess errors) Excess errors: /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/expr/bitfield14.C:15:12: error: use of deleted function 'void foo(long int)'
[Bug lto/91772] [8/9/10 Regression] ICE in add_dwarf_attr, at dwarf2out.c:4412 since r259749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91772 --- Comment #4 from Richard Biener --- Created attachment 46889 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46889=edit patch
[Bug lto/91772] [8/9/10 Regression] ICE in add_dwarf_attr, at dwarf2out.c:4412 since r259749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91772
Richard Biener changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #3 from Richard Biener ---
OK, so this happens when the DIE was not created early (due to -g1) then we do
/* We may have to generate early debug late for LTO in case debug
was not enabled at compile-time or the target doesn't support
the LTO early debug scheme. */
if (! die && in_lto_p)
{
dwarf2out_decl (decl);
die = lookup_decl_die (decl);
}
where dwarf2out_decl already adds a DW_AT_location attribute. Then
we fall through to
if (die)
{
/* We get called via the symtab code invoking late_global_decl
for symbols that are optimized out.
Do not add locations for those, except if they have a
DECL_VALUE_EXPR, in which case they are relevant for debuggers.
Still don't add a location if the DECL_VALUE_EXPR is not a trivial
INDIRECT_REF expression, as this could generate relocations to
text symbols in LTO object files, which is invalid. */
varpool_node *node = varpool_node::get (decl);
if ((! node || ! node->definition)
&& ! (DECL_HAS_VALUE_EXPR_P (decl)
&& is_trivial_indirect_ref (DECL_VALUE_EXPR (decl
tree_add_const_value_attribute_for_decl (die, decl);
else
add_location_or_const_value_attribute (die, decl, false);
}
obviously above we're not only creating "early" debug. It seems obvious
to me that we want to skip the later code which is intended for early
dwarf only.
[Bug target/91766] -fvisibility=hidden during -fpic still uses GOT indirection on arm64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91766
Wilco changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-09-17
Ever confirmed|0 |1
--- Comment #8 from Wilco ---
Confirmed btw - the difference is due to HAVE_LD_PIE_COPYRELOC in i386.c:
/* For i386, common symbol is local only for non-PIE binaries. For
x86-64, common symbol is local only for non-PIE binaries or linker
supports copy reloc in PIE binaries. */
static bool
ix86_binds_local_p (const_tree exp)
{
return default_binds_local_p_3 (exp, flag_shlib != 0, true, true,
(!flag_pic
|| (TARGET_64BIT
&& HAVE_LD_PIE_COPYRELOC != 0)));
}
[Bug sanitizer/91795] [UBSAN :- error] with combination of flags (shift and unsigned-integer-overflow)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91795 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Martin Liška --- I bet you are using clang and not gcc. Can you please run: $ gcc --version It's because we do not support unsigned-integer-overflow as a -fsanitize option.
[Bug target/91766] -fvisibility=hidden during -fpic still uses GOT indirection on arm64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91766 Wilco changed: What|Removed |Added CC||wilco at gcc dot gnu.org --- Comment #7 from Wilco --- (In reply to Eric Gallager from comment #6) > (In reply to Wilco from comment #4) > > (In reply to martin krastev from comment #3) > > > So it appears to be a clash between -fcommon and -fvisibility=hidden > > > during > > > -fpic -- passing either -fno-common or -fno-pic drops the GOT indirection. > > > And explicitly hiding the symbol obviously solves it. But the crux of the > > > issue, IMO, is a multi-platform one -- that behavior deviates on gcc-8.2 > > > from platform to platform. On amd64 it suffices to -fvisibility=hidden to > > > stop GOT detours, whereas on aarch64 it's -fvisibility=hidden -fno-common. > > > As a result aarch64 performance gets penalized in unsuspecting > > > multi-plats. > > > > -fno-common should really become the default, -fcommon causes way too many > > issues. > > That's bug 85678 Yes, we need to push on that one again since not much happened...
[Bug driver/91794] exception and unwind state is not carried to LTO but controls EH vs debug frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91794
--- Comment #2 from Richard Biener ---
So one possible fix would be
Index: gcc/dwarf2cfi.c
===
--- gcc/dwarf2cfi.c (revision 275639)
+++ gcc/dwarf2cfi.c (working copy)
@@ -3489,7 +3489,7 @@ bool
dwarf2out_do_eh_frame (void)
{
return
-(flag_unwind_tables || flag_exceptions)
+(opt_for_fn (cfun->decl, flag_unwind_tables) || flag_exceptions)
&& targetm_common.except_unwind_info (_options) == UI_DWARF2;
}
note this predicate also controls the 'dwarf2' RTL pass so you'd get
per function CFI notes(?).
[Bug driver/91794] exception and unwind state is not carried to LTO but controls EH vs debug frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91794 Richard Biener changed: What|Removed |Added Keywords||EH, lto CC||ebotcazou at gcc dot gnu.org --- Comment #1 from Richard Biener --- Eric - was the intent of the PR81351 fix that the dwarf2out_do_eh_frame () works per function? We could also fix this similar to how we do lto_init_eh which forces the global flag_exceptions to 1, force flag_unwind_tables to 1 in case any function had it enabled (that's still finer-grained than enabling it for all LTRANS units via lto-wrapper). Similar on targets where EH unwind is the default disabling it via -fno-unwind-tables would have no effect with LTO even if all functions have it disabled.
[Bug sanitizer/91795] New: [UBSAN :- error] with combination of flags (shift and unsigned-integer-overflow)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91795
Bug ID: 91795
Summary: [UBSAN :- error] with combination of flags (shift and
unsigned-integer-overflow)
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: akhilesh.k at samsung dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Hello
I am working on UBSAN.
When I tried to compile my stack with combination of ubsan checkers I got
"error: void value not ignored as it ought to be" ERROR.
Strange this error occurred when I use combination of flags (shift and
unsigned-integer-overflow)
I reproduced the same error with below sample test application.
Please confirm is issue is related with ubsan,
root@VDBS1454:tmp$ gcc -fsanitize=shift main.c
root@VDBS1454:tmp$ gcc -fsanitize=unsigned-integer-overflow main.c
root@VDBS1454:tmp$ gcc -fsanitize=shift,-fsanitize=unsigned-integer-overflow
main.c
gcc: error: unrecognized argument to -fsanitize= option:
'-fsanitize=unsigned-integer-overflow'
root@VDBS1454:tmp$ gcc -fsanitize=shift, -fsanitize=unsigned-integer-overflow
main.c
main.c: In function 'main':
main.c:5:15: error: void value not ignored as it ought to be
return (x << 1);
~~~^
root@VDBS1454:tmp$ cat main.c
#include
unsigned int main()
{
uint8_t x;
return (x << 1);
//return x*2;
}
root@VDBS1454:tmp$
[Bug other/91730] [10 regression] r275518 causes 3 verification errors in the cpu 2006 test suite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91730 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #9 from Tamar Christina --- Hmm yes the transformation is too aggressive and incorrect here. we'll fix that and resubmit a fixed patch.
[Bug driver/91794] New: exception and unwind state is not carried to LTO but controls EH vs debug frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91794
Bug ID: 91794
Summary: exception and unwind state is not carried to LTO but
controls EH vs debug frame
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
On targets where -funwind-tables is not enabled by default doing
gcc -c -flto -funwind-tables t.c -g
gcc t.o -g
ends up without unwind tables even if the flags state is recorded in
per-function settings. dwarf2out.c suggests the state is accumulated
from all functions in the TU
/* Unlike the debug version, the EH version of frame unwind info is a per-
function setting so we need to record whether we need it for the unit. */
do_eh_frame |= dwarf2out_do_eh_frame ();
but that doesn't work since dwarf2out_do_eh_frame looks at the global
flag_unwind_tables (and global flag_exceptions and passes global opts to
the target hook).
We probably can switch between EH-frame and debug-frame per function but
a way out would be to handle flag_{,asynchronous_}unwind_tables in
lto-wrapper.
Eric was here fixing the similar PR81351.
One target where this shows is riscv.
[Bug target/58442] bootstrapping vax crashes on NetBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 coypu changed: What|Removed |Added CC||coypu at sdf dot org --- Comment #12 from coypu --- I think this ticket can be closed. all the vax code with mode_dependent_address_p already checks that it's MEM_P like suggested by matt thomas. I can almost complete a build with the patch in #58901, with the other unfixed bug being in binutils rather than GCC :-)
[Bug c++/91793] [8/9/10 Regression] ICE on unexpanded parameter pack in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91793 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |8.4 Summary|[8/9/trunk regression] ICE |[8/9/10 Regression] ICE on |on unexpanded parameter |unexpanded parameter pack |pack in lambda |in lambda
[Bug c++/91793] [8/9/trunk regression] ICE on unexpanded parameter pack in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91793
--- Comment #2 from Cyp ---
Compiler output from reduced testcase:
---
91793.cpp: In instantiation of ‘ [with auto:1 = {}]’:
91793.cpp:6:4: required from here
91793.cpp:4:25: internal compiler error: Segmentation fault
using b = decltype(a);
^
0xb61e5f crash_signal
/var/tmp/portage/sys-devel/gcc-8.3.0-r1/work/gcc-8.3.0/gcc/toplev.c:325
0x7f1b8e9f202f ???
/var/tmp/portage/sys-libs/glibc-2.29-r2/work/glibc-2.29/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x70ea21 invalid_nonstatic_memfn_p(unsigned int, tree_node*, int)
/var/tmp/portage/sys-devel/gcc-8.3.0-r1/work/gcc-8.3.0/gcc/cp/typeck.c:1887
0x6f546a finish_decltype_type(tree_node*, bool, int)
/var/tmp/portage/sys-devel/gcc-8.3.0-r1/work/gcc-8.3.0/gcc/cp/semantics.c:8769
0x6c5661 tsubst(tree_node*, tree_node*, int, tree_node*)
/var/tmp/portage/sys-devel/gcc-8.3.0-r1/work/gcc-8.3.0/gcc/cp/pt.c:14982
0x6d6734 tsubst_decl
/var/tmp/portage/sys-devel/gcc-8.3.0-r1/work/gcc-8.3.0/gcc/cp/pt.c:13704
0x6c5d5f tsubst(tree_node*, tree_node*, int, tree_node*)
/var/tmp/portage/sys-devel/gcc-8.3.0-r1/work/gcc-8.3.0/gcc/cp/pt.c:14217
0x6c2b31 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-8.3.0-r1/work/gcc-8.3.0/gcc/cp/pt.c:16707
0x6c17ae tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-8.3.0-r1/work/gcc-8.3.0/gcc/cp/pt.c:16930
0x6c17ae tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-8.3.0-r1/work/gcc-8.3.0/gcc/cp/pt.c:16930
0x6d7578 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-8.3.0-r1/work/gcc-8.3.0/gcc/cp/pt.c:16615
0x6d7578 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
/var/tmp/portage/sys-devel/gcc-8.3.0-r1/work/gcc-8.3.0/gcc/cp/pt.c:17685
0x6cee41 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/var/tmp/portage/sys-devel/gcc-8.3.0-r1/work/gcc-8.3.0/gcc/cp/pt.c:18971
0x6c22d4 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-8.3.0-r1/work/gcc-8.3.0/gcc/cp/pt.c:17446
0x6c2098 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-8.3.0-r1/work/gcc-8.3.0/gcc/cp/pt.c:16644
0x6c18e6 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-8.3.0-r1/work/gcc-8.3.0/gcc/cp/pt.c:16630
0x6c17ae tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-8.3.0-r1/work/gcc-8.3.0/gcc/cp/pt.c:16930
0x6c17ae tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-8.3.0-r1/work/gcc-8.3.0/gcc/cp/pt.c:16930
0x6c03a3 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-8.3.0-r1/work/gcc-8.3.0/gcc/cp/pt.c:16615
0x6c03a3 instantiate_decl(tree_node*, bool, bool)
/var/tmp/portage/sys-devel/gcc-8.3.0-r1/work/gcc-8.3.0/gcc/cp/pt.c:24066
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/91793] [8/9/trunk regression] ICE on unexpanded parameter pack in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91793
--- Comment #1 from Cyp ---
Reduced (creduce) testcase which reproduces ICE:
---
int a(
[](auto... a) {
[] {
using b = decltype(a);
};
}()
---
[Bug c++/91780] Discrepancy between gcc 7.4, through 9.2, compared to clang.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91780 --- Comment #1 from Mikael Persson --- To clarify it also does not work in gcc trunk.
[Bug fortran/91588] ICE in check_inquiry, at fortran/expr.c:2673
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91588 --- Comment #4 from Paul Thomas --- Author: pault Date: Tue Sep 17 08:30:50 2019 New Revision: 275800 URL: https://gcc.gnu.org/viewcvs?rev=275800=gcc=rev Log: 2019-09-17 Paul Thomas PR fortran/91588 * expr.c (check_inquiry): Remove extended component refs by using symbol pointers. If a function argument is an associate variable with a constant target, copy the target expression in place of the argument expression. Check that the charlen is not NULL before using the string length. (gfc_check_assign): Remove extraneous space. 2019-09-17 Paul Thomas PR fortran/91588 * gfortran.dg/associate_49.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/associate_49.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug c++/91793] New: [8/9/trunk regression] ICE on unexpanded parameter pack in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91793
Bug ID: 91793
Summary: [8/9/trunk regression] ICE on unexpanded parameter
pack in lambda
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cyp561 at gmail dot com
Target Milestone: ---
Managed to produce a parameter pack expansion that works in clang
trunk but not GCC trunk today: https://godbolt.org/z/PkaZqQ. No bugzilla
account, so can't report it.
Also some deliberately incorrect expansion that causes GCC to
segfault: https://godbolt.org/z/rpi-qC
Might be related to Bug 84936.
#include
#include
#include
template
void invoke_all_of(Funcs&&... f) {
// initializer_list is special, and guarantees that the ... is expanded in
order.
(void)std::initializer_list{(void(
std::forward(f)()
), false)...};
}
int main() {
std::apply([](auto... a) {
invoke_all_of([&]{
using A = decltype(a);
}/*...*/);
}, std::make_tuple(1));
}
: In instantiation of 'main():: [with auto:1 =
{int}]':
/opt/compiler-explorer/gcc-trunk-20190917/include/c++/10.0.0/type_traits:2490:26:
required by substitution of 'template static
std::__result_of_success()((declval<_Args>)()...)),
std::__invoke_other> std::__result_of_other_impl::_S_test(int) [with _Fn =
main()::; _Args = {int}]'
/opt/compiler-explorer/gcc-trunk-20190917/include/c++/10.0.0/type_traits:2501:55:
required from 'struct std::__result_of_impl, int>'
/opt/compiler-explorer/gcc-trunk-20190917/include/c++/10.0.0/type_traits:138:12:
recursively required by substitution of 'template
struct std::__is_invocable_impl<_Result, _Ret, true, std::__void_t > [with _Result = std::__invoke_result, int>; _Ret = void]'
/opt/compiler-explorer/gcc-trunk-20190917/include/c++/10.0.0/type_traits:138:12:
required from 'struct
std::__and_, int>, void, true, void>,
std::__call_is_nothrow, int>,
main()::, int> >'
/opt/compiler-explorer/gcc-trunk-20190917/include/c++/10.0.0/type_traits:2963:12:
required from 'struct std::is_nothrow_invocable,
int>'
/opt/compiler-explorer/gcc-trunk-20190917/include/c++/10.0.0/tuple:1603:27:
required from 'constexpr const bool std::__unpack_std_tuple struct std::is_nothrow_invocable, main()::, std::tuple >'
/opt/compiler-explorer/gcc-trunk-20190917/include/c++/10.0.0/tuple:1631:14:
required from 'constexpr decltype(auto) std::apply(_Fn&&, _Tuple&&) [with _Fn =
main()::; _Tuple = std::tuple]'
:18:26: required from here
:16:19: internal compiler error: Segmentation fault
16 | using A = decltype(a);
| ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
Compiler returned: 1
Leaving out the "/*" and "*/" gives: (compiles in clang)
: In lambda function:
:17:10: error: expansion pattern '' contains no parameter packs
17 | }...);
| ^~~
Compiler returned: 1
[Bug target/91749] [10 Regression] ICE in arm_asm_trampoline_template, at config/arm/arm.c:3973
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91749 Christophe Lyon changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Christophe Lyon --- Fixed
[Bug target/91749] [10 Regression] ICE in arm_asm_trampoline_template, at config/arm/arm.c:3973
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91749 --- Comment #4 from Christophe Lyon --- Author: clyon Date: Tue Sep 17 08:13:11 2019 New Revision: 275799 URL: https://gcc.gnu.org/viewcvs?rev=275799=gcc=rev Log: [PR91749][arm] FDPIC: Handle -mflip-thumb 2019-09-16 Christophe Lyon PR target/91749 * config/arm/arm.c (arm_valid_target_attribute_rec): Make sure the mode attributed is supported by FDPIC. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c
[Bug c++/91705] [9 Regression] operator++ broken in constexpr floating point code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91705 Andrew Pinski changed: What|Removed |Added CC||cyp561 at gmail dot com --- Comment #13 from Andrew Pinski --- *** Bug 91792 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/91790] ICE: verify_ssa failed (error: definition in block 2 follows the use)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91790 --- Comment #3 from Richard Biener --- Author: rguenth Date: Tue Sep 17 08:08:40 2019 New Revision: 275798 URL: https://gcc.gnu.org/viewcvs?rev=275798=gcc=rev Log: 2019-09-17 Richard Biener PR tree-optimization/91790 * tree-vect-stmts.c (vectorizable_load): For BB vectorization use the correct DR for setting up realignment. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug c++/91792] [9 Regression] constexpr ++ or -- evaluation fails on float or double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91792 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Fixed around a week ago: 91705 *** This bug has been marked as a duplicate of bug 91705 ***
[Bug tree-optimization/91790] ICE: verify_ssa failed (error: definition in block 2 follows the use)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91790 Richard Biener changed: What|Removed |Added Known to work||10.0 --- Comment #2 from Richard Biener --- Fixed on trunk sofar. At least GCC 9 is affected as well.
[Bug c++/91792] New: [9 Regression] constexpr ++ or -- evaluation fails on float or double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91792
Bug ID: 91792
Summary: [9 Regression] constexpr ++ or -- evaluation fails on
float or double
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cyp561 at gmail dot com
Target Milestone: ---
According to https://godbolt.org/z/XzT1wz, compiles in 8.3 and trunk. Fails
compilation on 9.2.
constexpr float f() { float x = 42; ++x; return x; }
void g() { constexpr float x = f(); }
: In function 'void g()':
:2:33: in 'constexpr' expansion of 'f()'
:2:34: error: '((float)1 + 4.2e+1f)' is not a constant expression
2 | void g() { constexpr float x = f(); }
| ^
[Bug ada/91268] [10 Regression] adaint.c:38: warning: "_REENTRANT" redefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91268 --- Comment #2 from pmderodat at gcc dot gnu.org --- Author: pmderodat Date: Tue Sep 17 07:59:43 2019 New Revision: 275774 URL: https://gcc.gnu.org/viewcvs?rev=275774=gcc=rev Log: [Ada] PR ada/91268 Do not redefine macros This should fix PR ada/91268 by only defining macros if not already done. 2019-09-17 Arnaud Charlet gcc/ada/ * adaint.c (_REENTRANT, _THREAD_SAFE): Only define if needed. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/adaint.c
[Bug tree-optimization/91790] ICE: verify_ssa failed (error: definition in block 2 follows the use)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91790
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2019-09-17
Blocks||53947
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Summary|ICE: Segmentation fault (in |ICE: verify_ssa failed
|vr_values::vrp_visit_assign |(error: definition in block
|ment_or_call), or ICE: |2 follows the use)
|verify_ssa failed (error: |
|definition in block 2 |
|follows the use)|
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Clearly a vectorizer issue. Somewhat oldish. Fix
Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c (revision 275747)
+++ gcc/tree-vect-stmts.c (working copy)
@@ -9169,7 +9169,9 @@ vectorizable_load (stmt_vec_info stmt_in
|| alignment_support_scheme == dr_explicit_realign)
&& !compute_in_loop)
{
- msq = vect_setup_realignment (first_stmt_info, gsi, _token,
+ msq = vect_setup_realignment (first_stmt_info_for_drptr
+ ? first_stmt_info_for_drptr
+ : first_stmt_info, gsi, _token,
alignment_support_scheme, NULL_TREE,
_loop);
if (alignment_support_scheme == dr_explicit_realign_optimized)
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug c++/91777] No warning for iterator going out of scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91777 --- Comment #6 from Andrew Pinski --- So here is the thing. Tracking things via memory is hard.
