[Bug c++/89392] [7/8/9 Regression] ICE in bitmap_bit_p, at bitmap.c:978
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89392 --- Comment #6 from rguenther at suse dot de --- On Tue, 19 Feb 2019, ctice at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89392 > > --- Comment #5 from ctice at gcc dot gnu.org --- > I have been unable to reproduce this error, using the latest GCC and building > with VTV enabled. What architecture are you using? How are you configuring > your GCC build? I can reproduce on latest trunk when configuring with --disable-bootstrap --enable-valgrind-annotations (it's just a development build). But it also reproduces with system-installed gcc 7 and 8: > g++-8 t.cc -O -flto -fvtable-verify=std during GIMPLE pass: ealias t.cc: In function ‘_GLOBAL__sub_I.00099_t’: t.cc:4:4: internal compiler error: Segmentation fault s t; ^ 0x7ff556798fdf ??? > g++-7 t.cc -O -flto -fvtable-verify=std t.cc: In function ‘_GLOBAL__sub_I.00099_t’: t.cc:4:4: internal compiler error: Segmentation fault s t; ^ Please submit a full bug report,
[Bug middle-end/89091] ICE: Segmentation fault (in tree_class_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89091
--- Comment #3 from David Binderman ---
for gcc/testsuite/gcc.dg/pr89037.c, valgrind says:
./gcc.dg/pr89037.c:9:9: warning: missing braces around initializer
[-Wmissing-braces]
9 | T a[] = { 1, 1, 0x12345, 0xff01, 1ULL << 63, (__int128) 1 <<
64,
| ^
| {} {} { } { } { } {
}
10 |((__int128) 1 << 64) | 1 };
|{}
==11913== Invalid read of size 2
==11913==at 0x7F5B96: decode_field_reference(unsigned int, tree_node**,
long*, long*, machine_mode*, int*, int*, int*, tree_node**, tree_node**)
(fold-const.c:4327)
[Bug middle-end/89091] ICE: Segmentation fault (in tree_class_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89091 --- Comment #4 from Arseny Solokha --- (In reply to David Binderman from comment #3) > for gcc/testsuite/gcc.dg/pr89037.c, valgrind says: That's where I've minimized my testcase from.
[Bug c/89410] [7/8/9 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #4 from Jonny Grant ---
There's another related issue, can it be covered on this ticket?
GCC does not show the part of the output below I marked with after commenting
out line 4 <-
#1 with x86-64 gcc (trunk)
: In function 'main':
:6:7: warning: line number out of range
6 | #line 9223372036854775807<-
| ^~~
int main(void)
{
// Note: Comment back in the next line to reproduce
//#line 12147483647
#line 9223372036854775807
}
[Bug fortran/89413] New: [8/9 Regression] ICE in resolve_fl_derived, at fortran/resolve.c:14392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89413 Bug ID: 89413 Summary: [8/9 Regression] ICE in resolve_fl_derived, at fortran/resolve.c:14392 Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- gfortran-9.0.0-alpha20190217 snapshot (r268974) ICEs when compiling the following testcase: program sj type :: t5 () class (t5 ()), pointer :: ys end type t5 end program sj % powerpc-e300c3-linux-gnu-gfortran-9.0.0-alpha20190217 -c j1kbey21.f90 f951: internal compiler error: in resolve_fl_derived, at fortran/resolve.c:14392 0x574e6f resolve_fl_derived /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190217/work/gcc-9-20190217/gcc/fortran/resolve.c:14392 0x813497 resolve_symbol /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190217/work/gcc-9-20190217/gcc/fortran/resolve.c:14773 0x83c002 do_traverse_symtree /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190217/work/gcc-9-20190217/gcc/fortran/symbol.c:4156 0x820505 resolve_types /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190217/work/gcc-9-20190217/gcc/fortran/resolve.c:16685 0x81243e gfc_resolve(gfc_namespace*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190217/work/gcc-9-20190217/gcc/fortran/resolve.c:16799 0x804206 resolve_all_program_units /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190217/work/gcc-9-20190217/gcc/fortran/parse.c:6073 0x804206 gfc_parse_file() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190217/work/gcc-9-20190217/gcc/fortran/parse.c:6323 0x851d8e gfc_be_parse_file /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190217/work/gcc-9-20190217/gcc/fortran/f95-lang.c:204 (While my target here is powerpc, the ICE is not target-specific.)
[Bug c/89408] No constant folding when dereferencing string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89408 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- One thing is optimization, which gcc is obviously able to constant fold this, the other is the C language, which requires a constant expression (language term) and this expression is not such a constant expression. So, it is not valid C (and not valid C++98, but valid C++11 and later).
[Bug middle-end/89412] [8/9 Regression] gcc ICE in simplify_subreg, at simplify-rtx.c:6273 on i686-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89412 Matthias Klose changed: What|Removed |Added Summary|[8 Regression] bootstrap|[8/9 Regression] gcc ICE in |fails in libgfortran on |simplify_subreg, at |powerpc64le-linux-gnu |simplify-rtx.c:6273 on ||i686-linux-gnu --- Comment #1 from Matthias Klose --- also seen on the trunk, checked r268955.
[Bug fortran/89413] [8/9 Regression] ICE in resolve_fl_derived, at fortran/resolve.c:14392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89413 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |8.3
[Bug middle-end/89412] [7/8/9 Regression] gcc ICE in simplify_subreg, at simplify-rtx.c:6273 on i686-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89412 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-20 Known to work|8.2.0 |6.1.0 Target Milestone|--- |7.5 Summary|[8/9 Regression] gcc ICE in |[7/8/9 Regression] gcc ICE |simplify_subreg, at |in simplify_subreg, at |simplify-rtx.c:6273 on |simplify-rtx.c:6273 on |i686-linux-gnu |i686-linux-gnu Ever confirmed|0 |1 Known to fail||6.2.0, 7.1.0 --- Comment #2 from Richard Biener --- Fails for me with GCC 8.1.0 and 8.2.0 as well on i?86-linux (and x86_64 with -m32). Also GCC 7 and GCC 6 (but 6.1.0 is fine).
[Bug c/89410] [7/8/9 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.5
[Bug go/89406] Go testing leaves many temporary directories in /tmp around
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89406 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-20 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug c++/89404] [7/8/9 Regression] ICE in build_value_init_noctor, at cp/init.c:467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89404 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/89403] [7/8/9 Regression] ICE in maybe_clone_body, at cp/optimize.c:693
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89403 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug libstdc++/89402] [9 Regression] warning: ‘void _ZNKSt4hashIeEclEe()’ specifies less restrictive attribute than its target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89402 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug middle-end/89412] [7/8/9 Regression] gcc ICE in simplify_subreg, at simplify-rtx.c:6273 on i686-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89412
--- Comment #3 from Uroš Bizjak ---
Middle-end wants to create a subreg of BLKmode:
#3 0x00cd5899 in simplify_gen_subreg
(outermode=outermode@entry=E_DCmode, op=op@entry=0x7fffea778240,
innermode=E_BLKmode, byte=byte@entry=...)
at ../../git/gcc/gcc/simplify-rtx.c:6709
6709 newx = simplify_subreg (outermode, op, innermode, byte);
(gdb) p outermode
$1 = E_DCmode
(gdb) p innermode
$2 = E_BLKmode
(gdb) p debug_rtx (op)
(mem/c:BLK (symbol_ref:SI ("d") [flags 0x2] ) [3 d+0
S16 A32])
[Bug other/89347] gc-sections doesn't remove unused bss section variables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89347 --- Comment #3 from Maninder Singh --- But its not mentioned in gc-section or data-section manual pages, either that needs updation or it need to be handled by -fdata-section flag only. https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Optimize-Options.html#Optimize-Options -ffunction-sections -fdata-sections Place each function or data item into its own section in the output file if the target supports arbitrary sections. The name of the function or the name of the data item determines the section’s name in the output file. Use these options on systems where the linker can perform optimizations to improve locality of reference in the instruction space. Most systems using the ELF object format have linkers with such optimizations. On AIX, the linker rearranges sections (CSECTs) based on the call graph. The performance impact varies. Together with a linker garbage collection (linker --gc-sections option) these options may lead to smaller statically-linked executables (after stripping). On ELF/DWARF systems these options do not degenerate the quality of the debug information. There could be issues with other object files/debug info formats. Only use these options when there are significant benefits from doing so. When you specify these options, the assembler and linker create larger object and executable files and are also slower. These options affect code generation. They prevent optimizations by the compiler and assembler using relative locations inside a translation unit since the locations are unknown until link time. An example of such an optimization is relaxing calls to short call instructions.
[Bug fortran/89413] [PDT] ICE in resolve_fl_derived, at fortran/resolve.c:14392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89413 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-20 CC||pault at gcc dot gnu.org Blocks||82173 Summary|[8/9 Regression] ICE in |[PDT] ICE in |resolve_fl_derived, at |resolve_fl_derived, at |fortran/resolve.c:14392 |fortran/resolve.c:14392 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed, but it is not exactly a regression. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173 [Bug 82173] [meta-bug] Parameterized derived type errors
[Bug c/87924] OpenACC wait clauses without async-arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87924 --- Comment #4 from Chung-Lin Tang --- Author: cltang Date: Wed Feb 20 10:09:53 2019 New Revision: 269036 URL: https://gcc.gnu.org/viewcvs?rev=269036&root=gcc&view=rev Log: Correction of ChangeLog entry, Thomas provided the code for this change. 2019-02-19 Thomas Schwinge PR c/87924 * openmp.c (gfc_match_omp_clauses): Add representation of wait clause without argument as 'wait (GOMP_ASYNC_NOVAL)'. Modified: trunk/gcc/fortran/ChangeLog
[Bug fortran/89365] Inquiry functions for assumed rank objects fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89365 --- Comment #3 from Bader at lrz dot de --- I agree with Harald's assessment. The test case as delivered by me is indeed incorrectly written for the POINTER and ALLOCATABLE cases, in both of which I believe the bounds should be taken from the actual argument (versus remapping them). This has historical reasons (ifort has the POINTER and ALLOCATABLE case wrong), and the F2018 drafts did pick up some additional words in the last phase of corrections (see 8.5.8.7 para 1: "The bounds and shape of an assumed-rank entity with the ALLOCATABLE or POINTER attribute are determined as specified in 8.5.8.4." Regards Reinhold
[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262 --- Comment #20 from Egeyar Bagcioglu --- This issue is fixed in gold for binutils 2.33: https://sourceware.org/bugzilla/show_bug.cgi?id=23870
[Bug fortran/89365] Inquiry functions for assumed rank objects fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89365 --- Comment #4 from Dominique d'Humieres --- > I agree with Harald's assessment. The test case as delivered by me > is indeed incorrectly written for the POINTER and ALLOCATABLE cases, > in both of which I believe the bounds should be taken from the actual > argument (versus remapping them). So is the PR valid or not?
[Bug fortran/89365] Inquiry functions for assumed rank objects fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89365 --- Comment #5 from Bader at lrz dot de --- The corrected test case passes all tests, so the PR can be closed. Sorry for the noise.
[Bug c++/84536] [7/8/9 Regression] ICE with non-type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84536 --- Comment #3 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed Feb 20 10:47:02 2019 New Revision: 269037 URL: https://gcc.gnu.org/viewcvs?rev=269037&root=gcc&view=rev Log: /cp 2019-02-20 Paolo Carlini PR c++/84536 * pt.c (tsubst_init): Diagnose an initializer expanding to an empty list of expressions; tweak wrt dependent types. (regenerate_decl_from_template): For VAR_DECLs call tsubst_init instead of tsubst_expr. /testsuite 2019-02-20 Paolo Carlini PR c++/84536 * g++.dg/cpp1y/var-templ60.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp1y/var-templ60.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/88973] [8/9 Regression] New -Wrestrict warning since r268048
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88973 --- Comment #6 from Martin Liška --- (In reply to Bruce Korb from comment #5) > (In reply to Martin Sebor from comment #4) > > > canonicalize_pathname.c: In function ‘canonicalize_pathname’: > > canonicalize_pathname.c:61:2: warning: ‘strcpy’ accessing 1 byte at offsets > > [0, 9223372036854775807] and [0, 9223372036854775807] may overlap 1 byte at > > offset 0 [-Wrestrict] > >61 | strcpy( result + start + 1, result + i + 2 ); > > | ^~~~ > > strcpy (0x217f265 = "//bar", 0x217f267 = "bar"): 3 > > /foo/bar > > I have a copy of this code in my project, but I haven't been writing code > for several years now. How was this fixed? The best fix would be to > determine the string length and do memmove-s, but that's enough fiddling > that I'd have to clear cobwebs and spend a mess of time. If someone's > already done that, ... :) There's an upstream bug: https://sourceforge.net/p/autogen/bugs/193/ and I'm working on patch candidate.
[Bug tree-optimization/88973] [8/9 Regression] New -Wrestrict warning since r268048
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88973 --- Comment #7 from Martin Liška --- (In reply to Martin Sebor from comment #4) > I've created a test case using the canonicalize_pathname function showing > that it does, in fact, cause an overlap to take place. The following line > in the output of the test case > Thank you very much Martin for it! Btw. ASAN prints nice error about overlapping arguments: gcc -DPATHNAME='"/home//marxin"' -Wall canonicalize_pathname.c -fsanitize=address -g && ./a.out = ==14653==ERROR: AddressSanitizer: strcpy-param-overlap: memory ranges [0x60200016,0x6020001d) and [0x60200017, 0x6020001e) overlap #0 0x772051de (/usr/lib64/libasan.so.5+0x4b1de) #1 0x40137c in canonicalize_pathname /tmp/canonicalize_pathname.c:25 #2 0x401857 in main /tmp/canonicalize_pathname.c:64 #3 0x77018b7a in __libc_start_main ../csu/libc-start.c:308 #4 0x4010e9 in _start (/tmp/a.out+0x4010e9)
[Bug rtl-optimization/89414] New: wrong code with -Og -fno-forward-propagate -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89414
Bug ID: 89414
Summary: wrong code with -Og -fno-forward-propagate
-fno-tree-fre
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: armv7a-hardfloat-linux-gnueabi
Created attachment 45769
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45769&action=edit
reduced testcase
Output:
$ armv7a-hardfloat-linux-gnueabi-gcc -Og -fno-forward-propagate -fno-tree-fre
testcase.c -static
$ qemu-arm ./a.out
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
$ armv7a-hardfloat-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-armv7a-hardfloat/bin/armv7a-hardfloat-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-269006-checking-yes-rtl-df-extra-armv7a-hardfloat/bin/../libexec/gcc/armv7a-hardfloat-linux-gnueabi/9.0.1/lto-wrapper
Target: armv7a-hardfloat-linux-gnueabi
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-float=hard --with-fpu=vfpv4
--with-arch=armv7-a --with-sysroot=/usr/armv7a-hardfloat-linux-gnueabi
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=armv7a-hardfloat-linux-gnueabi
--with-ld=/usr/bin/armv7a-hardfloat-linux-gnueabi-ld
--with-as=/usr/bin/armv7a-hardfloat-linux-gnueabi-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-269006-checking-yes-rtl-df-extra-armv7a-hardfloat
Thread model: posix
gcc version 9.0.1 20190219 (experimental) (GCC)
In the assembly output:
foo:
@ args = 8, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push{r4, lr}@
@ testcase.c:5: a = __builtin_parityll (a);
movwr4, #:lower16:a @ tmp124,
movtr4, #:upper16:a @ tmp124,
ldr r0, [r4]@ a, a
asr r1, r0, #31 @, a,
bl __paritydi2 @
@ testcase.c:5: a = __builtin_parityll (a);
str r0, [r4]@ tmp139, a
@ testcase.c:6: b = __builtin_bswap64 (h);
mov r2, #0 @ tmp131,
@ testcase.c:6: b = __builtin_bswap64 (h);
movwr3, #:lower16:b @ tmp132,
movtr3, #:upper16:b @ tmp132,
str r2, [r3]@ tmp131, b
@ testcase.c:7: __builtin_memset (&h, b, 1);
strbr2, [sp, #4]@ tmp131, MEM[(void *)&h]
*** ^^^ this overwrites the return address *** ('h' has no stack slot
allocated)
@ testcase.c:9: }
mov r0, r2 @, tmp131
pop {r4, pc}@
[Bug sanitizer/89409] [9 Regression] FAIL: c-c++-common/ubsan/div-by-zero-[67].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89409 --- Comment #4 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01645.html
[Bug middle-end/89415] gcc.dg/sinatan-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89415 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug middle-end/89415] New: gcc.dg/sinatan-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89415 Bug ID: 89415 Summary: gcc.dg/sinatan-1.c FAILs Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: sparc-sun-solaris2.11, aarch64-unknown-linux-gnu, hppa2.0w-hp-hpux11.11, hppa64-hp-hpux11.11, i586-unknown-freebsd11.2, ia64-suse-linux-gnu, moxie-unknown-elf, s390x-ibm-linux-gnu, spu-unknown-elf, x86_64-unknown-freebsd11.2, x86_64-w64-mingw32 Between 20190218 (r268990) and 20190219 (r269021), the gcc.dg/sinatan-1.c began to FAIL: +FAIL: gcc.dg/sinatan-1.c execution test I see it on 32 and 64-bit Solaris/SPARC, but quite a number of other targets is affected, too. Thread 2 received signal SIGABRT, Aborted. [Switching to Thread 1 (LWP 1)] 0xfec7e740 in __lwp_sigqueue () from /lib/libc.so.1 (gdb) where #0 0xfec7e740 in __lwp_sigqueue () from /lib/libc.so.1 #1 0xfebb99f0 in raise () from /lib/libc.so.1 #2 0xfeb8b2d0 in abort () from /lib/libc.so.1 #3 0x0001126c in main () at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/sinatan-1.c:85 Maybe this is due to 2019-02-19 Richard Biener PR middle-end/88074 * toplev.c (do_compile): Initialize mpfr's exponent range based on available float modes. * gcc.dg/pr88074.c: New testcase.
[Bug middle-end/89415] gcc.dg/sinatan-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89415 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #1 from Christophe Lyon --- Yes, bisect confirmed it's due to that commit (r269015)
[Bug middle-end/89415] gcc.dg/sinatan-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89415 --- Comment #2 from Christophe Lyon --- I'm not sure it's worth opening another regression report, but that same commit creates regressions in fortran on arm: FAIL: gfortran.dg/integer_exponentiation_3.F90 -O0 (test for warnings, line 173) FAIL: gfortran.dg/integer_exponentiation_3.F90 -O1 (test for warnings, line 173) FAIL: gfortran.dg/integer_exponentiation_3.F90 -O2 (test for warnings, line 173) FAIL: gfortran.dg/integer_exponentiation_3.F90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for warnings, line 173) FAIL: gfortran.dg/integer_exponentiation_3.F90 -O3 -g (test for warnings, line 173) FAIL: gfortran.dg/integer_exponentiation_3.F90 -Os (test for warnings, line 173)
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #34 from Eric Gallager --- (In reply to Sebastian Huber from comment #33) > (In reply to Eric Gallager from comment #32) > > (In reply to Martin Liška from comment #31) > > > Can the bug be marked as resolved? > > > > WAITING on a reply. > > From my point of view it is fixed > > I guess since Daniel Gutson didn't get an answer in the last four years, he > will unlikely get it in the future. ok, closing then.
[Bug middle-end/89415] gcc.dg/sinatan-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89415 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- See https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01650.html
[Bug c++/89405] [8/9 Regression] ICE in import_export_decl, at cp/decl2.c:2959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89405 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 45770 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45770&action=edit gcc9-pr89405.patch Untested fix.
[Bug fortran/89385] Incorrect members of C descriptor for an allocatable object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89385 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-20 CC||pault at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- I get FAIL: this->elem_len -7 FAIL: this->type FAIL: this->rank 0 FAIL: this->attribute FAIL: dim[0] FAIL: dim[1] FAIL: that->elem_len FAIL: that->type FAIL: that->rank FAIL: that->attribute FAIL: dim[0] Due to #include "ISO_Fortran_binding.h" this PR compiles on trunk (9.0) only.
[Bug fortran/89348] Fortran Command Options documentation fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89348 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-20 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Patch approved at https://gcc.gnu.org/ml/fortran/2019-02/msg00116.html. As a general comment, there is no point to attach change logs to bugzilla: it is enough to add them when submitting the patches to the mailing lists. I also think there is no need to file a PR for such trivialities.
[Bug target/86487] [7/8/9 Regression] insn does not satisfy its constraints on arm big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86487 --- Comment #12 from avieira at gcc dot gnu.org --- Author: avieira Date: Wed Feb 20 14:11:43 2019 New Revision: 269039 URL: https://gcc.gnu.org/viewcvs?rev=269039&root=gcc&view=rev Log: [GCC] PR target/86487: fix the way 'uses_hard_regs_p' handles paradoxical subregs gcc/ChangeLog: 2019-02-20 Andre Vieira PR target/86487 * lra-constraints.c(uses_hard_regs_p): Fix handling of paradoxical SUBREGS. gcc/testsuite/ChangeLog: 2019-02-20 Andre Vieira PR target/86487 * gcc.target/arm/pr86487.c: New. Added: trunk/gcc/testsuite/gcc.target/arm/pr86487.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/89366] Fails to compile BIND(C) interface with assumed-length character argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89366 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-02-20 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- It has been my understanding that C interoperable CHARACTER should be of length 1, e.g., pr46496 comment 0, item f. Has it been changed in the extensions in C interoperable? If yes, could you please provide a pointer?
[Bug fortran/46496] Missing strlen check / interop warnings with BIND(C) and non-C_* kinds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46496 --- Comment #5 from Dominique d'Humieres --- b) -Wno-c-binding-type silences the warnings related to C binding. It remains in this PR the missed warnings in d) and e).
[Bug rtl-optimization/89414] wrong code with -Og -fno-forward-propagate -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89414
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-02-20
CC||jakub at gcc dot gnu.org,
||ktkachov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Can reproduce even with r208764 (oldest arm cross I have around).
Looks like a backend issue to me, in *.ira we still have:
(insn 32 42 33 2 (set (mem/c:QI (reg/f:SI 103 afp) [0 MEM[(void *)&h]+0 S1 A8])
(subreg:QI (reg:SI 132) 0)) "pr89414.c":7:3 189 {*arm_movqi_insn}
(expr_list:REG_DEAD (reg:SI 132)
(nil)))
and it is eliminated to:
(insn 32 42 33 2 (set (mem/c:QI (plus:SI (reg/f:SI 13 sp)
(const_int 4 [0x4])) [0 MEM[(void *)&h]+0 S1 A8])
(reg:QI 2 r2 [132])) "pr89414.c":7:3 189 {*arm_movqi_insn}
(nil))
even when pro_and_epilogue adds:
(insn/f 51 8 52 2 (parallel [
(set (mem/c:BLK (pre_modify:SI (reg/f:SI 13 sp)
(plus:SI (reg/f:SI 13 sp)
(const_int -8 [0xfff8]))) [2 A8])
(unspec:BLK [
(reg:SI 4 r4)
] UNSPEC_PUSH_MULT))
(use (reg:SI 14 lr))
]) "pr89414.c":4:1 -1
(expr_list:REG_FRAME_RELATED_EXPR (sequence [
(set/f (reg/f:SI 13 sp)
(plus:SI (reg/f:SI 13 sp)
(const_int -8 [0xfff8])))
(set/f (mem/c:SI (reg/f:SI 13 sp) [2 S4 A32])
(reg:SI 4 r4))
(set/f (mem/c:SI (plus:SI (reg/f:SI 13 sp)
(const_int 4 [0x4])) [2 S4 A32])
(reg:SI 14 lr))
])
(nil)))
in the prologue, so sp+4 can't be right. So, either something changed in the
frame size computation between RA and pro_and_epilogue (that would be a bug) or
the afp -> sp + offset elimination is incorrect.
[Bug middle-end/89415] [9 Regression] gcc.dg/sinatan-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89415 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Summary|gcc.dg/sinatan-1.c FAILs|[9 Regression] ||gcc.dg/sinatan-1.c FAILs
[Bug fortran/89366] Fails to compile BIND(C) interface with assumed-length character argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89366 --- Comment #2 from Bader at lrz dot de --- Fortran 2018 FDIS section 18.3.6, para 2, item 5, bullet 2: (5) any dummy argument without the VALUE attribute corresponds to a formal parameter of the prototype that is of a pointer type, and either • the dummy argument is interoperable with an entity of the referenced type (ISO/IEC 9899:2011, 6.2.5, 7.19, and 7.20.1) of the formal parameter, • the dummy argument is a nonallocatable nonpointer variable of type CHARACTER with assumed character length and the formal parameter is a pointer to CFI_cdesc_t, Note that as for all Fortran objects that don't have a C analog, interoperability is on the level of the procedure interface (not the object!), and the matching entity on the C side is the descriptor. Regards Reinhold
[Bug rtl-optimization/89414] wrong code with -Og -fno-forward-propagate -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89414 --- Comment #2 from Jakub Jelinek --- -march=armv7-a -mfpu=vfpv4 -mfloat-abi=hard -Og -fno-forward-propagate -fno-tree-fre is what I've been using for options.
[Bug fortran/89366] Fails to compile BIND(C) interface with assumed-length character argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89366 --- Comment #3 from Bader at lrz dot de --- Created attachment 45771 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45771&action=edit C code to be called Added the C side function call.
[Bug libstdc++/89416] New: [regression] std::vector::push_back no longer builds.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89416
Bug ID: 89416
Summary: [regression] std::vector::push_back no longer builds.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: emilio at crisal dot io
Target Milestone: ---
Created attachment 45772
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45772&action=edit
Test-case.
The attached test-case no longer builds.
It's a reduction from:
https://searchfox.org/mozilla-central/rev/93905b660fc99a5d52b683690dd26471daca08c8/tools/fuzzing/libfuzzer/FuzzerDriver.cpp#244
Both g++ and clang error. g++ errors with:
In file included from
/usr/include/c++/9/x86_64-redhat-linux/bits/c++allocator.h:33,
from /usr/include/c++/9/bits/allocator.h:46,
from /usr/include/c++/9/memory:63,
from /usr/include/c++/9/thread:39,
from t.cpp:1:
/usr/include/c++/9/ext/new_allocator.h: In instantiation of ‘void
__gnu_cxx::new_allocator<_Tp>::construct(_Up*, _Args&& ...) [with _Up =
std::thread; _Args = {const std::thread&}; _Tp = std::thread]’:
/usr/include/c++/9/bits/alloc_traits.h:226:6: required by substitution of
‘template static std::true_type
std::allocator_traits
>::__construct_helper::__test<_Alloc2,
>(int) [with _Alloc2 = fuzzer_allocator;
= ]’
/usr/include/c++/9/bits/alloc_traits.h:233:40: required from ‘struct
std::allocator_traits
>::__construct_helper’
/usr/include/c++/9/bits/alloc_traits.h:250:2: required by substitution of
‘template static
std::_Require >::__construct_helper<_Tp,
_Args>::type>, std::is_constructible<_Tp, _Args ...> > >
std::allocator_traits >::_S_construct<_Tp, _Args
...>(fuzzer_allocator&, _Tp*, _Args&& ...) [with _Tp =
std::thread; _Args = {const std::thread&}]’
/usr/include/c++/9/bits/alloc_traits.h:350:26: required by substitution of
‘template static decltype
(std::allocator_traits >::_S_construct(__a, __p,
(forward<_Args>)(std::allocator_traits::construct::__args)...))
std::allocator_traits >::construct<_Tp, _Args
...>(fuzzer_allocator&, _Tp*, _Args&& ...) [with _Tp =
std::thread; _Args = {const std::thread&}]’
/usr/include/c++/9/bits/alloc_traits.h:587:38: required by substitution of
‘template static std::true_type
std::__is_alloc_insertable_impl >::_M_select<_Up,
_Tp, >(int) [with _Up = const std::thread&; _Tp =
std::thread; = ]’
/usr/include/c++/9/bits/alloc_traits.h:598:57: required from ‘class
std::__is_alloc_insertable_impl >’
/usr/include/c++/9/bits/alloc_traits.h:616:12: required from ‘struct
std::__is_move_insertable >’
/usr/include/c++/9/bits/stl_vector.h:446:28: required from ‘static constexpr
bool std::vector<_Tp, _Alloc>::_S_use_relocate() [with _Tp = std::thread;
_Alloc = fuzzer_allocator]’
/usr/include/c++/9/bits/vector.tcc:459:44: required from ‘void
std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp, _Alloc>::iterator,
_Args&& ...) [with _Args = {void (&)()}; _Tp = std::thread; _Alloc =
fuzzer_allocator; std::vector<_Tp, _Alloc>::iterator =
__gnu_cxx::__normal_iterator > >; typename std::_Vector_base<_Tp,
_Alloc>::pointer = std::thread*]’
/usr/include/c++/9/bits/vector.tcc:121:4: required from ‘void
std::vector<_Tp, _Alloc>::emplace_back(_Args&& ...) [with _Args = {void (&)()};
_Tp = std::thread; _Alloc = fuzzer_allocator]’
t.cpp:30:30: required from here
/usr/include/c++/9/ext/new_allocator.h:145:20: error: use of deleted function
‘std::thread::thread(const std::thread&)’
145 | noexcept(noexcept(::new((void *)__p)
|^~
146 |_Up(std::forward<_Args>(__args)...)))
|~~~
In file included from t.cpp:1:
/usr/include/c++/9/thread:142:5: note: declared here
142 | thread(const thread&) = delete;
| ^~
clang++ errors with:
In file included from t.cpp:1:
In file included from
/usr/bin/../lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/thread:39:
In file included from
/usr/bin/../lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/memory:63:
In file included from
/usr/bin/../lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/bits/allocator.h:46:
In file included from
/usr/bin/../lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/x86_64-redhat-linux/bits/c++allocator.h:33:
/usr/bin/../lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/ext/new_allocator.h:146:8:
error: call to deleted constructor of 'std::thread'
_Up(std::forward<_Args>(__args)...)))
^ ~~~
/usr/bin/../lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/bits/alloc_traits.h:226:52:
note: in instantiation of exception specification for
'construct' requested here
typename = decltype(std::declval<_Alloc2*>()->construct(
[Bug middle-end/89091] ICE: Segmentation fault (in tree_class_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89091 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 45773 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45773&action=edit gcc9-pr89091.patch I'd just return NULL in that case. While in theory we could just build_nonstandard_integer_type or similar, I think for these > 64 bit bitfields it will be hardly a win and we'd need to ensure the backend will be able to deal with those types.
[Bug fortran/89366] Fails to compile BIND(C) interface with assumed-length character argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89366 --- Comment #4 from Dominique d'Humieres --- > Fortran 2018 FDIS section 18.3.6, para 2, item 5, bullet 2: On my draft it is probably 18.3.7 Interoperability of procedures and procedure interfaces For character(kind=c_char,len=:), allocatable :: s2 character(kind=c_char,len=:), pointer :: s3 > • the dummy argument is a nonallocatable nonpointer variable of type > CHARACTER with assumed character length and the formal parameter > is a pointer to CFI_cdesc_t, does not seem to apply. Is it not rather > • the dummy argument is allocatable, assumed-shape, assumed-rank, > or a pointer without the CONTIGUOUS attribute, and the formal parameter > is a pointer to CFI_cdesc_t?
[Bug middle-end/89412] [7/8/9 Regression] gcc ICE in simplify_subreg, at simplify-rtx.c:6273 on i686-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89412
--- Comment #4 from Jakub Jelinek ---
Started with r237429. Don't know why this has anything to do with libgfortran
powerpc64le-linux bootstrap, that worked for me just fine in 8.3-rc1.
Slightly adjusted testcase:
struct S { double a, b; } d;
int e;
double f;
void
foo ()
{
_Complex h;
while (e)
{
f = h;
*(struct S *) &h = d;
}
}
[Bug middle-end/89412] [7/8/9 Regression] gcc ICE in simplify_subreg, at simplify-rtx.c:6273 on i686-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89412 --- Comment #5 from Matthias Klose --- bug title was a cut and paste error
[Bug c/89410] [7/8/9 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #5 from Jonny Grant ---
What appears to be a related issue. the "line number out of supported range"
does not show, even when gcc outputs a negative line number. Three test cases
below
I believe that the #line that pushes beyond 2^31 (The limit on my 64bit
machine) does not cause an error. Only the #pragma message following does.
Just a note:
// 2^31 - 1. Any more than this, and A1 overflows as "line3.c:-2147483648:9:
note: #pragma message: A1"
#line 2147483647
Anyway, the output
Current output from gcc trunk godbolt:
#1 with x86-64 gcc (trunk)
: In function 'main':
:-2147483647:9: note: #pragma message: B
Compiler returned: 0
What I expected:
#1 with x86-64 gcc (trunk)
: In function 'main':
: warning: #line number 2147483649 out of supported range
:-2147483647:9: note: #pragma message: B
Compiler returned: 0
The program:
int main(void)
{
#line 2147483649
#pragma message "B "
}
It would be good if GCC could change to show the offending number, and write it
as #line. As GCC does in other output:
int main(void)
{
#line FOO
}
#1 with x86-64 gcc (trunk)
: In function 'main':
:3:7: error: "FOO" after #line is not a positive integer
3 | #line FOO
| ^~~
Compiler returned: 1
Another program which does manage to show "warning: line number out of out of
supported range"
#1 with x86-64 gcc (trunk)
: In function 'main':
:3:7: warning: line number out of range
3 | #line 112147483647
| ^~~~
Compiler returned: 0
int main(void)
{
#line 112147483647
}
[Bug target/89397] [7/8 Regression] ICE in build_call_expr_loc_array at gcc/tree.c:11563 since r229082
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89397 --- Comment #5 from uros at gcc dot gnu.org --- Author: uros Date: Wed Feb 20 15:23:47 2019 New Revision: 269040 URL: https://gcc.gnu.org/viewcvs?rev=269040&root=gcc&view=rev Log: Revert: PR target/89397 * config/i386/i386.c (ix86_option_override_internal): Set opts->x_ix86_fpmath to FPMATH_387 when SSE is disabled. gcc/testsuite/ PR target/89397 * gcc.target/i386/pr89397.c: New test. Removed: trunk/gcc/testsuite/gcc.target/i386/pr89397.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/89091] ICE: Segmentation fault (in tree_class_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89091 David Malcolm changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|dmalcolm at gcc dot gnu.org|unassigned at gcc dot gnu.org --- Comment #7 from David Malcolm --- Jakub: should we go with your patch?
[Bug middle-end/89091] ICE: Segmentation fault (in tree_class_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89091 --- Comment #6 from David Malcolm --- Created attachment 45774 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45774&action=edit Patch I came up with this patch; it survives bootstrap®rtesting, but am not sure if it's correct.
[Bug c/89410] [7/8/9 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #6 from Jonny Grant ---
Could this show the offending number in the "line number out of range" message?
And even the origin of the LINE1 macro too?
Actual:
#1 with x86-64 gcc (trunk)
: In function 'main':
:4:7: warning: line number out of range
4 | #line LINE1
| ^
Compiler returned: 0
Expected eg:
#1 with x86-64 gcc (trunk)
: In function 'main':
:4:7: warning: line number 112147483647 out of range
4 | #line LINE1
| ^
LINE1 was defined in header.h:10
Compiler returned: 0
#define LINE1 112147483647
int main(void)
{
#line LINE1
}
[Bug fortran/89366] Fails to compile BIND(C) interface with assumed-length character argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89366 --- Comment #5 from Bader at lrz dot de --- No. The dummy argument of the procedure process_string is declared character(kind=c_char,len=*), intent(in) :: this there is no POINTER or ALLOCATABLE attribute there. Regards Reinhold
[Bug rtl-optimization/88347] ICE in begin_move_insn, at sched-ebb.c:175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88347 Segher Boessenkool changed: What|Removed |Added Priority|P3 |P2
[Bug c++/87844] ICE in tsubst_copy using non-constant expression as a non-type template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87844 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug middle-end/89091] ICE: Segmentation fault (in tree_class_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89091 --- Comment #8 from Jakub Jelinek --- Comment on attachment 45774 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45774 Patch Well, for the decode_field_reference, I think it is essential not to change *exp_ if returning NULL, because the caller uses lr_arg/rr_arg without checking whether it returned NULL or not. The c_common_type_for_size change is independent of the rest, I'd find it too risky for GCC9, but could be posted for GCC10. Sorry for looking on this, I saw you have it ASSIGNED but didn't see any patch on gcc-patches nor recent progress in the PR and thought some input might help.
[Bug middle-end/89412] [7/8/9 Regression] gcc ICE in simplify_subreg, at simplify-rtx.c:6273 on i686-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89412 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Created attachment 45775 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45775&action=edit gcc9-pr89412.patch Untested fix.
[Bug target/89397] [7/8 Regression] ICE in build_call_expr_loc_array at gcc/tree.c:11563 since r229082
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89397
--- Comment #6 from Uroš Bizjak ---
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 269040)
+++ config/i386/i386.c (working copy)
@@ -50689,7 +50689,7 @@
static void
ix86_atomic_assign_expand_fenv (tree *hold, tree *clear, tree *update)
{
- if (!TARGET_80387 && !TARGET_SSE_MATH)
+ if (!TARGET_80387 && !(TARGET_SSE && TARGET_SSE_MATH))
return;
tree exceptions_var = create_tmp_var_raw (integer_type_node);
if (TARGET_80387)
@@ -50724,7 +50724,7 @@
tree update_fldenv = build_call_expr (fldenv, 1, fenv_addr);
*update = build2 (COMPOUND_EXPR, void_type_node, *update,
update_fldenv);
}
- if (TARGET_SSE_MATH)
+ if (TARGET_SSE && TARGET_SSE_MATH)
{
tree mxcsr_orig_var = create_tmp_var_raw (unsigned_type_node);
tree mxcsr_mod_var = create_tmp_var_raw (unsigned_type_node);
[Bug c/89410] [7/8/9 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org
[Bug target/88055] ICE in extract_insn, at recog.c:2305 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88055 Segher Boessenkool changed: What|Removed |Added Priority|P3 |P2
[Bug c/89410] [7/8/9 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410 --- Comment #7 from Jonny Grant --- (In reply to Jonny Grant from comment #6) > Could this show the offending number in the "line number out of range" > message? And even the origin of the LINE1 macro too? clang shows the origin of the offending LINE1 macro #1 with x86-64 clang (trunk) :4:7: error: #line directive requires a positive integer argument #line LINE1 ^ :1:15: note: expanded from macro 'LINE1' #define LINE1 112147483647 ^ 1 error generated. Compiler returned: 1
[Bug target/80505] FAIL: gcc.dg/ipa/iinline-attr.c scan-ipa-dump inline "hooray[^\\n]*inline copy in test"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80505 Segher Boessenkool changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Segher Boessenkool --- This all works now. Please reopen if you still see FAILs.
[Bug tree-optimization/88973] [8/9 Regression] New -Wrestrict warning since r268048
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88973 --- Comment #8 from Martin Sebor --- The Asan warning is much clearer because it's based on actually observed values. This instance of the -Wrestrict warning is based on a heuristic: "we think the copy may overlap because it is within the same object and we can't prove that the offsets and the size assure it doesn't happen." There may be a way to reword the warning to make things a little bit clearer but I don't think we can match the Asan form. When the offsets and the size are completely unbounded we could just avoid printing them altogether. That would make it: 'strcpy' accessing the same array may overlap [-Werror=restrict] When the size is known it would give us: 'strcpy' accessing N bytes of the same array may overlap [-Werror=restrict] and when the offsets are known but the size isn't: 'strcpy' accessing the same array at offsets [O1, O2] and [O3, O4] may overlap [-Werror=restrict] and so on. There are many forms of the -Wrestrict warning already: singular size (1 byte) vs plural size (bytes) vs closed range (between X and Y bytes) vs open range (X or more bytes), constant offsets vs closed ranges ([X, Y]), definitely overlaps vs may overlap, and others, and because of internationalization most have to be hardcoded and can't be easily parameterized, so adding a new form into the mix isn't completely straightforward.
[Bug c++/52130] missing check for matching underlying type during instantiation of enum member of class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52130 Eric Gallager changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #4 from Eric Gallager --- What should the correct diagnostic message for it say instead then?
[Bug middle-end/89270] [9 regression] AVR ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89270 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug sanitizer/89409] [9 Regression] FAIL: c-c++-common/ubsan/div-by-zero-[67].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89409
--- Comment #5 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Wed Feb 20 16:20:50 2019
New Revision: 269042
URL: https://gcc.gnu.org/viewcvs?rev=269042&root=gcc&view=rev
Log:
libsanitizer: Restore internal_readlink for x32
Cherry-pick compiler-rt revision 354451:
r316591 has
@@ -389,13 +383,11 @@ uptr internal_dup2(int oldfd, int newfd) {
}
uptr internal_readlink(const char *path, char *buf, uptr bufsize) {
-#if SANITIZER_NETBSD
- return internal_syscall_ptr(SYSCALL(readlink), path, buf, bufsize);
-#elif SANITIZER_USES_CANONICAL_LINUX_SYSCALLS
+#if SANITIZER_USES_CANONICAL_LINUX_SYSCALLS
return internal_syscall(SYSCALL(readlinkat), AT_FDCWD,
(uptr)path, (uptr)buf, bufsize);
#else
- return internal_syscall(SYSCALL(readlink), (uptr)path, (uptr)buf, bufsize);
+ return internal_syscall_ptr(SYSCALL(readlink), path, buf, bufsize);
#endif
}
which dropped the (uptr) cast and broke x32. This patch puts back the
(uptr) cast to restore x32 and fixes:
https://bugs.llvm.org/show_bug.cgi?id=40783
Differential Revision: https://reviews.llvm.org/D58413
PR sanitizer/89409
* sanitizer_common/sanitizer_linux.cc (internal_readlink):
Cherry-pick compiler-rt r354451.
Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc
[Bug sanitizer/89308] [8 only] The sanitizers do no longer work on GCC 8 with newer kernels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89308 Segher Boessenkool changed: What|Removed |Added Status|NEW |SUSPENDED --- Comment #9 from Segher Boessenkool --- We do not currently see problems in practice. Suspending.
[Bug libgcc/89417] New: helgrind detects a lock order violation inside std::scoped_lock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417
Bug ID: 89417
Summary: helgrind detects a lock order violation inside
std::scoped_lock
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.kircheis at gmail dot com
Target Milestone: ---
Created attachment 45776
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45776&action=edit
helgrind log output
Hello,
Im unsure if this is a bug or feature request, depending on who is "wrong"
(g++/valgrind)
I'm using g++ (Debian 8.2.0-14) 8.2.0, and the program is compiled with
following flags: "-std=c++17 -lpthread"
Consider following snippet of code:
int main(){
std::mutex m1;
std::mutex m2;
int data1{};
int data2{};
auto f1 = std::async(std::launch::async, [&](){
std::scoped_lock sl{m1, m2};
++data1;
++data2;
return data1;
});
auto f2 = std::async(std::launch::async, [&](){
std::scoped_lock sl{m2, m1};
++data1;
++data2;
return data2;
});
return f1.get() + f2.get(); // result should be 3
}
helgrind (valgrind-3.14.0) reports that the lock order is violated: error
message attached)
it prints exactly the same error for
int main(){
std::mutex m1;
std::mutex m2;
int data1{};
int data2{};
auto f1 = std::async(std::launch::async, [&](){
std::lock_guard lg1{m1};std::lock_guard lg2{m2};
++data1;
++data2;
return data1;
});
auto f2 = std::async(std::launch::async, [&](){
std::lock_guard lg1{m1};std::lock_guard lg2{m2};
++data1;
++data2;
return data2;
});
return f1.get() + f2.get(); // result should be 3
}
In case helgrind is correct, it seems that there are some issues behind
std::scoped_lock, since it was explicitly designed for solving issues with lock
order.
In case helgrind (and possibly for the same reason other tools) is wrong, this
is would be a feature request.
A possible fix (or improvement) would be for `std::scoped_lock` to sort its
arguments by address (since std::mutex are not copyable or movable, and thus
their address should remain constant):
auto make_lock(std::mutex& m1_, std::mutex& m2_) {
const auto mless = std::less{};
return std::scoped_lock{*std::min(&m1_, &m2_, mless), *std::max(&m1_,
&m2_, mless)};
}
int main(){
std::mutex m1;
std::mutex m2;
int data1{};
int data2{};
auto f1 = std::async(std::launch::async, [&](){
auto sl = make_lock(m1,m2);
++data1;
++data2;
return data1;
});
auto f2 = std::async(std::launch::async, [&](){
auto sl = make_lock(m2,m1);
++data1;
++data2;
return data2;
});
return f1.get() + f2.get(); // result should be 3
}
in this case, helgrind does not generate any warning.
I do not know the internal algorithm of `std::scoped_lock`, so it might be
completely wrong, but sorting by address might also avoid possible live-lock
issues.
[Bug c/35592] Want attribute to enable precision loss warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35592 --- Comment #8 from Eric Gallager --- Created attachment 45777 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45777&action=edit testcase (In reply to felix-gcc from comment #6) > Sure. For example: > > char* c=malloc(lseek(somefd,0,SEEK_END); > > on a platform where off_t is 64-bit, but where size_t is 32-bit. For > example: i686-linux with #define _FILE_OFFSET_BITS 64. > > Now that I'm thinking about it, would it be possible to have a generic > overflow warning in that context? For example, > > malloc(p->len+1) > > So that gcc sees I'm adding something there, and if the range is not clamped > down before that gives an error? I combined those into a testcase which is attached. I thought the new -Walloc-size-larger-than= warning that (I think it was) Martin added would catch it, but apparently not?
[Bug c/89410] [7/8/9 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410 --- Comment #8 from Segher Boessenkool --- The C standard does not allow the line number (in a #line directive) to be smaller than 1 or bigger than 0x7fff. It says nothing about actually having this many lines, or overflowing the line number with following lines, but I suppose we could disallow that as well. As the ICEs show many parts of GCC assume line numbers increase, so the wrap-around signed integer is a problem (it is anyway, it's UB in the compiler itself). We could make the line number saturate, but this particular ICE won't go away unless line numbers are strictly increasing (or the code is changed). Changing the type to 64 bit won't help at all either, of course (we never actually see source files of 2G lines, already).
[Bug ipa/86395] add support of -fopt-info-inline in inliner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86395 Eric Gallager changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #7 from Eric Gallager --- (In reply to Martin Liška from comment #6) > David: Can the bug be marked as resolved? WAITING on a reply
[Bug c/53063] encode group options in the .opt files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53063 Eric Gallager changed: What|Removed |Added Status|NEW |WAITING --- Comment #12 from Eric Gallager --- (In reply to Martin Liška from comment #11) > Can the bug be marked as resolved? WAITING on a reply
[Bug other/84889] Ideas on revamping how we format diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889 Eric Gallager changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #15 from Eric Gallager --- (In reply to Martin Liška from comment #14) > David: Can the bug be marked as resolved? WAITING on a reply
[Bug d/89418] New: D test cases fail on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89418
Bug ID: 89418
Summary: D test cases fail on powerpc64le
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
FAIL: gdc.test/compilable/ctfe_math.d -O2output-exists ctfe_math.o
FAIL: gdc.test/compilable/ctfe_math.d -O2 -freleaseoutput-exists
ctfe_math.o
FAIL: gdc.test/compilable/ctfe_math.d -freleaseoutput-exists ctfe_math.o
FAIL: gdc.test/compilable/ctfe_math.d -goutput-exists ctfe_math.o
FAIL: gdc.test/compilable/ctfe_math.d -g -O2output-exists ctfe_math.o
FAIL: gdc.test/compilable/ctfe_math.d -g -O2 -freleaseoutput-exists
ctfe_math.o
FAIL: gdc.test/compilable/ctfe_math.d -g -freleaseoutput-exists ctfe_math.o
FAIL: gdc.test/compilable/test5227.d output-exists test5227.o
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test/gcc/testsuite/gdc8/../../gdc
-B/home/seurer/gcc/build/gcc-test/gcc/testsuite/gdc8/../../
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never
-I/home/seurer/gcc/gcc-test/gcc/testsuite/../../libphobos/libdruntime
-I/home/seurer/gcc/gcc-test/gcc/testsuite/../../libphobos/src
-I/home/seurer/gcc/gcc-test/gcc/testsuite/../../libstdc++-v3/libsupc++ -g
-I/home/seurer/gcc/gcc-test/gcc/testsuite/gdc.test/compilable -c -o ctfe_math.o
compilable/ctfe_math.d
/home/seurer/gcc/gcc-test/libphobos/src/std/math.d:244:5: error: static assert
"Only 64-bit, 80-bit, and 128-bit reals are supported for LittleEndian CPUs"
compiler exited with status 1
package:
// The following IEEE 'real' formats are currently supported.
version (LittleEndian)
{
static assert(real.mant_dig == 53 || real.mant_dig == 64
|| real.mant_dig == 113,
"Only 64-bit, 80-bit, and 128-bit reals"~
" are supported for LittleEndian CPUs");
}
else
{
static assert(real.mant_dig == 53 || real.mant_dig == 106
|| real.mant_dig == 113,
"Only 64-bit and 128-bit reals are supported for BigEndian CPUs."~
" double-double reals have partial support");
}
I don't really know enough about D to diagnose this much further.
[Bug target/80204] macosx-version-min wrong for macOS Sierra 10.12.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80204 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Eric Gallager --- (In reply to simon from comment #6) > Selected output from "gcc empty.c -v -Wl,-v" on macOS 10.14.1 (darwin > 18.2.0), > with gcc 9.0.0 20181103 built on x86_64-apple-darwin15, correctly showing > -mmacosx-version-min=10.14.0 & equivalents throughout. > > Equivalent success with 8.1.0. > > > > Target: x86_64-apple-darwin15 > Configured with: /Volumes/Miscellaneous/tmp/gcc/configure > --prefix=/Volumes/Miscellaneous/tmp/opt/gcc-9.0.0 > --without-libiconv-prefix --disable-libmudflap --disable-libstdcxx-pch > --disable-libsanitizer --disable-libcc1 --disable-libcilkrts > --disable-multilib --disable-nls --enable-languages=c,c++,ada > --disable-bootstrap --host=x86_64-apple-darwin15 > --target=x86_64-apple-darwin15 --build=x86_64-apple-darwin15 > --with-boot-ldflags='-static-libstdc++ -static-libgcc > -Wl,-headerpad_max_install_names' > Thread model: posix > gcc version 9.0.0 20181103 (experimental) (GCC) > COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=10.14.0' > '-asm_macosx_version_min=10.14' '-mtune=core2' > /opt/gcc-9.0.0/bin/../libexec/gcc/x86_64-apple-darwin15/9.0.0/cc1 > -quiet -v -iprefix > /opt/gcc-9.0.0/bin/../lib/gcc/x86_64-apple-darwin15/9.0.0/ > -D__DYNAMIC__ empty.c -fPIC -quiet -dumpbase empty.c > -mmacosx-version-min=10.14.0 -mtune=core2 -auxbase empty -version > -o /var/folders/_q/fvnxz46903z9hjh38fz0lyhmgs/T//cc2Zzpgh.s > > > > as -arch x86_64 -v -force_cpusubtype_ALL -mmacosx-version-min=10.14 > -o /var/folders/_q/fvnxz46903z9hjh38fz0lyhmgs/T//cc9YzAyh.o > /var/folders/_q/fvnxz46903z9hjh38fz0lyhmgs/T//cc2Zzpgh.s > Apple LLVM version 10.0.0 (clang-1000.10.44.4) > Target: x86_64-apple-darwin18.2.0 > Thread model: posix > InstalledDir: /Library/Developer/CommandLineTools/usr/bin > "/Library/Developer/CommandLineTools/usr/bin/clang" -cc1as > -triple x86_64-apple-macosx10.14.0 -filetype obj > -main-file-name cc2Zzpgh.s -target-cpu penryn -fdebug-compilation-dir > /Users/simon/tmp -dwarf-debug-producer Apple LLVM version 10.0.0 > (clang-1000.10.44.4) -dwarf-version=4 -mrelocation-model pic -o > /var/folders/_q/fvnxz46903z9hjh38fz0lyhmgs/T//cc9YzAyh.o > /var/folders/_q/fvnxz46903z9hjh38fz0lyhmgs/T//cc2Zzpgh.s > > > > /usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.14.0 > -weak_reference_mismatches non-weak -o a.out > -L/opt/gcc-9.0.0/bin/../lib/gcc/x86_64-apple-darwin15/9.0.0 > -L/opt/gcc-9.0.0/bin/../lib/gcc > -L/opt/gcc-9.0.0/bin/../lib/gcc/x86_64-apple-darwin15/9.0.0/../../.. > -v /var/folders/_q/fvnxz46903z9hjh38fz0lyhmgs/T//cc9YzAyh.o > -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v So, that sounds like a "yes, this can be closed"
[Bug d/89418] D test cases fail on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89418 seurer at gcc dot gnu.org changed: What|Removed |Added Target||powerpc64le-unknown-linux-g ||nu Host||powerpc64le-unknown-linux-g ||nu Build||powerpc64le-unknown-linux-g ||nu --- Comment #1 from seurer at gcc dot gnu.org --- Note that these error messages only occur on powerpc64le. BE seems to work OK.
[Bug c++/88294] [9 Regression] ICE on (invalid) C++11 code: in tsubst_copy, at cp/pt.c:15391
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88294
--- Comment #6 from Marek Polacek ---
A similar test crashes:
bool b;
template struct A
{
void g () noexcept (b) { }
};
int main ()
{
A a;
a.g ();
}
but that's PR88987.
[Bug c++/89357] alignas for automatic variables with alignment greater than 16 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89357
Martin Sebor changed:
What|Removed |Added
Keywords|accepts-invalid |rejects-valid
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-02-20
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail||8.2.0, 9.0
--- Comment #3 from Martin Sebor ---
Confirmed.
The reason why the __attribute__ is accepted is because it's not considered a
C++ 11 form of specifying alignment and so it's subject to less checking (done
by the check_cxx_fundamental_alignment_constraints function).
The alignas form is considered a C++ form (has ATTR_FLAG_CXX11 bit set in flags
below) and so makes it pass the first test. The cxx_fundamental_alignment_p()
test also fails (the fundamental alignment on aarch64 is 16). The third if
statement is entered, followed by the else block of the inner if. There,
MAX_STACK_ALIGNMENT is used as the upper bound. On aarch64,
MAX_STACK_ALIGNMENT is defined to STACK_BOUNDARY which is 16, and that is why
alignas(128) is considered invalid. In contrast, on x86_64,
MAX_STACK_ALIGNMENT is defined to MAX_OFILE_ALIGNMENT, both of which are
2147483648.
So either MAX_STACK_ALIGNMENT on aarch64 is wrong or the test in
check_cxx_fundamental_alignment_constraint is wrong.
MAX_STACK_ALIGNMENT is defined in section 18.5 Storage Layout of the internals
manual as:
Biggest stack alignment guaranteed by the backend. Use this macro to specify
the maximum alignment of a variable on stack.
and with the following (far more descriptive) comment in gcc/defaults.h:
/* MAX_STACK_ALIGNMENT is the maximum stack alignment guaranteed by
the backend. MAX_SUPPORTED_STACK_ALIGNMENT is the maximum best
effort stack alignment supported by the backend. If the backend
supports stack alignment, MAX_SUPPORTED_STACK_ALIGNMENT and
MAX_STACK_ALIGNMENT are the same. Otherwise, the incoming stack
boundary will limit the maximum guaranteed stack alignment. */
It's a little ambiguous but my guess is that MAX_STACK_ALIGNMENT is meant to be
the maximum alignment the back-end will maintain for the stack pointer in
general, independent of any overaligned variables, and isn't intended as
constraint on the alignment of explicitly overaligned stack variables. (I can
think of no reason why the back-end would impose any such constraint on the
stack.) If that's correct the test for MAX_STACK_ALIGNMENT is the bug. The
test was introduced with the implementation of the alignas specifier in
r192199.
check_cxx_fundamental_alignment_constraints (tree node,
unsigned align_log,
int flags)
{
bool alignment_too_large_p = false;
unsigned requested_alignment = (1U << align_log) * BITS_PER_UNIT;
unsigned max_align = 0;
if ((!(flags & ATTR_FLAG_CXX11) && !warn_cxx_compat)
|| (node == NULL_TREE || node == error_mark_node))
return true;
if (cxx_fundamental_alignment_p (requested_alignment))
return true;
if (VAR_P (node))
{
if (TREE_STATIC (node) || DECL_EXTERNAL (node))
/* For file scope variables and static members, the target supports
alignments that are at most MAX_OFILE_ALIGNMENT. */
max_align = MAX_OFILE_ALIGNMENT;
else
/* For stack variables, the target supports at most
MAX_STACK_ALIGNMENT. */
max_align = MAX_STACK_ALIGNMENT;
if (requested_alignment > max_align)
alignment_too_large_p = true;
}
[Bug c/89410] [7/8/9 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #9 from Jonny Grant ---
(In reply to Segher Boessenkool from comment #8)
> The C standard does not allow the line number (in a #line directive) to be
> smaller than 1 or bigger than 0x7fff. It says nothing about actually
> having this many lines, or overflowing the line number with following lines,
> but I suppose we could disallow that as well.
int main(void)
{
#line 0
}
#1 with x86-64 gcc (trunk)
Compiler returned: 0
Maybe zero could be disallowed too.
> As the ICEs show many parts of GCC assume line numbers increase, so the
> wrap-around signed integer is a problem (it is anyway, it's UB in the
> compiler
> itself). We could make the line number saturate, but this particular ICE
> won't
> go away unless line numbers are strictly increasing (or the code is changed).
> Changing the type to 64 bit won't help at all either, of course (we never
> actually see source files of 2G lines, already).
Not sure what is best here, I'm not knowledgeable of GCC, but maybe setting it
to -1 if it goes above, and then never increment again if(-1 == line) ...
[Bug c/89410] [7/8/9 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #10 from David Malcolm ---
(In reply to Jonny Grant from comment #4)
> There's another related issue, can it be covered on this ticket?
>
> GCC does not show the part of the output below I marked with after
> commenting out line 4 <-
>
> #1 with x86-64 gcc (trunk)
> : In function 'main':
> :6:7: warning: line number out of range
> 6 | #line 9223372036854775807<-
> | ^~~
>
>
>
>
> int main(void)
> {
> // Note: Comment back in the next line to reproduce
> //#line 12147483647
>
> #line 9223372036854775807
> }
What's happening is that GCC is honoring the earlier #line directive, and it
attempts to load the source for that line; there aren't that many lines in the
file, so it doesn't print anything.
[Bug c++/88572] error: braces around scalar initializer - should be a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88572 Will Wray changed: What|Removed |Added Attachment #45683|0 |1 is obsolete|| --- Comment #16 from Will Wray --- Created attachment 45778 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45778&action=edit Updated patch addressing review comments (Updated Change Log entry for decl.c) Log: PR c++/88572 * decl.c (reshape_init_r): Remove condition that was incorrectly rejecting braces around scalar initializer within aggregate init. Produce no warning. Add a conditional block rejecting braced-init of scalar variable, including empty-brace value-initialization that was being incorrectly accepted.
[Bug fortran/89385] Incorrect members of C descriptor for an allocatable object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89385 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #3 from Paul Thomas --- Created attachment 45779 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45779&action=edit Draft patch One typo, one stupid error and a couple of misunderstood bits in the standard led to this. The testcase provided runs OK and the patch bootstraps and regtests. I will go through the other PRs that you provided and will see what further fixes are required. Thanks Paul
[Bug c++/89419] New: [8/9 Regression] ICE in is_normal_capture_proxy starting with r253601
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89419
Bug ID: 89419
Summary: [8/9 Regression] ICE in is_normal_capture_proxy
starting with r253601
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
The following testcase started to ICE with -std=c++17 in r253601:
struct A;
struct B {
struct C { C (); C (C &); } b;
};
struct D { A operator* (); };
struct A {
template void foo (T x) { x (this); }
};
struct E {
auto bar () { return e; }
D e;
};
struct F { B f; int g; };
int
main ()
{
E e;
auto f = *e.bar ();
auto i = [&] { F g; g.g = 1; auto h = [&](auto) { g.g = 0; }; f.foo (h);
return g; };
}
[Bug c++/89419] [8/9 Regression] ICE in is_normal_capture_proxy starting with r253601
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89419 Jakub Jelinek changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-20 CC||jason at gcc dot gnu.org Target Milestone|--- |8.3 Ever confirmed|0 |1
[Bug c++/89420] New: [9 Regression] ICE: unexpected expression 'int()' of kind cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89420 Bug ID: 89420 Summary: [9 Regression] ICE: unexpected expression 'int()' of kind cast_expr Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20181028 and 20181104 (with any -std) : $ cat z1.cc template $ g++-9-20190217 -c z1.cc z1.cc:1:11: warning: 'explicit(bool)' only available with -std=c++2a or -std=gnu++2a 1 | template | ^~~~ z1.cc:1:26: internal compiler error: unexpected expression 'int()' of kind cast_expr 1 | template | ^ 0x620880 cxx_eval_constant_expression ../../gcc/cp/constexpr.c:5001 0x622104 cxx_eval_outermost_constant_expr ../../gcc/cp/constexpr.c:5115 0x6243d0 maybe_constant_value(tree_node*, tree_node*, bool) ../../gcc/cp/constexpr.c:5347 0x74ade7 check_narrowing(tree_node*, tree_node*, int, bool) ../../gcc/cp/typeck2.c:931 0x5f95b0 convert_like_real ../../gcc/cp/call.c:7366 0x603692 build_converted_constant_expr(tree_node*, tree_node*, int) ../../gcc/cp/call.c:4215 0x6466d2 build_explicit_specifier(tree_node*, int) ../../gcc/cp/decl.c:16687 0x6ab02c cp_parser_function_specifier_opt ../../gcc/cp/parser.c:14236 0x6b6be0 cp_parser_decl_specifier_seq ../../gcc/cp/parser.c:13945 0x6ce143 cp_parser_parameter_declaration ../../gcc/cp/parser.c:22266 0x6cf003 cp_parser_template_parameter ../../gcc/cp/parser.c:15979 0x6cf003 cp_parser_template_parameter_list ../../gcc/cp/parser.c:15562 0x6d457d cp_parser_explicit_template_declaration ../../gcc/cp/parser.c:27955 0x6d457d cp_parser_template_declaration_after_export ../../gcc/cp/parser.c:27989 0x6d7119 cp_parser_declaration ../../gcc/cp/parser.c:13122 0x6d775e cp_parser_translation_unit ../../gcc/cp/parser.c:4698 0x6d775e c_parse_file() ../../gcc/cp/parser.c:41039 0x7962a0 c_common_parse_file() ../../gcc/c-family/c-opts.c:1155
[Bug c++/89421] New: [9 Regression] ICE in retrieve_specialization, at cp/pt.c:1245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89421
Bug ID: 89421
Summary: [9 Regression] ICE in retrieve_specialization, at
cp/pt.c:1245
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 2018 and 20181118 :
$ cat z1.cc
template < //>
auto c = []{ return []{}; }();
$ g++-9-20190217 -c z1.cc
z1.cc:2:29: internal compiler error: Segmentation fault
2 | auto c = []{ return []{}; }();
| ^
0xe32b7f crash_signal
../../gcc/toplev.c:326
0x7c6c75 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3175
0x7c6c75 retrieve_specialization
../../gcc/cp/pt.c:1245
0x815564 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:24335
0x6ef537 maybe_instantiate_decl
../../gcc/cp/decl2.c:5281
0x6f221c mark_used(tree_node*, int)
../../gcc/cp/decl2.c:5437
0x627aba build_over_call
../../gcc/cp/call.c:7945
0x63b0a8 build_op_call_1
../../gcc/cp/call.c:4671
0x63b0a8 build_op_call(tree_node*, vec**, int)
../../gcc/cp/call.c:4700
0x83c0b3 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/cp/semantics.c:2586
0x78cad6 cp_parser_postfix_expression
../../gcc/cp/parser.c:7373
0x79bc95 cp_parser_unary_expression
../../gcc/cp/parser.c:8459
0x77347f cp_parser_cast_expression
../../gcc/cp/parser.c:9345
0x773c92 cp_parser_binary_expression
../../gcc/cp/parser.c:9446
0x774da9 cp_parser_assignment_expression
../../gcc/cp/parser.c:9742
0x774705 cp_parser_constant_expression
../../gcc/cp/parser.c:10026
0x774d51 cp_parser_initializer_clause
../../gcc/cp/parser.c:22702
0x779737 cp_parser_initializer
../../gcc/cp/parser.c:22642
0x79e683 cp_parser_default_argument
../../gcc/cp/parser.c:22537
0x79e683 cp_parser_parameter_declaration
../../gcc/cp/parser.c:22430
[Bug c++/89420] [9 Regression] ICE: unexpected expression 'int()' of kind cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89420 Marek Polacek changed: What|Removed |Added Priority|P3 |P2
[Bug c++/89420] [9 Regression] ICE: unexpected expression 'int()' of kind cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89420 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-02-20 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- r265641
[Bug c++/89422] New: [8/9 Regression] ICE in field_byte_offset, at dwarf2out.c:19086
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89422
Bug ID: 89422
Summary: [8/9 Regression] ICE in field_byte_offset, at
dwarf2out.c:19086
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with gcc-8 and option -g :
$ cat z1.cc
template struct S
{
friend void foo (int a = []{ return 0; }()) {}
int b;
};
S<0> t;
$ g++-9-20190217 -c z1.cc
$
$ g++-9-20190217 -c z1.cc -g
z1.cc: In instantiation of 'struct S<0>':
z1.cc:6:6: required from here
z1.cc:3:28: internal compiler error: Segmentation fault
3 | friend void foo (int a = []{ return 0; }()) {}
|^~~
0xba166f crash_signal
../../gcc/toplev.c:326
0x8ac58e field_byte_offset
../../gcc/dwarf2out.c:19086
0x8ad27d add_data_member_location_attribute
../../gcc/dwarf2out.c:19365
0x8adb96 gen_field_die
../../gcc/dwarf2out.c:24290
0x898b5f gen_field_die
../../gcc/dwarf2out.c:24266
0x898b5f gen_decl_die
../../gcc/dwarf2out.c:26419
0x89a6a7 gen_member_die
../../gcc/dwarf2out.c:25169
0x89a6a7 gen_struct_or_union_type_die
../../gcc/dwarf2out.c:25265
0x89a6a7 gen_tagged_type_die
../../gcc/dwarf2out.c:25466
0x89b1ac gen_type_die_with_usage
../../gcc/dwarf2out.c:25661
0x89a2b7 gen_tagged_type_die
../../gcc/dwarf2out.c:25435
0x89b1ac gen_type_die_with_usage
../../gcc/dwarf2out.c:25661
0x89ba66 gen_type_die
../../gcc/dwarf2out.c:25715
0x8988ce gen_decl_die
../../gcc/dwarf2out.c:26347
0x899376 dwarf2out_decl
../../gcc/dwarf2out.c:26892
0x89963c dwarf2out_type_decl
../../gcc/dwarf2out.c:26619
0xadd0c2 rest_of_type_compilation(tree_node*, int)
../../gcc/passes.c:339
0x615b4d finish_struct_1(tree_node*)
../../gcc/cp/class.c:7068
0x616f74 finish_struct(tree_node*, tree_node*)
../../gcc/cp/class.c:7212
0x6f97e6 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:18126
[Bug c++/89403] [7/8/9 Regression] ICE in maybe_clone_body, at cp/optimize.c:693
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89403 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 45780 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45780&action=edit gcc9-pr89403.patch Untested fix. The problem is that maybe_clone_body really doesn't expect to be called multiple times on the same function.
[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314 --- Comment #25 from Wilco --- (In reply to Steve Ellcey from comment #24) > See email strings at: > > https://gcc.gnu.org/ml/fortran/2019-01/msg00276.html > https://gcc.gnu.org/ml/fortran/2019-02/msg00057.html > > For more discussion. Sure, it looks like we simply need to reinstate Szabolc's patch with a #ifdef arm/aarch64 around it. I need to find out whether a feclearexcept (FE_ALL_EXCEPT) is necessary on Arm targets which can trap (very few exist IIRC).
[Bug middle-end/89423] New: -fvtable-verify does not work properly with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89423 Bug ID: 89423 Summary: -fvtable-verify does not work properly with -flto Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ctice at gcc dot gnu.org Target Milestone: --- When compiled with '-flto' the extra internal functions that VTV generates,and which are necessary for it to work correctly, do not get propagated into the final binary. You can see this compiling the bb_tests.cc test case in the libvtv testsuite, and grepping for 'GLOBAL' in the final output: $ /usr/local/google3/cmtice/gcc-fsf.root/usr/local/bin/g++ -o bb_tests bb_tests.cc -O1 -fvtable-verify=std // Compile without flto $ nm bb_tests | grep GLOBAL 00601000 d _GLOBAL_OFFSET_TABLE_ 00400930 t _GLOBAL__sub_I.00099__Z14get_cond_value $ /usr/local/google3/cmtice/gcc-fsf.root/usr/local/bin/g++ -o bb_tests_flto bb_tests.cc -O1 -flto -fvtable-verify=std // Compile with flto $ nm bb_tests_flto | grep GLOBAL 00601000 d _GLOBAL_OFFSET_TABLE_
[Bug middle-end/89423] -fvtable-verify does not work properly with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89423 ctice at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-02-20 Assignee|unassigned at gcc dot gnu.org |ctice at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/80408] Problems with SIGNAL, pthread and print together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80408 --- Comment #4 from Raphael Monod --- Thank you for your answer. But I don't understand why adding -lpthread option change the behavior if I do not use any thread. Moreover, if I refer to this page ( https://docs.oracle.com/cd/E19455-01/806-5257/gen-26/index.html ) write statement seems to be async-signal safe ? Where am I wrong ? Finaly, what can I do if I want to print a message in my trap function ? Thank you for your interest to my problem.
[Bug target/89400] [7/8/9 Regression] ICE: output_operand: invalid %-code with -march=armv6kz -mthumb -munaligned-access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89400
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Milestone|--- |7.5
--- Comment #1 from Jakub Jelinek ---
r228540 compiled this fine with these options, r228940 already ICEs, though
with
pr89400.c: In function ‘foo’:
pr89400.c:7:1: error: unrecognizable insn:
}
^
(insn 9 8 10 2 (set (reg:SI 116)
(zero_extend:SI (unspec:HI [
(mem:HI (reg/f:SI 111 [ b.1_3 ]) [0 MEM[(char *
{ref-all})b.1_3]+0 S2 A8])
] UNSPEC_UNALIGNED_LOAD))) pr89400.c:6 -1
(nil))
Maybe started with r228643?
The invalid %-code appeared in between r230540 and r231340, maybe r231114 or
r230664 or r230663.
[Bug c++/89421] [9 Regression] ICE in retrieve_specialization, at cp/pt.c:1245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89421 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-20 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- r266056.
[Bug target/89400] [7/8/9 Regression] ICE: output_operand: invalid %-code with -march=armv6kz -mthumb -munaligned-access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89400
Jakub Jelinek changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
All the "unaligned_access" instructions use %? in the patterns (except the last
one) where %? is TARGET_32BIT specific.
If the unaligned loads/stores don't really work for thumb1, then
if (! opts_set->x_unaligned_access)
{
opts->x_unaligned_access = (TARGET_32BIT_P (opts->x_target_flags)
&& arm_arch6 && (arm_arch_notm || arm_arch7));
}
else if (opts->x_unaligned_access == 1
&& !(arm_arch6 && (arm_arch_notm || arm_arch7)))
{
warning (0, "target CPU does not support unaligned accesses");
opts->x_unaligned_access = 0;
}
should be changed to:
else if (opts->x_unaligned_access == 1
&& (!(arm_arch6 && (arm_arch_notm || arm_arch7))
|| !TARGET_32BIT_P (opts->x_target_flags)))
If the unaligned_access instructions are also for thumb1, then perhaps they
need to set predicable to no for !TARGET_32BIT e.g. based on isa attribute and
avoid using %? in the thumb1 alternative patterns.
[Bug c/89410] [7/8/9 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410 --- Comment #11 from Segher Boessenkool --- (In reply to Jonny Grant from comment #9) > Maybe zero could be disallowed too. Yes, but maybe we need that for historical reasons. > Not sure what is best here, I'm not knowledgeable of GCC, but maybe setting > it to -1 if it goes above, and then never increment again if(-1 == line) ... The testcase will still ICE then... The assert is /* The spans must be ordered. */ gcc_assert (prev->m_first_line < next->m_first_line);
