[Bug fortran/99350] [9/10/11 Regression] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99350 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||markeggleston at gcc dot gnu.org, ||marxin at gcc dot gnu.org Last reconfirmed||2021-03-03 --- Comment #1 from Martin Liška --- Started with r11-358-gf9f98e59a7f6663f.
[Bug fortran/99349] ICE in match_data_constant, at fortran/decl.c:426
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99349 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org --- Comment #2 from Martin Liška --- Started with r9-3803-ga5fbc2f36a291cbe.
[Bug fortran/99348] ICE in resolve_structure_cons, at fortran/resolve.c:1286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99348 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-03-03 --- Comment #2 from Martin Liška --- Started with r9-3803-ga5fbc2f36a291cbe.
[Bug fortran/82721] [8/9/10/11 Regression] Error message with corrupted text, sometimes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82721 Vittorio Zecca changed: What|Removed |Added CC||zeccav at gmail dot com --- Comment #13 from Vittorio Zecca --- On my sanitized trunk version I get the following. This is on x86-64 Fedora 33 and line numbers ~/local/gcc-150221-sanitized/bin/gfortran z82721.f90 -S z82721.f90:3:25: 3 |character(len(c)) :: b | 1 Error: Symbol ‘b’ at (1) already has basic type of REAL = ==147959==ERROR: AddressSanitizer: heap-use-after-free on address 0x604017f8 at pc 0x008b02df bp 0x7fffc363cef0 sp 0x7fffc363cee8 READ of size 8 at 0x604017f8 thread T0 #0 0x8b02de in check_host_association ../../gcc-150221/gcc/fortran/resolve.c:5978 #1 0x8c1b4b in gfc_resolve_expr(gfc_expr*) ../../gcc-150221/gcc/fortran/resolve.c:7096 #2 0x91d1bf in resolve_index_expr ../../gcc-150221/gcc/fortran/resolve.c:12406 #3 0x91d79f in resolve_charlen ../../gcc-150221/gcc/fortran/resolve.c:12459 #4 0x96f604 in resolve_types ../../gcc-150221/gcc/fortran/resolve.c:17294 #5 0x970adf in gfc_resolve(gfc_namespace*) ../../gcc-150221/gcc/fortran/resolve.c:17411 #6 0x81fc90 in resolve_all_program_units ../../gcc-150221/gcc/fortran/parse.c:6290 #7 0x82229f in gfc_parse_file() ../../gcc-150221/gcc/fortran/parse.c:6542 #8 0xa64b7c in gfc_be_parse_file ../../gcc-150221/gcc/fortran/f95-lang.c:212 #9 0x33fa43d in compile_file ../../gcc-150221/gcc/toplev.c:457 #10 0x34097a2 in do_compile ../../gcc-150221/gcc/toplev.c:2197 #11 0x340a39f in toplev::main(int, char**) ../../gcc-150221/gcc/toplev.c:2336 #12 0x7f24cb9 in main ../../gcc-150221/gcc/main.c:39 #13 0x147bdbb291e1 in __libc_start_main (/usr/lib64/libc.so.6+0x281e1) #14 0x41958d in _start (/home/vitti/1TB/local/gcc-150221-sanitized/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/f951+0x41958d) 0x604017f8 is located 40 bytes inside of 48-byte region [0x604017d0,0x60401800) freed by thread T0 here: #0 0x147bdca7b797 in __interceptor_free ../../../../gcc-150221/libsanitizer/asan/asan_malloc_linux.cpp:127 #1 0xa1cd6f in gfc_delete_symtree(gfc_symtree**, char const*) ../../gcc-150221/gcc/fortran/symbol.c:2964 #2 0xa25801 in gfc_restore_last_undo_checkpoint() ../../gcc-150221/gcc/fortran/symbol.c:3706 #3 0xa25a5f in gfc_undo_symbols() ../../gcc-150221/gcc/fortran/symbol.c:3739 #4 0x80175f in reject_statement ../../gcc-150221/gcc/fortran/parse.c:2678 #5 0x7f2bb0 in match_word ../../gcc-150221/gcc/fortran/parse.c:70 #6 0x7f445d in decode_statement ../../gcc-150221/gcc/fortran/parse.c:376 #7 0x7fd6c8 in next_free ../../gcc-150221/gcc/fortran/parse.c:1316 #8 0x7fe845 in next_statement ../../gcc-150221/gcc/fortran/parse.c:1548 #9 0x80cb86 in parse_spec ../../gcc-150221/gcc/fortran/parse.c:3967 #10 0x81bef7 in parse_progunit ../../gcc-150221/gcc/fortran/parse.c:5896 #11 0x821732 in gfc_parse_file() ../../gcc-150221/gcc/fortran/parse.c:6437 #12 0xa64b7c in gfc_be_parse_file ../../gcc-150221/gcc/fortran/f95-lang.c:212 #13 0x33fa43d in compile_file ../../gcc-150221/gcc/toplev.c:457 #14 0x34097a2 in do_compile ../../gcc-150221/gcc/toplev.c:2197 #15 0x340a39f in toplev::main(int, char**) ../../gcc-150221/gcc/toplev.c:2336 #16 0x7f24cb9 in main ../../gcc-150221/gcc/main.c:39 #17 0x147bdbb291e1 in __libc_start_main (/usr/lib64/libc.so.6+0x281e1) previously allocated by thread T0 here: #0 0x147bdca7bc47 in __interceptor_calloc ../../../../gcc-150221/libsanitizer/asan/asan_malloc_linux.cpp:154 #1 0x83c3e31 in xcalloc ../../gcc-150221/libiberty/xmalloc.c:162 #2 0xa1cade in gfc_new_symtree(gfc_symtree**, char const*) ../../gcc-150221/gcc/fortran/symbol.c:2934 #3 0xa20eed in gfc_get_sym_tree(char const*, gfc_namespace*, gfc_symtree**, bool) ../../gcc-150221/gcc/fortran/symbol.c:3384 #4 0xa21e11 in gfc_get_ha_sym_tree(char const*, gfc_symtree**) ../../gcc-150221/gcc/fortran/symbol.c:3469 #5 0x846df0 in gfc_match_rvalue(gfc_expr**) ../../gcc-150221/gcc/fortran/primary.c:3512 #6 0x7191c4 in match_primary ../../gcc-150221/gcc/fortran/matchexp.c:157 #7 0x7194a7 in match_level_1 ../../gcc-150221/gcc/fortran/matchexp.c:211 #8 0x719832 in match_mult_operand ../../gcc-150221/gcc/fortran/matchexp.c:267 #9 0x71a031 in match_add_operand ../../gcc-150221/gcc/fortran/matchexp.c:356 #10 0x71a9bd in match_level_2 ../../gcc-150221/gcc/fortran/matchexp.c:480 #11 0x71af3e in match_level_3 ../../gcc-150221/gcc/fortran/matchexp.c:551 #12 0x71b368 in match_level_4 ../../gcc-150221/gcc/fortran/matchexp.c:599 #13 0x71c2f7 in match_and_operand ../../gcc-150221/gcc/fortran/matchexp.c:693 #14 0x71c5b1 in match_or_operand ../../gcc-150221/gcc/fortra
[Bug middle-end/99339] Poor codegen with simple varargs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99339 Richard Biener changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #7 from Richard Biener --- For simple cases some IPA pass (IPA-CP or IPA-SRA?) could also 'clone' varargs functions based on callers, eliding varargs and thus also allow inlining (or like the early IPA-SRA did, modify a function in place if all callers are simple). Directly supporting inlining might also be possible. What's required for all this is some local analysis of the varargs function on whether it's possible to replace the .VA_ARG calls with direct parameter references (no .VA_ARG in loops for example, no passing of the va_list to other functions, etc.).
[Bug fortran/79524] [8/9/10/11 Regression] valgrind error for gcc/testsuite/gfortran.dg/fimplicit_none_2.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79524
Vittorio Zecca changed:
What|Removed |Added
CC||zeccav at gmail dot com
--- Comment #9 from Vittorio Zecca ---
On sanitized current trunk, note I have line numbers.
~/local/gcc-150221-sanitized/bin/gfortran
~/gcc-150221/gcc/testsuite/gfortran.dg/fimplicit_none_2.f90 -S
/home/vitti/gcc-150221/gcc/testsuite/gfortran.dg/fimplicit_none_2.f90:5:34:
5 |character(*), parameter :: z(2) = [character(n) :: 'x', 'y'] ! {
dg-error "Scalar INTEGER expression expected" }
| 1
Error: Cannot initialize parameter array at (1) with variable length elements
=
==130180==ERROR: AddressSanitizer: heap-use-after-free on address
0x60401628 at pc 0x008c1918 bp 0x7ffceba92260 sp 0x7ffceba92258
READ of size 8 at 0x60401628 thread T0
#0 0x8c1917 in gfc_resolve_expr(gfc_expr*)
../../gcc-150221/gcc/fortran/resolve.c:7079
#1 0x91d45b in resolve_charlen ../../gcc-150221/gcc/fortran/resolve.c:12436
#2 0x96f604 in resolve_types ../../gcc-150221/gcc/fortran/resolve.c:17294
#3 0x970adf in gfc_resolve(gfc_namespace*)
../../gcc-150221/gcc/fortran/resolve.c:17411
#4 0x81fc90 in resolve_all_program_units
../../gcc-150221/gcc/fortran/parse.c:6290
#5 0x82229f in gfc_parse_file() ../../gcc-150221/gcc/fortran/parse.c:6542
#6 0xa64b7c in gfc_be_parse_file
../../gcc-150221/gcc/fortran/f95-lang.c:212
#7 0x33fa43d in compile_file ../../gcc-150221/gcc/toplev.c:457
#8 0x34097a2 in do_compile ../../gcc-150221/gcc/toplev.c:2197
#9 0x340a39f in toplev::main(int, char**)
../../gcc-150221/gcc/toplev.c:2336
#10 0x7f24cb9 in main ../../gcc-150221/gcc/main.c:39
#11 0x152cd7c9a1e1 in __libc_start_main (/usr/lib64/libc.so.6+0x281e1)
#12 0x41958d in _start
(/home/vitti/1TB/local/gcc-150221-sanitized/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/f951+0x41958d)
0x60401628 is located 24 bytes inside of 48-byte region
[0x60401610,0x60401640)
freed by thread T0 here:
#0 0x152cd8bec797 in __interceptor_free
../../../../gcc-150221/libsanitizer/asan/asan_malloc_linux.cpp:127
#1 0xa1cd6f in gfc_delete_symtree(gfc_symtree**, char const*)
../../gcc-150221/gcc/fortran/symbol.c:2964
#2 0xa25801 in gfc_restore_last_undo_checkpoint()
../../gcc-150221/gcc/fortran/symbol.c:3706
#3 0xa25a5f in gfc_undo_symbols()
../../gcc-150221/gcc/fortran/symbol.c:3739
#4 0x80175f in reject_statement ../../gcc-150221/gcc/fortran/parse.c:2678
#5 0x7f2bb0 in match_word ../../gcc-150221/gcc/fortran/parse.c:70
#6 0x7f445d in decode_statement ../../gcc-150221/gcc/fortran/parse.c:376
#7 0x7fd6c8 in next_free ../../gcc-150221/gcc/fortran/parse.c:1316
#8 0x7fe845 in next_statement ../../gcc-150221/gcc/fortran/parse.c:1548
#9 0x80bfe5 in parse_spec ../../gcc-150221/gcc/fortran/parse.c:3783
#10 0x81bef7 in parse_progunit ../../gcc-150221/gcc/fortran/parse.c:5896
#11 0x821732 in gfc_parse_file() ../../gcc-150221/gcc/fortran/parse.c:6437
#12 0xa64b7c in gfc_be_parse_file
../../gcc-150221/gcc/fortran/f95-lang.c:212
#13 0x33fa43d in compile_file ../../gcc-150221/gcc/toplev.c:457
#14 0x34097a2 in do_compile ../../gcc-150221/gcc/toplev.c:2197
#15 0x340a39f in toplev::main(int, char**)
../../gcc-150221/gcc/toplev.c:2336
#16 0x7f24cb9 in main ../../gcc-150221/gcc/main.c:39
#17 0x152cd7c9a1e1 in __libc_start_main (/usr/lib64/libc.so.6+0x281e1)
previously allocated by thread T0 here:
#0 0x152cd8becc47 in __interceptor_calloc
../../../../gcc-150221/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x83c3e31 in xcalloc ../../gcc-150221/libiberty/xmalloc.c:162
#2 0xa1cade in gfc_new_symtree(gfc_symtree**, char const*)
../../gcc-150221/gcc/fortran/symbol.c:2934
#3 0xa20eed in gfc_get_sym_tree(char const*, gfc_namespace*, gfc_symtree**,
bool) ../../gcc-150221/gcc/fortran/symbol.c:3384
#4 0xa21e11 in gfc_get_ha_sym_tree(char const*, gfc_symtree**)
../../gcc-150221/gcc/fortran/symbol.c:3469
#5 0x846df0 in gfc_match_rvalue(gfc_expr**)
../../gcc-150221/gcc/fortran/primary.c:3512
#6 0x7191c4 in match_primary ../../gcc-150221/gcc/fortran/matchexp.c:157
#7 0x7194a7 in match_level_1 ../../gcc-150221/gcc/fortran/matchexp.c:211
#8 0x719832 in match_mult_operand
../../gcc-150221/gcc/fortran/matchexp.c:267
#9 0x71a031 in match_add_operand
../../gcc-150221/gcc/fortran/matchexp.c:356
#10 0x71a9bd in match_level_2 ../../gcc-150221/gcc/fortran/matchexp.c:480
#11 0x71af3e in match_level_3 ../../gcc-150221/gcc/fortran/matchexp.c:551
#12 0x71b368 in match_level_4 ../../gcc-150221/gcc/fortran/matchexp.c:599
#13 0x71c2f7 in match_and_operand
../../gcc-150221/gcc/fortran/matchexp.c:693
#14 0x71c5b1 in match_or_operand
../../gcc-
[Bug d/99337] Sanitizer detect heap-buffer-overflow in checkModFileAlias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99337
--- Comment #4 from Vittorio Zecca ---
(In reply to Iain Buclaw from comment #3)
> Fix is trivial
>
> --- a/gcc/d/dmd/dmodule.c
> +++ b/gcc/d/dmd/dmodule.c
> @@ -195,7 +195,7 @@ static void checkModFileAlias(OutBuffer *buf, OutBuffer
> *dotmods,
> const char *m = (*ms)[j];
> const char *q = strchr(m, '=');
> assert(q);
> -if (dotmods->length() <= (size_t)(q - m) &&
> memcmp(dotmods->peekChars(), m, q - m) == 0)
> +if (dotmods->length() == (size_t)(q - m) &&
> memcmp(dotmods->peekChars(), m, q - m) == 0)
> {
> buf->reset();
> size_t qlen = strlen(q + 1);
After applying the suggested fix
make check-gcc-d
runs without address sanitizer errors.
[Bug fortran/52622] heap-use-after-free with instrumented compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52622 Vittorio Zecca changed: What|Removed |Added CC||zeccav at gmail dot com --- Comment #16 from Vittorio Zecca --- On my sanitized gfortran, trunk version, I do not see sanitizer errors. Maybe must be compiled with some special options? By the way the delta-reduced-testcase contains syntax errors that I had to fix.
[Bug libfortran/81986] sanitizer detects negation of large number in string.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81986 --- Comment #6 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:006693a59f7cd1310aed53a2816020bedf1fb742 commit r11-7470-g006693a59f7cd1310aed53a2816020bedf1fb742 Author: Tobias Burnus Date: Wed Mar 3 08:05:45 2021 +0100 libgfortran: Fix negation for largest integer [PR81986] libgfortran/ChangeLog: 2021-03-01 Vittorio Zecca Tobias Burnus PR libfortran/81986 * runtime/string.c (gfc_itoa): Cast to unsigned before negating.
[Bug fortran/99355] -freal-X-real-Y -freal-Z-real-X promotes Z to Y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99355 --- Comment #1 from Nick --- Oh, sorry about gcc-version. I checked this for all these gcc, same for all: 4.8.5 4.9.4 5.4.0 6.5.0 7.5.0 8.4.0 9.2.0
[Bug fortran/99355] New: -freal-X-real-Y -freal-Z-real-X promotes Z to Y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99355 Bug ID: 99355 Summary: -freal-X-real-Y -freal-Z-real-X promotes Z to Y Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: nickpapior at gmail dot com Target Milestone: --- Created attachment 50291 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50291&action=edit Same as code snippet I came about this in LAPACK which allows compiling in quad precision. However, mixed precision algorithms will no longer be mixed precision since *everything* gets promoted. See this code snippet (and attached as well): program test real :: r1 real*4:: r2 real(4) :: r3 real(selected_real_kind(p=6)) :: r4 double precision :: d1 real*8 :: d2 real(8) :: d3 real(kind(1.d0)) :: d4 real(selected_real_kind(p=15)) :: d5 print '(tr3,a10,10(tr1,i2))', 'single', kind(r1), kind(r2), kind(r3), kind(r4) print '(tr3,a10,10(tr1,i2))', 'double', kind(d1), kind(d2), kind(d3), kind(d4), kind(d5) end program test Here listed with 4 different flag combinations: #FLAGS = single 4 4 4 4 double 8 8 8 8 8 #FLAGS = -freal-4-real-8 single 8 8 8 8 double 8 8 8 8 8 #FLAGS = -freal-8-real-16 single 4 4 4 4 double 16 16 16 16 16 #FLAGS = -freal-8-real-16 -freal-4-real-8 (order doesn't matter) single 8 16 16 16 double 16 16 16 16 16 The first 3 flag combinations works as intended. The last one behaves bad. I would have expected 8->16 and 4->8 (without double promotion).
[Bug tree-optimization/94092] Code size and performance degradations after -ftree-loop-distribute-patterns was enabled at -O[2s]+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94092
--- Comment #11 from Mel Chen ---
(In reply to Mel Chen from comment #10)
> (In reply to Richard Biener from comment #9)
> > (In reply to Mel Chen from comment #8)
> > > Sorry for using the bad example to describe the problem I am facing. Let
> > > me
> > > clarify my question with a more precise example.
> > >
> > > void array_mul(int N, int *C, short *A, short *B) {
> > > int i, j;
> > > for (i = 0; i < N; i++) {
> > > C[i] = 0; // Will be transformed to __builtin_memset
> > > for (j = 0; j < N; j++) {
> > > C[i] += (int)A[i * N + j] * (int)B[j];
> > > }
> > > }
> > > }
> > >
> > > If I compile the case with -O2 -fno-tree-loop-distribute-patterns, the
> > > store
> > > operation 'C[i] = 0' can be eliminated by dead store elimination (dse3).
> > > But
> > > without -fno-tree-loop-distribute-patterns, it will be transformed to
> > > memset
> > > by loop distribution (ldist) because ldist executes before dse3. Finally
> > > the
> > > memset will not be eliminated.
> > >
> > > Another point is if there are other operations in the same level loop as
> > > the
> > > store operation, is it really beneficial to do loop distribution and then
> > > convert to builtin function?
> >
> > Sure, it shows a cost modeling issue given that usually loop distribution
> > merges partitions which touch the same memory stream (but IIRC maybe only
> > for loads). But more to the point we're missing to eliminate the dead store
> > which should be appearant at least after PRE - LIM2 applied store motion
> > but only PRE elides the resulting load of C[i]. Usually DCE and DSE come in
> > pairs but after PRE we have DCE, CDDCE w/o accompaning DSE only with the
> > next DSE only happening after loop distribution.
> >
> > Which means we should eventually do
> >
> > diff --git a/gcc/passes.def b/gcc/passes.def
> > index e9ed3c7bc57..be3a9becde0 100644
> > --- a/gcc/passes.def
> > +++ b/gcc/passes.def
> > @@ -254,6 +254,7 @@ along with GCC; see the file COPYING3. If not see
> >NEXT_PASS (pass_sancov);
> >NEXT_PASS (pass_asan);
> >NEXT_PASS (pass_tsan);
> > + NEXT_PASS (pass_dse);
> >NEXT_PASS (pass_dce);
> >/* Pass group that runs when 1) enabled, 2) there are loops
> > in the function. Make sure to run pass_fix_loops before
>
> Yes, doing DSE before ldist is a simple and effective way.
> This patch has been verified to be work on coremark. Not only improved
> performance, but also code size.
The test case gcc.dg/tree-ssa/ldist-33.c is failure after I added DSE.
/* { dg-do compile { target size32plus } } */
/* { dg-options "-O2 -ftree-loop-distribution -ftree-loop-distribute-patterns
-fdump-tree-ldist-details" } */
#define N (1024)
double a[N][N], b[N][N], c[N][N];
void
foo (void)
{
unsigned i, j, k;
for (i = 0; i < N; ++i)
for (j = 0; j < N; ++j)
{
c[i][j] = 0.0;
for (k = 0; k < N; ++k)
c[i][j] += a[i][k] * b[k][j];
}
}
/* { dg-final { scan-tree-dump "Loop nest . distributed: split to 1 loops and 1
library" "ldist" } } */
It is similar to the example I showed earlier. DSE eliminated 'c[i][j] = 0.0'
so no loop will be split. My question is how to handle this test case? Add
-fno-tree-dse into dg-options, modify this test case, delete this test case, or
others.
[Bug c++/99354] spurious Wuninitialized warning diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99354 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- This code violates C/C++ aliasing rules. Use memcpy or an union.
[Bug c++/99354] New: spurious Wuninitialized warning diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99354
Bug ID: 99354
Summary: spurious Wuninitialized warning diagnostic
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: raj.khem at gmail dot com
Target Milestone: ---
below test file triggers a warning with gcc 11, this worked fine with gcc10
=
float HexFloat16ToFloat(const unsigned char* value) {
unsigned int sign = (static_cast(value[1]) & 0x80) << 24U;
unsigned int exponent = (((static_cast(value[1]) & 0x7c) >> 2U)
+ 112U)
<< 23U;
unsigned int mantissa = ((static_cast(value[1]) & 0x3) << 8U |
static_cast(value[0]))
<< 13U;
unsigned int hex = sign | exponent | mantissa;
float* hex_float = reinterpret_cast(&hex);
return *hex_float;
}
g++ -O2 a.cpp -c -Wall
a.cpp: In function 'float HexFloat16ToFloat(const unsigned char*)':
a.cpp:11:11: warning: 'hex' is used uninitialized [-Wuninitialized]
11 | return *hex_float;
| ^
a.cpp:9:16: note: 'hex' declared here
9 | unsigned int hex = sign | exponent | mantissa;
|^~~
===
gcc is configured as below
Using built-in specs.
COLLECT_GCC=/mnt/b/yoe/master/build/tmp/work/riscv64-yoe-linux/opengl-es-cts/3.2.6.1-r0/recipe-sysroot-native/usr/bin/riscv64-yoe-linux/riscv64-yoe-linux-g++
COLLECT_LTO_WRAPPER=/mnt/b/yoe/master/build/tmp/work/riscv64-yoe-linux/opengl-es-cts/3.2.6.1-r0/recipe-sysroot-native/usr/bin/riscv64-yoe-linux/../../libexec/riscv64-yoe-linux/gcc/riscv64-yoe-linux/11.0.1/lto-wrapper
Target: riscv64-yoe-linux
Configured with:
../../../../../../work-shared/gcc-11.0.1-r0/gcc-7c657339d6a4a671b4cd8bc62ba4e0df6bfc7c72/configure
--build=x86_64-linux --host=x86_64-linux --target=riscv64-yoe-linux
--prefix=/host-native/usr --exec_prefix=/host-native/usr
--bindir=/host-native/usr/bin/riscv64-yoe-linux
--sbindir=/host-native/usr/bin/riscv64-yoe-linux
--libexecdir=/host-native/usr/libexec/riscv64-yoe-linux
--datadir=/host-native/usr/share --sysconfdir=/host-native/etc
--sharedstatedir=/host-native/com --localstatedir=/host-native/var
--libdir=/host-native/usr/lib/riscv64-yoe-linux
--includedir=/host-native/usr/include --oldincludedir=/host-native/usr/include
--infodir=/host-native/usr/share/info --mandir=/host-native/usr/share/man
--disable-silent-rules --disable-dependency-tracking
--with-libtool-sysroot=/host-native --enable-clocale=generic --with-gnu-ld
--enable-shared --enable-languages=c,c++ --enable-threads=posix
--disable-multilib --enable-default-pie --enable-c99 --enable-long-long
--enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=riscv64-yoe-linux-
--without-local-prefix --disable-install-libiberty --disable-libssp
--enable-libitm --enable-lto --disable-bootstrap --with-system-zlib
--with-linker-hash-style=sysv --enable-linker-build-id --with-ppl=no
--with-cloog=no --enable-checking=release --enable-cheaders=c_global
--without-isl --with-gxx-include-dir=/not/exist/usr/include/c++/11.0.1
--with-sysroot=/not/exist --with-build-sysroot=/host
--enable-poison-system-directories --with-system-zlib --disable-static
--disable-nls --with-glibc-version=2.28 --enable-initfini-array
--enable-__cxa_atexit
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.1 20210226 (experimental) (GCC)
[Bug c++/95675] [8/9/10/11 Regression] internal compiler error: in build_over_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95675 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/96078] [10 Regression] flatten attribute on constructor and destructor causes spurious warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96078 Jason Merrill changed: What|Removed |Added Known to work||11.0 Known to fail|11.0| Summary|[10/11 Regression] flatten |[10 Regression] flatten |attribute on constructor|attribute on constructor |and destructor causes |and destructor causes |spurious warning|spurious warning --- Comment #5 from Jason Merrill --- Fixed for GCC 11 so far.
[Bug c++/96078] [10/11 Regression] flatten attribute on constructor and destructor causes spurious warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96078 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:f8e7f3f3f33e22721a28772cc3f9b616e48cd1c9 commit r11-7469-gf8e7f3f3f33e22721a28772cc3f9b616e48cd1c9 Author: Jason Merrill Date: Thu Feb 11 22:01:19 2021 -0500 cgraph: flatten and same_body aliases [PR96078] The patch for PR92372 made us start warning about a flatten attribute on an alias. But in the case of C++ 'tor base/complete variants, the user didn't create the alias. If the alias target also has the attribute, the alias points to a flattened function, so we shouldn't warn. gcc/ChangeLog: PR c++/96078 * cgraphunit.c (process_function_and_variable_attributes): Don't warn about flatten on an alias if the target also has it. * cgraph.h (symtab_node::get_alias_target_tree): New. gcc/testsuite/ChangeLog: PR c++/96078 * g++.dg/ext/attr-flatten1.C: New test.
[Bug fortran/99351] ICE in gfc_finish_var_decl, at fortran/trans-decl.c:695
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99351
kargl at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2021-03-03
Ever confirmed|0 |1
CC||kargl at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Priority|P3 |P4
--- Comment #1 from kargl at gcc dot gnu.org ---
Tested against original code here. Note regression tested.
diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 4d5890fd523..94f5a1dc464 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -3867,6 +3867,15 @@ sync_statement (gfc_statement st)
stat = tmp;
saw_stat = true;
+ if (tmp->symtree
+ && (tmp->symtree->n.sym->attr.flavor == FL_PARAMETER
+ || tmp->symtree->n.sym->ts.type != BT_INTEGER))
+ {
+ gfc_error ("Expecting scalar-int-variable at %L",
+&tmp->where);
+ goto cleanup;
+ }
+
if (gfc_match_char (',') == MATCH_YES)
continue;
@@ -3884,6 +3893,16 @@ sync_statement (gfc_statement st)
gfc_error ("Redundant ERRMSG tag found at %L", &tmp->where);
goto cleanup;
}
+
+ if (tmp->symtree
+ && (tmp->symtree->n.sym->attr.flavor == FL_PARAMETER
+ || tmp->symtree->n.sym->ts.type != BT_CHARACTER))
+ {
+ gfc_error ("Expecting scalar-default-char-variable at %L",
+&tmp->where);
+ goto cleanup;
+ }
+
errmsg = tmp;
saw_errmsg = true;
[Bug fortran/99349] ICE in match_data_constant, at fortran/decl.c:426
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99349 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Priority|P3 |P4 Ever confirmed|0 |1 Last reconfirmed||2021-03-03 CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Tested against original code. Not regression tested. diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c index 723915822f3..deac4df1627 100644 --- a/gcc/fortran/decl.c +++ b/gcc/fortran/decl.c @@ -410,9 +410,7 @@ match_data_constant (gfc_expr **result) /* If a parameter inquiry ends up here, symtree is NULL but **result contains the right constant expression. Check here. */ if ((*result)->symtree == NULL - && (*result)->expr_type == EXPR_CONSTANT - && ((*result)->ts.type == BT_INTEGER - || (*result)->ts.type == BT_REAL)) + && (*result)->expr_type == EXPR_CONSTANT) return m; /* F2018:R845 data-stmt-constant is initial-data-target.
[Bug c++/99353] New: warn_unused attribute does not seem to work for static variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99353
Bug ID: 99353
Summary: warn_unused attribute does not seem to work for static
variables
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: robert-gcc at debian dot org
Target Milestone: ---
According to
https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/C_002b_002b-Attributes.html#C_002b_002b-Attributes,
the 'warn_unused' attribute 'informs the compiler that variables of this type
should be warned about if they appear to be unused, just like variables of
fundamental types'.
However this does not seem to work in case of static variables - please see the
program pasted below, that does not use any of declared variables, but "g++
-Wall -Wextra -O2 -std=c++17" diagnoses mostly local unused variables, as
marked in the comments in the program.
See https://wandbox.org/permlink/fztgVWxYX8iJ5uYS for a demo. I've tried a few
different versions of g++ there, including the latest one, but with the same
result.
--- Program contents: ---
struct __attribute__ ((warn_unused)) A
{
};
struct __attribute__ ((warn_unused)) B
{
B() {};
};
struct __attribute__ ((warn_unused)) C
{
~C() {};
};
static int i1 = 0;// warning: 'i1' defined but not used
static const int i2 = 0; // NO WARNING
static A a1; // warning: 'a1' defined but not used
static const A a2; // NO WARNING
static B b1; // NO WARNING
static const B b2; // NO WARNING
static C c1; // NO WARNING
static const C c2; // NO WARNING
int main()
{
A a3; // warning: unused variable 'a3'
const A a4; // warning: unused variable 'a4'
B b3; // warning: unused variable 'b3
const B b4; // warning: unused variable 'b4'
C c3; // warning: unused variable 'c3'
const C c4; // warning: unused variable 'c4'
static A a5; // warning: unused variable 'a5', warning: 'a5' defined
but not used
static const A a6; // warning: unused variable 'a6'
static B b5; // warning: unused variable 'b5'
static const B b6; // warning: unused variable 'b6'
static C c5; // NO WARNING
static const C c6; // NO WARNING
return 0;
}
[Bug tree-optimization/91191] vrp and boolean arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191 --- Comment #9 from Jeffrey A. Law --- Yea, I think so -- which would be undefined because the sizes are different according to the docs you referenced. Which would also invalidate part of my responses in c#5 and c#7. It sounds like something ought to be checking the constraint that the input and output must have the same size.
[Bug bootstrap/98590] [11 regression] Bootstrap failure with Ada on Cygwin since switch to C++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98590 --- Comment #13 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:8b6ebc025cf2b25fdc1e8f6e6261701dc71bac74 commit r11-7464-g8b6ebc025cf2b25fdc1e8f6e6261701dc71bac74 Author: Mikael Pettersson Date: Tue Mar 2 15:20:06 2021 -0700 [PATCH] Fix Ada bootstrap failure on Cygwin since switch to C++11 (PR98590) gcc/ada PR bootstrap/98590 * cstreams.c: Ensure fileno_unlocked() is visible on Cygwin.
[Bug c++/99331] [8/9/10/11 Regression] -Wconversion false-positive in immediate context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99331 --- Comment #4 from Marek Polacek --- This is caused by this change: @@ -7278,7 +7306,7 @@ convert_template_argument (tree parm, val = error_mark_node; } } - else if (!dependent_template_arg_p (orig_arg) + else if (!type_dependent_expression_p (orig_arg) && !uses_template_parms (t)) /* We used to call digest_init here. However, digest_init will report errors, which we don't want when complain Here orig_arg is SIZEOF_EXPR; dependent_template_arg_p (orig_arg) was true, but type_dependent_expression_p (orig_arg) is false so we warn in convert_nontype_argument.
[Bug libbacktrace/98818] [libbacktrace] Don't throw fatal error for unsupported dwarf version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98818 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Ian Lance Taylor --- I've implemented the suggestion of passing -1 to the error callback when the DWARF version is unknown.
[Bug analyzer/95043] GCC 10 Analyzer and false positive on 'memcpy(dest, src, count);'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95043 David Malcolm changed: What|Removed |Added Status|ASSIGNED|UNCONFIRMED Ever confirmed|1 |0 --- Comment #2 from David Malcolm --- I can reproduce a warning with the preprocessed source with gcc 10 at -O1 and above; stripping out the line-markers with: perl -pi -e 's/^#.*\n//g;' idea.ii I get: https://godbolt.org/z/qxehzM which shows a diagnostic, where (I think) m_array is NULL from m_fallbackAllocator.allocate, which looks like a valid warning. With gcc 11, -Wanalyzer-too-complex shows that the analyzer is hitting the complexity limit and bailing out, without emitting the diagnostic.
[Bug libbacktrace/98818] [libbacktrace] Don't throw fatal error for unsupported dwarf version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98818 --- Comment #3 from CVS Commits --- The master branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:df003d1e0bf2d0a8e2ed45a323d4e974b15dc95f commit r11-7462-gdf003d1e0bf2d0a8e2ed45a323d4e974b15dc95f Author: Ian Lance Taylor Date: Tue Mar 2 13:45:56 2021 -0800 libbacktrace: pass -1 to error callback for unrecognized DWARF PR libbacktrace/98818 * dwarf.c (dwarf_buf_error): Add errnum parameter. Change all callers. * backtrace.h: Update backtrace_error_callback comment.
[Bug c/99323] [9/10 Regression] ICE in add_hint, at diagnostic-show-locus.c:2234 since r8-379-gd1b5f5cc3cfd148e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99323 David Malcolm changed: What|Removed |Added Summary|[9/10/11 Regression] ICE in |[9/10 Regression] ICE in |add_hint, at|add_hint, at |diagnostic-show-locus.c:223 |diagnostic-show-locus.c:223 |4 since |4 since |r8-379-gd1b5f5cc3cfd148e|r8-379-gd1b5f5cc3cfd148e --- Comment #5 from David Malcolm --- Should be fixed on trunk for gcc 11 by above commit.
[Bug c/99323] [9/10/11 Regression] ICE in add_hint, at diagnostic-show-locus.c:2234 since r8-379-gd1b5f5cc3cfd148e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99323 --- Comment #4 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:41fbacdd10305654b1d10f887fa3f4677f9b8f34 commit r11-7461-g41fbacdd10305654b1d10f887fa3f4677f9b8f34 Author: David Malcolm Date: Tue Mar 2 15:46:06 2021 -0500 diagnostics: fix ICE on fix-it hints on very long lines [PR99323] PR c/99323 describes an ICE due to a failed assertion deep inside the fix-it printing machinery, where the fix-it hints on one line have not been properly sorted in layout's constructor. The underlying issue occurs when multiple fix-it hints affect a line wider that LINE_MAP_MAX_COLUMN_NUMBER, where the location_t values for characters after that threshold fall back to having column zero. It's not meaningful to try to handle fix-it hints without column information, so this patch rejects them as they are added to the rich_location, falling back to the "no fix-it hints on this diagnostic" case, fixing the crash. gcc/ChangeLog: PR c/99323 * diagnostic-show-locus.c (selftest::test_one_liner_many_fixits_2): Fix accidental usage of column 0. gcc/testsuite/ChangeLog: PR c/99323 * gcc.dg/pr99323-1.c: New test. * gcc.dg/pr99323-2.c: New test. libcpp/ChangeLog: PR c/99323 * line-map.c (rich_location::maybe_add_fixit): Reject fix-it hints at column 0.
[Bug middle-end/99276] grammar in diagnostics for overflowing the destination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99276 Martin Sebor changed: What|Removed |Added Component|c |middle-end Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Sebor --- Fixed.
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 Bug 40883 depends on bug 99276, which changed state. Bug 99276 Summary: grammar in diagnostics for overflowing the destination https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99276 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c/99276] grammar in diagnostics for overflowing the destination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99276 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:e7ca37649e4f322e7512c6d11813992c61b0a4b3 commit r11-7460-ge7ca37649e4f322e7512c6d11813992c61b0a4b3 Author: Martin Sebor Date: Tue Mar 2 13:37:01 2021 -0700 PR middle-end/99276 - grammar in diagnostics for overflowing the destination gcc/ChangeLog: PR middle-end/99276 * builtins.c (warn_for_access): Remove stray warning text.
[Bug middle-end/93235] [AArch64] ICE with __fp16 in a struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93235 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #6 from ktkachov at gcc dot gnu.org --- Created attachment 50290 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50290&action=edit reduced file from PR 99346 Attaching reduced reproducer from PR 99346 that ICEs with GCC 8, 9, 10, 11 at -O3
[Bug testsuite/99352] check_effective_target_sqrt_insn for powerpc is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99352 Segher Boessenkool changed: What|Removed |Added Ever confirmed|0 |1 Target||powerpc*-*-* Last reconfirmed||2021-03-02 Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Segher Boessenkool --- Mine.
[Bug testsuite/99352] New: check_effective_target_sqrt_insn for powerpc is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99352 Bug ID: 99352 Summary: check_effective_target_sqrt_insn for powerpc is wrong Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: segher at gcc dot gnu.org Target Milestone: --- It just just says [istarget powerpc*-*-*] but it should test whether the preprocessor symbol "_ARCH_PPCSQ" is defined.
[Bug c/99347] [9/10/11 Regression] ICE in create_block_for_bookkeeping, at sel-sched.c:4549 since r9-6859-g25eafae67f186cfa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99347 --- Comment #3 from Martin Liška --- And before that it was fixed in r7-6819-gd4cbfca47f47194a.
[Bug c/99347] [9/10/11 Regression] ICE in create_block_for_bookkeeping, at sel-sched.c:4549 since r9-6859-g25eafae67f186cfa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99347 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-03-02 Summary|[9/10/11 Regression] ICE in |[9/10/11 Regression] ICE in |create_block_for_bookkeepin |create_block_for_bookkeepin |g, at sel-sched.c:4549 |g, at sel-sched.c:4549 ||since ||r9-6859-g25eafae67f186cfa CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Started with r9-6859-g25eafae67f186cfa.
[Bug rtl-optimization/99346] [aarch64] ICE in gen_rtx_SUBREG, at emit-rtl.c:1021
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99346 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > This is a dup of bug 93235. I should note I reduced it to that bug report and looking at the expand/optimized dumps to see it was also.
[Bug middle-end/93235] [AArch64] ICE with __fp16 in a struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93235 Andrew Pinski changed: What|Removed |Added CC||spop at gcc dot gnu.org --- Comment #5 from Andrew Pinski --- *** Bug 99346 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/99346] [aarch64] ICE in gen_rtx_SUBREG, at emit-rtl.c:1021
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99346 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- This is a dup of bug 93235. *** This bug has been marked as a duplicate of bug 93235 ***
[Bug fortran/99351] New: ICE in gfc_finish_var_decl, at fortran/trans-decl.c:695
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99351 Bug ID: 99351 Summary: ICE in gfc_finish_var_decl, at fortran/trans-decl.c:695 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : $ cat z1.f90 module m character(3), parameter :: c = 'abc' contains subroutine s sync all (errmsg=c) end end $ cat z2.f90 module m integer, parameter :: a = 0 contains subroutine s sync images (*, stat=a) end end $ gfortran-11-20210221 -c z1.f90 -fcoarray=single # seems to be accepted $ $ gfortran-11-20210221 -c z1.f90 -fcoarray=lib z1.f90:5:25: 5 | sync all (errmsg=c) | 1 internal compiler error: in gfc_finish_var_decl, at fortran/trans-decl.c:695 0x7a5d01 gfc_finish_var_decl ../../gcc/fortran/trans-decl.c:695 0x7a4640 gfc_get_symbol_decl(gfc_symbol*) ../../gcc/fortran/trans-decl.c:1872 0x7c0208 gfc_conv_variable ../../gcc/fortran/trans-expr.c:2913 0x7bacea gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:8916 0x814088 gfc_trans_sync(gfc_code*, gfc_exec_op) ../../gcc/fortran/trans-stmt.c:1242 0x7767e7 trans_code ../../gcc/fortran/trans.c:2052 0x7a9b05 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6880 0x777059 gfc_generate_module_code(gfc_namespace*) ../../gcc/fortran/trans.c:2322 0x720b21 translate_all_program_units ../../gcc/fortran/parse.c:6338 0x720b21 gfc_parse_file() ../../gcc/fortran/parse.c:6620 0x76df2f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug fortran/99350] New: [9/10/11 Regression] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99350 Bug ID: 99350 Summary: [9/10/11 Regression] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1869 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20200510 and 20200517 : $ cat z1.f90 program p type t character(:), pointer :: a end type type(t) :: z character((1.)/0), target :: c = 'abc' z%a => c associate (y => z%a) print *, y end associate end $ cat z2.f90 program p type t character(:), pointer :: a end type type(t) :: z character((0.)/0), target :: c = 'abc' z%a => c associate (y => z%a) print *, y end associate end $ gfortran-11-20200510 -c z1.f90 z1.f90:6:19: 6 |character((1.)/0), target :: c = 'abc' | 1 Error: Division by zero at (1) $ gfortran-11-20210228 -c z1.f90 z1.f90:1:9: 1 | program p | 1 internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1869 0x7596ec gfc_get_symbol_decl(gfc_symbol*) ../../gcc/fortran/trans-decl.c:1869 0x75c05f generate_local_decl ../../gcc/fortran/trans-decl.c:5950 0x71af42 do_traverse_symtree ../../gcc/fortran/symbol.c:4170 0x75d004 generate_local_vars ../../gcc/fortran/trans-decl.c:6156 0x75d004 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6815 0x6e3a46 translate_all_program_units ../../gcc/fortran/parse.c:6351 0x6e3a46 gfc_parse_file() ../../gcc/fortran/parse.c:6620 0x72fd7f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug fortran/99349] New: ICE in match_data_constant, at fortran/decl.c:426
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99349 Bug ID: 99349 Summary: ICE in match_data_constant, at fortran/decl.c:426 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with r9, between 20181028 and 20181104 : $ cat z1.f90 function f() logical, parameter :: a((1.)/0) = .true. integer :: b data b /a%kind/ end $ gfortran-11-20210228 -c z1.f90 f951: internal compiler error: Segmentation fault 0xc0666f crash_signal ../../gcc/toplev.c:327 0x66dab4 match_data_constant ../../gcc/fortran/decl.c:426 0x66dc63 top_val_list ../../gcc/fortran/decl.c:499 0x66df72 gfc_match_data() ../../gcc/fortran/decl.c:716 0x6d87e1 match_word ../../gcc/fortran/parse.c:65 0x6dca2e decode_statement ../../gcc/fortran/parse.c:469 0x6dd79c next_free ../../gcc/fortran/parse.c:1316 0x6dd79c next_statement ../../gcc/fortran/parse.c:1548 0x6dee0b parse_spec ../../gcc/fortran/parse.c:3967 0x6e1bdc parse_progunit ../../gcc/fortran/parse.c:5896 0x6e35e7 gfc_parse_file() ../../gcc/fortran/parse.c:6451 0x72fd7f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug fortran/99345] [11 Regression] ICE in doloop_contained_procedure_code, at fortran/frontend-passes.c:2464
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99345 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2021-03-02 --- Comment #1 from Martin Liška --- Can you please attach postahc.f90 file?
[Bug fortran/99348] ICE in resolve_structure_cons, at fortran/resolve.c:1286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99348
G. Steinmetz changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #1 from G. Steinmetz ---
Compiles and works without "parameter" :
$ cat z2.f90
program p
type t
character(3) :: c
end type
type(t) :: x(1) = t('abc')
print *, x%c%len
end
$ gfortran-11-20210228 z1.f90 && ./a.out
3
$
[Bug fortran/99348] New: ICE in resolve_structure_cons, at fortran/resolve.c:1286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99348
Bug ID: 99348
Summary: ICE in resolve_structure_cons, at
fortran/resolve.c:1286
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with r9, between 20181028 and 20181104 :
$ cat z1.f90
program p
type t
character(3) :: c
end type
type(t), parameter :: x(1) = t('abc')
print *, x%c%len
end
$ gfortran-11-20210228 -c z1.f90
f951: internal compiler error: Segmentation fault
0xc0666f crash_signal
../../gcc/toplev.c:327
0x702c1c resolve_structure_cons
../../gcc/fortran/resolve.c:1286
0x6f1161 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:7156
0x687212 find_inquiry_ref
../../gcc/fortran/expr.c:1776
0x68a7ad simplify_ref_chain
../../gcc/fortran/expr.c:2027
0x689e3d gfc_simplify_expr(gfc_expr*, int)
../../gcc/fortran/expr.c:2266
0x68a65b simplify_parameter_variable
../../gcc/fortran/expr.c:2110
0x68a3dd gfc_simplify_expr(gfc_expr*, int)
../../gcc/fortran/expr.c:2248
0x6e753f gfc_match_varspec(gfc_expr*, int, bool, bool)
../../gcc/fortran/primary.c:2442
0x6e92d3 gfc_match_rvalue(gfc_expr**)
../../gcc/fortran/primary.c:3611
0x6bd92e match_primary
../../gcc/fortran/matchexp.c:157
0x6bd92e match_level_1
../../gcc/fortran/matchexp.c:211
0x6bd92e match_mult_operand
../../gcc/fortran/matchexp.c:267
0x6bdb78 match_add_operand
../../gcc/fortran/matchexp.c:356
0x6bddcc match_level_2
../../gcc/fortran/matchexp.c:480
0x6bdf22 match_level_3
../../gcc/fortran/matchexp.c:551
0x6be014 match_level_4
../../gcc/fortran/matchexp.c:599
0x6be014 match_and_operand
../../gcc/fortran/matchexp.c:693
0x6be202 match_or_operand
../../gcc/fortran/matchexp.c:722
0x6be2d2 match_equiv_operand
../../gcc/fortran/matchexp.c:765
[Bug c/99347] [9/10/11 Regression] ICE in create_block_for_bookkeeping, at sel-sched.c:4549
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99347 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-valid-code Target||x86_64-pc-linux-gnu --- Comment #1 from G. Steinmetz --- Similar with gcc.dg/autopar/pr90211.c plus some additional options. This started with r10, between 20190811 and 20190818 : $ gcc-11-20210228 -c pr90211.c -fprofile-generate -gstatement-frontiers \ -O1 -fvar-tracking-assignments -fschedule-insns -fselective-scheduling cc1: warning: var-tracking-assignments changes selective scheduling during RTL pass: sched1 pr90211.c: In function 'foo': pr90211.c:24:1: internal compiler error: in create_block_for_bookkeeping, at sel-sched.c:4549 24 | } | ^ 0xb2c995 create_block_for_bookkeeping ../../gcc/sel-sched.c:4549 0xb2c995 find_place_for_bookkeeping ../../gcc/sel-sched.c:4686 #...
[Bug c/99347] New: [9/10/11 Regression] ICE in create_block_for_bookkeeping, at sel-sched.c:4549
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99347 Bug ID: 99347 Summary: [9/10/11 Regression] ICE in create_block_for_bookkeeping, at sel-sched.c:4549 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Using following options and testfile gcc.dg/tree-ssa/ifc-pr69489-2.c This issue started with r9, between 20190331 and 20190414 : (under the hood related to pr95636 ?) $ gcc-11-20210228 -c ifc-pr69489-2.c -O1 -fvar-tracking-assignments -fschedule-insns -fselective-scheduling cc1: warning: var-tracking-assignments changes selective scheduling during RTL pass: sched1 ifc-pr69489-2.c: In function 'foo': ifc-pr69489-2.c:15:1: internal compiler error: in create_block_for_bookkeeping, at sel-sched.c:4549 15 | } | ^ 0xb2c995 create_block_for_bookkeeping ../../gcc/sel-sched.c:4549 0xb2c995 find_place_for_bookkeeping ../../gcc/sel-sched.c:4686 0xb2c995 generate_bookkeeping_insn ../../gcc/sel-sched.c:4786 0xb2c995 move_op_at_first_insn ../../gcc/sel-sched.c:6063 0xb2d037 code_motion_path_driver ../../gcc/sel-sched.c:6657 0xb2d2ce code_motion_process_successors ../../gcc/sel-sched.c:6342 0xb2d2ce code_motion_path_driver ../../gcc/sel-sched.c:6608 0xb2d703 move_op ../../gcc/sel-sched.c:6702 0xb2d703 move_exprs_to_boundary ../../gcc/sel-sched.c:5223 0xb2d703 schedule_expr_on_boundary ../../gcc/sel-sched.c:5436 0xb30b94 fill_insns ../../gcc/sel-sched.c:5578 0xb32943 schedule_on_fences ../../gcc/sel-sched.c:7353 0xb32943 sel_sched_region_2 ../../gcc/sel-sched.c:7491 0xb334dd sel_sched_region_1 ../../gcc/sel-sched.c:7533 0xb33fab sel_sched_region(int) ../../gcc/sel-sched.c:7634 0xb349e9 run_selective_scheduling() ../../gcc/sel-sched.c:7720 0xb1642d rest_of_handle_sched ../../gcc/sched-rgn.c:3724 0xb1642d execute ../../gcc/sched-rgn.c:3834
[Bug web/98875] DWARF5 as default causes perf probe to hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98875 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Mark Wielaard --- Hopefully https://gcc.gnu.org/gcc-11/changes.html now lists the DWARF5 requirements correctly. gcc-wwwdocs commit 80dc53f6b38d697b169fad9ce3b8787ce1c6768c (HEAD -> master, origin/master, origin/HEAD) Author: Mark Wielaard Date: Fri Feb 19 18:02:19 2021 +0100 Document the GCC11 change to DWARF5 default. * gcc-11/changes.html (General Improvements): Add a section on the DWARF version 5 default.
[Bug rtl-optimization/99346] [aarch64] ICE in gen_rtx_SUBREG, at emit-rtl.c:1021
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99346 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from Andrew Pinski --- (In reply to Sebastian Pop from comment #0) > Similar bug was reported/fixed on x86: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83723 I highly doubt it is related as that dealt with debug info and debug is information is not turned on.
[Bug c/99295] [9/10 Regression] documentation on __attribute__((malloc)) is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99295 Martin Sebor changed: What|Removed |Added Known to fail|11.0| Summary|[9/10/11 Regression]|[9/10 Regression] |documentation on|documentation on |__attribute__((malloc)) is |__attribute__((malloc)) is |wrong |wrong Known to work||11.0 --- Comment #5 from Martin Sebor --- r11-7459 updates the GCC 11 manual.
[Bug c/99295] [9/10/11 Regression] documentation on __attribute__((malloc)) is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99295 --- Comment #4 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:397ed1dbffe6c4a48548b601b35699e571e200a3 commit r11-7459-g397ed1dbffe6c4a48548b601b35699e571e200a3 Author: Martin Sebor Date: Tue Mar 2 11:19:49 2021 -0700 PR middle-end/99295 - documentation on __attribute__((malloc)) is wrong gcc/ChangeLog: PR middle-end/99295 * doc/extend.texi (attribute malloc): Reword and clarify nonaliasing property.
[Bug middle-end/95507] [meta-bug] bogus/missing -Wnonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507 Bug 95507 depends on bug 99251, which changed state. Bug 99251 Summary: [11 Regression] inconsistent -Wnonnull warning behaviour with dynamic_cast https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99251 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/99251] [11 Regression] inconsistent -Wnonnull warning behaviour with dynamic_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99251 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Martin Sebor --- Fixed in r11-7458.
[Bug c++/99251] [11 Regression] inconsistent -Wnonnull warning behaviour with dynamic_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99251 --- Comment #4 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:66ecb059c9d77cfcfb06cbdc3cac6a63b9e67f3d commit r11-7458-g66ecb059c9d77cfcfb06cbdc3cac6a63b9e67f3d Author: Martin Sebor Date: Tue Mar 2 11:12:50 2021 -0700 PR c++/99251 - inconsistent -Wnonnull warning behaviour with dynamic_cast gcc/cp/ChangeLog: PR c++/99251 * class.c (build_base_path): Call build_if_nonnull. * cp-tree.h (build_if_nonnull): Declare. * rtti.c (ifnonnull): Rename... (build_if_nonnull): ...to this. Set no-warning bit on COND_EXPR. (build_dynamic_cast_1): Adjust to name change. gcc/testsuite/ChangeLog: PR c++/99251 * g++.dg/warn/Wnonnull9.C: Expect no warnings. * g++.dg/warn/Wnonnull12.C: New test.
[Bug d/99337] Sanitizer detect heap-buffer-overflow in checkModFileAlias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99337
--- Comment #3 from Iain Buclaw ---
Fix is trivial
--- a/gcc/d/dmd/dmodule.c
+++ b/gcc/d/dmd/dmodule.c
@@ -195,7 +195,7 @@ static void checkModFileAlias(OutBuffer *buf, OutBuffer
*dotmods,
const char *m = (*ms)[j];
const char *q = strchr(m, '=');
assert(q);
-if (dotmods->length() <= (size_t)(q - m) &&
memcmp(dotmods->peekChars(), m, q - m) == 0)
+if (dotmods->length() == (size_t)(q - m) &&
memcmp(dotmods->peekChars(), m, q - m) == 0)
{
buf->reset();
size_t qlen = strlen(q + 1);
[Bug debug/99319] DW_MACRO_define_strp uses uleb128 for second operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99319 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed for GCC 11.
[Bug c/99325] [11 Regression] ICE in maybe_print_line_1, at c-family/c-ppoutput.c:454 since r11-5091
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99325 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 --- I'll have a look.
[Bug debug/99319] DW_MACRO_define_strp uses uleb128 for second operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99319
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:5a233ae4d8c978a3c863c8199d6c3050389a84d1
commit r11-7457-g5a233ae4d8c978a3c863c8199d6c3050389a84d1
Author: Jakub Jelinek
Date: Tue Mar 2 18:25:45 2021 +0100
dwarf2out: Fix up split-dwarf .debug_macro handling [PR99319]
The -gsplit-dwarf changes came a few months after .debug_macro
and the r0-120109 changes just changed the 2nd operand of
DW_MACRO_GNU_{define,undef}_indirect from the usual .debug_str
section offset argument to leb128 index into .debug_str_offsets
without changing the opcodes.
DWARF5 standardized different opcodes for those, but GCC hasn't been
changed
yet for that.
This patch starts using DW_MACRO_define_strx and DW_MACRO_undef_strx
instead of DW_MACRO_define_strp and DW_MACRO_undef_strp when -gsplit-dwarf
-gdwarf-5 -g3. I'm not sure what to do if anything with the -gdwarf-4
-gsplit-dwarf -g3 -gno-strict-dwarf case, we've been emitting it that way
for 8 years and it is an extension, so presumably the consumers that cared
have already hacks to handle DW_MACRO_GNU_{define,undef}_indirect
differently in .debug_macro 4 sections depending on if it is
.debug_macro.dwo or .debug_macro.
Another change the patch does is that it will use
DW_MACRO_{define,undef}_str{p,x} even with -gdwarf-5 -gstrict-dwarf -g3,
for DWARF 4 we were doing that only for -gno-strict-dwarf as we've emitted
.debug_macro section only in that case.
2021-03-02 Jakub Jelinek
PR debug/99319
* dwarf2out.c (output_macinfo_op): Use DW_MACRO_*_str* even with
-gdwarf-5 -gstrict-dwarf. For -gsplit-dwarf -gdwarf-5 use
DW_MACRO_*_strx instead of DW_MACRO_*_strp. Handle
DW_MACRO_define_strx and DW_MACRO_undef_strx.
(save_macinfo_strings): Use DW_MACRO_*_str* even with
-gdwarf-5 -gstrict-dwarf. Handle DW_MACRO_define_strx and
DW_MACRO_undef_strx.
[Bug rtl-optimization/99346] New: [aarch64] ICE in gen_rtx_SUBREG, at emit-rtl.c:1021
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99346 Bug ID: 99346 Summary: [aarch64] ICE in gen_rtx_SUBREG, at emit-rtl.c:1021 Product: gcc Version: 8.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: spop at gcc dot gnu.org Target Milestone: --- Created attachment 50289 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50289&action=edit pre-processed reduced testcase gcc-8, gcc-9, and gcc-10 from Ubuntu 20.04 are failing to compile the attached test at -O2 and -O3 on Graviton2 aarch64-linux. $ g++-10 -O2 a.ii [...] a.ii:362:50: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:1021 $ g++-8 -O2 a.ii [...] a.ii:493:11: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:1010 Similar bug was reported/fixed on x86: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83723
[Bug fortran/99345] New: [11 Regression] ICE in doloop_contained_procedure_code, at fortran/frontend-passes.c:2464
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99345 Bug ID: 99345 Summary: [11 Regression] ICE in doloop_contained_procedure_code, at fortran/frontend-passes.c:2464 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: doko at debian dot org Target Milestone: --- seen with trunk 20210227, building the espresso package on x86_64-linux-gnu mpif90 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -cpp -fallow-argument-mismatch -D__FFTW3 -D__MPI -D__S CALAPACK -I/<>//include -I/<>//FoX/finclude -I/<>//upflib -I/<>//Modules -I /<>//FFTXlib -I/<>//LAXlib -I/<>//UtilXlib -I/<>//FoX/finclude -I../../PW/src -I../../dft-d3 -I../../LR_Modules -c postahc.f90 f951: internal compiler error: in doloop_contained_procedure_code, at fortran/frontend-passes.c:2464 0xb9fcda doloop_contained_procedure_code ../../src/gcc/fortran/frontend-passes.c:2464 0x1afc7e5 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int (*)(gfc_expr**, int*, void*), void*) ../../src/gcc/fortran/frontend-passes.c:5299 0x1afc91e gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int (*)(gfc_expr**, int*, void*), void*) ../../src/gcc/fortran/frontend-passes.c:5623 0x1b066c8 doloop_code ../../src/gcc/fortran/frontend-passes.c:2620 0x1afc7e5 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int (*)(gfc_expr**, int*, void*), void*) ../../src/gcc/fortran/frontend-passes.c:5299 0x1afc91e gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int (*)(gfc_expr**, int*, void*), void*) ../../src/gcc/fortran/frontend-passes.c:5623 0x1afc91e gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int (*)(gfc_expr**, int*, void*), void*) ../../src/gcc/fortran/frontend-passes.c:5623 0x1afdd3b doloop_warn ../../src/gcc/fortran/frontend-passes.c:3052 0x1afdd96 gfc_run_passes(gfc_namespace*) ../../src/gcc/fortran/frontend-passes.c:156 0x1a2b069 gfc_resolve(gfc_namespace*) ../../src/gcc/fortran/resolve.c:17428 0x19ed811 gfc_resolve(gfc_namespace*) ../../src/gcc/fortran/resolve.c:17407 0x19ed811 resolve_all_program_units ../../src/gcc/fortran/parse.c:6290 0x19ed811 gfc_parse_file() ../../src/gcc/fortran/parse.c:6542 0x1a444c8 gfc_be_parse_file ../../src/gcc/fortran/f95-lang.c:212 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. full build log at https://people.debian.org/~doko/logs/20210228/filtered/gcc11/espresso_6.7-2_unstable_gcc11.log
[Bug target/99321] [11 Regression] ICE: in extract_constrain_insn, at recog.c:2670: insn does not satisfy its constraints: {*uminv16qi3} since r11-7121-g37876976b0511ec9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99321 --- Comment #3 from Jakub Jelinek --- Created attachment 50288 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50288&action=edit gcc11-pr99321.patch Untested fix for the peephole2. The rest will be done separately.
[Bug ada/99095] [10/11 regression] issue with function returning unconstrained array of limited record
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99095 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Eric Botcazou --- Thanks for reporting the problem.
[Bug ada/99095] [10/11 regression] issue with function returning unconstrained array of limited record
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99095 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:7297af89ea22c1a1da8609d811e100cf73e574d6 commit r10-9402-g7297af89ea22c1a1da8609d811e100cf73e574d6 Author: Eric Botcazou Date: Tue Mar 2 17:58:46 2021 +0100 Fix PR ada/99095 This is a regression present on the mainline and 10 branch, where we fail to make the bounds explicit for the return value of a function returning an unconstrained array of a limited record type. gcc/ada/ PR ada/99095 * sem_ch8.adb (Check_Constrained_Object): Restrict again the special optimization for limited types to non-array types except in the case of an extended return statement. gcc/testsuite/ * gnat.dg/limited5.adb: New test.
[Bug ada/99095] [10/11 regression] issue with function returning unconstrained array of limited record
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99095 --- Comment #3 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:168b75ff54b4e70650b8709816edff13f93e737a commit r11-7456-g168b75ff54b4e70650b8709816edff13f93e737a Author: Eric Botcazou Date: Tue Mar 2 17:58:46 2021 +0100 Fix PR ada/99095 This is a regression present on the mainline and 10 branch, where we fail to make the bounds explicit for the return value of a function returning an unconstrained array of a limited record type. gcc/ada/ PR ada/99095 * sem_ch8.adb (Check_Constrained_Object): Restrict again the special optimization for limited types to non-array types except in the case of an extended return statement. gcc/testsuite/ * gnat.dg/limited5.adb: New test.
[Bug libstdc++/95079] unorderd_map::insert_or_assign and try_emplace should only hash and mod once unless there is a rehash.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95079 --- Comment #6 from François Dumont --- Thanks for the feedback. If this is still a problem for you after this enhancement you should perhaps try the _Power2_rehash_policy provided as an extension. In testsuite/23_containers/unordered_set/insert/hash_policy.cc you'll see an example with a unordered_set like container defined as: template using unordered_set_power2_rehash = std::_Hashtable<_Value, _Value, _Alloc, std::__detail::_Identity, _Pred, _Hash, std::__detail::_Mask_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Power2_rehash_policy, std::__detail::_Hashtable_traits>; As stated by its name _Power2_rehash_policy will make sure that number buckets is a power of 2 and so make the modulo much trivial.
[Bug c/99317] Missed warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99317 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=44209 --- Comment #4 from Martin Sebor --- To expand on Andrew's comment: The C rules specify the type of the result of operator ?: when either of the second and third operands is a pointer to void, but they do no specify the result type when the operands are pointers to incompatible types (like int* and float*). The warning points out the latter. The C++ rules, OTOH, are more restrictive and make the ?: expression valid only when the types of the arguments can be implicitly converted to one another. Since in C++ a pointer to void isn't implicitly convertible to a pointer to an object type all the expressions in the test case are invalid. In C mode, the -Wc++-compat option helps detect C/C++ incompatibilities and detects this problem (below). So with that, since the problem is diagnosed under the right option, I think this report can be resolved as WONTFIX. (That the warning in comment #0 is issued unconditionally and not under the control of a specific option, is a separate problem tracked in in bug 44209.) $ gcc -S -Wall -Wc++-compat pr99317.c pr99317.c: In function ‘foo’: pr99317.c:3:17: warning: request for implicit conversion from ‘void *’ to ‘float *’ not permitted in C++ [-Wc++-compat] 3 | float * f = v; | ^ pr99317.c:4:15: warning: request for implicit conversion from ‘void *’ to ‘int *’ not permitted in C++ [-Wc++-compat] 4 | int * i = w; | ^ pr99317.c:5:19: warning: pointer type mismatch in conditional expression 5 | return (x ? f : i); | ^ pr99317.c:5:19: warning: request for implicit conversion from ‘void *’ to ‘int *’ not permitted in C++ [-Wc++-compat] 5 | return (x ? f : i); |~~~^~~~ pr99317.c: In function ‘foo1’: pr99317.c:10:17: warning: request for implicit conversion from ‘void *’ to ‘float *’ not permitted in C++ [-Wc++-compat] 10 | float * f = v; | ^ pr99317.c:11:15: warning: request for implicit conversion from ‘void *’ to ‘int *’ not permitted in C++ [-Wc++-compat] 11 | int * i = w; | ^ pr99317.c:12:19: warning: request for implicit conversion from ‘void *’ to ‘int *’ not permitted in C++ [-Wc++-compat] 12 | return (1 ? f : (void *)i); |~~~^~~~ pr99317.c: In function ‘bar’: pr99317.c:16:17: warning: request for implicit conversion from ‘void *’ to ‘float *’ not permitted in C++ [-Wc++-compat] 16 | float * f = v; | ^ pr99317.c:17:15: warning: request for implicit conversion from ‘void *’ to ‘int *’ not permitted in C++ [-Wc++-compat] 17 | int * i = w; | ^ pr99317.c:18:19: warning: request for implicit conversion from ‘void *’ to ‘int *’ not permitted in C++ [-Wc++-compat] 18 | return (x ? f : (void *)i); |~~~^~~~
[Bug other/93090] RFE: Add a frontend for the Rust programming language
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93090 --- Comment #3 from John Paul Adrian Glaubitz --- It seems that the gccrs frontend is now sponsored by two companies, so I think it's fine to stop the Bountysource campaign [1] and move the money to other Bountysource campaigns. > [1] https://rust-gcc.github.io/
[Bug c++/99344] [modules] import failure with intermediate namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99344 Nathan Sidwell changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-03-02 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug c++/99344] New: [modules] import failure with intermediate namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99344
Bug ID: 99344
Summary: [modules] import failure with intermediate namespace
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nathan at gcc dot gnu.org
Target Milestone: ---
found during work on 99170
// bug_a.ii
module ;
# 4 "bug_a.ii" 1
namespace STD::RANGES::INNER
{
void Frob ();
}
struct gnu_char_traits
{
void Frob()
{
STD::RANGES::INNER::Frob ();
}
};
# 19 "" 2
export module hello;
export void greeter (gnu_char_traits const &name);
// bug_b.ii
import hello;
/cc1plus -quiet -fmodules-ts bug_a.ii -fdump-lang-module -dumpbase a &&
./cc1plus -quiet -fmodules-ts bug_b.ii -fdump-lang-module -dumpbase b
In module imported at bug_b.ii:1:1:
hello: error: failed to read compiled module: Bad file data
hello: note: compiled module file is 'gcm.cache/hello.gcm'
hello: fatal error: returning to the gate for a mechanical issue
compilation terminated.
We think RANGES is an xref'd namespace :(
[Bug middle-end/99339] Poor codegen with simple varargs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99339 --- Comment #6 from Mathias Stearn --- > The question is how common in the wild it is and if it is worth the work. I'm not sure how common it is, but this is my use case. The code in the bug report is a slightly simplified example from some Real World Code I am working on: https://source.wiredtiger.com/develop/struct_w_t___c_u_r_s_o_r.html#af19f6f9d9c7fc248ab38879032620b2f. Essentially WT_CURSOR is a structure of function pointers that all take a WT_CURSOR pointer as the first argument, similar to C++ virtual functions. The get_key() and get_value() "methods" both take (WT_CURSOR*, ...) arguments, and unpack the arguments based on the format string that was set up when you opened the cursor. The expectation is that they will be called many times for each cursor object. Since we know the format string when creating the cursor I was experimenting with creating specialized functions for common formats rather than dispatching through the generic format-inspecting logic every time. I noticed that I was able to get even more performance by declaring the functions as taking the arguments they actually take rather than dealing with va_args, then casting the function pointers to the generic (WT_CURSOR, ...) type when assigning into the method slot. I assume this is UB in C (I don't know the C standard nearly as well as C++) but all ABIs I know of are designed to make this kind of thing work. I'd rather not have to do that kind of questionable shenanigans in order to get the same performance.
[Bug inline-asm/99342] Clobbered register used for input operand (aarch64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99342
Stewart Hildebrand changed:
What|Removed |Added
Attachment #50286|0 |1
is obsolete||
--- Comment #4 from Stewart Hildebrand ---
Created attachment 50287
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50287&action=edit
Simplified test case
I simplified the test case - hopefully this should make it clearer. This:
asm volatile("\n"
"ldr x0, %0 \n"
"ldr x1, %1 \n"
"ldr x2, %2 \n"
: // No output operands
: // Inputs:
"Q"(s_current->_state.fp), "Ump"(s_current->_state.sp),
"Ump"(this->_state.fp)
: // Clobbers:
// Registers we use here
"x0", "x1", "x2",
// Callee-saved registers (general purpose)
"x19", "x20", "x21", "x22", "x23", "x24",
"x25", "x26", "x27", "x28",
// Memory access
"memory");
Results in:
118: f9400080ldr x0, [x4]
11c: f9401461ldr x1, [x3, #40]
120: f9400c02ldr x2, [x0, #24]
[Bug preprocessor/99343] New: Suggest: -H option support output to file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99343 Bug ID: 99343 Summary: Suggest: -H option support output to file Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: chen3feng at gmail dot com Target Milestone: --- I use the `-H` option to analyze the header file dependency. but it is mixed with other diagnostic messages, so I have to use an awk script to split them, this solution is boring and error-prone. I suggest adding a `-HF` option (similar to the relationship of -MM and -MF option), which all output this information to a dedicated file. I also suggest using `-HH` to output only non-system header files. I'd like to contribute if this suggestion is accepted. Thanks.
[Bug bootstrap/98338] [10/11 Regression] profiledbootstrap failure on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98338 --- Comment #26 from CVS Commits --- The releases/gcc-10 branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:62125ef043e19c58780bc06d0e2f2221bbbf28f6 commit r10-9401-g62125ef043e19c58780bc06d0e2f2221bbbf28f6 Author: Jan Hubicka Date: Mon Mar 1 14:36:11 2021 +0100 Fix ICE in compute_fn_summary PR ipa/98338 * ipa-fnsummary.c (compute_fn_summary): Fix sanity check. (cherry picked from commit 150bde36c119eff4b8a74667c9d728d6a8a5e8a1)
[Bug c/99323] [9/10/11 Regression] ICE in add_hint, at diagnostic-show-locus.c:2234 since r8-379-gd1b5f5cc3cfd148e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99323 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org --- Comment #3 from David Malcolm --- Mine
[Bug inline-asm/99342] Clobbered register used for input operand (aarch64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99342 Stewart Hildebrand changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED CC||stewart.hildebrand@dornerwo ||rks.com Resolution|INVALID |--- --- Comment #3 from Stewart Hildebrand --- (In reply to Jakub Jelinek from comment #1) > That is a user error, please read the GCC earlyclobber documentation: > https://gcc.gnu.org/onlinedocs/gcc/Modifiers.html Thanks. I've read the earlyclobber documentation. I read this sentence in particular: "As earlyclobber operands are always written, a read-only earlyclobber operand is ill-formed and will be rejected by the compiler". The example code doesn't have any output operands, it only has input operands. We're not writing to the input operands. Can you please explain what the exact user error is?
[Bug d/99337] Sanitizer detect heap-buffer-overflow in checkModFileAlias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99337 Martin Liška changed: What|Removed |Added Blocks|63426 |86656 --- Comment #2 from Martin Liška --- Sorry, fixed that. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 [Bug 63426] [meta-bug] Issues found with -fsanitize=undefined https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656 [Bug 86656] [meta-bug] Issues found with -fsanitize=address
[Bug d/99337] Sanitizer detect heap-buffer-overflow in checkModFileAlias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99337 --- Comment #1 from Vittorio Zecca --- This issue was found with the address sanitizer, while issues in bug 63426 were found with the undefined behavior sanitizer.
[Bug c/99340] -Werror=maybe-uninitialized warning with -fPIE, but not -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99340 --- Comment #6 from Richard Biener --- GCC 9 warns as well. I think this was a false negative which is now fixed. Note GCC 10.1.0 and GCC 10.2.0 warn for me as well, so something must have regressed this between 10.2.0 and g:eddcb627ccfbd97e025cf366 I'm inclined to mark as INVALID.
[Bug inline-asm/99342] Clobbered register used for input operand (aarch64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99342 --- Comment #2 from Stewart Hildebrand --- Created attachment 50286 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50286&action=edit Preprocessed file I compressed the sched.ii file since it exceeded 1000KB. I've attached sched.ii.tar.gz as the directions suggested: "The file you are trying to attach is 1239 kilobytes (KB) in size. Attachments cannot be more than 1000 KB. We recommend that you compress your attachment, e.g. using gzip, bzip2 or xz."
[Bug inline-asm/99342] Clobbered register used for input operand (aarch64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99342 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- That is a user error, please read the GCC earlyclobber documentation: https://gcc.gnu.org/onlinedocs/gcc/Modifiers.html
[Bug libstdc++/95079] unorderd_map::insert_or_assign and try_emplace should only hash and mod once unless there is a rehash.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95079 --- Comment #5 from Mathias Stearn --- @François Dumont: Sorry I didn't see your question earlier. The reason that unordered_map perf hurts on 64-bit platforms is because it is designed to do a size_t modulus-by-prime on every lookup, and on most platforms that is *very* expensive (up to 100 cycles for 64 bits vs 20ish for 32 bits). Some very modern CPUs have made improvements here, but it is still much more expensive than just using power-of-2 buckets and masking, even if you need to hash the hash if you don't trust the low order bits to have enough entropy. Unfortunately, fixing this is a pretty big ABI break, so it isn't going to change any time soon.
[Bug inline-asm/99342] New: Clobbered register used for input operand (aarch64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99342
Bug ID: 99342
Summary: Clobbered register used for input operand (aarch64)
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: stewart.hildebrand at dornerworks dot com
Target Milestone: ---
In this snippet (adapted from OSv unikernel's arch/aarch64/arch-switch.hh), x0,
x1, and x2 are in the clobber list, yet, under certain conditions the compiler
uses one of these clobbered registers for an input operand.
asm volatile("\n"
"str x29, %0 \n"
"mov x2, sp \n"
"adr x1, 1f \n" /* address of label */
"stp x2, x1, %1 \n"
"ldp x29, x0, %2 \n"
"ldp x2, x1, %3 \n"
"mov sp, x2 \n"
"blr x1 \n"
"1: \n" /* label */
:
: "Q"(s_current->_state.fp), "Ump"(s_current->_state.sp),
"Ump"(this->_state.fp), "Ump"(this->_state.sp)
: // Registers we use here
"x0", "x1", "x2",
// Callee-saved registers (general purpose)
"x19", "x20", "x21", "x22", "x23", "x24",
"x25", "x26", "x27", "x28",
// Callee-saved registers (SIMD/FPU)
"d8", "d9", "d10", "d11", "d12", "d13",
"d14", "d15",
// Memory access
"memory");
In the assembly code emitted, lines 184 and 188 use x1 as the input operand:
174: f99dstr x29, [x4]
178: 910003e2mov x2, sp
17c: 10c1adr x1, 194
<_ZN5sched3cpu25reschedule_from_interruptENSt6chrono8durationIlSt5ratioILl1ELl10+0x104>
180: a9028462stp x2, x1, [x3, #40]
184: a941803dldp x29, x0, [x1, #24]
188: a9428422ldp x2, x1, [x1, #40]
18c: 915fmov sp, x2
190: d63f0020blr x1
The conditions under which this happens seem to include the following:
* Optimization -O2
* The function containing the inline asm gets inlined
* The function that calls the inlined function has some other code in it
As I understand it, the compiler should not have chosen a register that is
listed in the clobber list:
"When the compiler selects which registers to use to represent input and
output operands, it does not use any of the clobbered registers. As a result,
clobbered registers are available for any use in the assembler code."
(https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Clobbers-and-Scratch-Registers)
This test case compiled correctly in g++ 9.2. We observed the bug in g++ 10.2.
We were able to reproduce this bug with the cross g++ 10.2.1 packaged with
Fedora x86_64, the native g++ 10.2.0 packaged with Ubuntu 20.10 aarch64, and
the ARM-packaged cross g++ 10.2.1 (10.2-2020.11) from
https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-a/downloads.
I attached the .ii file as described in the bug reporting instructions. Here is
the command line used to create the .ii file:
$ aarch64-none-linux-gnu-g++ -v -save-temps -std=gnu++11 -g -Wall -Wextra
-Werror -O2 -isystem
/home/stew/osv/build/downloaded_packages/aarch64/boost/upstream/boost_1_72_0 -c
-o sched.o sched.cc
There were no warnings/errors. Please let me know if you need any more info.
This bug was discovered by OSv developer Waldek Kozaczuk.
I verified that I can reproduce the buggy output with this command:
$ aarch64-none-linux-gnu-g++ -v -std=gnu++11 -g -Wall -Wextra -Werror -O2 -c -o
sched.o sched.ii
Using built-in specs.
COLLECT_GCC=aarch64-none-linux-gnu-g++
Target: aarch64-none-linux-gnu
Configured with:
/tmp/dgboter/bbs/build04--cen7x86_64/buildbot/cen7x86_64--aarch64-none-linux-gnu/build/src/gcc/configure
--target=aarch64-none-linux-gnu --prefix=
--with-sysroot=/aarch64-none-linux-gnu/libc
--with-build-sysroot=/tmp/dgboter/bbs/build04--cen7x86_64/buildbot/cen7x86_64--aarch64-none-linux-gnu/build/build-aarch64-none-linux-gnu/install//aarch64-none-linux-gnu/libc
--with-bugurl=https://bugs.linaro.org/ --enable-gnu-indirect-function
--enable-shared --disable-libssp --disable-libmudflap --enable-checking=release
--enable-languages=c,c++,fortran
--with-gmp=/tmp/dgboter/bbs/build04--cen7x86_64/buildbot/cen7x86_64--aarch64-none-linux-gnu/build/build-aarch64-none-linux-gnu/host-tools
--with-mpfr=/tmp/dgboter/bbs/build04--cen7x86_64/buildbot/cen7x86_64--aarch64-none-linux-gnu/build/build-aarch64-none-linux-gnu/host-tools
--with-mpc=/tmp/dgboter/bbs/build04--cen7x86_64/buildbot/cen7x86_64--aarch64-none-linux-gnu/build/build-aarch64-none-linux-gnu/host-tools
--with-isl=/tmp/dgboter/bbs/build04--cen
[Bug c++/82959] g++ doesn't appreciate C++17 evaluation order rules for overloaded operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82959 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Jakub Jelinek --- Created attachment 50285 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50285&action=edit gcc11-pr82959.patch Untested fix.
[Bug middle-end/99339] Poor codegen with simple varargs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99339 --- Comment #5 from Mathias Stearn --- I filed a related bug with clang right after this one if anyone want to follow along https://bugs.llvm.org/show_bug.cgi?id=49395. Just because clang does worse doesn't mean gcc shouldn't do better ;)
[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99307 --- Comment #5 from Paul Thomas --- (In reply to Tobias Burnus from comment #4) > (In reply to Dominique d'Humieres from comment #1) > > Reduced test > > While -fsanitize=address,undefined does not find anything on > x86_64-gnu-linux, I do see with valgrind: > > ==98347== Invalid write of size 8 > ==98347==at 0x40397E: test_t1_ (ijd.f90:43) > ==98347==by 0x403A4E: MAIN__ (ijd.f90:60) > ==98347==by 0x403A85: main (ijd.f90:61) > ==98347== Address 0x4f55c98 is 8 bytes inside a block of size 12 alloc'd > ==98347==at 0x483DFAF: realloc (in > /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==98347==by 0x402A6D: test_t1_ (ijd.f90:40) > ==98347==by 0x403A4E: MAIN__ (ijd.f90:60) > ==98347==by 0x403A85: main (ijd.f90:61) > > That's: > x = [t2(1,10.0),t2(2,20.0),t2(3,30.0)] > y = x > x = realloc_t1 (y) ! <<< line 40, 8 bytes alloc'd inside block of size 12 > x = realloc_t1 (x) > x = x(3:1:-1) + y > x = [t2(1,10.0),t2(2,20.0),t2(3,30.0)] ! <<< line 43, invalid write of > size 8 > > Looking at the Fortran code, > x and y have the dynamic type T2 until 'realloc_t1', which turns this into > the dynamic type T1. > > In the last line (line 43), the dynamic type changes again to T2. > > In terms of memory usage: 3*8bytes before the first realloc_t1 call, then > 3*4bytes and for the last line again 3*8bytes. > > * * * > > It seems as if the reallocation does not work properly if the dynamic type > changes – at least not if the required size increased in the assignment. > (The valgrind message implies that shrinking did work in line 40.) I am unable to see why this is happening. The valgrind complaints go away if a different array size is assigned before the changes in type. For some reason, it seems that the vptr->size is not being read correctly or is never set. Paul
[Bug libstdc++/99341] [11 Regression] new std::call_once is not backwards compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99341 --- Comment #2 from Jonathan Wakely --- The new implementation added these new symbols to libstdc++.so: _ZNSt9once_flag11_M_activateEv _ZNSt9once_flag9_M_finishEb I think I'd like to keep them, but have the new implementation disabled by default (except for the ABI-changing gnu-versioned-namespace build). The new implementation is superior (it fixes PR 66146, and performs better in some cases due to inlining an initial check to see if executions should be passive) so I'd like to retain it for users who explicitly request it. By default we need to be compatible with the old version based on pthread_once. At some point (maybe when there are further ABI changes queued) maybe we'll do another painful transition like the cxx11-abi one and switch to the new std::once_flag by default. Maybe the new std::once_flag should be moved to an inline namespace, and then the symbols above defined as aliases for the equivalents using the inline namespace in the mangled name (the aliases are needed if we want to support binaries that are already using them, e.g. packages in the upcoming Fedora 34 which were compiled with gcc-11.0.1 already).
[Bug libstdc++/99333] std::filesystem::path().is_absolute() thinks UNC paths aren't absolute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99333 --- Comment #4 from Moritz Bunkus --- Oh right, sorry — I misread your earlier comment.
[Bug libstdc++/99341] [11 Regression] new std::call_once is not backwards compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99341
Jonathan Wakely changed:
What|Removed |Added
Known to fail||11.0
Known to work||10.2.1
Priority|P3 |P1
Status|UNCONFIRMED |ASSIGNED
Target Milestone|--- |11.0
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2021-03-02
--- Comment #1 from Jonathan Wakely ---
More details ...
Although libstdc++ ignores any fork generation bits, glibc doesn't and
it *requires* a (possibly zero) fork generation to be present.
The __pthread_once_slow function uses CAS to set the once_control
variable, and if that succeeds and the IN_PROGRESS bit is set, it
compares the high bits with the current fork generation.
If the IN_PROGRESS bit was set by the new libstdc++ std::call_once
there won't be a fork generation. If the process' fork generation is
not zero then this check in glibc will be false:
/* Check whether the initializer execution was interrupted by a
fork. We know that for both values, __PTHREAD_ONCE_INPROGRESS
is set and __PTHREAD_ONCE_DONE is not. */
if (val == newval)
{
/* Same generation, some other thread was faster. Wait and
retry. */
futex_wait_simple ((unsigned int *) once_control,
(unsigned int) newval, FUTEX_PRIVATE);
continue;
}
If std::call_once in another thread set val=2 but the fork gen is 4,
then newval=4|1 and so val == newval is false. That means glibc
assumes that an in-progress initialization was interrupted by a fork
and so this thread should run it. That means two threads will be
running it at once.
Demo:
#include
#include
#include
#include
#include
extern std::once_flag once_flag;
extern void old();
#if __GNUC__ >= 11
std::once_flag once_flag;
int main()
{
// increase for generation:
switch (fork())
{
case -1:
abort();
case 0:
break;
default:
wait(nullptr);
return 0;
}
// This is the child process, fork generation is non-zero.
std::call_once(once_flag, [] {
std::cout << "Active execution started using new code\n";
old();
std::cout << "Active execution finished using new code\n";
});
}
#else
void old()
{
std::call_once(once_flag, [] {
std::cout << "Active execution started using old code\n";
std::cout << "Active execution finished using old code\n";
});
}
#endif
Compile this once with GCC 11 and once with GCC 10 and link with GCC
11, and instead of deadlocking (as it should do) you'll get:
Active execution started using new code
Active execution started using old code
Active execution finished using old code
Active execution finished using new code
And using a libstdc++ build with _GLIBCXX_ASSERTIONS you'll get:
/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++11/mutex.cc:79: void
std::once_flag::_M_finish(bool): Assertion 'prev & _Bits::_Active' failed.
because the "inner" execution changes the state to _Done when it
finishes, and the assertion in the "outer" execution fails.
[Bug middle-end/99339] Poor codegen with simple varargs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99339 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Clearly LLVM doesn't do the varargs optimizations we do. Anyway, perhaps for these special cases we could just figure out which of the exact arguments is accessed (if for all .VA_ARG calls we see the exact sequence of those calls from __builtin_va_start and they are few) in a target hook called from the stdarg pass and let the target hook replace them with some internal fn call or register var read etc. And optimize away __builtin_va_start if nothing else would use it after that optimization. The question is how common in the wild it is and if it is worth the work. I guess e.g. the open function (when not implemented in assembly or hacked up so that it just has 3 arguments on the definition instead of 2 + ...) is an example where it could benefit from that. The lowering is done so that the GIMPLE optimizers can actually optimize all the struct field loads/stores etc., doing it only in RTL optimizations results in worse code.
[Bug libstdc++/99341] New: [11 Regression] new std::call_once is not backwards compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99341 Bug ID: 99341 Summary: [11 Regression] new std::call_once is not backwards compatible Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: ABI Severity: blocker Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- Target: *-*-*linux* Creating a new bug for bug 66146 comment 41 increased visibility, and to deal with it separately from the exception-handling bug that is the topic of bug 66146. Quoting from there: The new std::call_once using a futex is not backwards compatible, so I think it needs to be reverted, or hidden behind an ABI-breaking flag. The new std::once_flag::_M_activate() function sets _M_once=1 when an initialization is in progress. With glibc, if a call to the new std::call_once happens before a call to the old version of std::call_once, then glibc's pthread_once will find no fork generation value in _M_once and so will think it should run the init_function itself. Both threads will run their init_function, instead of the second one waiting for the first to finish. With musl, if a call to the old std::call_once happens before a call to the new std::call_once, then the second thread won't set _M_once=3 and so musl's pthread_once won't wake the second thread when the first finishes. The second thread will sleep forever (or until a spurious wake from the futex wait).
[Bug c/99340] -Werror=maybe-uninitialized warning with -fPIE, but not -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99340 Martin Liška changed: What|Removed |Added Status|WAITING |NEW CC||rguenth at gcc dot gnu.org --- Comment #5 from Martin Liška --- Started on gcc-10 branch with g:eddcb627ccfbd97e025cf366cc3f3bad76211785. Anyway, the warning contains quite some false positives..
[Bug libstdc++/99333] std::filesystem::path().is_absolute() thinks UNC paths aren't absolute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99333 --- Comment #3 from Jonathan Wakely --- (In reply to Moritz Bunkus from comment #2) > while Boost recognizes both. That's what I wanted to know, thanks. > Note that __CYGWIN__ is not defined with the compiler from MXE! Obviously, because it's not cygwin. Which is why //x paths are not treated as a root-name. As I said, that's by design, but can be changed.
[Bug middle-end/99339] Poor codegen with simple varargs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99339 --- Comment #3 from Richard Biener --- So we could try to lower even va_start/end to expose the va_list meta fully to the middle-end early which should eventually allow eliding it. That would require introducing other builtins/internal fns to allow referencing the frame or the incoming arg registers by number.
[Bug c/99340] -Werror=maybe-uninitialized warning with -fPIE, but not -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99340 --- Comment #4 from Martin Liška --- (In reply to Matthias Klose from comment #3) > Created attachment 50284 [details] > preprocessed source > > original test case before reducing > > gcc -std=gnu99 -Werror=uninitialized -Werror=maybe-uninitialized -Wall > -Wno-unused-variable -Wno-unused-but-set-variable -Wformat -Wno-pointer-sign > -Werror=format-security -fstack-protector-strong -fPIC -O2 -c > ags_midi_buffer_util_orig.i Using this with -fPIE reports the warning only on gcc-10 branch. All other is fine.
[Bug c++/96443] Incorrect satisfaction value for dependent placeholder return type constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96443 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:e52f8ec25c0e58ebd083e8370e2fbc8af4120d87 commit r11-7454-ge52f8ec25c0e58ebd083e8370e2fbc8af4120d87 Author: Patrick Palka Date: Tue Mar 2 07:49:29 2021 -0500 c++: Fix satisfaction of placeholder type constraints [PR96443] This fixes the way we check satisfaction of constraints on placeholder types in various deduction contexts, and in particular when the constraint is dependent. Firstly, when evaluating the return type requirement of a compound requirement, we currently substitute the outer template arguments into the constraint before checking satisfaction. But we should instead be passing in the complete set of template arguments to satisfaction and not do a prior separate substitution. Our current approach leads to us incorrectly rejecting the testcase concepts-return-req2.C below. Secondly, when checking the constraints on a placeholder variable or return type, we don't consider the template arguments of the enclosing context at all. This leads to bogus errors during satisfaction when the constraint is dependent as in the testcase concepts-placeholder3.C below. In order to fix these two issues, we need to be able to normalize the constraints on a placeholder 'auto' on demand, which in turn requires us to know the template parameters that were in scope where the 'auto' was introduced. This information currently doesn't seem to be easily available when we need it, so this patch turns PLACEHOLDER_TYPE_CONSTRAINTS into a TREE_LIST whose TREE_PURPOSE additionally holds the value of current_template_parms whence a constrained 'auto' was formed. This patch also removes some seemingly wrong handling of placeholder type arguments from tsubst_parameter_mapping. The code doesn't trigger with the example used in the comments, because type_uses_auto doesn't look inside non-deduced contexts such as the operand of decltype. And the call to do_auto_deduction seems confused because if 'arg' is a type, then so is 'parm', and therefore 'init' too is a type, but do_auto_deduction expects it to be an expression. Before this patch, this code was dead (as far as our testsuite can tell), but now it breaks other parts of this patch, so let's remove it. gcc/cp/ChangeLog: PR c++/96443 PR c++/96960 * constraint.cc (type_deducible_p): Don't substitute into the constraints, and instead just pass 'args' to do_auto_deduction as the outer template arguments. (tsubst_parameter_mapping): Remove confused code for handling placeholder type arguments. (normalize_placeholder_type_constraint): Define. (satisfy_constraint_expression): Use it to handle placeholder 'auto' types. * cp-tree.h (PLACEHOLDER_TYPE_CONSTRAINTS_INFO): Define. (PLACEHOLDER_TYPE_CONSTRAINTS): Redefine in terms of the above. * pt.c (tsubst) : Use PLACEHOLDER_TYPE_CONSTRAINTS_INFO instead. (make_constrained_placeholder_type): Set PLACEHOLDER_TYPE_CONSTRAINTS_INFO instead. (do_auto_deduction): Clarify comments about the outer_targs parameter. Rework satisfaction of a placeholder type constraint to pass in the complete set of template arguments directly to constraints_satisfied_p. (splice_late_return_type): Use PLACEHOLDER_TYPE_CONSTRAINTS_INFO instead. Also rebuild the the constraint info on the new auto. gcc/testsuite/ChangeLog: PR c++/96443 PR c++/96960 * g++.dg/concepts/abbrev9.C: New test. * g++.dg/cpp2a/concepts-lambda15.C: New test. * g++.dg/cpp2a/concepts-placeholder3.C: New test. * g++.dg/cpp2a/concepts-return-req2.C: New test. * g++.dg/cpp2a/concepts-ts1.C: Add dg-bogus directive to the call to f15 that we expect to accept.
[Bug c++/96960] [C++20] ICE in tsubst_copy_and_build, at cp/pt.c:20531 from lambda in return-type-requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96960 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:e52f8ec25c0e58ebd083e8370e2fbc8af4120d87 commit r11-7454-ge52f8ec25c0e58ebd083e8370e2fbc8af4120d87 Author: Patrick Palka Date: Tue Mar 2 07:49:29 2021 -0500 c++: Fix satisfaction of placeholder type constraints [PR96443] This fixes the way we check satisfaction of constraints on placeholder types in various deduction contexts, and in particular when the constraint is dependent. Firstly, when evaluating the return type requirement of a compound requirement, we currently substitute the outer template arguments into the constraint before checking satisfaction. But we should instead be passing in the complete set of template arguments to satisfaction and not do a prior separate substitution. Our current approach leads to us incorrectly rejecting the testcase concepts-return-req2.C below. Secondly, when checking the constraints on a placeholder variable or return type, we don't consider the template arguments of the enclosing context at all. This leads to bogus errors during satisfaction when the constraint is dependent as in the testcase concepts-placeholder3.C below. In order to fix these two issues, we need to be able to normalize the constraints on a placeholder 'auto' on demand, which in turn requires us to know the template parameters that were in scope where the 'auto' was introduced. This information currently doesn't seem to be easily available when we need it, so this patch turns PLACEHOLDER_TYPE_CONSTRAINTS into a TREE_LIST whose TREE_PURPOSE additionally holds the value of current_template_parms whence a constrained 'auto' was formed. This patch also removes some seemingly wrong handling of placeholder type arguments from tsubst_parameter_mapping. The code doesn't trigger with the example used in the comments, because type_uses_auto doesn't look inside non-deduced contexts such as the operand of decltype. And the call to do_auto_deduction seems confused because if 'arg' is a type, then so is 'parm', and therefore 'init' too is a type, but do_auto_deduction expects it to be an expression. Before this patch, this code was dead (as far as our testsuite can tell), but now it breaks other parts of this patch, so let's remove it. gcc/cp/ChangeLog: PR c++/96443 PR c++/96960 * constraint.cc (type_deducible_p): Don't substitute into the constraints, and instead just pass 'args' to do_auto_deduction as the outer template arguments. (tsubst_parameter_mapping): Remove confused code for handling placeholder type arguments. (normalize_placeholder_type_constraint): Define. (satisfy_constraint_expression): Use it to handle placeholder 'auto' types. * cp-tree.h (PLACEHOLDER_TYPE_CONSTRAINTS_INFO): Define. (PLACEHOLDER_TYPE_CONSTRAINTS): Redefine in terms of the above. * pt.c (tsubst) : Use PLACEHOLDER_TYPE_CONSTRAINTS_INFO instead. (make_constrained_placeholder_type): Set PLACEHOLDER_TYPE_CONSTRAINTS_INFO instead. (do_auto_deduction): Clarify comments about the outer_targs parameter. Rework satisfaction of a placeholder type constraint to pass in the complete set of template arguments directly to constraints_satisfied_p. (splice_late_return_type): Use PLACEHOLDER_TYPE_CONSTRAINTS_INFO instead. Also rebuild the the constraint info on the new auto. gcc/testsuite/ChangeLog: PR c++/96443 PR c++/96960 * g++.dg/concepts/abbrev9.C: New test. * g++.dg/cpp2a/concepts-lambda15.C: New test. * g++.dg/cpp2a/concepts-placeholder3.C: New test. * g++.dg/cpp2a/concepts-return-req2.C: New test. * g++.dg/cpp2a/concepts-ts1.C: Add dg-bogus directive to the call to f15 that we expect to accept.
[Bug c/99340] -Werror=maybe-uninitialized warning with -fPIE, but not -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99340 --- Comment #3 from Matthias Klose --- Created attachment 50284 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50284&action=edit preprocessed source original test case before reducing gcc -std=gnu99 -Werror=uninitialized -Werror=maybe-uninitialized -Wall -Wno-unused-variable -Wno-unused-but-set-variable -Wformat -Wno-pointer-sign -Werror=format-security -fstack-protector-strong -fPIC -O2 -c ags_midi_buffer_util_orig.i
[Bug middle-end/99339] Poor codegen with simple varargs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99339 --- Comment #2 from Richard Biener --- Btw, clang manages to produce the following, which shows the situation could be worse ;) test_va:# @test_va .cfi_startproc # %bb.0: subq$88, %rsp .cfi_def_cfa_offset 96 movl%eax, %r10d movl%edi, %eax testb %r10b, %r10b je .LBB0_2 # %bb.1: movaps %xmm0, -48(%rsp) movaps %xmm1, -32(%rsp) movaps %xmm2, -16(%rsp) movaps %xmm3, (%rsp) movaps %xmm4, 16(%rsp) movaps %xmm5, 32(%rsp) movaps %xmm6, 48(%rsp) movaps %xmm7, 64(%rsp) .LBB0_2: movq%rsi, -88(%rsp) movq%rdx, -80(%rsp) movq%rcx, -72(%rsp) movq%r8, -64(%rsp) movq%r9, -56(%rsp) leaq-96(%rsp), %rcx movq%rcx, -112(%rsp) leaq96(%rsp), %rcx movq%rcx, -120(%rsp) movabsq $206158430216, %rcx # imm = 0x38 movq%rcx, -128(%rsp) movl$8, %edx cmpq$40, %rdx ja .LBB0_4 # %bb.3: movl$8, %ecx addq-112(%rsp), %rcx addl$8, %edx movl%edx, -128(%rsp) jmp .LBB0_5 .LBB0_4: movq-120(%rsp), %rcx leaq8(%rcx), %rdx movq%rdx, -120(%rsp) .LBB0_5: addl(%rcx), %eax addq$88, %rsp .cfi_def_cfa_offset 8 retq
[Bug middle-end/99339] Poor codegen with simple varargs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99339
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords||missed-optimization
Target||x86_64-*-*
Component|c |middle-end
CC||matz at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-03-02
--- Comment #1 from Richard Biener ---
The stack space is not eliminated because we lower __builtin_va_start only
after RTL expansion and that reserves stack space necessary for accessing
some of the meta (including the passed value itself) as memory.
So it's unavoidable up to somebody designing sth smarter around varargs
and GIMPLE.
Arguably the not lowered variant would be easier to expand optimally:
int test_va (int x)
{
struct va[1];
int i;
int _7;
[local count: 1073741824]:
__builtin_va_start (&va, 0);
i_4 = .VA_ARG (&va, 0B, 0B);
__builtin_va_end (&va);
_7 = i_4 + x_6(D);
va ={v} {CLOBBER};
return _7;
I'm not fully sure why we lower at all. Part of the lowering determines
whether there's any FP arguments referenced and optimizes based on that,
but IIRC that's all.
[Bug c/99340] -Werror=maybe-uninitialized warning with -fPIE, but not -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99340 --- Comment #2 from Richard Biener --- PIC allows interposing ags_midi_buffer_util_get_varlength and thus possibly initializing the argument. PIE does not allow this so we see it is not initialized. I suppose the change on the branch is for some unreduced testcase where different optimization might trigger the new warning (correctly I think).
