[Bug analyzer/93520] Compilation of Python 3.9 with gcc 10 and -fanalyzer fails with internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93520 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-31 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/93522] [10 Regression] ICE in gfc_release_symbol, at fortran/symbol.c:3121 since r10-2912-g70570ec192745095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93522 Martin Liška changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-31 CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org Known to work||9.2.0 Target Milestone|--- |10.0 Summary|f951: internal compiler |[10 Regression] ICE in |error: in |gfc_release_symbol, at |gfc_release_symbol, at |fortran/symbol.c:3121 since |fortran/symbol.c:3121 |r10-2912-g70570ec192745095 Ever confirmed|0 |1 Known to fail||10.0 --- Comment #1 from Martin Liška --- Confirmed, started with r10-2912-g70570ec192745095.
[Bug tree-optimization/93521] 40% slower in O2 than O1 (tree-pre)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93521 Alexander Monakov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||amonakov at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Alexander Monakov --- Dup. *** This bug has been marked as a duplicate of bug 93056 ***
[Bug tree-optimization/93056] Poor codegen for heapsort in stephanov_vector benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93056 Alexander Monakov changed: What|Removed |Added CC||hehaochen at hotmail dot com --- Comment #2 from Alexander Monakov --- *** Bug 93521 has been marked as a duplicate of this bug. ***
[Bug analyzer/93520] Compilation of Python 3.9 with gcc 10 and -fanalyzer fails with internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93520 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Martin Liška --- It's fixed on trunk, likely dup of PR93356. *** This bug has been marked as a duplicate of bug 93356 ***
[Bug analyzer/93356] ICE in add_constraint, at analyzer/constraint-manager.cc:672
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93356 Martin Liška changed: What|Removed |Added CC||cstratak at redhat dot com --- Comment #4 from Martin Liška --- *** Bug 93520 has been marked as a duplicate of this bug. ***
[Bug analyzer/93511] ICE in make_region_for_type analyzing zlib/gzwrite.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93511 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-31 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug tree-optimization/93516] [10 regression] ICE in verify_sra_access_forest, at tree-sra.c:2342 since r10-6276-g1d8593070a62b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93516 Martin Liška changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/93516] [10 regression] ICE in verify_sra_access_forest, at tree-sra.c:2342 since r10-6276-g1d8593070a62b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93516 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Known to work||9.2.0 Keywords||ice-on-valid-code Last reconfirmed||2020-01-31 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org Ever confirmed|0 |1 Summary|[10 regression] ICE in |[10 regression] ICE in |verify_sra_access_forest, |verify_sra_access_forest, |at tree-sra.c:2342 |at tree-sra.c:2342 since ||r10-6276-g1d8593070a62b Target Milestone|--- |10.0 Known to fail||10.0 --- Comment #1 from Martin Liška --- Confirmed, started with r10-6276-g1d8593070a62b.
[Bug middle-end/93509] Stack protector should offer trap-only handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93509 Richard Biener changed: What|Removed |Added Severity|normal |enhancement
[Bug middle-end/93512] Introduce rotate_truncation_mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93512 --- Comment #1 from Richard Biener --- Please do not introduce ROTATE_COUNT_TRUNCATED. RTL should always be well-defined and semantics _not_ depend on the recognized instruction (see all the hassle with SHIFT_COUNT_TRUNCATED and targets having shifts that do and shifts that don't truncate...). Preferably RTL semantics should also not depend on the target - instead different RTL, (rotaterttr?), should be used when semantics differ (or, when truncation is desired, simply explicitely truncate).
[Bug fortran/93365] ICE in match_data_constant, at fortran/decl.c:426
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93365 markeggleston at gcc dot gnu.org changed: What|Removed |Added Assignee|markeggleston at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #9 from markeggleston at gcc dot gnu.org --- Since I'm no longer investigating this I've removed myself from assignment. This problem does not occur when the compiler is built with bootstrap but does when built with gcc 6.3. What should be done about its status? I think it should be closed. Any suggestions/opinions?
[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374
--- Comment #30 from Thomas Henlich ---
(In reply to Jerry DeLisle from comment #29)
> I think this last patch above fixes the last adjustment needed. I could be
> wrong I suppose. Is this ready to close?
Jerry, thanks for the good work so far!
But I found this issue:
program test
write(*, "(g0.2)") 0.1e-9
write(*, "(g8.2)") 0.1e-9
write(*, "(g0.2)") 0.1e123_10
write(*, "(g8.2)") 0.1e123_10
end
Output from GCC 9.2.0:
0.10E-09
0.10E-09
0.10E+0123
0.10+123
I think this is correct, according to the table from the standard F2008/F2018
(see my comment #23 above)
Now after these patches, I get something different:
0.10E-9
0.10E-09
0.10E+123
0.10+123
With G0.d" (and starting with F2018 with E0.d, D0.d, EN0.d, ES0.d etc.
likewise), the processor is only allowed to remove leading/trailing spaces
("select ... actual field width"). It is not allowed to change the exponent
format in this case. This would only be the case if E...e0" editing is
explicitly requested.
[Bug middle-end/93512] Introduce rotate_truncation_mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93512 --- Comment #2 from Jakub Jelinek --- Segher said he thinks that ROTATE/ROTATERT on all targets will do the truncation, so it is just a matter of proving that. Sure, one can add explictly patterns like (define_insn "rotl3_cntmask" [(set (match_operand:GPR 0 "gpc_reg_operand" "=r") (rotate:GPR (match_operand:GPR 1 "gpc_reg_operand" "r") (and:SI (match_operand:SI 2 "reg_or_cint_operand" "rn") (match_operand:SI 3 "const_int_operand" "n")))] "UINTVAL (operands[3]) == GET_MODE_MASK (mode)" "rotl%I2 %0,%1,%2" [(set_attr "type" "shift") (set_attr "maybe_var_shift" "yes")]) and e.g. i386 target already does for a few patterns (but not all). But: $ find config -name \*.md | xargs grep '(rotate:' | wc -l 139 $ find config -name \*.md | xargs grep '(rotatert:' | wc -l 64 and that still doesn't include when rotates are macroized.
[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374
--- Comment #31 from Thomas Henlich ---
Jerry, I reviewed some of the code in write_float.def:
478 /* Calculate the format of the exponent field. */
479 if (expchar && !(dtp->u.p.g0_no_blanks && e == 0))
480 {
481 edigits = 1;
482 for (i = abs (e); i >= 10; i /= 10)
483 edigits++;
484
...
499 /* Zero width specified, no leading zeros in exponent */
500 if (e > 999 || e < -999)
501 edigits = 6;
502 else if (e > 99 || e < -99)
503 edigits = 5;
504 else if (e > 9 || e < -9)
505 edigits = 4;
506 else
507 edigits = 3;
To me this seems somewhat redundant.
Wouldn't the following be somewhat shorter, with the same result?
500 edigits += 2;
[Bug middle-end/93512] Introduce rotate_truncation_mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93512 Jakub Jelinek changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Actually (INTVAL (operands[3]) & (GET_MODE_BITSIZE (mode) - 1)) == GET_MODE_BITSIZE (mode) - 1 is the right condition (for modes with power of two bitsizes).
[Bug tree-optimization/93056] Poor codegen for heapsort in stephanov_vector benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93056
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-01-31
Ever confirmed|0 |1
--- Comment #3 from Andrew Pinski ---
Confirmed, reduced testcase:
void f(int *begin, int free, int count)
{
for ( int i = 2*(free+1); i < count; i += i) {
if ( *(begin+(i-1)) < *(begin+i))
i++;
*(begin + free) = *(begin+(i-1));
free = i-1;
}
}
For -O1, we get:
.L4:
add x4, x0, x3, sxtw 2
ldr w5, [x4, -4]
ldr w4, [x0, w3, sxtw 2]
cmp w5, w4
cincw3, w3, lt
add x4, x0, x3, sxtw 2
ldr w4, [x4, -4]
str w4, [x0, w1, sxtw 2]
sub w1, w3, #1
lsl w3, w3, 1
cmp w2, w3
bgt .L4
--- CUT ---
For -O2 we get:
.L2:
add x4, x0, x3, sxtw 2
ldr w5, [x0, w3, sxtw 2]
mov w7, w3
add w6, w3, 1
ldr w4, [x4, -4]
cmp w4, w5
blt .L4
mov w5, w4
sub w7, w3, #1
mov w6, w3
.L4:
str w5, [x0, w1, sxtw 2]
lsl w3, w6, 1
mov w1, w7
cmp w2, w3
bgt .L2
[Bug c/93523] New: Fails to cross compile from x86_64 to aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93523 Bug ID: 93523 Summary: Fails to cross compile from x86_64 to aarch64 Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: noel.kuntze at thermi dot consulting Target Milestone: --- Created attachment 47748 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47748&action=edit build log from package showing error Fails to cross compile. Specific problem is that the autoconf configure script running the tests for the host system's compiler tests for -version, -qversion and -V, which that minimal compiler doesn't support. Build script is at https://git.alpinelinux.org/aports/tree/main/gcc?h=master and build log is attached.
[Bug c/93523] Fails to cross compile from x86_64 to aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93523 --- Comment #1 from noel.kuntze at thermi dot consulting --- Created attachment 47749 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47749&action=edit config.log
[Bug tree-optimization/93056] Poor codegen for heapsort in stephanov_vector benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93056 --- Comment #4 from Andrew Pinski --- -O3 is worse: .p2align 3,,7 .L2: add x5, x0, x3, sxtw 2 ldr w6, [x0, w3, sxtw 2] add w4, w3, 1 sub w7, w3, #1 ldr w5, [x5, -4] lsl w4, w4, 1 cmp w5, w6 blt .L3 str w5, [x0, w1, sxtw 2] lsl w3, w3, 1 cmp w2, w3 mov w1, w7 bgt .L2 .L5: mov w0, 0 ret .p2align 2,,3 .L3: str w6, [x0, w1, sxtw 2] cmp w2, w4 mov w1, w3 mov w3, w4 bgt .L2
[Bug c/93523] Fails to cross compile from x86_64 to aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93523 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-01-31 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- we need the following config.log: /home/buildozer/aports/main/gcc/src/build-cross-pass2/aarch64-alpine-linux-musl/libgcc/config.log The one you attached is for the one in the toplevel directory.
[Bug analyzer/93388] ensure -fanalyzer works with our C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93388 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #4 from David Binderman --- I tried out -fanalyzer with all the C code under gcc/testsuite. There are 35368 C source code files. 234 crashes so far. Here are the first ten: ./c-c++-common/builtin-convertvector-2.c:10:3: internal compiler error: in make_ region_for_type, at analyzer/region-model.cc:5986 ./c-c++-common/builtin-shuffle-1.c:17:3: internal compiler error: in make_region _for_type, at analyzer/region-model.cc:5986 ./c-c++-common/dfp/convert.h:49:6: internal compiler error: in real_maxval, at r eal.c:2593 ./c-c++-common/dfp/convert.h:112:6: internal compiler error: in real_maxval, at real.c:2593 ./c-c++-common/dfp/convert.h:51:6: internal compiler error: in real_maxval, at r eal.c:2593 ./c-c++-common/pr51628-30.c:21:3: internal compiler error: in get_lvalue_1, at a nalyzer/region-model.cc:4595 ./c-c++-common/pr51628-31.c:14:3: internal compiler error: in get_lvalue_1, at a nalyzer/region-model.cc:4595 ./c-c++-common/pr59037.c:9:3: internal compiler error: in get_lvalue_1, at analy zer/region-model.cc:4595 ./c-c++-common/pr63764-2.c:32:3: internal compiler error: in make_region_for_typ e, at analyzer/region-model.cc:5986 ./c-c++-common/pr80162-2.c:11:3: internal compiler error: in get_lvalue_1, at an alyzer/region-model.cc:4595
[Bug c/93523] Fails to cross compile from x86_64 to aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93523 --- Comment #3 from noel.kuntze at thermi dot consulting --- Created attachment 47750 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47750&action=edit config log for pass 2
[Bug c/93523] Fails to cross compile from x86_64 to aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93523 --- Comment #4 from noel.kuntze at thermi dot consulting --- Thank you for the quick response. I attached it. :)
[Bug tree-optimization/93516] [10 regression] ICE in verify_sra_access_forest, at tree-sra.c:2342 since r10-6322
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93516 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summary|[10 regression] ICE in |[10 regression] ICE in |verify_sra_access_forest, |verify_sra_access_forest, |at tree-sra.c:2342 since|at tree-sra.c:2342 since |r10-6276-g1d8593070a62b |r10-6322 --- Comment #2 from Jakub Jelinek --- That bisection looks wrong, my bisection says it started with r10-6322-g6693911f069b1ada7c04aa1d00c3653ba694958a
[Bug bootstrap/93523] Fails to cross compile from x86_64 to aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93523 Andrew Pinski changed: What|Removed |Added Keywords||build Target|aarch64-alpine-linux-musl | Status|WAITING |RESOLVED Component|c |bootstrap Host|x86_64 | Resolution|--- |INVALID --- Comment #5 from Andrew Pinski --- Actually wait, something is definitely wrong here: configure:3529: /home/buildozer/aports/main/gcc/src/build-cross-pass2/./gcc/xgcc -B/home/buildozer/aports/main/gcc/src/build-cross-pass2/./gcc/ -B/usr/aarch64-alpine-linux-musl/bin/ -B/usr/aarch64-alpine-linux-musl/lib/ -isystem /usr/aarch64-alpine-linux-musl/include -isystem /usr/aarch64-alpine-linux-musl/sys-include-o conftestconftest.c >&5 /usr/aarch64-alpine-linux-musl/bin/as: line 1: ELFTш@ре@8: not found /usr/aarch64-alpine-linux-musl/bin/as: line 1: syntax error: unterminated quoted string It is picking up the assembler that which seems like is an aarch64 binary rather than the x86_64 binary. This must be a bug in your build script. configure:14793: checking where to find the target ld configure:14821: result: pre-installed in /usr/aarch64-alpine-linux-musl/bin configure:14835: checking where to find the target lipo configure:14861: result: pre-installed configure:14866: checking where to find the target nm configure:14894: result: pre-installed in /usr/aarch64-alpine-linux-musl/bin configure:14908: checking where to find the target objcopy configure:14936: result: pre-installed in /usr/aarch64-alpine-linux-musl/bin configure:14950: checking where to find the target objdump configure:14978: result: pre-installed in /usr/aarch64-alpine-linux-musl/bin configure:14992: checking where to find the target otool configure:15018: result: pre-installed configure:15023: checking where to find the target ranlib configure:15051: result: pre-installed in /usr/aarch64-alpine-linux-musl/bin configure:15065: checking where to find the target readelf configure:15093: result: pre-installed in /usr/aarch64-alpine-linux-musl/bin configure:15107: checking where to find the target strip configure:15135: result: pre-installed in /usr/aarch64-alpine-linux-musl/bin configure:15149: checking where to find the target windres That is the normal place to put the x86_64 binaries that target that target. NOT the target binaries. THIS IS NOT A GCC BUG but rather you have done something really really bad with your file system and/or the build scripts.
[Bug tree-optimization/93516] [10 regression] ICE in verify_sra_access_forest, at tree-sra.c:2342 since r10-6322
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93516 --- Comment #3 from Martin Jambor --- I'll have a look.
[Bug c++/92319] Macro expansion using the __VA_OPT__ construct is incorrect when the variadic argument expands to nothing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92319 Jakub Jelinek changed: What|Removed |Added Status|WAITING |NEW
[Bug c++/92319] Macro expansion using the __VA_OPT__ construct is incorrect when the variadic argument expands to nothing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92319 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Summary|Macro expansion using the |Macro expansion using the |__VAOPT__ construct is |__VA_OPT__ construct is |incorrect when the variadic |incorrect when the variadic |argument expands to nothing |argument expands to nothing --- Comment #3 from Jakub Jelinek --- Seems we don't really implement http://wg21.link/p1042r1 (nothing from it) although our cxx-status.html claims to do so.
[Bug tree-optimization/93440] scalar unrolled loop makes vectorized code unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93440 --- Comment #5 from Richard Biener --- OK, so I can compile the testcase now but I fail to see the error. We're doing pointer difference compares and those should work out fine? We're also doig many checks but you probably refer to the very first test? _Z12brokenvectorRKSt6vectorIiSaIiEES3_: .LFB2470: .cfi_startproc movq(%rsi), %rdx movq8(%rdi), %rsi xorl%r8d, %r8d movq(%rdi), %rax movq%rsi, %rcx subq%rax, %rcx cmpq$12, %rcx jle .L18 that's created from [local count: 1073741824]: _7 = MEM[(int * *)b_2(D)]; _6 = MEM[(int * *)a_3(D) + 8B]; _4 = MEM[(int * *)a_3(D)]; _10 = _6 - _4; if (_10 > 12) what are the actual pointers here?
[Bug fortran/92643] ISO_Fortran_binding_15.f90 failure on i586-*-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92643 vvinayag at arm dot com changed: What|Removed |Added CC||vvinayag at arm dot com --- Comment #6 from vvinayag at arm dot com --- Is anyone continuing to investigate or work on a fix for this bug report?
[Bug fortran/92123] [F2018/array-descriptor] Scalar allocatable/pointer with array descriptor (via bind(C)): ICE with select rank or error scalar variable with POINTER or ALLOCATABLE in procedure wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #26 from Jakub Jelinek --- Should be fixed now.
[Bug fortran/92643] ISO_Fortran_binding_15.f90 failure on i586-*-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92643 --- Comment #7 from Jakub Jelinek --- Should be fixed already by r10-6344-g2595f25cdaf4f16d04a1078a487b2ecc126cae29
[Bug fortran/93524] New: [ISO C Binding][F2018] CFI_allocate – elem_size mishandled + sm wrongly set?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93524
Bug ID: 93524
Summary: [ISO C Binding][F2018] CFI_allocate – elem_size
mishandled + sm wrongly set?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
CFI_cdesc_t structure type has:
size_t elem_len;
If the object is scalar, the value is the storage size in bytes of the
object;
otherwise, the value20is the storage size in bytes of an element of the
object.
CFI_establish has:
elem_len
If type is equal to CFI_type_struct, CFI_type_other, or a Fortran character
type
code, elem_len shall be greater than zero and equal to the storage size in
bytes
of an element of the object. Otherwise, elem_len will be ignored.
(Similarly: CFI_allocate and CFI_select_part, although they only have character
and not other/struct.)
EXPECTED:
1. For establish/allocate/select_part, the elem_len is handled properly.
(Check all three, the testcase only uses the first two.)
2. The CFI_allocate + CFI_contiguous work nice together.
Regarding 1: Is seems as if establish handles it correctly but allocate
fails if it's argument is elem_len = 0 – even if the descriptor has the
proper elem_len = 4.
Regaring 2: Currently, is_contiguous is 0 because:
{base_addr = 0x408910, elem_len = 4, version = 1, rank = 3, attribute =
1,
type = 1027,
dim = {{lower_bound = -10, extent = 21, sm = 4},
{lower_bound = 0, extent = 6, sm = 84},
{lower_bound = 3, extent = 8, sm = 24}}}
Here, the contiguous check works fine for dim=0 as sm=4 == elem_len.
It also works for dim=1 as sm[1]=84 == sm[0]=4 * extent[0]=21 => 84 == 84
But for dim=2, sm[2]=24 != sm[1]=84 * extent[1]=6 => 24 != 504
That looks like a bug in allocate – but I might have also misunderstood
something in is_contiguous.
Test case; note the bounds of the second Fortran function are wrong because
PR 92189
==> hello_world.c <==
#include // For size_t
#include
void my_fortran_sub_1 (CFI_cdesc_t *dv);
void my_fortran_sub_2 (CFI_cdesc_t *dv);
int main ()
{
CFI_CDESC_T (3) a;
CFI_cdesc_t *dv = (CFI_cdesc_t *) &a;
// dv, base_addr, attribute,type, elem_len, rank,
extents
CFI_establish (dv, NULL, CFI_attribute_allocatable, CFI_type_float, 0, 3,
NULL);
if (dv->base_addr != NULL)
return 1; // shall not be allocated
CFI_index_t lower_bounds[] = {-10, 0, 3};
CFI_index_t upper_bounds[] = {10, 5, 10};
size_t elem_len = 0; // only needed for strings
if (CFI_SUCCESS != CFI_allocate (dv, lower_bounds, upper_bounds, elem_len))
return 2;
if (!CFI_is_contiguous (dv))
return 2; // allocatables shall be contiguous,unless a strided section is
used
my_fortran_sub_1 (dv);
my_fortran_sub_2 (dv);
CFI_deallocate (dv);
return 0;
}
==> hello_world.f90 <==
subroutine my_fortran_sub_1 (A) bind(C)
real :: A(:, :, :)
print *, 'Lower bounds: ', lbound(A) ! Lower bounds:111
print *, 'Upper bounds: ', ubound(A) ! Upper bounds: 2168
end
subroutine my_fortran_sub_2 (A) bind(C)
real, ALLOCATABLE :: A(:, :, :)
print *, 'Lower bounds: ', lbound(A)
print *, 'Upper bounds: ', ubound(A)
end subroutine my_fortran_sub_2
[Bug preprocessor/92319] Macro expansion using the __VA_OPT__ construct is incorrect when the variadic argument expands to nothing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92319 --- Comment #4 from Jakub Jelinek --- Created attachment 47751 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47751&action=edit gcc10-pr92319.patch Untested patch that implements just this part of the paper (but not e.g. the padding preservation/stripping changes).
[Bug middle-end/93519] [8/9/10 Regression] bogus -Wrestrict for strcpy(d, s) call guarded by d != s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93519 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |8.4 Summary|bogus -Wrestrict for|[8/9/10 Regression] bogus |strcpy(d, s) call guarded |-Wrestrict for strcpy(d, s) |by d != s |call guarded by d != s --- Comment #1 from Jakub Jelinek --- Started with r8-5363-gcc8bea0ab6ed8046ede1a577ee681da2ca6a I'd say the bug is in trying to do this from whenever we try to fold such a call, because there is no way to cleanup the cfg after inlining before it happens. So, it would be much better to do this only in specific well chosen passes, say one among early opts, but sufficiently after einline so that unreachable code there could be optimized away, and once or twice in late opts. The overlapping arguments is UB, so I don't really think it is neccessary to fold it immediately. Another option is to turn it into IFN_WARNING and defer the diagnostics after some cleanups.
[Bug tree-optimization/93516] [10 regression] ICE in verify_sra_access_forest, at tree-sra.c:2342 since r10-6322
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93516 --- Comment #4 from Martin Liška --- (In reply to Jakub Jelinek from comment #2) > That bisection looks wrong, my bisection says it started with > r10-6322-g6693911f069b1ada7c04aa1d00c3653ba694958a You are right, I did it manually and then forgot to pass git hash to git gcc-desc ...
[Bug fortran/93365] ICE in match_data_constant, at fortran/decl.c:426
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93365 --- Comment #10 from Steve Kargl --- On Fri, Jan 31, 2020 at 08:41:29AM +, markeggleston at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93365 > > markeggleston at gcc dot gnu.org changed: > >What|Removed |Added > >Assignee|markeggleston at gcc dot gnu.org |unassigned at gcc dot > gnu.org > > --- Comment #9 from markeggleston at gcc dot gnu.org --- > Since I'm no longer investigating this I've removed myself from assignment. > > This problem does not occur when the compiler is built with bootstrap but does > when built with gcc 6.3. > > What should be done about its status? > > I think it should be closed. Any suggestions/opinions? > What do you mean by "this problem"? The original bug in z1.f90 from comment #1 has been fixed?
[Bug libgomp/93515] OpenMP target teams distribute parallel for with defaultmap not mapping correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93515
--- Comment #1 from Jakub Jelinek ---
Thanks for the report, confirmed. Simpler testcase:
#include
int
main ()
{
int i;
int a = 42;
#pragma omp target teams distribute parallel for defaultmap(tofrom: scalar)
for (i = 0; i < 64; ++i)
if (omp_get_team_num () == 0)
if (omp_get_thread_num () == 0)
a = 142;
if (a != 142)
__builtin_abort ();
return 0;
}
Quick workaround, tak address of the variable(s) somewhere, even with just
(void) &a;
For the non-addressable scalar vars, gcc sometimes implements shared by taking
address of the variable and at other times by performing copy in/out (of course
not possible on task/taskloop). Copy in/out works fine if e.g. the parallel is
not nested in another parallel/teams or the shared variable is private in the
outer parallel/teams. If it is shared in both, copy in/out is not possible.
The reason why the above testcase is miscompiled is that the teams immediately
nested inside of target is (intentionally ignored), but we need to treat map
clauses similarly to the shared clauses. If you take out the target from the
above testcase, then it will work, the shared(a) on teams then forces shared(a)
on parallel to be passed through reference instead of copy in/out.
[Bug analyzer/93450] ICE in real_maxval, at real.c:2593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93450 --- Comment #5 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:45eb3e4944ba93b1d4e9070c703068cfa7aaace4 commit r10-6368-g45eb3e4944ba93b1d4e9070c703068cfa7aaace4 Author: David Malcolm Date: Thu Jan 30 15:21:28 2020 -0500 analyzer: further fixes for comparisons between uncomparable types (PR 93450) gcc/analyzer/ChangeLog: PR analyzer/93450 * constraint-manager.cc (constraint_manager::get_or_add_equiv_class): Only compare constants if their types are compatible. * region-model.cc (constant_svalue::eval_condition): Replace check for identical types with call to types_compatible_p.
[Bug gcov-profile/93401] [9/10 regression] It is no longer possible to use -fprofile-generate= on setups with different instrumentation and feedback directories
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93401 --- Comment #3 from Jan Hubicka --- Just to summarize discussions we had. I think we need to think through setup where there are different build, train and pgo-buid machines and the directories are not known in advance. There -ffile-prefix-map for similar purpose and we could add -fprofile-prefix-map. Or maybe only -fprofile-prefix since at least for uses I have in mind the second part of map is going to be always empty. I guess we could support the following simulated makefile run: instrumented build == cd mkdir lib1 cd gcc foo.c -o /ibb1/foo.o -fprofile-prefix-map== -fprofile-generate=/ this will stet up binary to produce /lib1#foo.gcda on startup. At the instrumentation time we can training run GCOV_PREFIX= run_program then tar contents of my_favorite_profile_directory_during_train final build === untar profile data to Possibly use gcov-tool merge to merge data from multiple machines. cd mkdir lib1 gcc foo.c -o /ibb1/foo.o -fprofile-prefix-map== -fprofile-use= But it looks bit convoluted (especially passing the phony / to -fprofile-generate), so easier solution would be welcome. In particular I am not sure how llvmprofdata solve this problem
[Bug gcov-profile/93401] [9/10 regression] It is no longer possible to use -fprofile-generate= on setups with different instrumentation and feedback directories
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93401 --- Comment #4 from Jan Hubicka --- Actually passing phony / is not needed. We could do right thing with gcc foo.c -o /ibb1/foo.o -fprofile-prefix-map== -fprofile-generate or gcc foo.c -o /ibb1/foo.o -fprofile-strip-prefix= -fprofile-generate if we do not like the map infrastructure
[Bug libgomp/93515] OpenMP target teams distribute parallel for with defaultmap not mapping correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93515 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-31 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Created attachment 47752 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47752&action=edit gcc10-pr93515.patch Untested fix.
[Bug gcov-profile/93401] [9/10 regression] It is no longer possible to use -fprofile-generate= on setups with different instrumentation and feedback directories
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93401 --- Comment #5 from Martin Liška --- (In reply to Jan Hubicka from comment #3) > Just to summarize discussions we had. I think we need to think through > setup where there are different build, train and pgo-buid machines and the > directories are not known in advance. In that case I would recommend to use related paths for GCDA files with -fprofile-generate (without a folder). Then one needs to tar all .gcda files, move them to a different machine an extract. It will not suffer from a different path prefix.
[Bug gcov-profile/93401] [9/10 regression] It is no longer possible to use -fprofile-generate= on setups with different instrumentation and feedback directories
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93401 --- Comment #6 from Martin Liška --- (In reply to Jan Hubicka from comment #4) > Actually passing phony / is not needed. We could do right thing with > > gcc foo.c -o /ibb1/foo.o -fprofile-prefix-map== > -fprofile-generate > > or > > gcc foo.c -o /ibb1/foo.o -fprofile-strip-prefix= > -fprofile-generate If we really want to support the absolute paths, then I'm for -fprofile-strip-prefix. > > if we do not like the map infrastructure
[Bug tree-optimization/92924] [10 regression] reproducible indirect call profile merging causes 80% slowdown in Firefox pref-reftest-singletons id-getter microbenchmarks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924 --- Comment #27 from Martin Liška --- I've just made an experiment with the dynamic allocation of TOPN profile counts (similarly to what clang does). There's a GCC branch that does instrumentation and profiling (including merging): https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=shortlog;h=refs/users/marxin/heads/gcov-topn-dynamic -fprofile-use support is missing I've also made an analysis script for that: https://github.com/marxin/script-misc/blob/master/gcov-dump-dynamic.py Using that I see the following stats for GCC PGO: == Stats for /tmp/prev-gcc == stats for indirect_call: Total: 9218, total freq: 5945116271, covered freq: 3610877419 (60.74%) Histogram: 0 tracked tuples: 6257 (67.88%), >=0.5:0 (covered freq:0 (0.00%)) 1 tracked tuples: 1786 (19.38%), >=0.5: 1786 (covered freq: 2260547505 (38.02%)) 2 tracked tuples: 219 (2.38%), >=0.5: 219 (covered freq:529728820 (8.91%)) 3 tracked tuples:79 (0.86%), >=0.5: 50 (covered freq: 64471724 (1.08%)) 4 tracked tuples:79 (0.86%), >=0.5: 32 (covered freq:109408820 (1.84%)) 5 tracked tuples: 104 (1.13%), >=0.5: 24 (covered freq: 41008121 (0.69%)) 6 tracked tuples: 239 (2.59%), >=0.5: 35 (covered freq:109414082 (1.84%)) 7 tracked tuples: 135 (1.46%), >=0.5:8 (covered freq: 4288912 (0.07%)) 8 tracked tuples: 224 (2.43%), >=0.5: 68 (covered freq:192508962 (3.24%)) 9 tracked tuples:62 (0.67%), >=0.5: 17 (covered freq:180771320 (3.04%)) 10 tracked tuples: 2 (0.02%), >=0.5:1 (covered freq: 128158 (0.00%)) 11 tracked tuples: 2 (0.02%), >=0.5:1 (covered freq: 2440074 (0.04%)) 12 tracked tuples: 2 (0.02%), >=0.5:2 (covered freq: 878475 (0.01%)) 13 tracked tuples: 4 (0.04%), >=0.5:1 (covered freq: 815043 (0.01%)) 14 tracked tuples: 4 (0.04%), >=0.5:2 (covered freq: 1086680 (0.02%)) 17 tracked tuples: 2 (0.02%), >=0.5:0 (covered freq:0 (0.00%)) 20 tracked tuples: 1 (0.01%), >=0.5:0 (covered freq:0 (0.00%)) 21 tracked tuples: 3 (0.03%), >=0.5:0 (covered freq:0 (0.00%)) 27 tracked tuples: 1 (0.01%), >=0.5:0 (covered freq:0 (0.00%)) 28 tracked tuples: 1 (0.01%), >=0.5:0 (covered freq:0 (0.00%)) 30 tracked tuples: 1 (0.01%), >=0.5:1 (covered freq:113225312 (1.90%)) 33 tracked tuples: 1 (0.01%), >=0.5:0 (covered freq:0 (0.00%)) 38 tracked tuples: 1 (0.01%), >=0.5:0 (covered freq:0 (0.00%)) 39 tracked tuples: 1 (0.01%), >=0.5:0 (covered freq:0 (0.00%)) 44 tracked tuples: 1 (0.01%), >=0.5:0 (covered freq:0 (0.00%)) 47 tracked tuples: 1 (0.01%), >=0.5:0 (covered freq:0 (0.00%)) 52 tracked tuples: 1 (0.01%), >=0.5:0 (covered freq:0 (0.00%)) 56 tracked tuples: 1 (0.01%), >=0.5:0 (covered freq:0 (0.00%)) 91 tracked tuples: 1 (0.01%), >=0.5:0 (covered freq:0 (0.00%)) 126 tracked tuples: 1 (0.01%), >=0.5:1 (covered freq: 155411 (0.00%)) 177 tracked tuples: 1 (0.01%), >=0.5:0 (covered freq:0 (0.00%)) 204 tracked tuples: 1 (0.01%), >=0.5:0 (covered freq:0 (0.00%)) stats for topn: Total: 1514, total freq: 1761900196, covered freq: 783364641 (44.46%) Histogram: 0 tracked tuples: 1030 (68.03%), >=0.5:0 (covered freq:0 (0.00%)) 1 tracked tuples: 151 (9.97%), >=0.5: 151 (covered freq:362329033 (20.56%)) 2 tracked tuples:45 (2.97%), >=0.5: 45 (covered freq: 28110609 (1.60%)) 3 tracked tuples:37 (2.44%), >=0.5: 31 (covered freq: 50776835 (2.88%)) 4 tracked tuples:21 (1.39%), >=0.5: 17 (covered freq: 6067434 (0.34%)) 5 tracked tuples:38 (2.51%), >=0.5: 26 (covered freq: 57919679 (3.29%)) 6 tracked tuples:12 (0.79%), >=0.5: 11 (covered freq: 2615169 (0.15%)) 7 tracked tuples: 9 (0.59%), >=0.5:6 (covered freq: 13400400 (0.76%)) 8 tracked tuples: 5 (0.33%), >=0.5:5 (covered freq: 352773 (0.02%)) 9 tracked tuples: 2 (0.13%), >=0.5:1 (covered freq: 261382 (0.01%)) 10 tracked tuples: 5 (0.33%), >=0.5:4 (covered freq:47819 (0.00%)) 11 tracked tuples: 5 (0.33%), >=0.5:3 (covered freq: 5742397 (0.33%)) 12 tracked tuples: 3 (0.20%), >=0.5:2 (covered freq: 169186 (0.01%)) 13 tracked tuples:11 (0.73%), >=0.5:3 (covered freq: 64058047 (3.64%)) 14 tracked tuples: 2 (0.13%), >=0.5:1 (covered freq:16414 (0.00%)) 15 tracked tuples: 1 (0.07%), >=0.5:0 (covered freq:0 (0.00%
[Bug tree-optimization/92924] [10 regression] reproducible indirect call profile merging causes 80% slowdown in Firefox pref-reftest-singletons id-getter microbenchmarks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924 --- Comment #28 from Martin Liška --- Stats one more time (should not wrap around): == Stats for /tmp/prev-gcc == stats for indirect_call: Total: 9218, total freq: 5945116271, covered freq: 3610877419 (60.74%) Histogram: 0 tracked: 6257 (67.88%), >=0.5:0 (cov. freq:0 (0.00%)) 1 tracked: 1786 (19.38%), >=0.5: 1786 (cov. freq: 2260547505 (38.02%)) 2 tracked: 219 (2.38%), >=0.5: 219 (cov. freq:529728820 (8.91%)) 3 tracked:79 (0.86%), >=0.5: 50 (cov. freq: 64471724 (1.08%)) 4 tracked:79 (0.86%), >=0.5: 32 (cov. freq:109408820 (1.84%)) 5 tracked: 104 (1.13%), >=0.5: 24 (cov. freq: 41008121 (0.69%)) 6 tracked: 239 (2.59%), >=0.5: 35 (cov. freq:109414082 (1.84%)) 7 tracked: 135 (1.46%), >=0.5:8 (cov. freq: 4288912 (0.07%)) 8 tracked: 224 (2.43%), >=0.5: 68 (cov. freq:192508962 (3.24%)) 9 tracked:62 (0.67%), >=0.5: 17 (cov. freq:180771320 (3.04%)) 10 tracked: 2 (0.02%), >=0.5:1 (cov. freq: 128158 (0.00%)) 11 tracked: 2 (0.02%), >=0.5:1 (cov. freq: 2440074 (0.04%)) 12 tracked: 2 (0.02%), >=0.5:2 (cov. freq: 878475 (0.01%)) 13 tracked: 4 (0.04%), >=0.5:1 (cov. freq: 815043 (0.01%)) 14 tracked: 4 (0.04%), >=0.5:2 (cov. freq: 1086680 (0.02%)) 17 tracked: 2 (0.02%), >=0.5:0 (cov. freq:0 (0.00%)) 20 tracked: 1 (0.01%), >=0.5:0 (cov. freq:0 (0.00%)) 21 tracked: 3 (0.03%), >=0.5:0 (cov. freq:0 (0.00%)) 27 tracked: 1 (0.01%), >=0.5:0 (cov. freq:0 (0.00%)) 28 tracked: 1 (0.01%), >=0.5:0 (cov. freq:0 (0.00%)) 30 tracked: 1 (0.01%), >=0.5:1 (cov. freq:113225312 (1.90%)) 33 tracked: 1 (0.01%), >=0.5:0 (cov. freq:0 (0.00%)) 38 tracked: 1 (0.01%), >=0.5:0 (cov. freq:0 (0.00%)) 39 tracked: 1 (0.01%), >=0.5:0 (cov. freq:0 (0.00%)) 44 tracked: 1 (0.01%), >=0.5:0 (cov. freq:0 (0.00%)) 47 tracked: 1 (0.01%), >=0.5:0 (cov. freq:0 (0.00%)) 52 tracked: 1 (0.01%), >=0.5:0 (cov. freq:0 (0.00%)) 56 tracked: 1 (0.01%), >=0.5:0 (cov. freq:0 (0.00%)) 91 tracked: 1 (0.01%), >=0.5:0 (cov. freq:0 (0.00%)) 126 tracked: 1 (0.01%), >=0.5:1 (cov. freq: 155411 (0.00%)) 177 tracked: 1 (0.01%), >=0.5:0 (cov. freq:0 (0.00%)) 204 tracked: 1 (0.01%), >=0.5:0 (cov. freq:0 (0.00%)) stats for topn: Total: 1514, total freq: 1761900196, covered freq: 783364641 (44.46%) Histogram: 0 tracked: 1030 (68.03%), >=0.5:0 (cov. freq:0 (0.00%)) 1 tracked: 151 (9.97%), >=0.5: 151 (cov. freq:362329033 (20.56%)) 2 tracked:45 (2.97%), >=0.5: 45 (cov. freq: 28110609 (1.60%)) 3 tracked:37 (2.44%), >=0.5: 31 (cov. freq: 50776835 (2.88%)) 4 tracked:21 (1.39%), >=0.5: 17 (cov. freq: 6067434 (0.34%)) 5 tracked:38 (2.51%), >=0.5: 26 (cov. freq: 57919679 (3.29%)) 6 tracked:12 (0.79%), >=0.5: 11 (cov. freq: 2615169 (0.15%)) 7 tracked: 9 (0.59%), >=0.5:6 (cov. freq: 13400400 (0.76%)) 8 tracked: 5 (0.33%), >=0.5:5 (cov. freq: 352773 (0.02%)) 9 tracked: 2 (0.13%), >=0.5:1 (cov. freq: 261382 (0.01%)) 10 tracked: 5 (0.33%), >=0.5:4 (cov. freq:47819 (0.00%)) 11 tracked: 5 (0.33%), >=0.5:3 (cov. freq: 5742397 (0.33%)) 12 tracked: 3 (0.20%), >=0.5:2 (cov. freq: 169186 (0.01%)) 13 tracked:11 (0.73%), >=0.5:3 (cov. freq: 64058047 (3.64%)) 14 tracked: 2 (0.13%), >=0.5:1 (cov. freq:16414 (0.00%)) 15 tracked: 1 (0.07%), >=0.5:0 (cov. freq:0 (0.00%)) 16 tracked: 1 (0.07%), >=0.5:1 (cov. freq: 105031 (0.01%)) 17 tracked: 1 (0.07%), >=0.5:0 (cov. freq:0 (0.00%)) 18 tracked: 2 (0.13%), >=0.5:1 (cov. freq:12980 (0.00%)) 20 tracked: 2 (0.13%), >=0.5:1 (cov. freq: 208648 (0.01%)) 21 tracked: 2 (0.13%), >=0.5:0 (cov. freq:0 (0.00%)) 22 tracked: 1 (0.07%), >=0.5:1 (cov. freq: 617 (0.00%)) 24 tracked: 3 (0.20%), >=0.5:1 (cov. freq: 1704983 (0.10%)) 25 tracked: 1 (0.07%), >=0.5:0 (cov. freq:0 (0.00%)) 26 tracked: 2 (0.13%), >=0.5:1 (cov. freq: 827 (0.00%)) 27 tracked: 1 (0.07%), >=0.5:0 (cov. freq:0 (0.00%)) 28 tracked: 1 (0.07%), >=0.5:1 (cov. freq:14077 (0.00%)) 29 tracked: 1 (0.07%), >=0.5:0 (cov. freq:0 (0.00%))
[Bug gcov-profile/93401] [9/10 regression] It is no longer possible to use -fprofile-generate= on setups with different instrumentation and feedback directories
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93401 --- Comment #7 from Jan Hubicka --- do you have example how the relative paths can be used?
[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249
--- Comment #28 from Oleg Endo ---
(In reply to Rich Felker from comment #27)
> We've hit what seems like almost the exact same issue on gcc 8.3.0 with this
> minimized testcase:
>
> void fg(int *);
> int get_response(int a)
> {
> int b;
> if (a) fg(&b);
> return 0;
> }
>
> compiled with -O -c -fstack-protector-strong for sh2eb-linux-muslfdpic. With
> gcc 9.2.0 it compiles successfully. I looked for a record of such a fix
> having been made, but couldn't find one. Was it a known issue that was fixed
> silently, or might it be a lurking bug that's just no longer being hit?
No, nothing has been actively done to fix the R0 spill problems. Maybe there
were some SH unrelated fixes in the old reload code that fixed it on GCC 9 as a
side effect. But there hasn't been any active efforts to fix the issue on SH.
I'm considering to switch SH to use LRA instead of old reload. You might try
it out with option -mlra.
[Bug c++/93496] Miscompile of range-for over braced-init-list in constructor of class with virtual inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93496 --- Comment #5 from Justin LaPolla --- I think this may be a duplicate of PR 86669. Thanks for finding it. > Fixed on trunk by r266893 for PR 86669, which doesn't seem related. What makes you say it doesn't seem related?
[Bug libgomp/93510] [gfortran] OpenMP target teams distribute reduction with multiply operator gives incorrect results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93510
--- Comment #1 from Jakub Jelinek ---
If I get this right,
extern void abort (void);
extern int random ();
int
main ()
{
int a[1024];
for (int x = 0; x < 1024; x++)
a[x] = 1 + (random () & 1);
int d, h;
for (int x = 0; x < 1024; x += 16)
{
d = 1;
#pragma omp target teams distribute defaultmap(tofrom:scalar) \
reduction(*:d)
for (int y = 0; y < 16; y++)
d *= a[x + y];
h = 1;
for (int y = 0; y < 16; y++)
h *= a[x + y];
if (d != h)
abort ();
}
return 0;
}
as the testcase translated from Fortran to C doesn't FAIL even with nvptx
offloading.
[Bug rtl-optimization/91838] [8/9 Regression] incorrect use of shr and shrx to shift by 64, missed optimization of vector shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91838 Tamar Christina changed: What|Removed |Added Status|NEW |ASSIGNED Component|target |rtl-optimization
[Bug gcov-profile/93401] [9/10 regression] It is no longer possible to use -fprofile-generate= on setups with different instrumentation and feedback directories
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93401
--- Comment #8 from Martin Liška ---
(In reply to Jan Hubicka from comment #7)
> do you have example how the relative paths can be used?
We use them in GCC boostrap for instance ;) We copy .gcda files with:
{ find . -name '*.*da' | sed 's,.*,$(LN) -f "&" "../'$$j'/&",' |
$(SHELL); }; \
[Bug libgomp/93510] [gfortran] OpenMP target teams distribute reduction with multiply operator gives incorrect results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93510 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jakub Jelinek --- Ah, no, that translation is not faithful, the original testcase has undefined behavior. The a array has 1024 elements, with indexes 1 to 1024. So, when you use: DO x = 1, N, 16 DO y = 1, 16 ... a(x + y) END DO END DO it doesn't do what you expect it to do, it doesn't access elements 1 to 1024, but 2 to 1025 and the a(1025) read is where the UB is invoked. I guess you meant either to do: DO x = 0, N - 1, 16 DO y = 1, 16 or DO x = 1, N, 16 DO y = 0, 15
[Bug rtl-optimization/91838] [8/9 Regression] incorrect use of shr and shrx to shift by 64, missed optimization of vector shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91838 --- Comment #10 from CVS Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:e60b1e23626701939e8a2f0cf6fc1e48abdf867b commit r10-6371-ge60b1e23626701939e8a2f0cf6fc1e48abdf867b Author: Tamar Christina Date: Fri Jan 31 14:39:38 2020 + middle-end: Fix logical shift truncation (PR rtl-optimization/91838) This fixes a fall-out from a patch I had submitted two years ago which started allowing simplify-rtx to fold logical right shifts by offsets a followed by b into >> (a + b). However this can generate inefficient code when the resulting shift count ends up being the same as the size of the shift mode. This will create some undefined behavior on most platforms. This patch changes to code to truncate to 0 if the shift amount goes out of range. Before my older patch this used to happen in combine when it saw the two shifts. However since we combine them here combine never gets a chance to truncate them. The issue mostly affects GCC 8 and 9 since on 10 the back-end knows how to deal with this shift constant but it's better to do the right thing in simplify-rtx. Note that this doesn't take care of the Arithmetic shift where you could replace the constant with MODE_BITS (mode) - 1, but that's not a regression so punting it. gcc/ChangeLog: PR rtl-optimization/91838 * simplify-rtx.c (simplify_binary_operation_1): Update LSHIFTRT case to truncate if allowed or reject combination. gcc/testsuite/ChangeLog: PR rtl-optimization/91838 * g++.dg/pr91838.C: New test.
[Bug c++/92169] crash on referring to a local class member by unqualified name from outside the enclosing function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92169 Marek Polacek changed: What|Removed |Added Status|WAITING |NEW CC||mpolacek at gcc dot gnu.org --- Comment #5 from Marek Polacek --- Confirmed with -g. #350 0x00f32eea in gen_subprogram_die (decl=, context_die=) at /home/mpolacek/src/gcc/gcc/dwarf2out.c:22942 #351 0x00f3c548 in force_decl_die (decl=) at /home/mpolacek/src/gcc/gcc/dwarf2out.c:26038 #352 0x00f3c458 in get_context_die (context=) at /home/mpolacek/src/gcc/gcc/dwarf2out.c:26008 #353 0x00f3c6e8 in force_type_die (type=) at /home/mpolacek/src/gcc/gcc/dwarf2out.c:26087 #354 0x00f3c438 in get_context_die (context=) at /home/mpolacek/src/gcc/gcc/dwarf2out.c:26005 #355 0x00f2f07d in scope_die_for (t=, context_die=) at /home/mpolacek/src/gcc/gcc/dwarf2out.c:21504 #356 0x00f169f5 in modified_type_die (type=, cv_quals=0, reverse=false, context_die=) at /home/mpolacek/src/gcc/gcc/dwarf2out.c:13287 #357 0x00f2f390 in add_type_attribute ( object_die=>, type=, cv_quals=0, reverse=false, context_die=) at /home/mpolacek/src/gcc/gcc/dwarf2out.c:21580 #358 0x00f32eea in gen_subprogram_die (decl=, context_die=) at /home/mpolacek/src/gcc/gcc/dwarf2out.c:22942 #359 0x00f3c548 in force_decl_die (decl=) at /home/mpolacek/src/gcc/gcc/dwarf2out.c:26038 #360 0x00f3c458 in get_context_die (context=) at /home/mpolacek/src/gcc/gcc/dwarf2out.c:26008 #361 0x00f3c6e8 in force_type_die (type=) at /home/mpolacek/src/gcc/gcc/dwarf2out.c:26087 #362 0x00f3c438 in get_context_die (context=) at /home/mpolacek/src/gcc/gcc/dwarf2out.c:26005 #363 0x00f2f07d in scope_die_for (t=, context_die=) at /home/mpolacek/src/gcc/gcc/dwarf2out.c:21504 #364 0x00f169f5 in modified_type_die (type=, cv_quals=0, reverse=false, context_die=) at /home/mpolacek/src/gcc/gcc/dwarf2out.c:13287 #365 0x00f2f390 in add_type_attribute ( object_die=>, type=, cv_quals=0, reverse=false, context_die=) at /home/mpolacek/src/gcc/gcc/dwarf2out.c:21580 #366 0x00f32eea in gen_subprogram_die (decl=, context_die=) at /home/mpolacek/src/gcc/gcc/dwarf2out.c:22942
[Bug rtl-optimization/93525] New: Left shift and arithmetic shift could be futher simplified in simplify-rtx.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93525 Bug ID: 93525 Summary: Left shift and arithmetic shift could be futher simplified in simplify-rtx.c Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: tnfchris at gcc dot gnu.org Target Milestone: --- simplify-rtx currently will fold and combine Arithmetic and Logical right shifts with a constant shift count and fold consecutive shifts into a single one. If for the logical case if the if the shift count goes out of range it truncates it to 0 but doesn't handle the case for the arithmetic shift. Also neither operation is performed for left shifts.
[Bug middle-end/93505] [8/9 Regression] wrong code or ICE with __builtin_bswap64() and rotation at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93505 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10 Regression] wrong |[8/9 Regression] wrong code |code or ICE with|or ICE with |__builtin_bswap64() and |__builtin_bswap64() and |rotation at -Og |rotation at -Og --- Comment #17 from Jakub Jelinek --- The wrong-code is now fixed on the trunk. What we want to do further depends on whether we want to make ROTATE/ROTATERT imply truncation (always or only on selected targets), let's defer that part to PR93512.
[Bug middle-end/93505] [8/9 Regression] wrong code or ICE with __builtin_bswap64() and rotation at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93505 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P2
[Bug gcov-profile/93401] [9/10 regression] It is no longer possible to use -fprofile-generate= on setups with different instrumentation and feedback directories
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93401 --- Comment #9 from Jan Hubicka --- This only work because the directory does not change from build time to train time. The paths are not relative instead absolute path is put into every .o file at compile time. jan@skylake:~> gcc -fprofile-generate t.c -c | strings t.o | grep gcda /home/jan/t.gcda now the compile time path is typically something like /home//programming//build while at runtime it is uploaded to different machine where /home/ does not exist. I guess one can count the number of components in the path at build time, write it into the package and then setup GCOV_PREFIX_STRIP=5 GCOV_PREFIX=/home/runbot/profile-data and then tar things around and untar into the build directory prior building. But this does not seem very pretty either, especially the step of counting components and passing it to the runtime environment.
[Bug fortran/93462] ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:3771
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93462 --- Comment #3 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:6a97d9eae4543a995f895e6739530f55f5d039a7 commit r10-6372-g6a97d9eae4543a995f895e6739530f55f5d039a7 Author: Tobias Burnus Date: Fri Jan 31 15:54:21 2020 +0100 [Fortran] Disable front-end optimization for OpenACC atomic (PR93462) PR fortran/93462 * frontend-passes.c (gfc_code_walker): For EXEC_OACC_ATOMIC, set in_omp_atomic to true prevent front-end optimization. PR fortran/93462 * gfortran.dg/goacc/atomic-1.f90: New.
[Bug target/40838] gcc shouldn't assume that the stack is aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838 --- Comment #100 from Dzianis Kahanovich --- Created attachment 47753 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47753&action=edit additional aligning on demand <10.0 Finally (for me), if somebody think to patch by H.J. Lu is not enough, there are my patch to force "-fvect-cost-model=cheap -fsimd-cost-model=cheap" or "-mstackrealign" on demand. Default - first, as no abi violation, but if defined ENABLE_STACKREALIGN_ABI_VIOLATION=1 - first choice will be "-mstackrealign". This is for gcc <10.0 and verifyed.
[Bug target/40838] gcc shouldn't assume that the stack is aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838 --- Comment #101 from Dzianis Kahanovich --- Created attachment 47754 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47754&action=edit additional aligning on demand 10.0 (unsure) This is same for gcc 10.0 and not fully verifyed. It MUST work in gcc 10.0, but in current git options helps show nothing changed: gcc -Q -O3 -m32 -march=core2 --help=target --help=optimizers |grep 'stackrealign\|cost-model' Looks like deep options behaviour rework in progress.
[Bug c++/92169] crash on referring to a local class member by unqualified name from outside the enclosing function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92169 --- Comment #6 from Marek Polacek --- Started with r0-116587-g0fd0752e83525409addcdb904c67dc535bd5c1d1: commit 0fd0752e83525409addcdb904c67dc535bd5c1d1 Author: Jason Merrill Date: Thu May 3 12:19:02 2012 -0400 dwarf2out.c (modified_type_die): Use scope_die_for. * dwarf2out.c (modified_type_die): Use scope_die_for. (gen_type_die_with_usage, dwarf2out_finish): Likewise. (uses_local_type_r, uses_local_type): New. (scope_die_for): Keep a type that uses a local type in local scope. Use get_context_die for namespace and type scope. From-SVN: r187106
[Bug c++/91465] [9/10 Regression] unexpected expression of kind overload (ICE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91465
--- Comment #5 from Marek Polacek ---
(In reply to Marek Polacek from comment #4)
> This is the fix, thought I recall it broke something.
That was constexpr-ex4.C:
constexpr-ex4.C:13:11: error: no matching function for call to ‘A::operator
int(const A*)’
13 | int ar[a];
| ^
constexpr-ex4.C:6:13: note: candidate: ‘constexpr A::operator int() const’
6 | constexpr operator int() const { return 1; };
| ^~~~
constexpr-ex4.C:6:13: note: candidate expects 0 arguments, 1 provided
[Bug target/93526] New: x86-64: %c cannot be used in asm for "i" constraint operand and arbitrary constant value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93526
Bug ID: 93526
Summary: x86-64: %c cannot be used in asm for "i" constraint
operand and arbitrary constant value
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at suse dot com
Target Milestone: ---
In
//#define VAL 0x7fffUL // works
//#define VAL 0x8000 // works, but produces -0x8000L
#define VAL 0x8000U // works, but produces -0x8000L
//#define VAL -0x8000L // works
//#define VAL 0x8000L
//#define VAL 0x8000UL
//#define VAL 0x8000UL
unsigned long ul = VAL;
void test(void) {
asm ( ".equ C1, %c0; .global C1" :: "i" (VAL) );
asm ( ".equ C2, %c0; .global C2" :: "n" (VAL) );
// these all work
asm ( ".equ C3, -%n0; .global C3" :: "i" (VAL) );
asm ( ".equ C4, %p0; .global C4" :: "i" (VAL) );
asm ( ".equ C5, %P0; .global C5" :: "i" (VAL) );
}
play with the various values for VAL. The ones not marked "works" will produce
"operand is not a condition code" errors. But even among the ones that work
there looks to be a signedness issue with the produced constants in some cases.
(I realize the 'n' modifier is not documented. Perhaps it should be, or else
consider it here just for completeness.)
[Bug rtl-optimization/90275] [8/9/10 Regression] ICE: in insert_regs, at cse.c:1128 with -O2 -fno-dce -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90275 --- Comment #8 from Jeffrey A. Law --- *** Bug 92388 has been marked as a duplicate of this bug. ***
[Bug target/92388] [10 Regression] ICE in insert_regs, at cse.c:1129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92388 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |DUPLICATE --- Comment #3 from Jeffrey A. Law --- Almost certainly another dup of 90275. We have the same dual-output insn that sets the condition codes + a pseudo and later in the block a nop-set where the source is referenced by the earlier dual-output insn. *** This bug has been marked as a duplicate of bug 90275 ***
[Bug target/93526] x86-64: %c cannot be used in asm for "i" constraint operand and arbitrary constant value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93526 --- Comment #1 from jbeulich at suse dot com --- Bug 85344 may be related for the signedness aspect.
[Bug fortran/93365] ICE in match_data_constant, at fortran/decl.c:426
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93365 markeggleston at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from markeggleston at gcc dot gnu.org --- (In reply to Steve Kargl from comment #10) > On Fri, Jan 31, 2020 at 08:41:29AM +, markeggleston at gcc dot gnu.org > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93365 > > > > markeggleston at gcc dot gnu.org changed: > > > >What|Removed |Added > > > >Assignee|markeggleston at gcc dot gnu.org |unassigned at gcc > > dot gnu.org > > > > --- Comment #9 from markeggleston at gcc dot gnu.org --- > > Since I'm no longer investigating this I've removed myself from assignment. > > > > This problem does not occur when the compiler is built with bootstrap but > > does > > when built with gcc 6.3. > > > > What should be done about its status? > > > > I think it should be closed. Any suggestions/opinions? > > > > What do you mean by "this problem"? The original bug in > z1.f90 from comment #1 has been fixed? The problem of getting an ICE if I build using gcc 6.3.0. Since the original problem is fixed. I'm changing the status to RESOLVED/FIXED.
[Bug target/93526] x86-64: %c cannot be used in asm for "i" constraint operand and arbitrary constant value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93526 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Why do you think this is a bug? c modifier behaves differently depending on whether the operand is CONSTANT_ADDRESS_P or not, and if it is not, it falls through to the target specific hook (ix86_output_operand in this case) and that for c/C as documented requires the operand to be a comparison from which it extracts condition codes. E.g. 0x8000UL or 0x8000UL is neither of those, therefore you get a failure.
[Bug lto/93384] [10 Regression] Python 3.9.0a3 fails to build on ppc64le with GCC 10.0.1: redefined symbol cannot be used on reloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93384 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #28 from Jakub Jelinek --- Fixed on the trunk.
[Bug tree-optimization/93055] [10 Regression] accumulation loops in stepanov_vector benchmark use more instruction level parpallelism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055 --- Comment #9 from Jakub Jelinek --- Vlad, any thoughts on this?
[Bug lto/93384] [10 Regression] Python 3.9.0a3 fails to build on ppc64le with GCC 10.0.1: redefined symbol cannot be used on reloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93384 --- Comment #29 from Victor Stinner --- Jakub Jelinek: "Fixed on the trunk." Oh wow, that was quick! Thanks for the fix!
[Bug target/93526] x86-64: %c cannot be used in asm for "i" constraint operand and arbitrary constant value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93526 --- Comment #3 from jbeulich at suse dot com --- Let me quote documentation then: "Require a constant operand and print the constant expression with no punctuation." There's nothing said about valid value ranges or alike. To me as a user of the compiler it doesn't matter what CONSTANT_ADDRESS_P() actually means or does. Of course I'm not going to exclude that the documentation is wrong, and the code works as intended (less the signedness issue).
[Bug c++/93496] Miscompile of range-for over braced-init-list in constructor of class with virtual inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93496 --- Comment #6 from Jonathan Wakely --- A brief, but maybe too brief look at the other bug. If it's the same issue, I don't understand how it was fixed in GCC 8.2 when r267702 wasn't committed until after the 8.2 release.
[Bug sanitizer/92634] [8/9/10 regression] -fsanitize=undefined erroneous null pointer check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634 Jakub Jelinek changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #12 from Jakub Jelinek --- Joseph said on IRC: I don't think that's valid (runtime undefined, the lvalue that is the operand of & does not designate an object and neither of the other cases in the constraints for & applies). Thus closing as INVALID.
[Bug c++/93527] New: Internal compiler error when static_assert concept std::regular on class with variadic constrained constructor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93527
Bug ID: 93527
Summary: Internal compiler error when static_assert concept
std::regular on class with variadic constrained
constructor.
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pacoarjonilla at yahoo dot es
Target Milestone: ---
Variations of the source code (not included) yield compiler errors in other GCC
files and also memory access violation.
GCC version:
gcc git commit 5a28e2727f718f14a2afccf16c4dda814af5b6f8
(master branch as of 2020/1/31)
System:
OpenSUSE Tumbleweed running on intel i7-8700K
$ uname -ra
Linux linux-fikn 5.4.14-1-default #1 SMP Thu Jan 23 08:54:47 UTC 2020 (fc4ea7a)
x86_64 x86_64 x86_64 GNU/Linux
$ gcc10git --version
gcc10git (GCC) 10.0.1 20200131 (experimental)
configuration options:
$ ../gcc/configure --disable-multilib --enable-languages=c++
--program-suffix=10git
Build command:
$ make -j 12
maybe related to bug 79917
Compiler command:
$ /usr/local/bin/g++10git -E -std=c++2a -o namidevel.pp.cc -c namidevel.cc
Compiler output:
../namidevel.cc:4:20: error: static assertion failed
4 | static_assert(std::regular);
| ~^~
../namidevel.cc:4:20: note: constraints not satisfied
In file included from ../namiplot:10,
from ../namidevel.cc:1:
/usr/local/include/c++/10.0.1/concepts:288:15: required for the satisfaction
of ‘__weakly_eq_cmp_with’
/usr/local/include/c++/10.0.1/concepts:298:13: required for the satisfaction
of ‘equality_comparable’
/usr/local/include/c++/10.0.1/concepts:289:4: in requirements with
‘std::remove_reference_t& __t’, ‘std::remove_reference_t& __u’
/usr/local/include/c++/10.0.1/concepts:290:10: note: the required expression
‘(__t == __u)’ is invalid
290 |{ __t == __u } -> boolean;
| ^~
/usr/local/include/c++/10.0.1/concepts:291:10: internal compiler error: in
move_fn_p, at cp/decl.c:14076
291 |{ __t != __u } -> boolean;
| ^~
0x62720e move_fn_p(tree_node const*)
../../gcc/gcc/cp/decl.c:14076
0x885111 joust
../../gcc/gcc/cp/call.c:11150
0x88546c tourney
../../gcc/gcc/cp/call.c:11656
0x892edb build_new_op_1
../../gcc/gcc/cp/call.c:6250
0x89382d build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
../../gcc/gcc/cp/call.c:6546
0xa71e43 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node**, int)
../../gcc/gcc/cp/typeck.c:4245
0xa09267 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:19293
0x9fb299 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:18622
0x8c9e26 diagnose_valid_expression
../../gcc/gcc/cp/constraint.cc:3143
0x8cfddb satisfy_constraint_r
../../gcc/gcc/cp/constraint.cc:3182
0x8d0218 satisfy_constraint
../../gcc/gcc/cp/constraint.cc:2599
0xa490f3 finish_static_assert(tree_node*, tree_node*, unsigned int, bool)
../../gcc/gcc/cp/semantics.c:9685
0x99eaf2 cp_parser_static_assert
../../gcc/gcc/cp/parser.c:14678
0x9d48f2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:13377
0x9d506a cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4731
0x9d506a c_parse_file()
../../gcc/gcc/cp/parser.c:43696
0xae942b c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1186
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug c++/93527] Internal compiler error when static_assert concept std::regular on class with variadic constrained constructor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93527 --- Comment #1 from Paco Arjonilla --- Created attachment 47755 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47755&action=edit Preprocessed source code File is gzipped because its original size is 1055841 bytes.
[Bug c++/93527] Internal compiler error when static_assert concept std::regular on class with variadic constrained constructor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93527 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-01-31 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- tar: This does not look like a tar archive unzip x.zip also doesn't work
[Bug c++/93527] Internal compiler error when static_assert concept std::regular on class with variadic constrained constructor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93527 --- Comment #3 from Andreas Schwab --- zcat namidevel.pp.cc.gz
[Bug tree-optimization/93440] scalar unrolled loop makes vectorized code unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93440 --- Comment #6 from ikonomisma at googlemail dot com --- (In reply to Richard Biener from comment #5) > OK, so I can compile the testcase now but I fail to see the error. We're > doing pointer difference compares and those should work out fine? > > We're also doig many checks but you probably refer to the very first test? > > _Z12brokenvectorRKSt6vectorIiSaIiEES3_: > .LFB2470: > .cfi_startproc > movq(%rsi), %rdx > movq8(%rdi), %rsi > xorl%r8d, %r8d > movq(%rdi), %rax > movq%rsi, %rcx > subq%rax, %rcx > cmpq$12, %rcx > jle .L18 > > that's created from > >[local count: 1073741824]: > _7 = MEM[(int * *)b_2(D)]; > _6 = MEM[(int * *)a_3(D) + 8B]; > _4 = MEM[(int * *)a_3(D)]; > _10 = _6 - _4; > if (_10 > 12) > > what are the actual pointers here? So the structure of the code is like this: - function label - function prologue - test whether less than or equal 12 bytes (3 or less ints) are to be processed, jump to SIMD vector prologue - unrolled scalar loop - test whether less than or equal 12 bytes remain to be processed - jump back to scalar loop if more of the vector remains to be processed - SIMD vector prologue testing whether enough of the vector remains unprocessed to warrant vectorized execution. This will effectively never be the case To see the problem, you could call the function (non-inlined) in a test program with a reasonably large vector. Run under gdb, set a breakpoint on one of the instructions in the SIMD-vector code, run. You'll find the SIMD code never gets executed.
[Bug c++/93527] Internal compiler error when static_assert concept std::regular on class with variadic constrained constructor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93527 Marek Polacek changed: What|Removed |Added Status|WAITING |NEW --- Comment #4 from Marek Polacek --- Confirmed thus: $ ./cc1plus -quiet namidevel.pp.cc -std=c++2a ../namidevel.cc:4:20: error: static assertion failed ../namidevel.cc:4:20: note: constraints not satisfied In file included from ../namiplot:10, from ../namidevel.cc:1: /usr/local/include/c++/10.0.1/concepts:288:15: required for the satisfaction of ‘__weakly_eq_cmp_with’ /usr/local/include/c++/10.0.1/concepts:298:13: required for the satisfaction of ‘equality_comparable’ /usr/local/include/c++/10.0.1/concepts:289:4: in requirements with ‘std::remove_reference_t& __t’, ‘std::remove_reference_t& __u’ /usr/local/include/c++/10.0.1/concepts:290:10: note: the required expression ‘(__t == __u)’ is invalid /usr/local/include/c++/10.0.1/concepts:291:10: internal compiler error: in move_fn_p, at cp/decl.c:14076 0xa3cf91 move_fn_p(tree_node const*) /home/mpolacek/src/gcc/gcc/cp/decl.c:14076 0x944954 joust /home/mpolacek/src/gcc/gcc/cp/call.c:11150 0x9473b1 tourney /home/mpolacek/src/gcc/gcc/cp/call.c:11656 0x931565 build_new_op_1 /home/mpolacek/src/gcc/gcc/cp/call.c:6250 0x932371 build_new_op(op_location_t const&, tree_code, int, tree_node*, tree_node*, tree_node*, tree_node**, int) /home/mpolacek/src/gcc/gcc/cp/call.c:6546 0xc9f580 build_x_binary_op(op_location_t const&, tree_code, tree_node*, tree_code, tree_node*, tree_code, tree_node**, int) /home/mpolacek/src/gcc/gcc/cp/typeck.c:4245 0xbea998 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /home/mpolacek/src/gcc/gcc/cp/pt.c:19293 0xbe7d0a tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) /home/mpolacek/src/gcc/gcc/cp/pt.c:18622 0x9b5e7a diagnose_valid_expression /home/mpolacek/src/gcc/gcc/cp/constraint.cc:3143 0x9b5fd9 diagnose_compound_requirement /home/mpolacek/src/gcc/gcc/cp/constraint.cc:3182 0x9b641c diagnose_requirement /home/mpolacek/src/gcc/gcc/cp/constraint.cc:3262 0x9b6584 diagnose_requires_expr /home/mpolacek/src/gcc/gcc/cp/constraint.cc:3289 0x9b677c diagnose_atomic_constraint /home/mpolacek/src/gcc/gcc/cp/constraint.cc:3325 0x9b4776 satisfy_atom /home/mpolacek/src/gcc/gcc/cp/constraint.cc:2550 0x9b4847 satisfy_constraint_r /home/mpolacek/src/gcc/gcc/cp/constraint.cc:2579 0x9b3dd2 satisfy_conjunction /home/mpolacek/src/gcc/gcc/cp/constraint.cc:2386 0x9b4815 satisfy_constraint_r /home/mpolacek/src/gcc/gcc/cp/constraint.cc:2575 0x9b48c7 satisfy_constraint /home/mpolacek/src/gcc/gcc/cp/constraint.cc:2599 0x9b4ab4 satisfy_constraint_expression /home/mpolacek/src/gcc/gcc/cp/constraint.cc:2644 0x9b4e5a constraint_satisfaction_value /home/mpolacek/src/gcc/gcc/cp/constraint.cc:2734
[Bug target/91320] [9/10 Regression] x86-64 code generation / register allocation regressed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91320 --- Comment #6 from Jeffrey A. Law --- Sounds good Vlad. Real curious to see what, if any, heuristics work in practice. We can obviously reevaluate this BZ once you've wrapped up on 91333.
[Bug middle-end/93509] Stack protector should offer trap-only handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93509 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-31 Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- I don't know if doing a trap is often a good solution, but the current situation is pretty bad, we need better options; trapping could be one.
[Bug c++/93496] Miscompile of range-for over braced-init-list in constructor of class with virtual inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93496 --- Comment #7 from Jonathan Wakely --- On the gcc-8 branch it was fixed by r261091 for PR 85873
[Bug libgomp/92305] [10 regression] libgomp.fortran/use_device_addr-1.f90 fails starting with r277606
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92305
--- Comment #17 from Jakub Jelinek ---
So, to sum up, in #c9 we are (or want to do) in Fortran roughly what in C we
would do with:
void foo (double aa, double bb, void *c_aptr, void *c_bptr, double **aptr,
double **bptr, _Bool _aa, _Bool _bb, _Bool _c_aptr, _Bool _c_bptr)
{
if (!_c_aptr | !_c_bptr)
__builtin_abort ();
}
void bar (double aa, double bb, void *c_aptr, void *c_bptr, double **aptr,
double **bptr, unsigned char _aa, unsigned char _bb, unsigned char _c_aptr,
unsigned char _c_bptr)
{
if (!_c_aptr | !_c_bptr)
__builtin_abort ();
}
int
main ()
{
double *aptr, *bptr;
foo (0.0, 0.0, 0, 0, &aptr, &bptr, 1, 1, 1, 1);
bar (0.0, 0.0, 0, 0, &aptr, &bptr, 1, 1, 1, 1);
return 0;
}
and that works just fine in C, even at -O0.
Looking at expand dump of foo vs. test_dummy_opt_val_callee_2
I don't see any relevant differences in the arg passing:
-;; _1 = ~_c_aptr_4(D);
+;; _1 = ~_c_aptr_6(D);
-(insn 17 16 18 (set (reg:QI 124)
+(insn 17 16 18 (set (reg:QI 126)
(mem/c:QI (plus:DI (reg/f:DI 111 virtual-incoming-args)
-(const_int 64 [0x40])) [4 _c_aptr+0 S1 A64])) "pr92305.c":3:7
-1
+(const_int 64 [0x40])) [4 _c_aptr+0 S1 A64]))
"pr92305.f90":14:0 -1
(nil))
...
-;; _2 = ~_c_bptr_5(D);
+;; _3 = ~_c_bptr_7(D);
-(insn 20 19 21 (set (reg:QI 126)
+(insn 22 21 23 (set (reg:QI 129)
(mem/c:QI (plus:DI (reg/f:DI 111 virtual-incoming-args)
-(const_int 72 [0x48])) [4 _c_bptr+0 S1 A64])) "pr92305.c":3:18
-1
+(const_int 72 [0x48])) [4 _c_bptr+0 S1 A64]))
"pr92305.f90":14:0 -1
(nil))
In the caller, in Fortran I see:
(expr_list (use (reg:DI 2 2))
(expr_list:DF (use (reg:DF 33 1))
(expr_list:DF (use (reg:DF 34 2))
(expr_list:DI (use (reg:DI 5 5))
(expr_list:DI (use (reg:DI 6 6))
(expr_list:DI (use (reg:DI 7 7))
(expr_list:DI (use (reg:DI 8 8))
(expr_list:QI (use (reg:DI 9 9))
(expr_list:QI (use (reg:DI 10 10))
(expr_list:QI (use (mem:DI (reg/f:DI
114 virtual-outgoing-args) [0 S1 A64]))
(expr_list:QI (use (mem:DI (plus:DI
(reg/f:DI 114 virtual-outgoing-args)
(const_int 8
[0x8])) [0 S1 A64]))
(nil)
and both DImode slot at virtual-outgoing-args and at +8 are initialized with
full DImode store of 1 in there, while in C:
(expr_list (use (reg:DI 2 2))
(expr_list:DF (use (reg:DF 33 1))
(expr_list:DF (use (reg:DF 34 2))
(expr_list:DI (use (reg:DI 5 5))
(expr_list:DI (use (reg:DI 6 6))
(expr_list:DI (use (reg:DI 7 7))
(expr_list:DI (use (reg:DI 8 8))
(expr_list:QI (use (reg:DI 9 9))
(expr_list:QI (use (reg:DI 10 10))
(expr_list:QI (use (mem:DI (plus:DI
(reg/f:DI 114 virtual-outgoing-args)
(const_int 64 [0x40]))
[0 S1 A64]))
(expr_list:QI (use (mem:DI (plus:DI
(reg/f:DI 114 virtual-outgoing-args)
(const_int 72
[0x48])) [0 S1 A64]))
(nil)
and again, the +64 and +72 slots are initialized to full DImode values of 1.
[Bug rtl-optimization/91838] [8/9 Regression] incorrect use of shr and shrx to shift by 64, missed optimization of vector shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91838 --- Comment #11 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5910b14503dd82772dfeca5336a0176f9b1d260a commit r10-6381-g5910b14503dd82772dfeca5336a0176f9b1d260a Author: Jakub Jelinek Date: Fri Jan 31 19:35:11 2020 +0100 testsuite: Fix up pr91838.C test [PR91838] The test FAILs on i686-linux with: FAIL: g++.dg/pr91838.C (test for excess errors) Excess errors: /home/jakub/src/gcc/gcc/testsuite/g++.dg/pr91838.C:7:8: warning: MMX vector return without MMX enabled changes the ABI [-Wpsabi] /home/jakub/src/gcc/gcc/testsuite/g++.dg/pr91838.C:7:3: warning: MMX vector argument without MMX enabled changes the ABI [-Wpsabi] and on x86_64-linux with -m32 testing with failure to match the expected pattern in there (or both with e.g. -m32/-mno-mmx/-mno-sse testing). The test is also in a wrong directory, has non-standard specification that it requires c++11 or later. 2020-01-31 Jakub Jelinek PR rtl-optimization/91838 * g++.dg/pr91838.C: Moved to ... * g++.dg/opt/pr91838.C: ... here. Require c++11 target instead of dg-skip-if for c++98. Pass -Wno-psabi -w to avoid psabi style warnings on vector arg passing or return. Add -masm=att on i?86/x86_64. Only check for pxor %xmm0, %xmm0 on lp64 i?86/x86_64.
[Bug libgomp/93515] OpenMP target teams distribute parallel for with defaultmap not mapping correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93515 --- Comment #3 from Jakub Jelinek --- The patch unfortunately regressed: +FAIL: c-c++-common/gomp/loop-5.c (internal compiler error) +FAIL: c-c++-common/gomp/loop-5.c (test for excess errors) which looks like previously broken code on the testcase, but wI won't apply the patch until that issue gets fixed, so needs to wait for next week.
[Bug c++/93528] New: Object copy not optimized out for most sizes in strict aliasing memcpy pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93528
Bug ID: 93528
Summary: Object copy not optimized out for most sizes in strict
aliasing memcpy pattern
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andrey.vihrov at gmail dot com
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Consider the following code (a common pattern to avoid strict aliasing
violations):
struct X
{
char arr[10];
};
void foo(void *p)
{
X x;
memcpy(&x, p, sizeof(x));
x.arr[0] = 42;
memcpy(p, &x, sizeof(x));
}
When the array is 1, 2, 4, 8 or 16 elements long, memcpy() is optimized out
with -O2. Output for x86-64 Linux:
_Z3fooPv:
movb $42, (%rdi)
ret
For other struct sizes, copies are performed nonetheless. Depending on the
array size either an inline implementation or a call to memcpy() is inserted.
For the above case, on x86-64 Linux GCC generates
_Z3fooPv:
movq (%rdi), %rax
movq %rax, -10(%rsp)
movb $42, -10(%rsp)
movq -10(%rsp), %rax
movq %rax, (%rdi)
ret
It seems that the field types and the layout of the struct don't matter, and
the optimization is conditional on object size only. For example,
struct Y
{
int a, b, c;
};
is affected as well.
As a variant, the problem also appears with a plain array instead of a struct:
void bar(void *p)
{
int arr[3];
memcpy(arr, p, sizeof(arr));
arr[0] = 42;
memcpy(p, arr, sizeof(arr));
}
gives
_Z3barPv:
movq (%rdi), %rax
movq %rax, -12(%rsp)
movl $42, -12(%rsp)
movq -12(%rsp), %rax
movq %rax, (%rdi)
ret
[Bug c++/93529] New: Implement P1009R2, Array size deduction in new-expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93529 Bug ID: 93529 Summary: Implement P1009R2, Array size deduction in new-expressions Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jason at gcc dot gnu.org Target Milestone: --- One more C++20 feature, though this one is a DR against earlier versions as well. https://wg21.link/P1009R2
[Bug c++/93529] Implement P1009R2, Array size deduction in new-expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93529 --- Comment #1 from Jason Merrill --- Created attachment 47756 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47756&action=edit initial WIP This implements the simplest form, but not the string literal case or parenthesized init.
[Bug c++/93529] Implement P1009R2, Array size deduction in new-expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93529 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-31 Ever confirmed|0 |1
[Bug analyzer/93438] ICE in operator[], at vec.h:867
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93438 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:455f58ec50465aed9d92dc31d68708a05e499388 commit r10-6382-g455f58ec50465aed9d92dc31d68708a05e499388 Author: David Malcolm Date: Fri Jan 31 09:20:38 2020 -0500 analyzer: fix ICE with pointers between stack frames (PR 93438) PR analyzer/93438 reports an ICE when merging two region_models in which an older stack frame has a local pointing to a local in a more recent stack frame. stack older frame int *: "ow" --+ | newer frame | int: "pk" <---+ The root cause is that the state-merging code assumes that all frame regions in the merged model have already been created. stack_region::can_merge_p iterates through the frames, creating and populating each merged frame in turn, so when it attempts to populate the older frame, it attempts to reference the newer frame in the merged model, which doesn't exist yet. This patch reworks stack_region::can_merge_p to use a two-pass approach in which all frames in the merged model are created first, and then are all populated, fixing the bug. gcc/analyzer/ChangeLog: PR analyzer/93438 * region-model.cc (stack_region::can_merge_p): Split into a two pass approach, creating all stack regions first, then populating them. (selftest::test_state_merging): Add test coverage for (a) the case of self-merging a model in which a local in an older stack frame points to a local in a more recent stack frame (which previously would ICE), and (b) the case of self-merging a model in which a local points to a global (which previously worked OK). gcc/testsuite/ChangeLog: PR analyzer/93438 * gcc.dg/analyzer/torture/pr93438.c: New test. * gcc.dg/analyzer/torture/pr93438-2.c: New test.
[Bug analyzer/93379] ICE in set_value, at analyzer/region-model.cc:5149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93379 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:f1c807e887d43551bca0acc16a438d880cfaf7c9 commit r10-6383-gf1c807e887d43551bca0acc16a438d880cfaf7c9 Author: David Malcolm Date: Fri Jan 31 12:05:03 2020 -0500 analyzer: fix ICE getting void return value (PR 93379) PR analyzer/93379 reports an ICE within region_model::update_for_return_superedge when writing the returned svalue_id to the lhs of the call_stmt The root cause is that this analyzer code assumed that for any call with a non-NULL gimple_call_lhs, the called fndecl would have non-void return type, and thus that a non-null svalue_id would be returned from region_model::pop_frame. This isn't the case e.g. for a call with conflicting types where the callee returns void but the caller assumes int. This patch fixes the ICE by moving the check for null result so that it also guards setting the lhs. gcc/analyzer/ChangeLog: PR analyzer/93379 * region-model.cc (region_model::update_for_return_superedge): Move check for null result so that it also guards setting the lhs. gcc/testsuite/ChangeLog: PR analyzer/93379 * gcc.dg/analyzer/torture/pr93379-2.c: New test. * gcc.dg/analyzer/torture/pr93379.c: New test.
[Bug analyzer/93438] ICE in operator[], at vec.h:867
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93438 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by the above commit.
[Bug fortran/93365] ICE in match_data_constant, at fortran/decl.c:426
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93365 --- Comment #12 from Steve Kargl --- On Fri, Jan 31, 2020 at 03:46:04PM +, markeggleston at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93365 > > markeggleston at gcc dot gnu.org changed: > >>> Since I'm no longer investigating this I've removed myself from assignment. >>> >>> This problem does not occur when the compiler is built with bootstrap but >>> does > > > when built with gcc 6.3. > > > > > > What should be done about its status? > > > > > > I think it should be closed. Any suggestions/opinions? > > > > > > > What do you mean by "this problem"? The original bug in > > z1.f90 from comment #1 has been fixed? > > The problem of getting an ICE if I build using gcc 6.3.0. Since the original > problem is fixed. I'm changing the status to RESOLVED/FIXED. > So, only a part of the bug documented by this PR has been fixed. The other bug exposed by z1.f90 remains?
[Bug analyzer/93379] ICE in set_value, at analyzer/region-model.cc:5149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93379 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by the above patch.
[Bug c++/93530] New: [10 Regression] ICE on invalid alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93530
Bug ID: 93530
Summary: [10 Regression] ICE on invalid alignas
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kretz at kde dot org
Target Milestone: ---
Test case (no flags required):
template struct a {
using b = a;
void c() alignas(b::d);
};
This test case fell out of creduce while trying to reduce a different ICE. This
should diagnose
a) that b::d does not exist
b) that alignas is incorrectly placed
[Bug c++/93530] [10 Regression] ICE on invalid alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93530 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-31 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
