[Bug testsuite/101969] [10 regression] reactivated test case gcc.dg/pr78213.c in r10-10042 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101969 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:fc1993af02a3076e91c24f372be1883517453095 commit r9-9681-gfc1993af02a3076e91c24f372be1883517453095 Author: Thomas Schwinge Date: Thu Aug 19 08:25:47 2021 +0200 Fix up 'gcc.dg/pr78213.c' for '--enable-checking=release' etc. Fix up for r242748 (commit 3615816da830d41f67a5d8955ae588eba7f0b6fb) "[PR target/78213] Do not ICE on non-empty -fself-test", as made apparent by recent commit a42467bdb70650cd2f421e67b6c3418f74feaec2 "Restore 'gcc.dg/pr78213.c' testing", after the test case had gotten disabled in r243681 (commit ecfc21ff34ddc6f8aa517251fb51494c68ff741f) "Introduce selftest::locate_file" shortly after its original introduction. gcc/testsuite/ PR testsuite/101969 * gcc.dg/pr78213.c: Fix up for '--enable-checking=release' etc. (cherry picked from commit b7fc42073c04813f6b63e0641d3f6765424857c9)
[Bug testsuite/101969] [10 regression] reactivated test case gcc.dg/pr78213.c in r10-10042 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101969 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:ee7502e5fec1a1c0215febfd486a0df9ffaf5692 commit r10-10046-gee7502e5fec1a1c0215febfd486a0df9ffaf5692 Author: Thomas Schwinge Date: Thu Aug 19 08:25:47 2021 +0200 Fix up 'gcc.dg/pr78213.c' for '--enable-checking=release' etc. Fix up for r242748 (commit 3615816da830d41f67a5d8955ae588eba7f0b6fb) "[PR target/78213] Do not ICE on non-empty -fself-test", as made apparent by recent commit a42467bdb70650cd2f421e67b6c3418f74feaec2 "Restore 'gcc.dg/pr78213.c' testing", after the test case had gotten disabled in r243681 (commit ecfc21ff34ddc6f8aa517251fb51494c68ff741f) "Introduce selftest::locate_file" shortly after its original introduction. gcc/testsuite/ PR testsuite/101969 * gcc.dg/pr78213.c: Fix up for '--enable-checking=release' etc. (cherry picked from commit b7fc42073c04813f6b63e0641d3f6765424857c9)
[Bug testsuite/101969] [10 regression] reactivated test case gcc.dg/pr78213.c in r10-10042 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101969 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:5fb588a677bf34dc864c577ed848405752905b89 commit r11-8885-g5fb588a677bf34dc864c577ed848405752905b89 Author: Thomas Schwinge Date: Thu Aug 19 08:25:47 2021 +0200 Fix up 'gcc.dg/pr78213.c' for '--enable-checking=release' etc. Fix up for r242748 (commit 3615816da830d41f67a5d8955ae588eba7f0b6fb) "[PR target/78213] Do not ICE on non-empty -fself-test", as made apparent by recent commit a42467bdb70650cd2f421e67b6c3418f74feaec2 "Restore 'gcc.dg/pr78213.c' testing", after the test case had gotten disabled in r243681 (commit ecfc21ff34ddc6f8aa517251fb51494c68ff741f) "Introduce selftest::locate_file" shortly after its original introduction. gcc/testsuite/ PR testsuite/101969 * gcc.dg/pr78213.c: Fix up for '--enable-checking=release' etc. (cherry picked from commit b7fc42073c04813f6b63e0641d3f6765424857c9)
[Bug testsuite/101969] [10 regression] reactivated test case gcc.dg/pr78213.c in r10-10042 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101969 --- Comment #2 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:b7fc42073c04813f6b63e0641d3f6765424857c9 commit r12-3012-gb7fc42073c04813f6b63e0641d3f6765424857c9 Author: Thomas Schwinge Date: Thu Aug 19 08:25:47 2021 +0200 Fix up 'gcc.dg/pr78213.c' for '--enable-checking=release' etc. Fix up for r242748 (commit 3615816da830d41f67a5d8955ae588eba7f0b6fb) "[PR target/78213] Do not ICE on non-empty -fself-test", as made apparent by recent commit a42467bdb70650cd2f421e67b6c3418f74feaec2 "Restore 'gcc.dg/pr78213.c' testing", after the test case had gotten disabled in r243681 (commit ecfc21ff34ddc6f8aa517251fb51494c68ff741f) "Introduce selftest::locate_file" shortly after its original introduction. gcc/testsuite/ PR testsuite/101969 * gcc.dg/pr78213.c: Fix up for '--enable-checking=release' etc.
[Bug fortran/101735] Type parameter inquiries for substrings are rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101735 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org Keywords||rejects-valid --- Comment #3 from Tobias Burnus --- Additional example – same general issue, different error message: character(len=5) :: str2(4) type t character(len=5) :: str(4) end type t type(t) :: var integer :: x, y x = var%str(:)(1:1)%len ! Bogus: 'Invalid character in name' y = str2(:)(1:1)%len ! Bogus: 'Invalid character in name' Plus: same issue with: % kind
[Bug target/82730] extra store/reload of an XMM for every byte extracted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82730 --- Comment #2 from Hongtao.liu --- Similar as 48609
[Bug target/81496] AVX load from adjacent memory location followed by concatenation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81496 --- Comment #8 from Hongtao.liu --- Similar as 48609
[Bug target/81496] AVX load from adjacent memory location followed by concatenation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81496 --- Comment #7 from Hongtao.liu --- we have plenty of such issues which are related to ABI and middle-end, when pass/return struct/complex/int128 as parameter and middle-end will push them to stack and load it back, but the problem is that either the data is stored on the stack with a large size and then loaded back with multiple small sizes, or stored on the stack with multiple small sizes and then loaded back with a large size, because the store size and load size are not the same, so cse cannot eliminate these redundancies, and neither can combine, but in fact if there is vec_set/vec_extract on the back end, these spill/reloads can be completely replaced. I'm wondering whether cse can be extend to handle such partial extract/set stuff, or we should avoid spill to stack in the first place.
[Bug c/101974] New: ICE on compilable code: in from_mode_char, at attribs.h:304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101974
Bug ID: 101974
Summary: ICE on compilable code: in from_mode_char, at
attribs.h:304
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cnsun at uwaterloo dot ca
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.A3uaEFFAHF-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210818 (experimental) [master revision
:ac65007c1:2d14d64bf2d42a87ec58dd3760be12aeaa4a4279] (GCC)
$ cat mutant.c
__attribute__((access("+nosimd"))) rdonly_v_all();
$ gcc-trunk mutant.c
mutant.c:1:36: warning: type defaults to ‘int’ in declaration of ‘rdonly_v_all’
[-Wimplicit-int]
1 | __attribute__((access("+nosimd"))) rdonly_v_all();
|^~~~
mutant.c:1:1: internal compiler error: in from_mode_char, at attribs.h:304
1 | __attribute__((access("+nosimd"))) rdonly_v_all();
| ^
0x64da68 attr_access::from_mode_char(char)
/tmp/tmp.A3uaEFFAHF-gcc-builder/gcc/gcc/attribs.h:304
0x64da68 init_attr_rdwr_indices(hash_map, attr_access> >*,
tree_node*)
/tmp/tmp.A3uaEFFAHF-gcc-builder/gcc/gcc/attribs.c:2138
0x9f7802 append_access_attr
/tmp/tmp.A3uaEFFAHF-gcc-builder/gcc/gcc/c-family/c-attribs.c:4472
0x9f8612 handle_access_attribute
/tmp/tmp.A3uaEFFAHF-gcc-builder/gcc/gcc/c-family/c-attribs.c:4718
0x8efeb6 decl_attributes(tree_node**, tree_node*, int, tree_node*)
/tmp/tmp.A3uaEFFAHF-gcc-builder/gcc/gcc/attribs.c:715
0x90c67e start_decl(c_declarator*, c_declspecs*, bool, tree_node*, unsigned
int*)
/tmp/tmp.A3uaEFFAHF-gcc-builder/gcc/gcc/c/c-decl.c:5201
0x969715 c_parser_declaration_or_fndef
/tmp/tmp.A3uaEFFAHF-gcc-builder/gcc/gcc/c/c-parser.c:2306
0x973723 c_parser_external_declaration
/tmp/tmp.A3uaEFFAHF-gcc-builder/gcc/gcc/c/c-parser.c:1778
0x97418b c_parser_translation_unit
/tmp/tmp.A3uaEFFAHF-gcc-builder/gcc/gcc/c/c-parser.c:1651
0x97418b c_parse_file()
/tmp/tmp.A3uaEFFAHF-gcc-builder/gcc/gcc/c/c-parser.c:22302
0x9d6515 c_common_parse_file()
/tmp/tmp.A3uaEFFAHF-gcc-builder/gcc/gcc/c-family/c-opts.c:1223
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 tree-optimization/13563] if-conversion not agressive enough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13563 Andrew Pinski changed: What|Removed |Added CC||rth at gcc dot gnu.org --- Comment #8 from Andrew Pinski --- *** Bug 45032 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/45032] Missed optimization in ifcvt/crossjump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45032 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from Andrew Pinski --- This is a dup of bug 13563. *** This bug has been marked as a duplicate of bug 13563 ***
[Bug target/60104] load not folded into indirect branch on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60104 Andrew Pinski changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #6 from Andrew Pinski --- *** Bug 53772 has been marked as a duplicate of this bug. ***
[Bug target/53772] Failed to combine load and jump on vtable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53772 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Fixed in GCC 5+ with PR 60104. *** This bug has been marked as a duplicate of bug 60104 ***
[Bug tree-optimization/59132] Missing aggressive array based optimisation warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59132 Andrew Pinski changed: What|Removed |Added Keywords|missed-optimization |diagnostic --- Comment #2 from Andrew Pinski --- Are you asking for an out of bounds warning?
[Bug middle-end/101973] subtraction of clz is not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101973 Sven changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Sven --- OK. Closing this myself.
[Bug middle-end/101973] subtraction of clz is not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101973 --- Comment #1 from Andrew Pinski --- This is fixed on the trunk.
[Bug middle-end/101973] New: subtraction of clz is not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101973
Bug ID: 101973
Summary: subtraction of clz is not optimized
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: sven.koehler at gmail dot com
Target Milestone: ---
On Intel x86_64, the generated code for __builtin_clz(x) looks something like
this: clz(x) = 63 - bsr(x)
Since Intel does not seem to have a way to do 63-y in a single instruction, XOR
is used instead and the actual assembly code corresponds to clz(x) = 63 ^
bsr(x). Since bsr(x) is in the range 0 to 63, the XOR with 63 is equivalent to
63-y.
However, when we actually need the index of the most significant non-zero bit,
we have another 63-y, as in this function:
int bsr(unsigned long x) {
return sizeof(x)*8 - 1 - __builtin_clzl(x);
}
With -O3, GCC emits the following assembly code:
bsr:
bsr rdi, rdi
mov eax, 63
xor rdi, 63
sub eax, edi
ret
The XOR with 63 and the subtraction from 63 cancel each other out in this
special case. LLVM/clang performs this optimization.
One might also consider the arbitrary case of z-clz(x) as a test case. On
Intel, this is equivalent to bsr(x)+(z-63).
[Bug tree-optimization/14721] jump optimization involving a sibling call within a jump table
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14721 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=47253 --- Comment #6 from Andrew Pinski --- Related to PR 47253.
[Bug target/47253] Conditional jump to tail function is not generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47253 Andrew Pinski changed: What|Removed |Added CC||jay.foad at gmail dot com --- Comment #6 from Andrew Pinski --- *** Bug 60159 has been marked as a duplicate of this bug. ***
[Bug target/60159] improve code for conditional sibcall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60159 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from Andrew Pinski --- Dup of bug 47253. *** This bug has been marked as a duplicate of bug 47253 ***
[Bug target/82668] could use BMI2 rorx for unpacking struct { int a,b }; from a register (SysV ABI)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82668 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/101972] [9/10/11/12 Regression] wrong code at -O2 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101972 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.5 Keywords||wrong-code Summary|wrong code at -O2 on|[9/10/11/12 Regression] |x86_64-linux-gnu|wrong code at -O2 on ||x86_64-linux-gnu
[Bug tree-optimization/101972] wrong code at -O2 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101972 --- Comment #1 from Qirun Zhang --- My bisection points to g:a81e2c6240655f60a49c16e0d8bbfd2ba40bba51
[Bug tree-optimization/101972] New: wrong code at -O2 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101972
Bug ID: 101972
Summary: wrong code at -O2 on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: qrzhang at gatech dot edu
Target Milestone: ---
It appears to be a regression in gcc-9. gcc-8 works fine.
$ gcc-trunk -O2 abc.c ; ./a.out
0
$ gcc-trunk abc.c ; ./a.out
30
$ gcc-8 -O2 abc.c ; ./a.out
30
$ cat abc.c
int a, b, c, d, f;
static short e = 63891;
char g = 30;
unsigned h(i, j) { return i << j; }
int *l(int *);
void m() {
a = 0;
for (; a >= 0; a--) {
int *k = &b;
*k = e < 0;
}
c = b;
l(&c);
}
int *l(int *i) {
d = 2;
for (; d <= 6; d++) {
if (h(d, *i) <= d)
;
else
continue;
g = 0;
return &f;
}
}
int main() {
m();
printf("%d\n", g);
}
[Bug tree-optimization/100457] [meta bug] Enabling O2 vectorization in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100457 Bug 100457 depends on bug 99881, which changed state. Bug 99881 Summary: Regression compare -O2 -ftree-vectorize with -O2 on SKX/CLX https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99881 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug target/99881] Regression compare -O2 -ftree-vectorize with -O2 on SKX/CLX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99881 Hongtao.liu changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #11 from Hongtao.liu --- r12-2549 is reverted due to pr101929 pr101936
[Bug target/101936] [12 Regression] 538.imagick_r -Ofast regression on Kabylake since g:872da9a6f664a06d73c987aa0cb2e5b830158a10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101936 --- Comment #4 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:1db70e61a92978377a648bbd90e383859fc0126b commit r12-3011-g1db70e61a92978377a648bbd90e383859fc0126b Author: liuhongt Date: Tue Aug 17 17:29:06 2021 +0800 Revert "Add the member integer_to_sse to processor_cost as a cost simulation for movd/pinsrd. It will be used to calculate the cost of vec_construct." This reverts commit 872da9a6f664a06d73c987aa0cb2e5b830158a10. PR target/101936 PR target/101929
[Bug target/101929] r12-2549 regress x264_r by 4% on CLX.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101929 --- Comment #4 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:1db70e61a92978377a648bbd90e383859fc0126b commit r12-3011-g1db70e61a92978377a648bbd90e383859fc0126b Author: liuhongt Date: Tue Aug 17 17:29:06 2021 +0800 Revert "Add the member integer_to_sse to processor_cost as a cost simulation for movd/pinsrd. It will be used to calculate the cost of vec_construct." This reverts commit 872da9a6f664a06d73c987aa0cb2e5b830158a10. PR target/101936 PR target/101929
[Bug bootstrap/55886] gcc/configure.ac problems lead to GCC 4.7.2 not building for x86_64-pc-mingw64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55886 jyong at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX CC||jyong at gcc dot gnu.org --- Comment #3 from jyong at gcc dot gnu.org --- x86_64-w64-mingw32 has been the defacto triplet for targeting Windows 64bit Win32API for awhile now. Closing this ticket for now.
[Bug tree-optimization/78579] redundant instruction of the form cmp r0, r0 generated in assembly with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78579 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Component|rtl-optimization|tree-optimization
[Bug tree-optimization/21278] Move maximum out of a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21278 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2016-11-16 00:00:00 |2021-8-18 --- Comment #3 from Andrew Pinski --- No compilers do this ...
[Bug middle-end/76174] Missed VRP optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76174 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2016-08-13 00:00:00 |2021-8-18 --- Comment #3 from Andrew Pinski --- VN can optimizes this away now. So you need "-fno-tree-fre -fno-tree-pre -fno-code-hoisting" to see VRP is not able to optimize this away.
[Bug tree-optimization/65084] Lack of type narrowing/widening inhibits good vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65084 --- Comment #7 from Andrew Pinski --- I see the first testcase produces: .L2: vpand a+32(%rax), %ymm4, %ymm1 vpand a(%rax), %ymm4, %ymm0 addq$64, %rax vpaddw b-32(%rax), %ymm2, %ymm5 vpackuswb %ymm1, %ymm0, %ymm0 vpermq $216, %ymm0, %ymm0 vextracti128$0x1, %ymm0, %xmm1 vpmovsxbw %xmm0, %ymm0 vpmovsxbw %xmm1, %ymm1 vpaddw %ymm3, %ymm0, %ymm0 vpaddw %ymm3, %ymm1, %ymm1 vpaddw %ymm5, %ymm1, %ymm1 vpaddw b-64(%rax), %ymm2, %ymm5 vmovdqa %ymm1, a-32(%rax) vpaddw %ymm5, %ymm0, %ymm0 vmovdqa %ymm0, a-64(%rax) cmpq$2048, %rax jne .L2 While the second one produces: .L6: vmovdqa a(%rax), %ymm3 vpaddw b(%rax), %ymm2, %ymm1 addq$32, %rax vpsllw $8, %ymm3, %ymm0 vpsraw $8, %ymm0, %ymm0 vpaddw %ymm1, %ymm0, %ymm0 vmovdqa %ymm0, a-32(%rax) cmpq$2048, %rax jne .L6
[Bug middle-end/66391] suboptimal code for assignment of SImode struct with bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66391 --- Comment #1 from Andrew Pinski --- So at -O2 we get decent code from GCC 9+ due to store merging which "undoes" what SRA did. But at -O3 the loop gets split into two.
[Bug rtl-optimization/68282] Optimization fails to remove unnecessary sign extension instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68282
--- Comment #4 from Andrew Pinski ---
clang can now produce:
andl$-4, %edi
movltable+4(%rdi), %eax
retq
GCC no longer has the sign extend but still not the above:
shrb$2, %dil
addl$1, %edi
andl$127, %edi
movltable(,%rdi,4), %eax
ret
Trying 8, 9, 11 -> 12:
8: {r90:QI=r95:SI#0 0>>0x2;clobber flags:CC;}
REG_DEAD r95:SI
REG_UNUSED flags:CC
9: {r91:QI=r90:QI+0x1;clobber flags:CC;}
REG_DEAD r90:QI
REG_UNUSED flags:CC
11: {r93:DI=r91:QI#0&0x7f;clobber flags:CC;}
REG_UNUSED flags:CC
REG_DEAD r91:QI
12: r94:SI=[r93:DI*0x4+`table']
REG_DEAD r93:DI
Failed to match this instruction:
(set (reg:SI 94 [ table[_3] ])
(mem:SI (plus:DI (and:DI (plus:DI (mult:DI (subreg:DI (lshiftrt:QI
(subreg:QI (reg:SI 95) 0)
(const_int 2 [0x2])) 0)
(const_int 4 [0x4]))
(const_int 4 [0x4]))
(const_int 508 [0x1fc]))
(symbol_ref:DI ("table") [flags 0x2] )) [1 table[_3]+0 S4 A32]))
Note I think the -4 is incorrect even because I think the upper 24bits of eax
is undefined when comining into the function.
If we do this:
int func(unsigned long c)
{
c&=0xff;
return table[(c >> 2) + 1];
}
We get the correct code even:
andl$252, %edi
movltable+4(%rdi), %eax
ret
[Bug rtl-optimization/64082] virtual register elimination doing bad for local array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64082 Andrew Pinski changed: What|Removed |Added Known to fail||5.4.0 Known to work||6.3.0 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=64164 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #2 from Andrew Pinski --- GCC 6 expansion: (insn 9 8 10 (set (reg:DI 76) (sign_extend:DI (reg/v:SI 74 [ i ]))) /app/example.cpp:7 -1 (nil)) (insn 10 9 11 (set (reg:DI 77) (plus:DI (reg/f:DI 68 virtual-stack-vars) (const_int -16 [0xfff0]))) /app/example.cpp:7 -1 (nil)) (insn 11 10 12 (set (reg:QI 78) (mem/j:QI (plus:DI (reg:DI 77) (reg:DI 76)) [0 A S1 A8])) /app/example.cpp:7 -1 (nil)) GCC 5 expansion: (insn 9 8 10 (set (reg:DI 76) (sign_extend:DI (reg/v:SI 74 [ i ]))) /app/example.cpp:7 -1 (nil)) (insn 10 9 11 (set (reg:DI 78) (plus:DI (reg/f:DI 68 virtual-stack-vars) (const_int -4096 [0xf000]))) /app/example.cpp:7 -1 (nil)) (insn 11 10 12 (set (reg:DI 79) (plus:DI (reg:DI 78) (reg:DI 76))) /app/example.cpp:7 -1 (nil)) (insn 12 11 13 (set (reg/f:DI 77) (reg:DI 79)) /app/example.cpp:7 -1 (nil)) (insn 13 12 14 (set (reg:QI 80) (mem/j:QI (plus:DI (reg/f:DI 77) (const_int 4080 [0xff0])) [0 A S1 A8])) /app/example.cpp:7 -1 (nil)) I think the patch which fixed this was one of the patches for PR 64164. So fixed.
[Bug target/101971] M68k: ICE: Tried to convert PC relative branch to absolute jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101971 --- Comment #4 from Giulio Benetti --- Package is libmodsecurity, not bullet.
[Bug analyzer/101837] [11/12 Regression] ICE with -O3 -fsanitize=undefined -fanalyzer since r11-7941-ge4bb1bd60a9fd1be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101837 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-08-18 --- Comment #2 from David Malcolm --- Thanks for filing this; I'm testing a fix.
[Bug analyzer/101875] [12 Regression] ICE: Segmentation fault (in c_tree_printer)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101875 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from David Malcolm --- Thanks for filing this. I'm testing a fix.
[Bug target/101971] M68k: ICE: Tried to convert PC relative branch to absolute jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101971 --- Comment #3 from Giulio Benetti --- Thank you for pointing, I give it a try, it seems to that one. Also the classic work-around disabling optimization doesn't work and I was trying other workaround. But I try that patch now. Thanks again!
[Bug target/101971] M68k: ICE: Tried to convert PC relative branch to absolute jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101971 --- Comment #2 from Andrew Pinski --- Or a buildroot issue of trying to use elf2flt : https://buildroot.uclibc.narkive.com/EOUb7PvD/patch-v2-m68k-disable-br2-binfmt-flat-sep-data-for-coldfire
[Bug target/101971] M68k: ICE: Tried to convert PC relative branch to absolute jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101971 Andrew Pinski changed: What|Removed |Added Target||m68k-linux Component|c++ |target --- Comment #1 from Andrew Pinski --- This sounds more like a binutils bug than GCC bug.
[Bug c++/101971] New: M68k: ICE: Tried to convert PC relative branch to absolute jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101971 Bug ID: 101971 Summary: M68k: ICE: Tried to convert PC relative branch to absolute jump Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: giulio.benetti at benettiengineering dot com Target Milestone: --- When building package bullet on buildroot we get this error: ''' libtool: compile: /home/giuliobenetti/br_reproduce/b92980a563fe7ee331e70f288ce041be0bf29d40/output/host/bin/m68k-linux-g++ -DHAVE_CONFIG_H -I. -std=c++11 -I.. -g -I../others -fPIC -O3 -I../headers -DCURL_STATICLIB -I/home/giuliobenetti/br_reproduce/b92980a563fe7ee331e70f288ce041be0bf29d40/output/host/m68k-buildroot-uclinux-uclibc/sysroot/usr/bin/../../usr/include -DWITH_CURL_SSLVERSION_TLSv1_2 -DWITH_CURL -I/home/giuliobenetti/br_reproduce/b92980a563fe7ee331e70f288ce041be0bf29d40/output/host/m68k-buildroot-uclinux-uclibc/sysroot/usr/bin/../../usr/include -DPCRE_STATIC -I/home/giuliobenetti/br_reproduce/b92980a563fe7ee331e70f288ce041be0bf29d40/output/host/m68k-buildroot-uclinux-uclibc/sysroot/usr/bin/../../usr/include/libxml2 -DWITH_LIBXML2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g0 -fno-dwarf2-cfi-asm -Wl,-elf2flt -fno-dwarf2-cfi-asm -Wl,-elf2flt -c variables/xml.cc -o variables/libmodsecurity_la-xml.o /tmp/ccU6wDwq.s: Assembler messages: /tmp/ccU6wDwq.s: Fatal error: Tried to convert PC relative branch to absolute jump make[5]: *** [Makefile:1886: parser/libmodsecurity_la-seclang-scanner.lo] Error 1 make[5]: *** Waiting for unfinished jobs /tmp/cckb1Yg3.s: Assembler messages: /tmp/cckb1Yg3.s: Fatal error: Tried to convert PC relative branch to absolute jump make[5]: *** [Makefile:1879: parser/libmodsecurity_la-seclang-parser.lo] Error 1 make[4]: *** [Makefile:3282: all-recursive] Error 1 make[3]: *** [Makefile:1033: all] Error 2 make[2]: *** [Makefile:1032: all-recursive] Error 1 make[1]: *** [package/pkg-generic.mk:270: /home/giuliobenetti/br_reproduce/b92980a563fe7ee331e70f288ce041be0bf29d40/output/build/libmodsecurity-3.0.5/.stamp_built] Error 2 make: *** [Makefile:23: _all] Error 2 ''' To reproduce it: ''' # git clone git://git.busybox.net/buildroot # wget https://git.busybox.net/buildroot-test/tree/utils/br-reproduce-build - modify BASE_GIT=... with your buildroot path in br-reproduce-build then: # chmod a+x br-reproduce-build # ./br-reproduce-build b92980a563fe7ee331e70f288ce041be0bf29d40 '''
[Bug ada/101970] New: [11 regression] ICE on 'Enum_Rep for the enum that filled its representation range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101970 Bug ID: 101970 Summary: [11 regression] ICE on 'Enum_Rep for the enum that filled its representation range Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: demoonlit at panathenaia dot halfmoon.jp Target Milestone: --- Created attachment 51322 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51322&action=edit full test code Perhaps this is a regression by fixing the bug 101094. 'Enum_Rep causes GNAT bug Box, with the enum type containing the number of elements to fill just its (signed?) representation range. Thanks. test code Here is the abbreviated test code. The full code is attached. with Ada.Integer_Text_IO; with Ada.Text_IO; procedure test_enumrep2 is type T is (E80, ..., E00, ..., E7F); -- 256 elements for T use (E80 => -16#80#, ..., E00 => 16#00#, ..., E7F => 16#7F#); -- -128 to +127 for T'Size use 8; procedure P (X : T); pragma No_Inline (P); procedure P (X : T) is begin Ada.Integer_Text_IO.Put (T'Pos (X)); Ada.Integer_Text_IO.Put (T'Enum_Rep (X)); -- GNAT BUG DETECTED Ada.Text_IO.New_Line; end P; begin P (T'First); P (T'Last); end test_enumrep2; gcc-10.2.0 % /opt/ytomino/gcc-10.2.0/bin/gnatmake --version GNATMAKE 10.2.0 Copyright (C) 1995-2020, Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. % /opt/ytomino/gcc-10.2.0/bin/gnatmake test_enumrep2.adb gcc -c test_enumrep2.adb gnatbind -x test_enumrep2.ali gnatlink test_enumrep2.ali % ./test_enumrep2 0 -128 255127 It's fine. gcc-11.1.0 % /opt/ytomino/gcc-11.1.0/bin/gnatmake --version GNATMAKE 11.1.0 Copyright (C) 1995-2021, Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. % /opt/ytomino/gcc-11.1.0/bin/gnatmake test_enumrep2.adb gcc -c test_enumrep2.adb gnatbind -x test_enumrep2.ali gnatlink test_enumrep2.ali % ./test_enumrep2 0128 255127 Note, T'Enum_Rep(T'First) returns the unsigned value in gcc-11.1 because bug 101094. gcc-11.2.0 % /opt/ytomino/gcc-11.2.0/bin/gnatmake --version GNATMAKE 11.2.0 Copyright (C) 1995-2021, Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. % /opt/ytomino/gcc-11.2.0/bin/gnatmake test_enumrep2 gcc -c test_enumrep2.adb +===GNAT BUG DETECTED==+ | 11.2.0 (x86_64-linux-gnu) GCC error: | | in build_binary_op, at ada/gcc-interface/utils2.c:1164 | | Error detected at test_enumrep2.adb:107:44 | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). test_enumrep2.adb compilation abandoned gnatmake: "test_enumrep2.adb" compilation error
[Bug tree-optimization/73457] Missed optimizations: count_if on std::array of constants.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73457 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #3 from Andrew Pinski --- GCC 8+ can handle this at -O3 and above because we can vectorize the loop (which GCC 7 could not do, I have not looked into why) so DOM is able to optimize it after unrolling. GCC 10+ can handle this at -O3 -fno-tree-loop-vectorize (with SLP still happening) because of r10-1420. I do think we should be able to optimize this for -O2 though.
[Bug c/101953] bug on the default cast operator from double to unsigned short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
--- Comment #28 from Jakub Jelinek ---
That flag does work:
gcc -fsanitize=float-cast-overflow -Wall -o pr101953{,.c} -lm; ./pr101953
pr101953.c:12:11: runtime error: -32000 is outside the range of representable
values of type 'unsigned int'
-32000 vs -32000
Sanitizers are runtime instrumentation, so you actually need to run the
program.
[Bug c/101953] bug on the default cast operator from double to unsigned short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
--- Comment #27 from Harald van Dijk ---
(In reply to jos...@codesourcery.com from comment #25)
> The option to use to detect this is -fsanitize=float-cast-overflow (note:
> I haven't tested if it detects this particular case). As per the manual:
> "Unlike other similar options, @option{-fsanitize=float-cast-overflow} is
> not enabled by @option{-fsanitize=undefined}.". (Annex F makes the result
> an unspecified value with "invalid" raised, instead of being undefined
> behavior, which justifies not including it in -fsanitize=undefined by
> default.
Have just tested that -fsanitize=float-cast-overflow does indeed catch this
case. Thanks for the explanation, that makes sense.
The fact that it's not included by -fsanitize=undefined even in compilations
where Annex F is not followed or does not apply is a bit weird, but changing it
to be included was bug #100591, closed as invalid; I won't open a new bug
asking for the same thing again.
(In reply to M W from comment #24)
> I know it is documented as "undefined," but it is also unexpected without
> even a warning.
Martin Sebor requested opening a new bug if you'd like to see a compile-time
warning for this, rather than tracking that as part of this bug.
(In reply to M W from comment #26)
> pi@raspberrypi:~ $ gcc -fsanitize=float-cast-overflow -Wall -o badpi badpi.c
> -lm
> pi@raspberrypi:~ $
>
> That flag doesn't work
The flag does work, but it's a runtime warning, not a compile-time warning. Run
badpi and you should see it.
[Bug c/101953] bug on the default cast operator from double to unsigned short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953 --- Comment #26 from M W --- pi@raspberrypi:~ $ gcc -fsanitize=float-cast-overflow -Wall -o badpi badpi.c -lm pi@raspberrypi:~ $ That flag doesn't work
[Bug tree-optimization/73457] Missed optimizations: count_if on std::array of constants.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73457
--- Comment #2 from Andrew Pinski ---
testcase:
#include
#include
enum event {
stuff,
crap
};
template
auto count_event(event e, Cont const& events) {
return std::count(events.begin(), events.end(), e);
}
int main() {
std::array events = { stuff, crap, stuff, stuff };
return count_event(stuff, events);
}
[Bug middle-end/55771] Negation and type conversion incorrectly exchanged
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55771 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #13 from Andrew Pinski --- Fixed for GCC 4.9.0+ by r0-124269 which references this PR but for some reason it does not show up in the bugzilla.
[Bug rtl-optimization/29144] Missing if-conversion. If-conversion dependent on operand order. Inconsistent if-conversion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29144 Andrew Pinski changed: What|Removed |Added Known to work||10.1.0, 8.1.0 --- Comment #3 from Andrew Pinski --- For i686 (-m32), GCC does cmov for all functions since GCC 8.1.0; with GCC 10+ having the best code gen so far (there is another bug report about improving similar functions already). For x86_64, GCC does cmov for all functions since GCC 4.6.0
[Bug debug/101905] [9/10/11/12 Regression] Missed debug information for global register variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101905
--- Comment #6 from Jakub Jelinek ---
--- gcc/dwarf2out.c.jj 2021-08-17 09:25:08.196923026 +0200
+++ gcc/dwarf2out.c 2021-08-18 23:18:56.284227245 +0200
@@ -24477,7 +24477,9 @@ gen_variable_die (tree decl, tree origin
{
if (early_dwarf)
add_pubname (decl_or_origin, var_die);
- else
+ if (!early_dwarf
+ || (DECL_HARD_REGISTER (decl_or_origin)
+ && TREE_STATIC (decl_or_origin)))
add_location_or_const_value_attribute (var_die, decl_or_origin,
decl == NULL);
}
isn't sufficient because add_location_or_const_value_attribute has an early
exit for early_dwarf...
[Bug analyzer/101962] Analyzer NULL false positive with pointer manipulation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101962 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-08-18 --- Comment #1 from David Malcolm --- Am testing a fix.
[Bug tree-optimization/68557] Missed x86 peephole optimization for multiplying by a bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68557 Andrew Pinski changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 97743 has been marked as a duplicate of this bug. ***
[Bug middle-end/97743] Failure to optimize boolean multiplication to select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97743 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Andrew Pinski --- This is really a dup of bug 68557. *** This bug has been marked as a duplicate of bug 68557 ***
[Bug target/82680] Use cmpXXss and cmpXXsd for setcc boolean compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82680 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) I should say this is with the following options: /O2 /std:c++latest /arch:AVX2
[Bug debug/101905] [9/10/11/12 Regression] Missed debug information for global register variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101905 --- Comment #5 from Jakub Jelinek --- assemble_decl isn't even called for DECL_HARD_REGISTER global vars: if (DECL_HARD_REGISTER (node->decl) || DECL_HAS_VALUE_EXPR_P (node->decl)) continue; if (node->definition) changed |= node->assemble_decl (); else assemble_undefined_decl (node->decl); and even if it would be, it wouldn't get into the spot that calls the debug hook: /* Hard register vars do not need to be output. */ if (DECL_HARD_REGISTER (decl)) return false; ... debug_hooks->late_global_decl (decl); return true; So, either we should make sure that those vars get DW_AT_location already during early debug (IMHO best, as the location should be known then already), or we need to call late_global_decl on those somewhere else.
[Bug target/82680] Use cmpXXss and cmpXXsd for setcc boolean compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82680 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-08-18 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- MSVC (in 64bit 19.30.30423.0) does: vucomisd xmm0, xmm1 jp SHORT $LN3@g jne SHORT $LN3@g mov eax, 1 ret 0 $LN3@g: xor eax, eax ret 0 MSVC (32bit, 19.30.30423.0) does: vmovsd xmm0, QWORD PTR _x$[esp-4] vucomisd xmm0, QWORD PTR _y$[esp-4] mov edx, 1 lahf xor ecx, ecx testah, 68 ; 0044H cmovnp ecx, edx mov eax, ecx ; Line 5 ret 0 I don't know why there is a difference as both are the same version. Confirmed.
[Bug debug/101905] [9/10/11/12 Regression] Missed debug information for global register variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101905 Jakub Jelinek changed: What|Removed |Added Summary|Missed debug information|[9/10/11/12 Regression] |for global register |Missed debug information |variable|for global register ||variable Target Milestone|--- |9.5 --- Comment #4 from Jakub Jelinek --- Started with r6-2867-g5fc6ae7dab2809a4607de11b2c4e48752176a562
[Bug c/101953] bug on the default cast operator from double to unsigned short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
--- Comment #25 from joseph at codesourcery dot com ---
The option to use to detect this is -fsanitize=float-cast-overflow (note:
I haven't tested if it detects this particular case). As per the manual:
"Unlike other similar options, @option{-fsanitize=float-cast-overflow} is
not enabled by @option{-fsanitize=undefined}.". (Annex F makes the result
an unspecified value with "invalid" raised, instead of being undefined
behavior, which justifies not including it in -fsanitize=undefined by
default. That means that each time such a conversion occurs in the
abstract machine, some value representable in the result type must be
produced; it can't be a "wobbly" value where different uses of the result
of the conversion, that was only executed once in the abstract machine,
act like different values or like values not of the result type. If such
a conversion does produce a wobbly value, that's a bug; see bug 93806
comments 27 to 29 for examples of such a bug.)
[Bug debug/101905] Missed debug information for global register variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101905 --- Comment #3 from Yuri Karlsbrun --- With the gcc-5.3 correct debug info for global register variable is written, and variable is visible to gdb gcc -v Using built-in specs. COLLECT_GCC=/tools/oss/packages/x86_64-centos7/gcc/5.3.0/bin/gcc COLLECT_LTO_WRAPPER=/tools/oss/packages/x86_64-rhel7/gcc/5.3.0/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../../gcc-5.3.0/configure --prefix=/tools/oss/packages/x86_64-centos7/gcc/5.3.0 --with-gnu-as --with-as=/tools/oss/packages/x86_64-centos7/binutils/2.25/bin/as --with-gnu-ld --with-ld=/tools/oss/packages/x86_64-centos7/binutils/2.25/bin/ld --with-mpc=/tools/oss/packages/x86_64-centos7/mpc/1.0.3 --with-mpfr=/tools/oss/packages/x86_64-centos7/mpfr/3.1.2 --enable-languages=c,c++,objc,java,fortran --enable-symvers=gnu Thread model: posix gcc version 5.3.0 (GCC) < 1><0x0075>DW_TAG_variable DW_AT_name regVar DW_AT_decl_file 0x0001 /projects/play/ev.c DW_AT_decl_line 0x0001 DW_AT_type <0x0082> DW_AT_external yes(1) DW_AT_location len 0x0001: 5f: DW_OP_reg15
[Bug testsuite/101969] [10 regression] reactivated test case gcc.dg/pr78213.c in r12-10042 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101969 seurer at gcc dot gnu.org changed: What|Removed |Added Summary|[12 regression] reactivated |[10 regression] reactivated |test case gcc.dg/pr78213.c |test case gcc.dg/pr78213.c |in r12-10042 fails |in r12-10042 fails CC||tschwinge at gcc dot gnu.org Version|12.0|10.3.1 --- Comment #1 from seurer at gcc dot gnu.org --- I noticed this with gcc 10 but it looks like it was also activated for gcc 9 and gcc 11.
[Bug testsuite/101969] New: [12 regression] reactivated test case gcc.dg/pr78213.c in r12-10042 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101969 Bug ID: 101969 Summary: [12 regression] reactivated test case gcc.dg/pr78213.c in r12-10042 fails Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:e475b9088b790ba1a71870f18f431aad23f5e3eb, r10-10042 make -k check-gcc RUNTESTFLAGS="dg.exp=gcc.dg/pr78213.c" FAIL: gcc.dg/pr78213.c -fself-test (test for warnings, line ) # of expected passes1 # of unexpected failures1 Executing on host: /home3/seurer/gcc/git/build/gcc-10-test/gcc/xgcc -B/home3/seurer/gcc/git/build/gcc-10-test/gcc/ /home/seurer/gcc/git/gcc-10-test/gcc/testsuite/gcc.dg/pr78213.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -fself-test=/home/seurer/gcc/git/gcc-10-test/gcc/testsuite/selftests -S -o pr78213.s(timeout = 300) spawn -ignore SIGHUP /home3/seurer/gcc/git/build/gcc-10-test/gcc/xgcc -B/home3/seurer/gcc/git/build/gcc-10-test/gcc/ /home/seurer/gcc/git/gcc-10-test/gcc/testsuite/gcc.dg/pr78213.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -fself-test=/home/seurer/gcc/git/gcc-10-test/gcc/testsuite/selftests -S -o pr78213.s cc1: note: self-tests are not enabled in this build FAIL: gcc.dg/pr78213.c -fself-test (test for warnings, line ) commit e475b9088b790ba1a71870f18f431aad23f5e3eb (HEAD, refs/bisect/bad) Author: Thomas Schwinge Date: Tue Aug 17 08:45:18 2021 +0200 Restore 'gcc.dg/pr78213.c' testing
[Bug gcov-profile/89961] When "--intermediate-format" is used "--preserve-paths"/"--hash-filenames" is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961 --- Comment #20 from xaizek --- The patch works! I think you actually implemented behaviour of `-p` for `-l` (you hash path in the code and don't process includes). `-l` doesn't seem to make much sense for JSON, because all includes will be in the same object anyway, while `-p` does. Thank you for making it work. I really think that's what users of gcov expect from those options. By the way, since this is another change related to automatic invocation of gcov. Just as lcov does it, I recently started to parse output of `gcov --help` with regexes in uncov to detect JSON support. This works, but it would be more reliable if gcov could print its capabilities in some fixed form to don't make tools do such things. Of course existing parsing code won't go away, but it might become a fallback for a more robust path.
[Bug bootstrap/101966] The specified --host is not always passed correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101966
--- Comment #4 from Andrew Pinski ---
And then I just do for building:
PMAKE="make -j24"
$PMAKE all-host
make install-host DESTDIR=${SYSROOT}
[Bug preprocessor/101968] Preprocessor line number statements become wrong after '#include'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101968 --- Comment #1 from Aaron Hill --- Created attachment 51321 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51321&action=edit Add the empty 'foo.h' file used by 'test.cpp' This file contains a blank line, to allow me to attach it to this issue. However, the issue can also be reproduced with a completely empty file named 'foo.h'
[Bug bootstrap/101966] The specified --host is not always passed correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101966
--- Comment #3 from Andrew Pinski ---
This configure works for me:
TOP=`pwd`
target=aarch64-marvell-linux-gnu
GCC_CONFIG_ARGS="--disable-fixed-point --without-ppl --without-python
--disable-werror --enable-plugins --with-system-zlib --with-system-zstd
--enable-initfini-array --disable-source-highlight"
ENABLE_CHECKING=""
languages="c,c++,fortran"
extra_config="--disable-sim --enable-symvers=gnu --enable-__cxa_atexit""
SYSROOT=${prefix}/${target}/sys-root
libs=${TOP}/libs-${target}
CC="$target-gcc -L${libs}/lib -I${libs}/include" \
CXX="$target-g++ -L${libs}/lib -I${libs}/include" \
${TOP}/src/configure $GCC_CONFIG_ARGS $ENABLE_CHECKING $extra_config
--target=${target} --host=${target} --enable-languages=${languages}
--prefix=/usr --with-sysroot=/ --with-build-sysroot=${SYSROOT}
--with-pkgversion="$pkgversion" --with-bugurl="$bugurl"
--with-libexpat-prefix=${libs}
[Bug preprocessor/101968] New: Preprocessor line number statements become wrong after '#include'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101968 Bug ID: 101968 Summary: Preprocessor line number statements become wrong after '#include' Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: aaron.hill at wdc dot com Target Milestone: --- Created attachment 51320 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51320&action=edit Add the 'test.cpp' file needed to reproduce the bug When running the preprocessor with 'cpp -nostdinc test.cpp', the following output is generated: ``` # 1 "test.cpp" # 1 "" # 1 "" # 1 "test.cpp" # 327681 "test.cpp" # 1 "foo.h" 1 # 327681 "test.cpp" 2 MISSING_DEF ``` The file 'test.cpp' (attached to this issue) consists of 327,680 empty lines, followed by: ``` #include "foo.h" MISSING_DEF ``` The file 'foo.h' is empty. Notice how the lines `# 327681 "test.cpp"` and `# 327681 "test.cpp" 2` both refer to the same line number (the line number of the '#include' statement), despite the fact that we have exited the file 'foo.h', and should now be on the next line (line 327682). The flag '-nostdinc' is needed to prevent the preprocessor from injecting an include of '/usr/include/stdc-predef.h', which breaks the conditions needed to reproduce the bug. Alternatively, running `arm-none-eabi-cpp test.cpp` will also reproduce the bug, since that toolchain doesn't have 'stdc-predef.h'. When run through the compiler, this produces an error message on the wrong line (using 'g++-11 -nostdinc test.cpp'): ``` test.cpp:327681:1: error: ‘MISSING_DEF’ does not name a type 327681 | #include "foo.h" | ^~~ ``` This issue occurs since GCC 9 (I haven't tested earlier versions), and still occurs as of the latest commit (1b34248527472496ca3fe2a07183beac8cf69041 at the time of writing). This bug is caused by a decrement of `pfile->line_table->highest_location--` in `libcpp/files.c` (https://github.com/gcc-mirror/gcc/blob/f0fca213bc52644ba896da622b35842a6157bd98/libcpp/files.c#L988). If reading the line following the '#include' caused us to create a new line map, then 'pfile->line_table->highest_location' will be equal to 'LINEMAPS_LAST_ORDINARY_MAP(pfile->line_table)->start_location. Therefore, decrementing 'pfile->line_table->highest_location' causes the location to move outside of the correct line map. Reproducing this bug in actual code is very difficult, but has happened on several occasions. In this reproducer, the large number of blank lines causes 'linemap_line_start' to create a new line map, due to the condition 'line_delta * map->m_column_and_range_bits > 1000' (https://github.com/gcc-mirror/gcc/blob/f0fca213bc52644ba896da622b35842a6157bd98/libcpp/line-map.c#L775). However, there are several other conditions that can cause 'linemap_line_start' to create a new line map - triggering one of them on the line immediately following an '#include' should also cause this bug to occur. In my local tests, changing 'decrement' to also check that `pfile->line_table->highest_location != LINEMAPS_LAST_ORDINARY_MAP(pfile->line_table)->start_location` is enough to avoid the bug. However, I hadn't looked at the preprocessor code before investigating this bug, so I'm not sure if this change will have any other consequences.
[Bug fortran/101967] Implement F2018:C949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101967 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-08-18 Priority|P3 |P4 --- Comment #1 from kargl at gcc dot gnu.org --- Affects all versions where coarray are permitted.
[Bug fortran/101967] New: Implement F2018:C949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101967
Bug ID: 101967
Summary: Implement F2018:C949
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: kargl at gcc dot gnu.org
Target Milestone: ---
The source-expr in an ALLOCATE statement cannot
have a type with an coarray ultimate component.
This patch catches the issue.
diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 16502da001d..03d250985d7 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -4373,7 +4383,7 @@ gfc_match_allocate (void)
if (!gfc_type_compatible (&tail->expr->ts, &ts))
{
gfc_error ("Type of entity at %L is type incompatible with "
-"typespec", &tail->expr->where);
+"type-spec", &tail->expr->where);
goto cleanup;
}
@@ -4381,7 +4391,7 @@ gfc_match_allocate (void)
if (ts.kind != tail->expr->ts.kind && !UNLIMITED_POLY (tail->expr))
{
gfc_error ("Kind type parameter for entity at %L differs from "
-"the kind type parameter of the typespec",
+"the kind type parameter of the type-spec",
&tail->expr->where);
goto cleanup;
}
@@ -4476,7 +4486,7 @@ alloc_opt_list:
/* The next 2 conditionals check C631. */
if (ts.type != BT_UNKNOWN)
{
- gfc_error ("SOURCE tag at %L conflicts with the typespec at %L",
+ gfc_error ("SOURCE tag at %L conflicts with the type-spec at %L",
&tmp->where, &old_locus);
goto cleanup;
}
@@ -4487,6 +4497,8 @@ alloc_opt_list:
&tmp->where))
goto cleanup;
+
+
source = tmp;
tmp = NULL;
saw_source = true;
@@ -4536,6 +4548,17 @@ alloc_opt_list:
if (gfc_match (" )%t") != MATCH_YES)
goto syntax;
+ /* C949 (R930) The declared type of source-expr shall not have a
+ coarray ultimate component. */
+ if (source
+ && source->ts.type == BT_DERIVED
+ && source->ts.u.derived->attr.coarray_comp)
+{
+ gfc_error ("Declared type of source expression at %L has a coarray "
+"ultimate component", &source->where);
+ goto cleanup;
+}
+
/* Check F08:C637. */
if (source && mold)
{
diff --git a/gcc/testsuite/gfortran.dg/allocate_alloc_opt_4.f90
b/gcc/testsuite/gfortran.dg/allocate_alloc_opt_4.f90
index ee6c3635912..b98352a9104 100644
--- a/gcc/testsuite/gfortran.dg/allocate_alloc_opt_4.f90
+++ b/gcc/testsuite/gfortran.dg/allocate_alloc_opt_4.f90
@@ -15,7 +15,7 @@ program a
allocate(i(4), source=42, source=n) ! { dg-error "Redundant SOURCE tag
found" }
- allocate(integer(4) :: i(4), source=n) ! { dg-error "conflicts with the
typespec" }
+ allocate(integer(4) :: i(4), source=n) ! { dg-error "conflicts with the
type-spec" }
allocate(i(4), j(n), source=n) ! { dg-error "Fortran 2008: SOURCE tag at .1.
with more than a single allocate object" }
diff --git a/gcc/testsuite/gfortran.dg/allocate_derived_1.f90
b/gcc/testsuite/gfortran.dg/allocate_derived_1.f90
index d2c65ffa38b..12633eb5dc7 100644
--- a/gcc/testsuite/gfortran.dg/allocate_derived_1.f90
+++ b/gcc/testsuite/gfortran.dg/allocate_derived_1.f90
@@ -34,16 +34,16 @@
allocate(t3 :: x(4))
allocate(tx :: x(5)) ! { dg-error "Error in type-spec at" }
allocate(u0 :: x(6)) ! { dg-error "may not be ABSTRACT" }
- allocate(v1 :: x(7)) ! { dg-error "is type incompatible with typespec" }
+ allocate(v1 :: x(7)) ! { dg-error "is type incompatible with type-spec" }
allocate( y(1))
- allocate(t1 :: y(2)) ! { dg-error "is type incompatible with typespec" }
+ allocate(t1 :: y(2)) ! { dg-error "is type incompatible with type-spec" }
allocate(t2 :: y(3))
- allocate(t3 :: y(3)) ! { dg-error "is type incompatible with typespec" }
+ allocate(t3 :: y(3)) ! { dg-error "is type incompatible with type-spec" }
allocate( z(1))
- allocate(t1 :: z(2)) ! { dg-error "is type incompatible with typespec" }
- allocate(t2 :: z(3)) ! { dg-error "is type incompatible with typespec" }
+ allocate(t1 :: z(2)) ! { dg-error "is type incompatible with type-spec" }
+ allocate(t2 :: z(3)) ! { dg-error "is type incompatible with type-spec" }
allocate(t3 :: z(4))
end
diff --git a/gcc/testsuite/gfortran.dg/f2018c949.f90
b/gcc/testsuite/gfortran.dg/f2018c949.f90
new file mode 100644
index 000..14a1facbd73
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/f2018c949.f90
@@ -0,0 +1,13 @@
+! { dg-do compile }
+! { dg-options "-fcoarray=single" }
+program main
+ type :: type
+integer, allocatable :: a[:]
+ end type
+
+ type(type) :: x
+ class(*), allocatable :: y
+
+ allocate(x%a[*])
+
[Bug c/101966] The specified --host is not always passed correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101966 --- Comment #2 from Andreas Schwab --- Why are you overriding CC_FOR_TARGET? All build modules need to be executable on the build system, so host=build is correct. Where does -mtune=cortex-a53 come from?
[Bug testsuite/101963] New test case gfortran.dg/nothing-1.f90 in r12-2992 doesn't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101963 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Tobias Burnus --- FIXED. Sorry for the breakage.
[Bug testsuite/101963] New test case gfortran.dg/nothing-1.f90 in r12-2992 doesn't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101963 --- Comment #1 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:f0fca213bc52644ba896da622b35842a6157bd98 commit r12-3009-gf0fca213bc52644ba896da622b35842a6157bd98 Author: Tobias Burnus Date: Wed Aug 18 21:47:04 2021 +0200 Fortran: Add OpenMP's nothing directive support (con't) Fix directory to enable -fopenmp processing. gcc/testsuite/ PR testsuite/101963 * gfortran.dg/nothing-1.f90: Moved to ... * gfortran.dg/gomp/nothing-1.f90: ... here. * gfortran.dg/nothing-2.f90: Moved to ... * gfortran.dg/gomp/nothing-2.f90: ... here; avoid $ issue in $OMP in dg-error.
[Bug c/101966] The specified --host is not always passed correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101966 --- Comment #1 from frans at fransdb dot nl --- Created attachment 51319 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51319&action=edit partial listing of compiler
[Bug c/101966] New: The specified --host is not always passed correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101966
Bug ID: 101966
Summary: The specified --host is not always passed correctly
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: frans at fransdb dot nl
Target Milestone: ---
Host: aarch64 (cortex-a53)
Target: same
Build: x86-64
Issue while trying to compile the second stage of gcc-11.2, to be used on an
aarch64 architecture.
Used configure command:
--prefix=/usr \
--host=aarch64-cross-linux-gnueabi \
--build=x86_64-suse-linux \
CC_FOR_TARGET=aarch64-cross-linux-gnueabi-gcc \
--enable-languages=c,c++\
--disable-multilib \
--disable-nls \
--disable-decimal-float \
--disable-libatomic \
--disable-libgomp \
--disable-libquadmath \
--disable-libssp\
--disable-libvtv\
--disable-libstdcxx
First some listing:
gcc -c -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -Wno-overlength-strings
-pedantic -Wno-long-long -DHAVE_CONFIG_H -I.
-I/mnt/lfs/sources-base/gcc-11.2.0/fixincludes -I../include
-I/mnt/lfs/sources-base/gcc-11.2.0/fixincludes/../include
/mnt/lfs/sources-base/gcc-11.2.0/fixincludes/fixopts.c
gcc -o fixincl fixincl.o fixtests.o fixfixes.o server.o procopen.o fixlib.o
fixopts.o ../libiberty/libiberty.a
echo timestamp > full-stamp
srcdir="/mnt/lfs/sources-base/gcc-11.2.0/fixincludes" /bin/sh
/mnt/lfs/sources-base/gcc-11.2.0/fixincludes/mkfixinc.sh
aarch64-cross-linux-gnueabi
sed -e 's/@gcc_version@/11.2.0/' < mkheaders.almost > mkheadersT
mv -f mkheadersT mkheaders
make[2]: Leaving directory
'/mnt/lfs/sources-base/gcc-11.2.0/gcc-build/build-x86_64-suse-linux/fixincludes'
mkdir -p -- build-x86_64-suse-linux/libcpp
Configuring in build-x86_64-suse-linux/libcpp
configure: creating cache ./config.cache
checking build system type... x86_64-suse-linux-gnu
checking host system type... x86_64-suse-linux-gnu
checking target system type... aarch64-cross-linux-gnueabi
checking whether make sets $(MAKE)... yes
checking for a BSD-compatible install... /usr/bin/install -c
.
config.status: executing depdir commands
mkdir -p -- .deps
make[2]: Entering directory
'/mnt/lfs/sources-base/gcc-11.2.0/gcc-build/build-x86_64-suse-linux/libcpp'
g++ -I/mnt/lfs/sources-base/gcc-11.2.0/libcpp -I.
-I/mnt/lfs/sources-base/gcc-11.2.0/libcpp/../include
-I/mnt/lfs/sources-base/gcc-11.2.0/libcpp/include -mtune=cortex-a53 -W -Wall
-Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic
-Wno-long-long -fno-exceptions -fno-rtti
-I/mnt/lfs/sources-base/gcc-11.2.0/libcpp -I.
-I/mnt/lfs/sources-base/gcc-11.2.0/libcpp/../include
-I/mnt/lfs/sources-base/gcc-11.2.0/libcpp/include-c -o charset.o -MT
charset.o -MMD -MP -MF .deps/charset.Tpo
/mnt/lfs/sources-base/gcc-11.2.0/libcpp/charset.c
cc1plus: error: bad value ('cortex-a53') for '-mtune=' switch
cc1plus: note: valid arguments to '-mtune=' switch are: nocona core2 nehalem
corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2
broadwell skylake skylake-avx512 cannonlake icelake-client rocketlake
icelake-server cascadelake tigerlake cooperlake sapphirerapids alderlake
bonnell atom silvermont slm goldmont goldmont-plus tremont knl knm intel x86-64
eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3
opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1
bdver2 bdver3 bdver4 znver1 znver2 znver3 btver1 btver2 generic native
make[2]: *** [Makefile:226: charset.o] Error 1
make[2]: Leaving directory
'/mnt/lfs/sources-base/gcc-11.2.0/gcc-build/build-x86_64-suse-linux/libcpp'
make[1]: *** [Makefile:2898: all-build-libcpp] Error 2
make[1]: Leaving directory '/mnt/lfs/sources-base/gcc-11.2.0/gcc-build'
make: *** [Makefile:947: all] Error 2
The above is right, the only thing is that the wrong host has been forwarded.
On most others it is:
Configuring in ./gcc
configure: creating cache ./config.cache
checking build system type... x86_64-suse-linux-gnu
checking host system type... aarch64-cross-linux-gnueabi
checking target system type... aarch64-cross-linux-gnueabi
It goes wrong at this point:
mkdir -p -- build-x86_64-suse-linux/libiberty
Configuring in build-x86_64-suse-linux/libiberty
configure: creating cache ./config.cache
checking whether to enable maintainer-specific portions of Makefiles... no
checking for makeinfo... makeinfo --split-size=500
checking for perl... perl
checking build system type... x86_64-suse-linux-gnu
checking host system type... x86_64-suse-linux-gnu
checking for x86_64-suse-linux-ar... ar
The wrong host system is mentioned, which is passed on to fixinclude with the
resulting err
[Bug middle-end/101955] (signed<<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101955 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- (In reply to Andreas Schwab from comment #2) > If you want to be agressive you can optimize f to return 0. In the middle-end? No, whether it is well defined or undefined depends heavily on the C/C++ version. At least ubsan flags it only with C99..C2X, not in C89 nor any C++ versions for b 1. For b -1 flaged in C99..C2X and C++11..C++17. C89, C++98 and C++20..C++23 accept that. Similarly for b > 1, flagged in C99..C2x and C++11..C++17 only.
[Bug jit/100613] libgccjit should produce dylib on macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100613 --- Comment #3 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:08defd9c4e4f8dc428f2f490705ab816af81a03d commit r12-3008-g08defd9c4e4f8dc428f2f490705ab816af81a03d Author: Iain Sandoe Date: Thu Aug 5 09:55:19 2021 +0100 Darwin, jit: Fix build [PR100613]. The generic unix build is not completely suitable for Darwin platforms: * It is a convention to encode the library versioning in the binary and to have only one level of symlink for the installed files. This needs to be applied to the installation too. * The library needs to be built with its correct install name so that two-level library naming works. * The extension for shared libraries should be .dylib Signed-off-by: Iain Sandoe PR jit/100613 - libgccjit should produce dylib on macOS PR jit/100613 gcc/jit/ChangeLog: * Make-lang.in: Provide clauses for Darwin hosts.
[Bug objc/101666] Objective-C frontend crashes with `-fobjc-nilcheck`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101666
--- Comment #4 from CVS Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:d2aa4e0b3b5053df8f5853d9ed29022ff0d3ecf6
commit r12-3006-gd2aa4e0b3b5053df8f5853d9ed29022ff0d3ecf6
Author: Iain Sandoe
Date: Sat Aug 14 12:27:55 2021 +0100
Objective-C: fix crash with -fobjc-nilcheck
When -fobjc-nilcheck is enabled, messages that result in a struct type
should
yield a zero-initialized struct when sent to nil. Currently, the frontend
crashes when it encounters this situation. This patch fixes the crash by
generating the tree for the `{}` initializer.
Signed-off-by: Iain Sandoe
Co-authored-by: Matt Jacobson
PR objc/101666
gcc/objc/ChangeLog:
* objc-act.c (objc_build_constructor): Handle empty constructor
lists.
* objc-next-runtime-abi-02.c (build_v2_objc_method_fixup_call):
Handle nil receivers.
(build_v2_build_objc_method_call): Likewise.
gcc/testsuite/ChangeLog:
* obj-c++.dg/pr101666-0.mm: New test.
* obj-c++.dg/pr101666-1.mm: New test.
* obj-c++.dg/pr101666.inc: New.
* objc.dg/pr101666-0.m: New test.
* objc.dg/pr101666-1.m: New test.
* objc.dg/pr101666.inc: New.
[Bug libstdc++/101965] New: check in charconv is vacuously true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101965
Bug ID: 101965
Summary: check in charconv is vacuously true
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
When investigating PVS-Studio in our codebase, it flagged this check in
charconv:
322template
323 __detail::__integer_to_chars_result_type<_Tp>
324 __to_chars_i(char* __first, char* __last, _Tp __value, int __base =
10)
325 {
326__glibcxx_assert(2 <= __base && __base <= 36);
327
328using _Up = __detail::__unsigned_least_t<_Tp>;
329_Up __unsigned_val = __value;
330
331if (__first == __last) [[__unlikely__]]
332 return { __last, errc::value_too_large };
333
334if (__value == 0)
335 {
336*__first = '0';
337return { __first + 1, errc{} };
338 }
339
340if _GLIBCXX17_CONSTEXPR (std::is_signed<_Tp>::value)
341 if (__value < 0)
342{
343 if (__builtin_expect(__first != __last, 1))
344*__first++ = '-';
345 __unsigned_val = _Up(~__value) + _Up(1);
346}
347
348switch (__base)
349{
350case 16:
On line 343, __first is never equal to __last. If it were, we would've returned
on line 332.
[Bug c/101964] using scanf makes compiler never terminate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101964 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|UNCONFIRMED --- Comment #2 from Andrew Pinski --- Works for me.
[Bug c/101964] using scanf makes compiler never terminate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101964
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Andrew Pinski ---
:6:13: warning: format '%d' expects argument of type 'int*', but
argument 2 has type 'int' [-Wformat=]
6 | scanf("%d", x);
|~^ ~
| | |
| | int
| int*
:6:10: warning: 'x' is used uninitialized [-Wuninitialized]
6 | scanf("%d", x);
| ~^
[Bug c/101964] New: using scanf makes compiler never terminate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101964
Bug ID: 101964
Summary: using scanf makes compiler never terminate
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mateusmoraisdias3 at gmail dot com
Target Milestone: ---
OS: 5.13.8-1-MANJARO - x86_64
Description:
using a simple call with `scanf` makes gcc never compile the source. Even a
file (the bin output) is created, but once ran nothing happens, as it were
stuck in a empty loop.
Steps to reproduce:
write a file with this content
```c
#!/main.c
#include
int main(){
int x;
scanf("%d", x);
return 0;
}
```
type `gcc main.c -o main` to compile.
[Bug middle-end/101955] (signed<<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101955
--- Comment #3 from Andrew Pinski ---
This is also the sign extend for loading one bit.
That is take
struct g
{
int a:1;
int b0:1;
int b1:1;
int b2:1;
int b:1;
};
int h(struct g *a)
{
return a->a;
}
Currently on x86_64 -O2 GCC does:
movzbl (%rdi), %eax
sall$31, %eax
sarl$31, %eax
ret
While we should do (and llvm does):
movzbl (%rdi), %eax
andl$1, %eax
negl%eax
retq
This helps really on targets like avr more than any really.
[Bug analyzer/97114] Support for vfuncs in -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97114 --- Comment #2 from CVS Commits --- The master branch has been updated by Ankur saini : https://gcc.gnu.org/g:1b34248527472496ca3fe2a07183beac8cf69041 commit r12-3003-g1b34248527472496ca3fe2a07183beac8cf69041 Author: Ankur Saini Date: Sun Aug 15 19:19:07 2021 +0530 analyzer: detect and analyze virtual function calls 2021-08-15 Ankur Saini gcc/analyzer/ChangeLog: PR analyzer/97114 * region-model.cc (region_model::get_rvalue_1): Add case for OBJ_TYPE_REF. gcc/testsuite/ChangeLog: PR analyzer/97114 * g++.dg/analyzer/vfunc-2.C: New test. * g++.dg/analyzer/vfunc-3.C: New test. * g++.dg/analyzer/vfunc-4.C: New test. * g++.dg/analyzer/vfunc-5.C: New test.
[Bug analyzer/100546] -Wanayzer-null-dereference false positive through noreturn function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546 --- Comment #2 from CVS Commits --- The master branch has been updated by Ankur saini : https://gcc.gnu.org/g:aef703cf982072427e74034f4c460a11c5e04b8e commit r12-3002-gaef703cf982072427e74034f4c460a11c5e04b8e Author: Ankur Saini Date: Thu Jul 29 15:48:07 2021 +0530 analyzer: detect and analyze calls via function pointer 2021-07-29 Ankur Saini gcc/analyzer/ChangeLog: PR analyzer/100546 * analysis-plan.cc (analysis_plan::use_summary_p): Don't use call summaries if there is no callgraph edge * checker-path.cc (call_event::call_event): Handle calls events that are not represented by a supergraph call edge (return_event::return_event): Likewise. (call_event::get_desc): Work with new call_event structure. (return_event::get_desc): Likeise. * checker-path.h (call_event::m_src_snode): New field. (call_event::m_dest_snode): New field. (return_event::m_src_snode): New field. (return_event::m_dest_snode): New field. * diagnostic-manager.cc (diagnostic_manager::prune_for_sm_diagnostic): Refactor to work with edges without callgraph edge. (diagnostic_manager::prune_for_sm_diagnostic): Likewise. * engine.cc (dynamic_call_info_t::update_model): New function. (dynamic_call_info_t::add_events_to_path): New function. (exploded_graph::create_dynamic_call): New function. (exploded_graph::process_node): Work with dynamically discovered calls. * exploded-graph.h (class dynamic_call_info_t): New class. (exploded_graph::create_dynamic_call): New decl. * program-point.cc (program_point::push_to_call_stack): New function. (program_point::pop_from_call_stack): New function. * program-point.h (program_point::push_to_call_stack): New decl. (program_point::pop_from_call_stack): New decl. * program-state.cc (program_state::push_call): New function. (program_state::returning_call): New function. * program-state.h (program_state::push_call): New decl. (program_state::returning_call): New decl. * region-model.cc (region_model::update_for_gcall) New function. (region_model::update_for_return_gcall): New function. (egion_model::update_for_call_superedge): Get the underlying gcall and update for gcall. (region_model::update_for_return_superedge): Likewise. * region-model.h (region_model::update_for_gcall): New decl. (region_model::update_for_return_gcall): New decl. * state-purge.cc (state_purge_per_ssa_name::process_point): Update to work with calls without underlying cgraph edge. * supergraph.cc (supergraph::supergraph) Split snodes at every callsite. * supergraph.h (supernode::get_returning_call) New accessor. gcc/testsuite/ChangeLog: PR analyzer/100546 * gcc.dg/analyzer/function-ptr-4.c: New test. * gcc.dg/analyzer/pr100546.c: New test.
[Bug testsuite/101963] New: New test case gfortran.dg/nothing-1.f90 in r12-2992 doesn't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101963 Bug ID: 101963 Summary: New test case gfortran.dg/nothing-1.f90 in r12-2992 doesn't compile Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:f74433e70ae94a3b5291e45fea488b1cfdee4a34, r12-2992 ERROR: gfortran.dg/nothing-2.f90 -O : can't read "OMP": no such variable for " dg-error 6 "Unexpected junk after $OMP NOTHING statement" " ERROR: gfortran.dg/nothing-2.f90 -O : can't read "OMP": no such variable for " dg-error 6 "Unexpected junk after $OMP NOTHING statement" " commit f74433e70ae94a3b5291e45fea488b1cfdee4a34 (HEAD, refs/bisect/bad) Author: Tobias Burnus Date: Wed Aug 18 15:21:18 2021 +0200 Fortran: Add OpenMP's nothing directive support
[Bug analyzer/101962] New: Analyzer NULL false positive with pointer manipulation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101962
Bug ID: 101962
Summary: Analyzer NULL false positive with pointer manipulation
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
-fanalyzer emits two warnings on this code:
#define NULL ((void *)0)
int *
func1(int *ptr) {
if (!ptr)
return NULL;
return ++ptr;
}
int
main() {
int stack;
int *a = &stack;
a = func1(a);
a = func1(a);
return *a;
}
Compiler Explorer link: https://godbolt.org/z/ohecfvdd8
gcc 11.2 emits:
:16:10: warning: dereference of NULL 'a' [CWE-476]
[-Wanalyzer-null-dereference]
16 | return *a;
| ^~
for the path in which ptr is non-NULL in the first call, and then NULL in the
2nd call, i.e. for which &stack == (NULL) - 1.
Whilst this is technically correct, it won't occur in practise and is thus
effectively a false positive that we shouldn't warn for.
trunk also emits:
:16:10: warning: use of uninitialized value '*a' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
16 | return *a;
| ^~
for the path in which ptr is non-NULL in both calls, and so we're effectively
accessing (&stack)[2], which is a true problem in the software under test, but
would be better to report as an out-of-bounds warning (the analyzer doesn't yet
do bounds checking).
Downstream report: https://bugzilla.redhat.com/show_bug.cgi?id=1995092
[Bug bootstrap/101959] [12 Regression] hash_map self test bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101959 Thomas Schwinge changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Thomas Schwinge --- (In reply to David Edelsohn from comment #2) > This may be related to 32 bit builds. Quite right: was broken for all 32-bit hosts. Should now be fixed -- please re-open if it isn't.
[Bug bootstrap/101959] [12 Regression] hash_map self test bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101959 --- Comment #4 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:bb04a03c6f9bacc890118b9e12b657503093c2f8 commit r12-3001-gbb04a03c6f9bacc890118b9e12b657503093c2f8 Author: Thomas Schwinge Date: Wed Aug 18 17:20:40 2021 +0200 Make 'gcc/hash-map-tests.c:test_map_of_type_with_ctor_and_dtor_expand' work on 32-bit architectures [PR101959] Bug fix for recent commit e4f16e9f357a38ec702fb69a0ffab9d292a6af9b "Add more self-tests for 'hash_map' with Value type with non-trivial constructor/destructor". gcc/ PR bootstrap/101959 * hash-map-tests.c (test_map_of_type_with_ctor_and_dtor_expand): Use an 'int_hash'.
[Bug middle-end/101197] __builtin_memmove does not perform constant optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101197 --- Comment #18 from Tamar Christina --- (In reply to Martin Liška from comment #17) > Waiting for Tamara's test-case now. > Btw. can you please share a pointer to the Github repsitory? Sure, it's this project and this particular call https://github.com/google/snappy/blob/b4888f76161debdbcde30a64be577b82fd40de29/snappy.cc#L1166
[Bug middle-end/101955] (signed<<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101955 --- Comment #2 from Andreas Schwab --- If you want to be agressive you can optimize f to return 0.
[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399 --- Comment #13 from Vincent Lefèvre --- (In reply to Jakub Jelinek from comment #12) > That isn't representable in the GCC internal representation, which pretends > the type has fixed 106 bit precision [...] So, if I understand correctly, this is due to a limitation of GCC internals. > The only way around that would be to actually represent it in GCC internal > representation as sum of two doubles and rewrite all operations on this mode > to treat it specially. That is a lot of work and given that powerpc64le is > switching from this floating point format to IEEE quad long double format, > I'm certain nobody is willing to spend that much time (months) on it. Well, if there is a difficulty of implementation, perhaps leave LDBL_MAX as is, and consider for instance that an operation that with the result 0x1.f7cp+1023 would overflow (which is AFAIK undefined behavior for non-IEEE-754 formats, so that this would be conforming). But this should be documented.
[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865 --- Comment #3 from Segher Boessenkool --- The current code reads if ((flags & OPTION_MASK_DIRECT_MOVE) != 0) rs6000_define_or_undefine_macro (define_p, "_ARCH_PWR8"); if ((flags & OPTION_MASK_MODULO) != 0) rs6000_define_or_undefine_macro (define_p, "_ARCH_PWR9"); if ((flags & OPTION_MASK_POWER10) != 0) rs6000_define_or_undefine_macro (define_p, "_ARCH_PWR10"); Only the p10 one here is (maybe?) correct, all the other defines depend on flags that can be (directly or indirectly) disabled. This is not limited to just these three, of course. The reason this showed up for p8 is that it shows up with a reasonable choice of flags.
[Bug c/101953] bug on the default cast operator from double to unsigned short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953 --- Comment #24 from M W --- I know it is documented as "undefined," but it is also unexpected without even a warning. Anyone maintaining code and/or porting to rpi will simply not expect this behavior. I certainly didn't. I had been using my code for over a decade and the default casting did the "correct" (expected) thing across many different platforms. I'm really not sure how anyone is OK with this behavior. I'm concerned about the mountains of code out in the real world that may be failing silently. Now that the RaspberryPI is being used more and more as a drop in replacement for old x86 servers, this will impact a lot of people.
[Bug target/101723] arm: incorrect order of .fpu and .arch_extension directives leads to unsupported instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101723 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:b8a001599d21eaa77737df7efc6bc206e6964cdf commit r11-8883-gb8a001599d21eaa77737df7efc6bc206e6964cdf Author: Christophe Lyon Date: Fri Aug 6 14:25:47 2021 + arm: Fix pr69245.c testcase for reorder assembler architecture directives [PR101723] In gcc.target/arm/pr69245.c, to have a .fpu neon-vfpv4 directive, make sure code for fn1() is emitted, by removing the static keyword. Fix a typo in gcc.target/arm/pr69245.c, where \s should be \\s. 2021-08-06 Christophe Lyon gcc/testsuite/ PR target/101723 * gcc.target/arm/pr69245.c: Make sure to emit code for fn1, fix typo. (cherry picked from commit aff75af3b50f8c039ed6fbfa3f313ba45d44f6e6)
[Bug c/101953] bug on the default cast operator from double to unsigned short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #23 from Martin Sebor --- With a constant argument it should be possible to issue a warning at compile time. If that's sufficient I would suggest to open a new bug requesting it. Similarly, if the sanitizers should detect it but don't please open a separate request to make that work. Link them to this one for background.
[Bug target/101723] arm: incorrect order of .fpu and .arch_extension directives leads to unsupported instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101723 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:39bb64e79a280fa773c8dcd79b992745e8c1b738 commit r11-8882-g39bb64e79a280fa773c8dcd79b992745e8c1b738 Author: Christophe Lyon Date: Fri Aug 6 14:06:44 2021 + arm: Fix typos for reorder assembler architecture directives [PR101723] Two tests had typos preventing them from passing, committed as obvious. 2021-08-06 Christophe Lyon gcc/testsuite/ PR target/101723 * gcc.target/arm/attr-neon3.c: Fix typo. * gcc.target/arm/pragma_fpu_attribute_2.c: Fix typo. (cherry picked from commit a22b3e022c2b45047a28d901042888eb77620499)
[Bug target/101723] arm: incorrect order of .fpu and .arch_extension directives leads to unsupported instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101723 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:c21ba5e57e49b870f1607944c0742e78feb7bc8d commit r11-8881-gc21ba5e57e49b870f1607944c0742e78feb7bc8d Author: Richard Earnshaw Date: Thu Jul 29 11:00:31 2021 +0100 arm: reorder assembler architecture directives [PR101723] A change to the way gas interprets the .fpu directive in binutils-2.34 means that issuing .fpu will clear any features set by .arch_extension that apply to the floating point or simd units. This unfortunately causes problems for more recent versions of the architecture because we currently emit .arch, .arch_extension and .fpu directives at different times and try to suppress redundant changes. This change addresses this by firstly unifying all the places where we emit these directives to a single block of code and secondly (re)emitting all the directives if any changes have been made to the target options. Whilst this is slightly more than the strict minimum it should be enough to catch all cases where a change could have happened. The new code also emits the directives in the order: .arch, .fpu, .arch_extension. This ensures that the additional architectural extensions are not removed by a later .fpu directive. Whilst writing this patch I also noticed that in the corner case where the last function to be compiled had a non-standard set of architecture flags, the assembler would add an incorrect set of derived attributes for the file as a whole. Instead of reflecting the command-line options it would reflect the flags from the last file in the function. To address this I've also added a call to re-emit the flags from the asm_file_end callback so the assembler will be in the correct state when it finishes processing the intput. There's some slight churn to the testsuite as a consequence of this, because previously we had a hack to suppress emitting a .fpu directive for one specific case, but with the new order this is no-longer necessary. gcc/ChangeLog: PR target/101723 * config/arm/arm-cpus.in (generic-armv7-a): Add quirk to suppress writing .cpu directive in asm output. * config/arm/arm.c (arm_identify_fpu_from_isa): New variable. (arm_last_printed_arch_string): Delete. (arm_last-printed_fpu_string): Delete. (arm_configure_build_target): If use of floating-point/SIMD is disabled, remove all fp/simd related features from the target ISA. (last_arm_targ_options): New variable. (arm_print_asm_arch_directives): Add new parameters. Change order of emitted directives and handle all cases here. (arm_file_start): Always call arm_print_asm_arch_directives, move all generation of .arch/.arch_extension here. (arm_file_end): Call arm_print_asm_arch. (arm_declare_function_name): Call arm_print_asm_arch_directives instead of printing .arch/.fpu directives directly. gcc/testsuite/ChangeLog: PR target/101723 * gcc.target/arm/cortex-m55-nofp-flag-hard.c: Update expected output. * gcc.target/arm/cortex-m55-nofp-flag-softfp.c: Likewise. * gcc.target/arm/cortex-m55-nofp-nomve-flag-softfp.c: Likewise. * gcc.target/arm/mve/intrinsics/mve_fpu1.c: Convert to dg-do assemble. Add a non-no-op function body. * gcc.target/arm/mve/intrinsics/mve_fpu2.c: Likewise. * gcc.target/arm/pr98636.c (dg-options): Add -mfloat-abi=softfp. * gcc.target/arm/attr-neon.c: Tighten scan-assembler tests. * gcc.target/arm/attr-neon2.c: Use -Ofast, convert test to use check-function-bodies. * gcc.target/arm/attr-neon3.c: Likewise. * gcc.target/arm/pr69245.c: Tighten scan-assembler match, but allow multiple instances. * gcc.target/arm/pragma_fpu_attribute.c: Likewise. * gcc.target/arm/pragma_fpu_attribute_2.c: Likewise. (cherry picked from commit c1cdabe3aab817d95a8db00a8b5e9f6bcdea936f)
[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399 --- Comment #12 from Jakub Jelinek --- (In reply to Vincent Lefèvre from comment #11) > In addition to the maximum exponent issue, for LDBL_MAX following the defect > report, instead of > > 0x1.f78p+1023 > > I would expect > > 0x1.f7cp+1023 = DBL_MAX + DBL_MAX * DBL_EPSILON / 4 > > as it is larger (it has one more trailing 1) and representable. That isn't representable in the GCC internal representation, which pretends the type has fixed 106 bit precision (like double has 53 bit precision), 0x1.f7cp+1023 needs 107 bit precision (and generally the type has variable precision). The only way around that would be to actually represent it in GCC internal representation as sum of two doubles and rewrite all operations on this mode to treat it specially. That is a lot of work and given that powerpc64le is switching from this floating point format to IEEE quad long double format, I'm certain nobody is willing to spend that much time (months) on it.
[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399 --- Comment #11 from Vincent Lefèvre --- In addition to the maximum exponent issue, for LDBL_MAX following the defect report, instead of 0x1.f78p+1023 I would expect 0x1.f7cp+1023 = DBL_MAX + DBL_MAX * DBL_EPSILON / 4 as it is larger (it has one more trailing 1) and representable.
