[Bug fortran/100776] Error in automatic object of parameterized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100776 --- Comment #1 from Mohd Furquan --- Renaming result variable alleviates the problem. The following code compiles without complain: ``` module vector type :: vec(dimen) integer,len :: dimen real:: e(dimen) end type vec contains function double(a) result (d) type(vec(*)),intent(in) :: a type(vec(a%dimen)) :: d d%e = 2.*a%e end function double end module vector ```
[Bug c/100793] New: ICE: in expand_assignment, at expr.c:5363
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100793
Bug ID: 100793
Summary: ICE: in expand_assignment, at expr.c:5363
Product: gcc
Version: tree-ssa
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.SQC1E9RsGE-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 20210527 (experimental) [master revision
:d03f010a0:01c59ef2e5a59b44d2b662361196abb6be872a20] (GCC)
$ cat mutant.c
f4() {
register a;
register __attribute__((vector_size(16))) b __asm("xmm17");
b[a] = a;
asm("" : "+v"(b));
}
$ gcc-trunk mutant.c
mutant.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | f4() {
| ^~
mutant.c: In function ‘f4’:
mutant.c:2:12: warning: type defaults to ‘int’ in declaration of ‘a’
[-Wimplicit-int]
2 | register a;
|^
mutant.c:3:45: warning: type defaults to ‘int’ in declaration of ‘b’
[-Wimplicit-int]
3 | register __attribute__((vector_size(16))) b __asm("xmm17");
| ^
mutant.c:3:45: error: the register specified for ‘b’ cannot be accessed by the
current target
during RTL pass: expand
mutant.c:4:8: internal compiler error: in expand_assignment, at expr.c:5363
4 | b[a] = a;
| ~^~~
0x6b2f16 expand_assignment(tree_node*, tree_node*, bool)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/expr.c:5363
0xa4307f expand_gimple_stmt_1
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/cfgexpand.c:3916
0xa4307f expand_gimple_stmt
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/cfgexpand.c:4014
0xa49159 expand_gimple_basic_block
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/cfgexpand.c:6056
0xa4b02f execute
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/cfgexpand.c:6782
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/100792] New: ICE: gimplify_expr, at gimplify.c:14879
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100792
Bug ID: 100792
Summary: ICE: gimplify_expr, at gimplify.c:14879
Product: gcc
Version: tree-ssa
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.SQC1E9RsGE-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 20210527 (experimental) [master revision
:d03f010a0:01c59ef2e5a59b44d2b662361196abb6be872a20] (GCC)
$ cat mutant.c
ldt_add_entry() {
__asm__("" : : "m"(({ __asm__(""); })));
}
$ gcc-trunk mutant.c
mutant.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | ldt_add_entry() {
| ^
mutant.c: In function ‘ldt_add_entry’:
mutant.c:2:25: internal compiler error: in gimplify_expr, at gimplify.c:14879
2 | __asm__("" : : "m"(({ __asm__(""); })));
| ~~~^~~
0x6df932 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:14879
0xc4955d gimplify_asm_expr
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:6512
0xc3f245 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:14298
0xc41aaa gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:6883
0xc422de gimplify_bind_expr
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:1424
0xc3e513 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:14166
0xc41aaa gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:6883
0xc430a3 gimplify_body(tree_node*, bool)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:15210
0xc434f1 gimplify_function_tree(tree_node*)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:15364
0xa85717 cgraph_node::analyze()
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/cgraphunit.c:670
0xa88641 analyze_functions
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/cgraphunit.c:1234
0xa89111 symbol_table::finalize_compilation_unit()
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/cgraphunit.c:2508
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/100791] New: ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100791
Bug ID: 100791
Summary: ICE: verify_gimple failed
Product: gcc
Version: tree-ssa
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.SQC1E9RsGE-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 20210527 (experimental) [master revision
:d03f010a0:01c59ef2e5a59b44d2b662361196abb6be872a20] (GCC)
$ cat mutant.c
__attribute__((__always_inline__)) sprintf() {
return log_bad_request(0, __builtin_va_arg_pack());
}
void log_bad_request() { sprintf(0); }
$ gcc-trunk mutant.c
mutant.c:1:36: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | __attribute__((__always_inline__)) sprintf() {
|^~~
mutant.c:1:36: warning: conflicting types for built-in function ‘sprintf’;
expected ‘int(char *, const char *, ...)’ [-Wbuiltin-declaration-mismatch]
mutant.c:1:1: note: ‘sprintf’ is declared in header ‘’
+++ |+#include
1 | __attribute__((__always_inline__)) sprintf() {
mutant.c: In function ‘sprintf’:
mutant.c:1:36: warning: number of arguments doesn’t match built-in prototype
1 | __attribute__((__always_inline__)) sprintf() {
|^~~
mutant.c:2:10: warning: implicit declaration of function ‘log_bad_request’
[-Wimplicit-function-declaration]
2 | return log_bad_request(0, __builtin_va_arg_pack());
| ^~~
mutant.c: At top level:
mutant.c:4:6: warning: conflicting types for ‘log_bad_request’; have ‘void()’
4 | void log_bad_request() { sprintf(0); }
| ^~~
mutant.c:2:10: note: previous implicit declaration of ‘log_bad_request’ with
type ‘void()’
2 | return log_bad_request(0, __builtin_va_arg_pack());
| ^~~
mutant.c:1:36: warning: ‘always_inline’ function might not be inlinable
[-Wattributes]
1 | __attribute__((__always_inline__)) sprintf() {
|^~~
mutant.c: In function ‘log_bad_request’:
mutant.c:4:1: error: invalid conversion in gimple call
4 | void log_bad_request() { sprintf(0); }
| ^~~~
int
void
# .MEM_4 = VDEF <.MEM_1(D)>
_3 = log_bad_request (0, 0);
during GIMPLE pass: einline
mutant.c:4:1: internal compiler error: verify_gimple failed
0xf77e71 verify_gimple_in_cfg(function*, bool)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/tree-cfg.c:5509
0xe24f6f execute_function_todo
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/passes.c:2042
0xe25d5e execute_todo
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/passes.c:2096
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/100790] New: ICE with -O2: in verify_range, at value-range.cc:385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100790
Bug ID: 100790
Summary: ICE with -O2: in verify_range, at value-range.cc:385
Product: gcc
Version: tree-ssa
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.SQC1E9RsGE-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 20210527 (experimental) [master revision
:d03f010a0:01c59ef2e5a59b44d2b662361196abb6be872a20] (GCC)
$ cat mutant.c
__builtin_clz(int x) { x ? __builtin_clz(x) : 32; }
$ gcc-trunk -O2 mutant.c
mutant.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | __builtin_clz(int x) { x ? __builtin_clz(x) : 32; }
| ^
during GIMPLE pass: evrp
mutant.c: In function ‘__builtin_clz’:
mutant.c:1:1: internal compiler error: in verify_range, at value-range.cc:385
0x7d4aa5 irange::verify_range()
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/value-range.cc:385
0xc18ef7 fold_using_range::range_of_builtin_call(irange&, gcall*, fur_source&)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimple-range.cc:799
0xc1a6aa fold_using_range::range_of_call(irange&, gcall*, fur_source&)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimple-range.cc:626
0xc1ad40 fold_using_range::fold_stmt(irange&, gimple*, fur_source&, tree_node*)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimple-range.cc:380
0xc1afc2 gimple_ranger::fold_range_internal(irange&, gimple*, tree_node*)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimple-range.cc:1067
0xc1afc2 gimple_ranger::range_of_stmt(irange&, gimple*, tree_node*)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimple-range.cc:1097
0xc1a417 gimple_ranger::range_of_expr(irange&, tree_node*, gimple*)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimple-range.cc:980
0x12481b4 range_query::value_of_expr(tree_node*, gimple*)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/value-query.cc:86
0x1962865 hybrid_folder::value_of_expr(tree_node*, gimple*)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimple-ssa-evrp.c:233
0x10e1e06 substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/tree-ssa-propagate.c:816
0x1935277 dom_walker::walk(basic_block_def*)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/domwalk.c:309
0x10e10f9 substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/tree-ssa-propagate.c:987
0x196244d execute_early_vrp
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimple-ssa-evrp.c:347
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/100789] New: ICE: in gimplify_expr, at gimplify.c:14750
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100789
Bug ID: 100789
Summary: ICE: in gimplify_expr, at gimplify.c:14750
Product: gcc
Version: tree-ssa
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.SQC1E9RsGE-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 20210527 (experimental) [master revision
:d03f010a0:01c59ef2e5a59b44d2b662361196abb6be872a20] (GCC)
$ cat mutant.c
bar() { return __transaction_relaxed(0x1234567876543210LL << 32); }
$ gcc-trunk mutant.c
mutant.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | bar() { return __transaction_relaxed(0x1234567876543210LL << 32); }
| ^~~
mutant.c: In function ‘bar’:
mutant.c:1:59: warning: result of ‘1311768466852950544 << 32’ requires 94 bits
to represent, but ‘long long int’ only has 64 bits [-Wshift-overflow=]
1 | bar() { return __transaction_relaxed(0x1234567876543210LL << 32); }
| ^~
mutant.c:1:16: error: ‘__transaction_relaxed ’ without transactional memory
support enabled
1 | bar() { return __transaction_relaxed(0x1234567876543210LL << 32); }
|^
mutant.c:1:59: internal compiler error: in gimplify_expr, at gimplify.c:14750
1 | bar() { return __transaction_relaxed(0x1234567876543210LL << 32); }
| ~^
0x6dffc4 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:14750
0xc4e997 gimplify_modify_expr
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:5824
0xc3e178 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:13965
0xc41aaa gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:6883
0xc422de gimplify_bind_expr
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:1424
0xc3e513 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:14166
0xc41aaa gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:6883
0xc40c58 gimplify_and_add(tree_node*, gimple**)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:492
0xc40c58 gimplify_and_return_first
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:504
0xc40c58 gimplify_transaction
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:13585
0xc40c58 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:14593
0xc3e37f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:14270
0xc4e997 gimplify_modify_expr
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:5824
0xc3e178 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:13965
0xc41aaa gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:6883
0xc4d2cd gimplify_and_add(tree_node*, gimple**)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:492
0xc4d2cd gimplify_return_expr
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:1674
0xc3ee1f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:14227
0xc41aaa gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:6883
0xc422de gimplify_bind_expr
/tmp/tmp.SQC1E9RsGE-gcc-builder/gcc/gcc/gimplify.c:1424
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/100530] [9/10/11/12 Regression] ICE with -g: in add_dwarf_attr with __seg_gs (Alternative address-space) global variable since r8-4385-ga297ccb52e0c894e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100530 --- Comment #2 from Chengnian Sun --- A duplicate. __seg_gs pitches[];
[Bug gcov-profile/100788] Internal compiler error related to #line macros(?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100788 --- Comment #1 from seberg --- Created attachment 50875 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50875=edit preprocessed_file
[Bug gcov-profile/100788] New: Internal compiler error related to #line macros(?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100788 Bug ID: 100788 Summary: Internal compiler error related to #line macros(?) Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: sebastian-gcc at sipsolutions dot net CC: marxin at gcc dot gnu.org Target Milestone: --- I first thought this might have been the identical issue as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95847 as it seemed similar. There is also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96353, but I do not think this is the same issue. We have a large file in NumPy which generates compile errors on gcc 9+ (gcc 8 seems fine as far as I can tell). The issue on NumPy is: https://github.com/numpy/numpy/issues/18529 (It is not a major issue, but I fear it might get problematic for our coverage tools when they stop using GCC 8, which I think they are still using.) I have attached the source file that generates the issue. Note that it is generated by a custom templating language, so I can't fully rule out that the inserted `#line` directives are incorrect. The one clear thing I know is that removing all `#line` directives makes the coverage compilation successfully. I expect you may need more information, but am not sure how to best provide it, considering that the file is part of the larger project. The error/log is (this one with gcc (Debian 10.2.1-6) 10.2.1 20210110, but confirmed on a gcc 11: ... x86_64-linux-gnu-gcc: numpy/core/src/common/python_xerbla.c during IPA pass: profile numpy/core/src/multiarray/einsum_sumprod.c.src: In function ‘longdouble_sum_of_products_contig_three’: numpy/core/src/multiarray/einsum_sumprod.c.src:1264:1: internal compiler error: in coverage_begin_function, at coverage.c:656 1264 | } | ^ 0x7ff60fe2cd09 __libc_start_main ../csu/libc-start.c:308 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. error: Command "x86_64-linux-gnu-gcc -pthread --coverage -Wno-unused-result -Wsign-compare -O0 -ggdb -g -ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=. -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -Werror=vla -Werror=nonnull -Werror=pointer-arith -Wlogical-op -Werror=unused-function -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DNPY_INTERNAL_BUILD=1 -DHAVE_NPY_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DHAVE_CBLAS -Ibuild/src.linux-x86_64-3.9/numpy/core/src/common -Ibuild/src.linux-x86_64-3.9/numpy/core/src/umath -Inumpy/core/include -Ibuild/src.linux-x86_64-3.9/numpy/core/include/numpy -Ibuild/src.linux-x86_64-3.9/numpy/distutils/include -Inumpy/core/src/common -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/src/_simd -I/usr/include/python3.9 -Ibuild/src.linux-x86_64-3.9/numpy/core/src/common -Ibuild/src.linux-x86_64-3.9/numpy/core/src/npymath -c build/src.linux-x86_64-3.9/numpy/core/src/multiarray/einsum_sumprod.c -o build/temp.linux-x86_64-3.9/build/src.linux-x86_64-3.9/numpy/core/src/multiarray/einsum_sumprod.o -MMD -MF build/temp.linux-x86_64-3.9/build/src.linux-x86_64-3.9/numpy/core/src/multiarray/einsum_sumprod.o.d -msse -msse2 -msse3" failed with exit status 1
[Bug middle-end/100787] [12 Regression] Bootstrap failure caused by r12-1077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100787 Andrew Pinski changed: What|Removed |Added Component|bootstrap |middle-end Keywords||build Severity|normal |blocker Target Milestone|--- |12.0 --- Comment #1 from Andrew Pinski --- Most likely related to PR 100774 or PR 100781.
[Bug c/100783] [11/12 Regression] ICE while printing out error message with nonnull attribute and undeclared decl in an array size in parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100783 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Summary|ICE: at |[11/12 Regression] ICE |c/c-objc-common.c:188 |while printing out error ||message with nonnull ||attribute and undeclared ||decl in an array size in ||parameter Version|tree-ssa|12.0 Last reconfirmed||2021-05-27 Keywords||diagnostic, ||ice-on-invalid-code Target Milestone|--- |11.2 Known to work||7.5.0 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug middle-end/100786] ICE: in fold_convert_loc with alias attribute and different types and different sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100786 Andrew Pinski changed: What|Removed |Added Version|tree-ssa|12.0 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100509 --- Comment #1 from Andrew Pinski --- Related to PR 100509.
[Bug inline-asm/100785] [9/10/11/12 Regression] ICE: in expand_asm_stmt with "m" and bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100785 Andrew Pinski changed: What|Removed |Added Known to work||4.8.5 Severity|normal |minor Status|UNCONFIRMED |NEW Summary|ICE: in expand_asm_stmt |[9/10/11/12 Regression] |with "m" and bitfield |ICE: in expand_asm_stmt ||with "m" and bitfield Target Milestone|--- |9.4 Ever confirmed|0 |1 Last reconfirmed||2021-05-27 --- Comment #1 from Andrew Pinski --- Confirmed, a regression from at least 4.8.5 where there was no ICE (or "confused by earlier errors, bailing out"). At least GCC 7.5.0 has the bug. Minor issue as there was an error emitted before the ICE happens.
[Bug bootstrap/100787] New: [12 Regression] Bootstrap failure caused by r12-1077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100787 Bug ID: 100787 Summary: [12 Regression] Bootstrap failure caused by r12-1077 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: aldyh at redhat dot com Target Milestone: --- Target: i686 On Linux/i686, r12-1077 failed to bootstrap when configured with --prefix=/export/project/git/gcc-bisect-bootstrap/master/r12-1077/usr --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-languages=c,c++ --enable-cet i686-linux --enable-bootstrap --with-fpmath=sse --disable-libcc1 --disable-libcilkrts --disable-libsanitizer Comparing stages 2 and 3 Bootstrap comparison failure! gcc/tree-vrp.o differs
[Bug c/100786] New: ICE: in fold_convert_loc, at fold-const.c:2429
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100786
Bug ID: 100786
Summary: ICE: in fold_convert_loc, at fold-const.c:2429
Product: gcc
Version: tree-ssa
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.tVhv2eaPzV-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 20210526 (experimental) [master revision
:21638bbbf:1fd76b24306ed4df4cf9e797d900699ed59ce7f7] (GCC)
$ cat mutant.c
const double a = 0;
extern b __attribute__((alias("a")));
inc() { b++; }
$ gcc-trunk mutant.c
mutant.c:2:8: warning: type defaults to ‘int’ in declaration of ‘b’
[-Wimplicit-int]
2 | extern b __attribute__((alias("a")));
|^
mutant.c:3:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
3 | inc() { b++; }
| ^~~
mutant.c: In function ‘inc’:
mutant.c:3:10: internal compiler error: in fold_convert_loc, at
fold-const.c:2429
3 | inc() { b++; }
| ~^~
0x6bfba3 fold_convert_loc(unsigned int, tree_node*, tree_node*)
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/fold-const.c:2429
0xc085b7 fold_stmt_1
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/gimple-fold.c:6251
0xc3cbf2 gimplify_modify_expr
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/gimplify.c:6000
0xc2c1f8 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/gimplify.c:13965
0xc2fb2a gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/gimplify.c:6883
0xc31ce6 gimplify_and_add(tree_node*, gimple**)
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/gimplify.c:492
0xc31ce6 internal_get_tmp_var
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/gimplify.c:645
0xc2b777 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/gimplify.c:14954
0xc2bf91 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/gimplify.c:14720
0xc3ca07 gimplify_modify_expr
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/gimplify.c:5824
0xc2c1f8 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/gimplify.c:13965
0xc2fb2a gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/gimplify.c:6883
0xc3035e gimplify_bind_expr
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/gimplify.c:1424
0xc2c593 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/gimplify.c:14166
0xc2fb2a gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/gimplify.c:6883
0xc31123 gimplify_body(tree_node*, bool)
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/gimplify.c:15210
0xc31571 gimplify_function_tree(tree_node*)
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/gimplify.c:15364
0xa842c7 cgraph_node::analyze()
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/cgraphunit.c:670
0xa871f1 analyze_functions
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/cgraphunit.c:1234
0xa87cc1 symbol_table::finalize_compilation_unit()
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/cgraphunit.c:2508
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/100785] New: ICE: in expand_asm_stmt, at cfgexpand.c:3401
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100785
Bug ID: 100785
Summary: ICE: in expand_asm_stmt, at cfgexpand.c:3401
Product: gcc
Version: tree-ssa
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.tVhv2eaPzV-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 20210526 (experimental) [master revision
:21638bbbf:1fd76b24306ed4df4cf9e797d900699ed59ce7f7] (GCC)
$ cat mutant.c
foo(struct { int a : 1; } * x) { __asm__("" : "+m"(x->a)); }
$ gcc-trunk mutant.c
mutant.c:1:5: warning: anonymous struct declared inside parameter list will not
be visible outside of this definition or declaration
1 | foo(struct { int a : 1; } * x) { __asm__("" : "+m"(x->a)); }
| ^~
mutant.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | foo(struct { int a : 1; } * x) { __asm__("" : "+m"(x->a)); }
| ^~~
mutant.c: In function ‘foo’:
mutant.c:1:34: error: output number 0 not directly addressable
1 | foo(struct { int a : 1; } * x) { __asm__("" : "+m"(x->a)); }
| ^~~
during RTL pass: expand
mutant.c:1:34: internal compiler error: in expand_asm_stmt, at cfgexpand.c:3401
0x68b3a6 expand_asm_stmt
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/cfgexpand.c:3401
0xa41bb9 expand_gimple_stmt_1
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/cfgexpand.c:3847
0xa41bb9 expand_gimple_stmt
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/cfgexpand.c:4014
0xa47d09 expand_gimple_basic_block
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/cfgexpand.c:6056
0xa49bdf execute
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/cfgexpand.c:6782
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/100784] New: ICE: Segmentation fault, contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100784
Bug ID: 100784
Summary: ICE: Segmentation fault,
contains_struct_check(tree_node*,
tree_node_structure_enum, char const*, int, char
const*)
Product: gcc
Version: tree-ssa
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.tVhv2eaPzV-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 20210526 (experimental) [master revision
:21638bbbf:1fd76b24306ed4df4cf9e797d900699ed59ce7f7] (GCC)
$ cat mutant.c
typedef double v2df __attribute__((__vector_size__(16)));
f() {
v2df x;
v2df y;
__builtin_ia32_shufpd(x, y, 1);
}
$ gcc-trunk mutant.c
mutant.c:2:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
2 | f() {
| ^
during GIMPLE pass: lower
mutant.c: In function ‘f’:
mutant.c:2:1: internal compiler error: Segmentation fault
0xf01803 crash_signal
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/toplev.c:327
0xf3cf82 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/tree.h:3479
0xf3cf82 verify_gimple_assign_ternary
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/tree-cfg.c:4180
0xf3fb37 verify_gimple_in_seq_2
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/tree-cfg.c:5121
0xf42485 verify_gimple_in_seq(gimple*)
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/tree-cfg.c:5160
0xe12660 execute_function_todo
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/passes.c:2044
0xe1331e execute_todo
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/passes.c:2096
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/100783] New: ICE: at c/c-objc-common.c:188
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100783
Bug ID: 100783
Summary: ICE: at c/c-objc-common.c:188
Product: gcc
Version: tree-ssa
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.tVhv2eaPzV-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 20210526 (experimental) [master revision
:21638bbbf:1fd76b24306ed4df4cf9e797d900699ed59ce7f7] (GCC)
$ cat mutant.c
__attribute__((nonnull(1))) foo(char[z]) {}
$ gcc-trunk mutant.c
mutant.c:1:38: error: ‘z’ undeclared here (not in a function)
1 | __attribute__((nonnull(1))) foo(char[z]) {}
| ^
‘
in print_type, at c/c-objc-common.c:188
1 | __attribute__((nonnull(1))) foo(char[z]) {}
| ^
0x654caa print_type
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/c/c-objc-common.c:188
0x91de6a c_tree_printer
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/c/c-objc-common.c:310
0x91de6a c_tree_printer
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/c/c-objc-common.c:254
0x1b358ec pp_format(pretty_printer*, text_info*)
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/pretty-print.c:1475
0x1b19f6c diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/diagnostic.c:1244
0x1b1a4ae diagnostic_impl
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/diagnostic.c:1406
0x1b1a9d9 warning(int, char const*, ...)
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/diagnostic.c:1527
0x9d04d4 positional_argument(tree_node const*, tree_node const*, tree_node*,
tree_code, int, int)
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/c-family/c-attribs.c:747
0x9d07c2 handle_nonnull_attribute
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/c-family/c-attribs.c:4358
0x8ce496 decl_attributes(tree_node**, tree_node*, int, tree_node*)
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/attribs.c:723
0x8eb137 start_function(c_declspecs*, c_declarator*, tree_node*)
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/c/c-decl.c:9436
0x947cae c_parser_declaration_or_fndef
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/c/c-parser.c:2440
0x94ff73 c_parser_external_declaration
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/c/c-parser.c:1777
0x9509d9 c_parser_translation_unit
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/c/c-parser.c:1650
0x9509d9 c_parse_file()
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/c/c-parser.c:21994
0x9b1155 c_common_parse_file()
/tmp/tmp.tVhv2eaPzV-gcc-builder/gcc/gcc/c-family/c-opts.c:1219
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 target/94613] S/390, powerpc: Wrong code generated for vec_sel builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613 luoxhu at gcc dot gnu.org changed: What|Removed |Added CC||luoxhu at gcc dot gnu.org --- Comment #14 from luoxhu at gcc dot gnu.org --- Patch submmited: https://gcc.gnu.org/pipermail/gcc-patches/2021-April/569255.html
[Bug target/97142] __builtin_fmod not optimized on POWER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142 --- Comment #12 from luoxhu at gcc dot gnu.org --- Patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568143.html
[Bug c++/100779] Partial specialization with non-deducible template parameters accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100779 --- Comment #2 from Patrick Palka --- The problem is ultimately that for_each_template_parm doesn't honor included_nondeduced_p correctly.
[Bug tree-optimization/100732] [11/12 Regression] ICE with -Wall: in ao_ref_init_from_ptr_and_range, at tree-ssa-alias.c:824 since r11-959-gb825a22890740f34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100732 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Keywords||patch Status|NEW |ASSIGNED Known to fail||11.1.0, 12.0 --- Comment #3 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571346.html
[Bug c/100653] usage of scalar_storage_order produces incorrect result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100653 --- Comment #7 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:58523f23fefcef0850841e7055d75d4309f0453e commit r12-1083-g58523f23fefcef0850841e7055d75d4309f0453e Author: Eric Botcazou Date: Thu May 27 00:24:20 2021 +0200 Small tweak to documentation of scalar_storage_order gcc/ PR c/100653 * doc/extend.texi (scalar_storage_order): Rephrase slightly.
[Bug target/100771] Types differ between i386-elf and x86_64-elf -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100771 Andrew Pinski changed: What|Removed |Added Version|unknown |12.0 Component|c |target Target||x86_64-elf, i?86-elf Keywords||wrong-code --- Comment #1 from Andrew Pinski --- It might be nobody cares enough about the x86_64-elf/i?86-elf targets to fix this. Is there a difference for x86_64-linux-gnu/i?86-linux-gnu target?
Re: compiler produces an error message
On Wed, May 26, 2021 at 8:55 AM lexa kop via Gcc-bugs wrote: > > [ver]i try compile it on gcc 11 and gcc 12 > [new features]i use gcc modules features(module;export module, import, > import export) > [command]g++ *.cpp -std=c++20 -fmodules-ts > /usr/lib/gcc/x86_64-pc-linux-gnu/12.0.0/include/g++-v12/bits/basic_string.h: > In member function ‘std::__cxx11::basic_string<_CharT, _Traits, > _Alloc>::pointer std::__cxx11::basic_string<_CharT, _Traits, > _Alloc>::_M_create(std::__cxx11::basic_string<_CharT, _Traits, > _Alloc>::size_type&, std::__cxx11::basic_string<_CharT, _Traits, > _Alloc>::size_type) [with _CharT = char; _Traits = > std::char_traits; _Alloc = std::allocator]’: > /usr/lib/gcc/x86_64-pc-linux-gnu/12.0.0/include/g++-v12/bits/basic_string.h:233:7: > error: unrecognizable insn: > 233 | _M_create(size_type&, size_type); > | ^ > (insn 20 19 21 5 (set (reg:DI 98) > (reg/v 87 [ __old_capacity ])) > "/usr/lib/gcc/x86_64-pc-linux-gnu/12.0.0/include/g++-v12/bits/basic_string.tcc":143:7 > -1 > (nil)) > during RTL pass: vregs > /usr/lib/gcc/x86_64-pc-linux-gnu/12.0.0/include/g++-v12/bits/basic_string.h:233:7: > internal compiler error: in extract_insn, at recog.c:2770 The error message does not look related at all to modules. Can you file a bug to https://gcc.gnu.org/bugzilla/ after reading https://gcc.gnu.org/bugs/? So on the internal compiler error message here, it looks like a mode is missing for reg 87; I don't know why off hand either. Thanks, Andrew
[Bug middle-end/100593] [ELF] -fno-pic: Use GOT to take address of an external default visibility function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593 --- Comment #9 from Fangrui Song --- I have a patch to implement this Clang. It'd be good to have a name even if GCC wants to postpone the implementation for now. How about -fdirect-access-external-function & -fno-direct-access-external-function ? It is similar to the feature request -fdirect-access-external-data
[Bug tree-optimization/100781] [12 Regression] Emitted binary code changes when -g is enabled at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100781 --- Comment #4 from Andrew Pinski --- The first major difference shows up in evrp. With debugging info turned on we get: Merging blocks 4 and 6 Merging blocks 5 and 7
[Bug target/100782] New: [11 Regression] sh4 ICEs on -O2 -fPIE -fstack-protector: internal compiler error: in curr_insn_transform, at lra-constraints.c:4132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100782
Bug ID: 100782
Summary: [11 Regression] sh4 ICEs on -O2 -fPIE
-fstack-protector: internal compiler error: in
curr_insn_transform, at lra-constraints.c:4132
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: sh4-unknown-linux-gnu
Build: x86_64-pc-linux-gnu
Not sure if it's a dupe of bug #100241. Filing just in case.
Observed when built libffi for sh4 target. Minimal example:
// cat raw_api.c.c
void ffi_raw_to_ptrarray(void);
int ffi_call(void (*)(void *, void *), void*, void*, void*);
void ffi_raw_call_cif(void *fn, void *rvalue) {
void *avalue = __builtin_alloca(sizeof 0);
ffi_raw_to_ptrarray();
ffi_call(ffi_raw_call_cif, fn, rvalue, avalue);
}
$ ./xgcc -B. -O2 -mlra -fexceptions -fPIE -fstack-protector -c raw_api.c.c -o
raw_api.o
raw_api.c.c: In function 'ffi_raw_call_cif':
raw_api.c.c:8:1: error: unable to generate reloads for:
8 | }
| ^
(call_insn 18 16 20 2 (parallel [
(call (mem:SI (symbol_ref:SI ("ffi_raw_to_ptrarray") [flags 0x41]
) [0 ffi_raw_to_ptrarray S4
A32])
(const_int 0 [0]))
(use (reg:SI 154 fpscr0))
(use (reg:SI 12 r12))
(clobber (reg:SI 146 pr))
(clobber (reg:SI 183))
]) "raw_api.c.c":6:3 228 {call_pcrel}
(expr_list:REG_CALL_DECL (symbol_ref:SI ("ffi_raw_to_ptrarray") [flags
0x41] )
(nil))
(nil))
during RTL pass: reload
raw_api.c.c:8:1: internal compiler error: in curr_insn_transform, at
lra-constraints.c:4132
0x7fc7aea9287c __libc_start_main
../csu/libc-start.c:332
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.
Using built-in specs.
COLLECT_GCC=./xgcc
Target: sh4-unknown-linux-gnu
Configured with: ../gcc/configure --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=sh4-unknown-linux-gnu
--prefix=/home/slyfox/dev/git/gcc-sh4-ice/../gcc-sh4-installed
--with-sysroot=/usr/sh4-unknown-linux-gnu --disable-bootstrap
--enable-languages=c --disable-nls CFLAGS=-O0 CXXFLAGS=-O0
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210526 (experimental) (GCC)
[Bug c++/86355] [9/10/11/12 Regression] Internal compiler error with pack expansion and fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86355 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug tree-optimization/100781] [12 Regression] Emitted binary code changes when -g is enabled at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100781 --- Comment #3 from Andrew Pinski --- At least I thought this is related to PR 100774 but this was introduced after the patch which introduced that one.
[Bug tree-optimization/100781] [12 Regression] Emitted binary code changes when -g is enabled at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100781 --- Comment #2 from Andrew Pinski --- apinski@xeond:~/src/upstream-gcc/gcc/objdir/stage1-gcc$ ./xgcc -B. -fcompare-debug -O2 t.c xgcc: error: t.c: ‘-fcompare-debug’ failure (length)
[Bug tree-optimization/100781] [12 Regression] Emitted binary code changes when -g is enabled at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100781 Andrew Pinski changed: What|Removed |Added Summary|Emitted binary code changes |[12 Regression] Emitted |when -g is enabled at -O2 |binary code changes when -g ||is enabled at -O2 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-05-26 Target Milestone|--- |12.0 --- Comment #1 from Andrew Pinski --- apinski@xeond:~/src/upstream-gcc/gcc/objdir/stage1-gcc$ ./xgcc -B. -fcompare-debug -O2 t.c xgcc: error: t.c: ‘-fcompare-debug’ failure (length) This is a recent regression, it worked with 20210523.
[Bug target/100777] MMA builtin usage ICEs when used in a #pragma omp parallel and using -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100777 Peter Bergner changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2021-May/571 ||339.html Target Milestone|--- |12.0 Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org
[Bug tree-optimization/100781] New: Emitted binary code changes when -g is enabled at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100781
Bug ID: 100781
Summary: Emitted binary code changes when -g is enabled at -O2
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tlwang at uwaterloo dot ca
Target Milestone: ---
The .text section for the following program (transformed_program0.c) changes
after toggling the -g flag.
$ cat transformed_program0.c
struct a {
int b;
};
long c(short d, long e, struct a f) {
g:;
int h = f.b <= e, i = d, n = h >= d;
if (!n)
goto j;
goto k;
j:;
long l = 5;
if (l)
goto m;
d = 0;
m:
if (d)
return f.b;
k:
goto g;
}
int main() {}
$
$ 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.tVhv2eaPzV-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 20210526 (experimental) [master revision
:21638bbbf:1fd76b24306ed4df4cf9e797d900699ed59ce7f7] (GCC)
$
$ gcc-trunk transformed_program0.c -O2 -w ; objdump --disassemble a.out >
"no-g.txt"
$ gcc-trunk transformed_program0.c -O2 -w -g; objdump --disassemble a.out >
"g.txt"
$ diff no-g.txt g.txt
108,111c108,111
< 401125: 89 f9 mov%edi,%ecx
< 401127: 0f bf ffmovswl %di,%edi
< 40112a: 49 39 f0cmp%rsi,%r8
< 40112d: 0f 9e c0setle %al
---
> 401125: 0f bf ffmovswl %di,%edi
> 401128: 4c 39 c6cmp%r8,%rsi
> 40112b: 0f 9d c0setge %al
> 40112e: 66 90 xchg %ax,%ax
114,118c114,117
< 401134: 66 85 c9test %cx,%cx
< 401137: 74 f7 je 401130
< 401139: 4c 89 c0mov%r8,%rax
< 40113c: c3 retq
< 40113d: 0f 1f 00nopl (%rax)
---
> 401134: 4c 89 c0mov%r8,%rax
> 401137: c3 retq
> 401138: 0f 1f 84 00 00 00 00nopl 0x0(%rax,%rax,1)
> 40113f: 00
[Bug target/100757] [12 Regression] arm: ICE (unrecognizable insn) with MVE VPSELQ_S since r12-834-ga6eacbf10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100757 --- Comment #8 from Christophe Lyon --- At expand time, we have: (insn 33 32 34 6 (set (reg:V4SI 144) (const_vector:V4SI [ (const_int 0 [0]) repeated x4 ])) "bz-100757.c":5:12 -1 (nil)) (insn 34 33 35 6 (set (reg:HI 143) (ne:HI (reg:V4SI 126 [ vect_cst__32 ]) (reg:V4SI 144))) "bz-100757.c":5:12 -1 (nil)) (insn 35 34 36 6 (set (reg:V4SI 145) (const_vector:V4SI [ (const_int 0 [0]) repeated x4 ])) "bz-100757.c":5:12 -1 (nil)) (insn 36 35 37 6 (set (reg:V4SI 146) (const_vector:V4SI [ (const_int 1 [0x1]) repeated x4 ])) "bz-100757.c":5:12 -1 (nil)) (insn 37 36 38 6 (set (reg:V4SI 142 [ mask__1.8 ]) (unspec:V4SI [ (reg:V4SI 146) (reg:V4SI 145) (reg:HI 143) ] VPSELQ_S)) "bz-100757.c":5:12 -1 (nil)) (insn 38 37 39 6 (set (reg:V4SI 147 [ mask__2.9 ]) (ior:V4SI (reg:V4SI 142 [ mask__1.8 ]) (reg:V4SI 130 [ vect_cst__36 ]))) "bz-100757.c":5:14 -1 (nil)) (insn 39 38 40 6 (set (reg:V4SI 148) (const_vector:V4SI [ (const_int 1 [0x1]) repeated x4 ])) -1 (nil)) (insn 40 39 41 6 (set (reg:V4SI 149) (const_vector:V4SI [ (const_int 0 [0]) repeated x4 ])) -1 (nil)) (insn 41 40 42 6 (set (reg:V4SI 132 [ vect_patt_4.10 ]) (unspec:V4SI [ (reg:V4SI 148) (reg:V4SI 149) (reg:V4SI 147 [ mask__2.9 ]) ] VPSELQ_S)) -1 (nil)) The problem is with the second VPSELQ_S, where operand 3 is not of HI type.
[Bug c++/63164] unnecessary calls to __dynamic_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164 Marc Glisse changed: What|Removed |Added Last reconfirmed||2021-05-26 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Marc Glisse --- I was going to file exactly the same RFE for dynamic_cast and final types (preferably it should also work if 'final' is only detected by LTO, but that shouldn't block an easier front-end patch), so confirmed.
[Bug fortran/100656] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1934
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100656 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org CC||anlauf at gcc dot gnu.org --- Comment #4 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-May/056088.html
[Bug tree-optimization/100780] New: __builtin___sprintf_chk not optimized when it could be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100780
Bug ID: 100780
Summary: __builtin___sprintf_chk not optimized when it could be
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Calls to __builtin___sprintf_chk that can be proven not to overflow the
destination can be folded to calls to plain sprintf (or even memcpy). Only the
simplest are, but the more interesting ones aren't, even though the sprintf
pass has all the smarts to do it.
$ cat a.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout a.c
extern char a[32];
void f (void)
{
__builtin___sprintf_chk (a, 0, sizeof a, "%s", "1234"); // optimized
}
void g (void)
{
__builtin___sprintf_chk (a, 0, sizeof a, "%i", 1234);// not optimized
}
;; Function f (f, funcdef_no=0, decl_uid=1944, cgraph_uid=1, symbol_order=0)
void f ()
{
[local count: 1073741824]:
__builtin_memcpy (, "1234", 5); [tail call]
return;
}
;; Function g (g, funcdef_no=1, decl_uid=1947, cgraph_uid=2, symbol_order=1)
void g ()
{
[local count: 1073741824]:
__builtin___sprintf_chk (, 0, 32, "%i", 1234); [tail call]
return;
}
[Bug d/100769] [D] memcmp() == 0 for small constant strings not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100769 Witold Baryluk changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug d/100769] [D] memcmp() == 0 for small constant strings not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100769 Witold Baryluk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Witold Baryluk --- Ok. That makes sense. Thanks.
[Bug tree-optimization/100773] [12 Regression] ice in operator[], at vec.h:890
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100773 Andrew Pinski changed: What|Removed |Added Summary|ice in operator[], at |[12 Regression] ice in |vec.h:890 |operator[], at vec.h:890 Target Milestone|--- |12.0
[Bug c++/100502] [11/12 Regression] ICE in enforce_access at cp/semantics.c:368 since r11-6800-g29853c653245c37e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100502 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:abe8787a8492013145b275b858f70943522d7226 commit r12-1082-gabe8787a8492013145b275b858f70943522d7226 Author: Patrick Palka Date: Wed May 26 16:02:33 2021 -0400 c++: access for hidden friend of nested class template [PR100502] Here, during ahead of time access checking for the private member EnumeratorRange::end_reached_ in the hidden friend f, we're triggering the assert in enforce_access that verifies we're not trying to add a access check for a dependent decl onto TI_DEFERRED_ACCESS_CHECKS. The special thing about this class member access expression is that the overall expression is non-dependent (so finish_class_member_access_expr doesn't exit early at parse time), and then accessible_p rejects the access (so we don't exit early from enforce access either, and end up triggering the assert b/c the member itself is dependent). I think we're correct to reject the access because a hidden friend is not a member function, so [class.access.nest] doesn't apply, and also a hidden friend of a nested class is not a friend of the enclosing class. To fix this ICE, this patch disables ahead of time access checking during the member lookup in finish_class_member_access_expr. This avoids potentially pushing an access check for a dependent member onto TI_DEFERRED_ACCESS_CHECKS, and it's safe because we're going to redo the same lookup at instantiation time anyway. PR c++/100502 gcc/cp/ChangeLog: * typeck.c (finish_class_member_access_expr): Disable ahead of time access checking during the member lookup. gcc/testsuite/ChangeLog: * g++.dg/template/access37.C: New test. * g++.dg/template/access37a.C: New test.
[Bug c++/100754] Order of multiple inheritance can lead to illegal code jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100754 --- Comment #2 from Martin --- Hi Richard, Thanks for the quick response. I had to do a bit of research to try to properly express my suspicions. 1st the function from the dispatch table is properly called. Not problems there: 01a4 <_ZThn4_N7Derived9ModifyIntEi>: It's the body of this reference function that seems wrong. It should do a local relative jump to the implementation address, but instead performs a global relocation, making the implementation function's address change based on the current shared object it's being called from. // Base. int ModifyInt(int value) override; 1a4: 30a5fffcaddik r5, r5, -4 1a8: b000imm 0 1a8: R_MICROBLAZE_GOT_64$LTHUNK2 1ac: e994lwi r12, r20, 0 1b0: 98086000bra r12 We x-compile and natively compile similar code on a few platforms and only the microblaze one generates such code. For instance, the sample program attached in the bug entry generates the following code on different compilers: //proper local jump from inside the reference function aarch64, gcc8.2.0: 00d8 <_ZThn8_N7Derived9ModifyIntEi>: d8: d1002000sub x0, x0, #0x8 dc: 17f7b b8 <_ZN7Derived9ModifyIntEi> // jumps to implementation function. //proper local jump from inside the reference function aarch64, gcc 8.2.0: 0128 <_ZThn4_N7Derived9ModifyIntEi>: 128: e244sub r0, r0, #4 12c: eaf1b f8 <_ZN7Derived9ModifyIntEi> // again //proper local jump from inside the reference function x86_64, gcc 5.4.0: 00c8 <_ZThn8_N7Derived9ModifyIntEi>: c8: 48 83 ef 08 sub$0x8,%rdi cc: eb e6 jmpb4 <_ZN7Derived9ModifyIntEi> // and again... So these last 3 compilers properly generated the local relocation, where the microblaze code generates global relocation for that thunk. Wouldn't that point to the microblaze backend? Also, it is highly suspicious that inverting the order of the parent classes changes the generated code. And that would point at the gcc front end?
[Bug c++/100752] [11/12 Regression] error: cannot call member function ‘void S::f()’ without object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100752 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Mine then.
[Bug tree-optimization/100778] [11 Regression] Get SIGFPE on simple test with -fpe-trap=invalid and SLP vectorization ON, with gfortran 11.1.0 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100778 anlauf at gcc dot gnu.org changed: What|Removed |Added Component|fortran |tree-optimization --- Comment #2 from anlauf at gcc dot gnu.org --- Changing component to tree-optimization for inspection by experts.
[Bug c++/100752] [11/12 Regression] error: cannot call member function ‘void S::f()’ without object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100752 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|NEW
[Bug c++/100752] [11/12 Regression] error: cannot call member function ‘void S::f()’ without object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100752 Jason Merrill changed: What|Removed |Added Assignee|jason at gcc dot gnu.org |unassigned at gcc dot gnu.org CC||mpolacek at gcc dot gnu.org --- Comment #1 from Jason Merrill --- This is happening because we aren't deferring the parse of this noexcept the way we're supposed to. Marek?
[Bug middle-end/100734] [12 Regression] /test/gnu/gcc/objdir/gcc/include-fixed/stdlib.h:291:8: internal compiler error: in from_mode_char, at attribs.h:304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100734 --- Comment #10 from dave.anglin at bell dot net --- On 2021-05-25 3:04 p.m., msebor at gcc dot gnu.org wrote: > In parallel, I wonder if there's something funny about > snprintf on HP-UX. Does the snprintf call added in r12-930 do the right thing > (i.e., append a nonempty string to spec)? No. When passed a size of 0, snprintf on hpux11.11 returns 0. This issue is noted in Linux man page for snprintf. Attached a possible fix.
[Bug c/100719] missing -Wvla-parameter on a mismatch in second parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100719 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #1 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571332.html
[Bug fortran/100778] [11 Regression] Get SIGFPE on simple test with -fpe-trap=invalid and SLP vectorization ON, with gfortran 11.1.0 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100778 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to fail||11.1.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Known to work||10.3.0, 12.0 Keywords||wrong-code Summary|Get SIGFPE on simple test |[11 Regression] Get SIGFPE |with -fpe-trap=invalid and |on simple test with |SLP vectorization ON, with |-fpe-trap=invalid and SLP |gfortran 11.1.0 on x86_64 |vectorization ON, with ||gfortran 11.1.0 on x86_64 Last reconfirmed||2021-05-26 CC||anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed for 11.1, but mainline (12-trunk) seems fine (again?). Comparing the assembler code for both, there seems to be a lot going on ...
[Bug c++/100752] [11/12 Regression] error: cannot call member function ‘void S::f()’ without object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100752 Jason Merrill changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-05-26
[Bug c++/100779] Partial specialization with non-deducible template parameters accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100779
--- Comment #1 from Patrick Palka ---
Another accepts-invalid example:
template struct A;
template struct B;
template struct B> { };
[Bug c++/100779] New: Partial specialization with non-deducible template parameters accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100779
Bug ID: 100779
Summary: Partial specialization with non-deducible template
parameters accepted
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
template struct A;
template struct B;
template struct B> { };
This partial specialization should be rejected because its template parameter T
is not deducible.
[Bug fortran/100778] New: Get SIGFPE on simple test with -fpe-trap=invalid and SLP vectorization ON, with gfortran 11.1.0 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100778 Bug ID: 100778 Summary: Get SIGFPE on simple test with -fpe-trap=invalid and SLP vectorization ON, with gfortran 11.1.0 on x86_64 Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gabrielle.hugo at cern dot ch Target Milestone: --- Hello, Updating gfortran from 10.3.0 to 11.1.0 leads to SIGFPE in a Fortran 77 project (all things else equal). The issue can actually be isolated and reproduced on x86_64 with the equivalent simple test.f [1]: it runs smoothly when compiled with gfortran 10.3.0, and leads to SIGFPE with gfortran 11.1.0. To reproduce: gfortran -O3 -Wall -Wextra -g -ffpe-trap=invalid test.f -o test ./test The FPE is thrown from `x = x / norm` (while the branch should not have been entered). The issue disappears if additionally compiling with -fno-tree-slp-vectorize, or if placing a printout in between `x = x / norm` and ` y = y / norm`. The issue does not appear on ARM (tested on Apple M1). Thanks in advance [1] test.f: program test implicit none double precision input(2) input(1) = 0.D+00 input(2) = 0.D+00 call normalize(input) end subroutine normalize(input) implicit none double precision input(2) double precision x, y, norm common / coordinates / x, y save / coordinates / x = input(1) y = input(2) norm = sqrt(x**2 + y**2) if (norm .gt. 1.D+00) then x = x / norm y = y / norm write (*, *) 'Normalized x and y.' end if write (*, *) 'Ended as expected.' end [2] gcc versions: gcc version 10.3.0 (GCC) Configured with: /build/dkonst/gcc-clang/build/contrib/gcc-10.3.0/src/gcc/10.3.0/configure --prefix=/build/dkonst/gcc-clang/lcgcmake-install/gcc/10.3.0/x86_64-centos7 -with-system-zlib --disable-multilib --enable-languages=all --with-gnu-ld --with-gnu-as Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.1.0 (GCC) Target: x86_64-pc-linux-gnu Configured with: /build/dkonst/gcc-clang-2/build/contrib/gcc-11.1.0/src/gcc/11.1.0/configure --prefix=/build/dkonst/gcc-clang-2/lcgcmake-install/gcc/11.1.0/x86_64-centos7 -with-system-zlib --disable-multilib --enable-languages=all --with-gnu-ld --with-gnu-as Thread model: posix Supported LTO compression algorithms: zlib Tested on Centos7 and Fedora33. [3] objdump -S test gfortran 10.3.0 case: x = input(1) 4011d9: f2 0f 10 0f movsd (%rdi),%xmm1 y = input(2) 4011dd: f2 0f 10 57 08 movsd 0x8(%rdi),%xmm2 x = input(1) 4011e2: 66 0f 10 27 movupd (%rdi),%xmm4 norm = sqrt(x**2 + y**2) 4011e6: 66 0f 28 c1 movapd %xmm1,%xmm0 4011ea: 66 0f 28 da movapd %xmm2,%xmm3 4011ee: f2 0f 59 c1 mulsd %xmm1,%xmm0 x = input(1) 4011f2: 0f 29 25 77 2e 00 00movaps %xmm4,0x2e77(%rip)# 404070 norm = sqrt(x**2 + y**2) 4011f9: f2 0f 59 da mulsd %xmm2,%xmm3 4011fd: f2 0f 58 c3 addsd %xmm3,%xmm0 401201: f2 0f 51 c0 sqrtsd %xmm0,%xmm0 if (norm .gt. 1.D+00) then 401205: 66 0f 2f 05 53 0e 00comisd 0xe53(%rip),%xmm0# 402060 40120c: 00 40120d: 77 51 ja 401260 40120f: 48 8b 1d 52 0e 00 00mov0xe52(%rip),%rbx# 402068 401216: 48 89 e5mov%rsp,%rbp x = x / norm y = y / norm write (*, *) 'Normalized x and y.' end if gfortran 11.1.0 case: x = input(1) 4011d9: 66 0f 10 0f movupd (%rdi),%xmm1 4011dd: 66 0f 28 d9 movapd %xmm1,%xmm3 4011e1: 66 0f 28 c1 movapd %xmm1,%xmm0 4011e5: 0f 29 0d 84 2e 00 00movaps %xmm1,0x2e84(%rip)# 404070 y = input(2) norm = sqrt(x**2 + y**2) 4011ec: f2 0f 59 c1 mulsd %xmm1,%xmm0 4011f0: 66 0f 15 db unpckhpd %xmm3,%xmm3 4011f4: 66 0f 28 d3 movapd %xmm3,%xmm2 4011f8: f2 0f 59 d3 mulsd %xmm3,%xmm2 4011fc: f2 0f 58 c2 addsd %xmm2,%xmm0 401200: f2 0f 51 c0 sqrtsd %xmm0,%xmm0 if (norm .gt. 1.D+00) then 401204: 66 0f 2f 05 54 0e 00comisd 0xe54(%rip),%xmm0# 402060 40120b: 00 x = x / norm 40120c: 66 0f 28 d0 movapd %xmm0,%xmm2 401210: 66 0f 14 d2 unpcklpd %xmm2,%xmm2 401214: 66 0f 5e ca divpd %xmm2,%xmm1 if (norm .gt. 1.D+00) then 401218: 77 4e ja 401268 40121a: 48 8b 1d
[Bug libstdc++/100768] Range iterator operations should be function objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100768 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a49a045b92f982f5617c3bbde97a33157237e25b commit r12-1074-ga49a045b92f982f5617c3bbde97a33157237e25b Author: Jonathan Wakely Date: Wed May 26 17:32:53 2021 +0100 libstdc++: Change [range.iter.op] functions to function objects [PR 100768] The standard specifies std::ranges::distance etc as function templates, but it also requires them to not be found by ADL, and to suppress ADL when normal unqualified lookup does find them. That means they need to be function objects. libstdc++-v3/ChangeLog: PR libstdc++/100768 * include/bits/ranges_base.h (advance, distance, next, prev): Replace function templates with function objects. * testsuite/24_iterators/headers/iterator/synopsis_c++20.cc: Adjust for changes to function objects. * testsuite/std/ranges/adaptors/elements.cc: Add using declarations for names from namespace ranges. * testsuite/std/ranges/adaptors/transform.cc: Likewise. * testsuite/24_iterators/range_operations/100768.cc: New test.
[Bug target/100777] MMA builtin usage ICEs when used in a #pragma omp parallel and using -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100777 Peter Bergner changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2021-05-26 Target||powerpc64le-linux Known to fail||10.0, 11.0, 12.0 --- Comment #1 from Peter Bergner --- Mine. I have a patch I'm testing that changes the MMA gimple builtin expansion code to use create_tmp_reg_or_ssa_name() rather than make_ssa_name() that seems to fix the ICE.
[Bug target/100777] New: MMA builtin usage ICEs when used in a #pragma omp parallel and using -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100777
Bug ID: 100777
Summary: MMA builtin usage ICEs when used in a #pragma omp
parallel and using -fopenmp
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
bergner@pike:~/$ cat bug.i
void
foo (__vector_quad *dst)
{
#pragma omp parallel
{
__builtin_mma_xxsetaccz (dst);
}
}
bergner@pike:~/$ gcc -S -O1 -mcpu=power10 -fopenmp bug.i
during GIMPLE pass: ssa
bug.i: In function ‘foo’:
bug.i:8:1: internal compiler error: Segmentation fault
8 | }
| ^
0x10b89f63 crash_signal
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/toplev.c:327
0x10ea5a00 verify_ssa(bool, bool)
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/tree-ssa.c:1070
...
This fails on trunk back to GCC10 (ie, first MMA support).
[Bug d/100769] [D] memcmp() == 0 for small constant strings not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100769 --- Comment #3 from Iain Buclaw --- (In reply to Witold Baryluk from comment #2) > Hmm. It appears that using `import core.stdc.string : memcmp;` actually > resolves the problem. It looks like my manually declaration of memcmp for > some reason disabled optimisations for memcmp. Yes, for protective reasons, only extern(C) symbols in `core.stdc` are considered as possible candidates for mapping to GCC built-ins.
[Bug fortran/100776] New: Error in automatic object of parameterized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100776 Bug ID: 100776 Summary: Error in automatic object of parameterized derived type Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: furquan2011 at gmail dot com Target Milestone: --- gfortran gives a compilation error while trying to use an automatic object of a parameterized derived type. For example, trying to compile ``` module vector type :: vec(dimen) integer,len :: dimen real:: e(dimen) end type vec contains function double(a) type(vec(*)),intent(in) :: a type(vec(a%dimen)) :: double double%e = 2.*a%e end function double end module vector results into the following error: Error: The AUTOMATIC object ‘double’ at (1) must not have the SAVE attribute or be a variable declared in the main program, a module or a submodule(F08/C513) As much as I know, there is no SAVEd variable here. The code works without issues with intel and NAG compilers.
[Bug c/100653] usage of scalar_storage_order produces incorrect result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100653 --- Comment #6 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:401bd4adcfda9965363b1ac3ba7e1580f15d6883 commit r12-1072-g401bd4adcfda9965363b1ac3ba7e1580f15d6883 Author: Eric Botcazou Date: Wed May 26 19:12:05 2021 +0200 Warn on type punning that toggles scalar storage order As documented in the manual, we do not support type punning that toggles the scalar storage order, so this adds a warning for the case of unions. gcc/c/ PR c/100653 * c-decl.c (finish_struct): Warn for a union containing an aggregate field with a differing scalar storage order. gcc/testsuite/ * gcc.dg/sso-13.c: New test.
[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453 Khem Raj changed: What|Removed |Added CC||raj.khem at gmail dot com --- Comment #8 from Khem Raj --- this change seems to cause a regression when build baremetal toolchain, it ends up generating /usr/lib/-gdb.py instead of libstdc++-gdb.py, the gcc tuple to build is arm-none-eabi the libstdc++.la looks like this # libstdc++.la - a libtool library file # Generated by libtool (GNU libtool 1.3134 2009-11-29) 2.2.7a # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='' # Names of this library. library_names='' # The name of the static archive. old_library='libstdc++.a' # Linker flags that can not go in dependency_libs. inherited_linker_flags='' # Libraries that this one depends upon. dependency_libs=' -lm' # Names of additional weak libraries provided by this library weak_library_names='' # Version information for libstdc++. current=6 age=0 revision=29 # Is this an already installed library? installed=no # Should we warn about portability when linking against -modules? shouldnotlink=no # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/usr/lib'
Order Requirements from 06:13:21 PM
Hello dear friend,
How are you and hope you are safe regarding the corona virus pandemic?
As instructed by our customer earlier, see below our order requirements.
Please check and arrange the Profoma invoice for remittance.
View Excel File Online (526kb)
: VIEW EXCEL FILE : OPEN EXCEL FILE
Please, do you also have ISO standard, CE certificate or any certificatio?
Because we couldn't find any on your website.
Let me know if any there are any questions.
Warm reminder: Reduce going out, wear masks, protect yourself and protect
others as we deal with this pandemic together.
Best Regards,
Steve Fu.
This Excel file was sent to {gcc-bugs@gcc.gnu.org}.
[Bug target/100757] [12 Regression] arm: ICE (unrecognizable insn) with MVE VPSELQ_S since r12-834-ga6eacbf10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100757 --- Comment #7 from Alex Coplan --- Note that it also ICEs with e.g. -mtune=arm920t.
[Bug target/100757] [12 Regression] arm: ICE (unrecognizable insn) with MVE VPSELQ_S since r12-834-ga6eacbf10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100757 --- Comment #6 from Christophe Lyon --- That's related to the tune_params::LOG_OP_NON_SHORT_CIRCUIT tuning param for Thumb mode. Setting it to FALSE in the a53 tuning params (used by a55) avoids the ICE.
[Bug target/100775] New: ICE: in df_exit_block_bitmap_verify, at df-scan.c:4164 with -mthumb -fzero-call-used-regs=used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100775 Bug ID: 100775 Summary: ICE: in df_exit_block_bitmap_verify, at df-scan.c:4164 with -mthumb -fzero-call-used-regs=used Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: armv7a-hardfloat-linux-gnueabi Created attachment 50873 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50873=edit reduced testcase Compiler output: $ armv7a-hardfloat-linux-gnueabi-gcc -mthumb -fzero-call-used-regs=used testcase.c exit_block_uses = 0 [r0] 3 [r3] 7 [r7] 13 [sp] 14 [lr] 102 [sfp] df->exit_block_uses = 0 [r0] 7 [r7] 13 [sp] 14 [lr] 102 [sfp] during RTL pass: mach testcase.c: In function 'foo': testcase.c:5:1: internal compiler error: in df_exit_block_bitmap_verify, at df-scan.c:4164 5 | } | ^ 0xbb6462 df_exit_block_bitmap_verify /repo/gcc-trunk/gcc/df-scan.c:4164 0xbb6462 df_scan_verify() /repo/gcc-trunk/gcc/df-scan.c:4217 0xba0067 df_verify() /repo/gcc-trunk/gcc/df-core.c:1818 0xba0067 df_analyze_1 /repo/gcc-trunk/gcc/df-core.c:1214 0x13b5a99 thumb2_reorg /repo/gcc-trunk/gcc/config/arm/arm.c:18990 0x13b5a99 arm_reorg /repo/gcc-trunk/gcc/config/arm/arm.c:19209 0xf96979 execute /repo/gcc-trunk/gcc/reorg.c:3927 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. $ armv7a-hardfloat-linux-gnueabi-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-armv7a-hardfloat/bin/armv7a-hardfloat-linux-gnueabi-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-1066-20210526112842-g95d67762171-checking-yes-rtl-df-extra-armv7a-hardfloat/bin/../libexec/gcc/armv7a-hardfloat-linux-gnueabi/12.0.0/lto-wrapper Target: armv7a-hardfloat-linux-gnueabi Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-float=hard --with-fpu=vfpv4 --with-arch=armv7-a --with-sysroot=/usr/armv7a-hardfloat-linux-gnueabi --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=armv7a-hardfloat-linux-gnueabi --with-ld=/usr/bin/armv7a-hardfloat-linux-gnueabi-ld --with-as=/usr/bin/armv7a-hardfloat-linux-gnueabi-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-1066-20210526112842-g95d67762171-checking-yes-rtl-df-extra-armv7a-hardfloat Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.0 20210526 (experimental) (GCC)
[Bug testsuite/100750] new test case gcc.target/powerpc/rop-5.c fails on BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100750 --- Comment #1 from seurer at gcc dot gnu.org --- There are also some failures with gcc 11 including on power 10 LE. FAIL: gcc.target/powerpc/rop-3.c (test for excess errors) FAIL: gcc.target/powerpc/rop-5.c (test for excess errors) FAIL: gcc.target/powerpc/rop-5.c (test for excess errors)
[Bug libstdc++/100770] Incorrect if constexpr statement in ranges::unique_copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100770 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- We should use a requires expression here instead.
compiler produces an error message
[ver]i try compile it on gcc 11 and gcc 12 [new features]i use gcc modules features(module;export module, import, import export) [command]g++ *.cpp -std=c++20 -fmodules-ts /usr/lib/gcc/x86_64-pc-linux-gnu/12.0.0/include/g++-v12/bits/basic_string.h: In member function ‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::pointer std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_M_create(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type&, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type) [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]’: /usr/lib/gcc/x86_64-pc-linux-gnu/12.0.0/include/g++-v12/bits/basic_string.h:233:7: error: unrecognizable insn: 233 | _M_create(size_type&, size_type); | ^ (insn 20 19 21 5 (set (reg:DI 98) (reg/v 87 [ __old_capacity ])) "/usr/lib/gcc/x86_64-pc-linux-gnu/12.0.0/include/g++-v12/bits/basic_string.tcc":143:7 -1 (nil)) during RTL pass: vregs /usr/lib/gcc/x86_64-pc-linux-gnu/12.0.0/include/g++-v12/bits/basic_string.h:233:7: internal compiler error: in extract_insn, at recog.c:2770
[Bug tree-optimization/100774] [12 Regression] -fcompare-debug failure (length) with -O2 -fno-tree-forwprop --param=evrp-mode=ranger-trace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100774 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com, ||jakub at gcc dot gnu.org Status|UNCONFIRMED |NEW Priority|P3 |P1 Last reconfirmed||2021-05-26 Target Milestone|--- |12.0 --- Comment #1 from Jakub Jelinek --- Started with r12-852-g3f476de7fd274f619a0b04c2e2f7077ee8ab17a5
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751 --- Comment #12 from Gejoe --- Thanks for all the info. > Btw. why do you need calling __gcov_dump and __gcov_reset manually? How is > your training run special? Actually I work for a firm where the program runs on a device continually and we get the .gcda files from the device using a command which in turn invoked __gcov_dump(). Similarly to reset all the counters, we thought of using __gcov_reset after a __gcov_dump. We tar up the gcda files and take to the source code where gcov is run.
[Bug tree-optimization/100774] New: [12 Regression] -fcompare-debug failure (length) with -O2 -fno-tree-forwprop --param=evrp-mode=ranger-trace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100774
Bug ID: 100774
Summary: [12 Regression] -fcompare-debug failure (length) with
-O2 -fno-tree-forwprop --param=evrp-mode=ranger-trace
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
CC: aoliva at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Created attachment 50872
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50872=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-g++ -O2 -fno-tree-forwprop --param=evrp-mode=ranger-trace
-fcompare-debug testcase.C
x86_64-pc-linux-gnu-g++: error: testcase.C: '-fcompare-debug' failure (length)
$ diff -u *gkd
--- a-testcase.C.gkd2021-05-26 17:07:09.776753885 +0200
+++ a-testcase.gk.C.gkd 2021-05-26 17:07:09.856753886 +0200
@@ -1,31 +1,15 @@
-Declarations used by foo, sorted by DECL_UID:
-0: extern void error (void);
;; Function foo (_Z3foov, funcdef_no=1, cgraph_uid=2, symbol_order=2)
(executed once)
(note # 0 0 NOTE_INSN_DELETED)
-(note # 0 0 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note # 0 0 NOTE_INSN_FUNCTION_BEG)
-(insn/f:TI # 0 0 2 (parallel [
-(set (reg/f:DI 7 sp)
-(plus:DI (reg/f:DI 7 sp)
-(const_int -8 [0xfff8])))
-(clobber (reg:CC 17 flags))
-(clobber (mem:BLK (scratch) [ A8]))
-]) "testcase.C":12:1# {pro_epilogue_adjust_stack_add_di}
- (expr_list:REG_UNUSED (reg:CC 17 flags)
-(expr_list:REG_CFA_ADJUST_CFA (set (reg/f:DI 7 sp)
-(plus:DI (reg/f:DI 7 sp)
-(const_int -8 [0xfff8])))
-(nil
(note # 0 0 NOTE_INSN_PROLOGUE_END)
-(call_insn:TI # 0 0 2 (call (mem:QI (symbol_ref:DI ("_Z5errorv") [flags 0x41]
) [ error S1 A8])
-(const_int 0 [0])) "testcase.C":19:12# {*call}
- (expr_list:REG_CALL_DECL (symbol_ref:DI ("_Z5errorv") [flags 0x41]
)
-(expr_list:REG_ARGS_SIZE (const_int 0 [0])
-(expr_list:REG_NORETURN (const_int 0 [0])
-(nil
-(nil))
+(code_label # 0 0 2 2 (nil) [1 uses])
+(note # 0 0 [bb 2] NOTE_INSN_BASIC_BLOCK)
+(jump_insn:TI # 0 0 2 (set (pc)
+(label_ref #))# {jump}
+ (nil)
+ -> 2)
(barrier # 0 0)
(note # 0 0 NOTE_INSN_DELETED)
[Bug ada/36638] c34008: Program received signal SIGILL, Illegal instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36638 Eric Botcazou changed: What|Removed |Added Resolution|--- |WONTFIX Status|WAITING |RESOLVED --- Comment #3 from Eric Botcazou --- .
[Bug libstdc++/100770] Incorrect if constexpr statement in ranges::unique_copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100770 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Last reconfirmed||2021-05-26 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug ada/71911] [Cygwin] "gnatclean program" will remove the standard package .ali file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71911 Eric Botcazou changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #7 from Eric Botcazou --- .
[Bug ada/66390] Text_IO.Get_Line does not correctly handle missing line marker for last line in all cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66390 Eric Botcazou changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Eric Botcazou --- .
[Bug ada/66525] Implicit function declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66525 Eric Botcazou changed: What|Removed |Added Resolution|--- |WONTFIX Status|WAITING |RESOLVED --- Comment #2 from Eric Botcazou --- .
[Bug c++/100772] New: Templated coroutine new function's arguments have incorrect value categories/overload selection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100772 Bug ID: 100772 Summary: Templated coroutine new function's arguments have incorrect value categories/overload selection Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: davidledger at live dot com.au Target Milestone: --- Hello! When using c++20 coroutines the overload selection for operator new is incorrect. ~~~ The reference collapsing for reference arguments is disfunctional. For this: ```CPP Task Foo(auto && ... args) noexcept; int v; Foo(v, 2134); ``` With user provided new: ```CPP void* operator new(std::size_t len, auto && ...args) noexcept; ``` No arguments are provided to the new function (ie. sizeof...(args) == 0). This is demonstrated here: https://godbolt.org/z/dd3PEbc74 ~~~ The arguments are not provided as lvalues: For this: ```CPP Task Foo(auto && ... args) noexcept; int v; Foo(v, 2134); ``` With this user provided operator new: ```CPP void* operator new(std::size_t len, auto...args) noexcept; ``` The compiler selects this: ```CPP void* operator new(std::size_t len, int , int &) noexcept; ``` Note, arg2 here is an rvalue, which is not as per the standard: https://eel.is/c++draft/dcl.fct.def.coroutine#9.1 Specifically: "...The lvalues p1…pn are the succeeding arguments." There is an rvalue above. This is demonstrated here: https://godbolt.org/z/Yx7T8ndn1
[Bug c/100771] New: Types differ between i386-elf and x86_64-elf -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100771 Bug ID: 100771 Summary: Types differ between i386-elf and x86_64-elf -m32 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: pmenzel+gcc at molgen dot mpg.de Target Milestone: --- coreboot still builds 32-bit objects(?), and passes `-m32` for “64-bit compilers”. Doing that, sometimes there are type differences, which is unexpected. For GCC 8.3.0: ``` $ diff -u <(:|/dev/shm/coreboot/util/crossgcc/xgcc/bin/i386-elf-gcc -E -dM -|sort) <(:|/dev/shm/coreboot/util/crossgcc/xgcc/bin/x86_64-elf-gcc -m32 -E -dM -|sort) --- /dev/fd/63 2021-05-26 16:51:51.94800 +0200 +++ /dev/fd/62 2021-05-26 16:51:51.94800 +0200 @@ -132,18 +132,23 @@ #define __FLT_MIN_EXP__ (-125) #define __FLT_NORM_MAX__ 3.40282346638528859811704183484516925e+38F #define __FLT_RADIX__ 2 +#define __FXSR__ 1 #define __GCC_ASM_FLAG_OUTPUTS__ 1 -#define __GCC_ATOMIC_BOOL_LOCK_FREE 1 -#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1 -#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 1 -#define __GCC_ATOMIC_CHAR_LOCK_FREE 1 -#define __GCC_ATOMIC_INT_LOCK_FREE 1 -#define __GCC_ATOMIC_LLONG_LOCK_FREE 1 -#define __GCC_ATOMIC_LONG_LOCK_FREE 1 -#define __GCC_ATOMIC_POINTER_LOCK_FREE 1 -#define __GCC_ATOMIC_SHORT_LOCK_FREE 1 +#define __GCC_ATOMIC_BOOL_LOCK_FREE 2 +#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 2 +#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2 +#define __GCC_ATOMIC_CHAR_LOCK_FREE 2 +#define __GCC_ATOMIC_INT_LOCK_FREE 2 +#define __GCC_ATOMIC_LLONG_LOCK_FREE 2 +#define __GCC_ATOMIC_LONG_LOCK_FREE 2 +#define __GCC_ATOMIC_POINTER_LOCK_FREE 2 +#define __GCC_ATOMIC_SHORT_LOCK_FREE 2 #define __GCC_ATOMIC_TEST_AND_SET_TRUEVAL 1 -#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 1 +#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2 +#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1 +#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1 +#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1 +#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1 #define __GCC_IEC_559 2 #define __GCC_IEC_559_COMPLEX 2 #define __GNUC__ 11 @@ -200,10 +205,12 @@ #define __INTMAX_MAX__ 0x7fffLL #define __INTMAX_TYPE__ long long int #define __INTMAX_WIDTH__ 64 -#define __INTPTR_MAX__ 0x7fffL -#define __INTPTR_TYPE__ long int +#define __INTPTR_MAX__ 0x7fff +#define __INTPTR_TYPE__ int #define __INTPTR_WIDTH__ 32 #define __INT_WIDTH__ 32 +#define __k8 1 +#define __k8__ 1 #define __LAHF_SAHF__ 1 #define __LDBL_DECIMAL_DIG__ 21 #define __LDBL_DENORM_MIN__ 3.64519953188247460252840593361941982e-4951L @@ -225,13 +232,14 @@ #define __LONG_LONG_WIDTH__ 64 #define __LONG_MAX__ 0x7fffL #define __LONG_WIDTH__ 32 +#define __MMX__ 1 #define __NO_INLINE__ 1 #define __ORDER_BIG_ENDIAN__ 4321 #define __ORDER_LITTLE_ENDIAN__ 1234 #define __ORDER_PDP_ENDIAN__ 3412 #define __PRAGMA_REDEFINE_EXTNAME 1 -#define __PTRDIFF_MAX__ 0x7fffL -#define __PTRDIFF_TYPE__ long int +#define __PTRDIFF_MAX__ 0x7fff +#define __PTRDIFF_TYPE__ int #define __PTRDIFF_WIDTH__ 32 #define __REGISTER_PREFIX__ #define __SCHAR_MAX__ 0x7f @@ -244,7 +252,7 @@ #define __SIG_ATOMIC_MIN__ (-__SIG_ATOMIC_MAX__ - 1) #define __SIG_ATOMIC_TYPE__ int #define __SIG_ATOMIC_WIDTH__ 32 -#define __SIZE_MAX__ 0xUL +#define __SIZE_MAX__ 0xU #define __SIZEOF_DOUBLE__ 8 #define __SIZEOF_FLOAT128__ 16 #define __SIZEOF_FLOAT__ 4 @@ -259,14 +267,15 @@ #define __SIZEOF_SIZE_T__ 4 #define __SIZEOF_WCHAR_T__ 4 #define __SIZEOF_WINT_T__ 4 -#define __SIZE_TYPE__ long unsigned int +#define __SIZE_TYPE__ unsigned int #define __SIZE_WIDTH__ 32 +#define __SSE__ 1 +#define __SSE2__ 1 #define __STDC__ 1 #define __STDC_HOSTED__ 1 #define __STDC_UTF_16__ 1 #define __STDC_UTF_32__ 1 #define __STDC_VERSION__ 201710L -#define __tune_i386__ 1 #define __UINT16_C(c) c #define __UINT16_MAX__ 0x #define __UINT16_TYPE__ short unsigned int @@ -298,8 +307,8 @@ #define __UINTMAX_C(c) c ## ULL #define __UINTMAX_MAX__ 0xULL #define __UINTMAX_TYPE__ long long unsigned int -#define __UINTPTR_MAX__ 0xUL -#define __UINTPTR_TYPE__ long unsigned int +#define __UINTPTR_MAX__ 0xU +#define __UINTPTR_TYPE__ unsigned int #define __USER_LABEL_PREFIX__ #define __VERSION__ "11.1.0" #define __WCHAR_MAX__ 0x7fff ```
[Bug c/100773] New: ice in operator[], at vec.h:890
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100773
Bug ID: 100773
Summary: ice in operator[], at vec.h:890
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Someplace between gcc trunk dated 20210524 (experimental) (0f3cd532fa02d178)
and 20210526 (experimental) (0eac9c60ac1f28ee), this C code:
fts_build_mail() {
int attempts = 2;
while (fts_build_mail_real())
if (--attempts == 0)
break;
}
with compiler flag -O2 does this:
$ /home/dcb/gcc/results/bin/gcc -c -O2 -w bug720.c
during GIMPLE pass: evrp
fts-build-mail.c: In function ‘fts_build_mail’:
fts-build-mail.c:633:1: internal compiler error: in operator[], at vec.h:890
633 | }
| ^
0x1789c8e vec::operator[](unsigned
int)
../../trunk.git/gcc/vec.h:890
0x1789c8e vec::operator[](unsigned int)
../../trunk.git/gcc/vec.h:1461
0x1789c8e range_def_chain::register_dependency(tree_node*, tree_node*,
basic_blo
ck_def*)
../../trunk.git/gcc/gimple-range-gori.cc:179
0x177f4e6 fold_using_range::range_of_range_op(irange&, gimple*, fur_source&)
../../trunk.git/gcc/gimple-range.cc:447
[Bug c/79216] Feature request: byte order attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79216 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |6.0 --- Comment #11 from Eric Botcazou --- The scalar_storage_order attribute is probably the best we can do.
[Bug bootstrap/55293] bootstrap failure: invalid conversion from 'char**' to 'const char**' [-fpermissive]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #19 from Eric Botcazou --- .
[Bug libstdc++/100770] New: Incorrect if constexpr statement in ranges::unique_copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100770
Bug ID: 100770
Summary: Incorrect if constexpr statement in
ranges::unique_copy
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
In ranges::unique_copy in ranges_algo.h#L1435:
else if constexpr (input_iterator<_Out>
&& same_as, iter_value_t<_Out>>)
Since there is no short circuit in if constexpr statement, this will
incorrectly abort compilation when iter_value_t<_Out> is ill-formed.
(thanks T.C. for pointing that out).
#include
#include
#include
int main() {
std::istringstream str("42 42 42");
std::ranges::unique_copy(
std::istream_iterator(str),
std::istream_iterator(),
std::ostream_iterator(std::cout, " "));
}
https://godbolt.org/z/PM58b3KrE
[Bug bootstrap/77512] gcc compilation stops with Arithmetic Exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77512 Eric Botcazou changed: What|Removed |Added Resolution|--- |WONTFIX Status|WAITING |RESOLVED --- Comment #12 from Eric Botcazou --- .
[Bug d/100769] [D] memcmp() == 0 for small constant strings not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100769 --- Comment #2 from Witold Baryluk --- Hmm. It appears that using `import core.stdc.string : memcmp;` actually resolves the problem. It looks like my manually declaration of memcmp for some reason disabled optimisations for memcmp.
[Bug d/100769] [D] memcmp() == 0 for small constant strings not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100769
--- Comment #1 from Witold Baryluk ---
A typo in the example (godbolt is good), I forgot the `.ptr`:
extern(C) int memcmp(const void *s1, const void *s2, size_t n);
int recognize3(const char* s) {
return memcmp(s, "stract class".ptr, 12) == 0;
}
casting to ubyte*, or void*, doesn't change anything really.
options: -O3 -frelease -fno-semantic-interposition
tested on amd64, Debian / Linux.
[Bug d/100769] New: [D] memcmp() == 0 for small constant strings not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100769
Bug ID: 100769
Summary: [D] memcmp() == 0 for small constant strings not
folded
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: witold.baryluk+gcc at gmail dot com
Target Milestone: ---
I expect this D code to be quite optimal, but it isn't.
```
extern(C) int memcmp(const void *s1, const void *s2, size_t n);
int recognize3(const char* s) {
return memcmp(s, "stract class", 12) == 0;
}
```
https://godbolt.org/z/vx17WK9rs
It produces a call to memcmp, instead of inlining and specializing the code for
this specific case.
int example.recognize3(const(char*)):
sub rsp, 8
mov edx, 12
mov esi, OFFSET FLAT:.LC0
callmemcmp
testeax, eax
seteal
add rsp, 8
movzx eax, al
ret
ldc2 1.24.0 (for D) and clang 11.0.1-2 (for C and C++), and gcc 10.2.1 (for C
and C++) produce close to optimal codes. Similarly ldc2 1.26.0 (for D), and gcc
11.1 (for C and C++):
int example.recognize3(const(char*)):
movabs rcx, 7142836979195081843
xor rcx, qword ptr [rdi]
mov edx, dword ptr [rdi + 8]
xor rdx, 1936941420
xor eax, eax
or rdx, rcx
seteal
ret
and
recognize3:
movabs rax, 7142836979195081843
cmp QWORD PTR [rdi], rax
je .L6
.L2:
mov eax, 1
xor eax, 1
ret
.L6:
xor eax, eax
cmp DWORD PTR [rdi+8], 1936941420
jne .L2
xor eax, 1
ret
Notice, how both gcc, clang and ldc2, compare first 8 bytes of input, then 4
bytes of input. clang and ldc2 just xor/or the result, then return, with no
conditional jumps. gcc does a bit poorer, with more conditionals and more
jumps, but still pretty good and same idea.
gdc however, calls the generic memcmp, that does looping and does about 12
jumps and/or 13 exists.
[Bug middle-end/100755] Error with fortran object (v11.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100755 --- Comment #7 from afernandez at odyhpc dot com --- @anlauf. Thanks! I'll open a PR with the developers so that they fix these issues.
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 --- Comment #30 from Aldy Hernandez --- On 5/26/21 3:23 PM, rguenther at suse dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 > > --- Comment #29 from rguenther at suse dot de --- > On Wed, 26 May 2021, amacleod at redhat dot com wrote: > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 >> >> --- Comment #28 from Andrew Macleod --- >> (In reply to rguent...@suse.de from comment #27) >>> On Wed, 26 May 2021, aldyh at redhat dot com wrote: >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 --- Comment #26 from Aldy Hernandez --- On Wed, May 26, 2021 at 10:34 AM rguenther at suse dot de wrote: > It's probably too strict for multiple_of_p which is fine with > overflows that preserve modulo behavior. Could you provide an example? >>> >>> Like with DECL_SIZE being D.1234 * 8 as unsigned multiplication >>> and the query whether it's a multiple of 8. Once you have no >>> range for 'D.1234' you will signal overflow (correctly) but >>> even then it's still a mutliple of 8. >> >> Determining whether an arbitrary expression is a multiple of some number is >> not >> really something we can figure out via ranges. Well, that's not quite true. >> If >> we fully fleshed out the operations you care about, things like multiply or >> shift you could get some results. presumably things like multiply by 2,4,8 >> and >> 16.. if we created correct multi-ranges for those, a cast of the high >> precision >> range back to the original precision would yield an identical non-varying >> range. and for non-multiples/unsupported values we'd get varying or something >> not the same as the original value?. This would only work if the original >> value doesn't come out varying.Although if its varying, maybe you dont >> care >> and a match is ok anyway?We could have may_overflow_p also return the >> higher precision range for inspection if its true... > > I guess optimally multiple_of_p would check for each individual > operation it looks at whether the op is transparent for the > modulo query and only if not checks whether there's possible overflow > (where ranges could help). My POC gimple_ranger_wider class can just be overloaded and in range_of_expr, you could just hijack the operations you care about (PLUS_EXPR, MULTIPLY_EXPR, etc) and treat them specially. Just a thought... Aldy
[Bug libstdc++/100768] Range iterator operations should be function objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100768 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-05-26
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 --- Comment #29 from rguenther at suse dot de --- On Wed, 26 May 2021, amacleod at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 > > --- Comment #28 from Andrew Macleod --- > (In reply to rguent...@suse.de from comment #27) > > On Wed, 26 May 2021, aldyh at redhat dot com wrote: > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 > > > > > > --- Comment #26 from Aldy Hernandez --- > > > On Wed, May 26, 2021 at 10:34 AM rguenther at suse dot de > > > wrote: > > > > > > > It's probably too strict for multiple_of_p which is fine with > > > > overflows that preserve modulo behavior. > > > > > > Could you provide an example? > > > > Like with DECL_SIZE being D.1234 * 8 as unsigned multiplication > > and the query whether it's a multiple of 8. Once you have no > > range for 'D.1234' you will signal overflow (correctly) but > > even then it's still a mutliple of 8. > > Determining whether an arbitrary expression is a multiple of some number is > not > really something we can figure out via ranges. Well, that's not quite true. If > we fully fleshed out the operations you care about, things like multiply or > shift you could get some results. presumably things like multiply by 2,4,8 and > 16.. if we created correct multi-ranges for those, a cast of the high > precision > range back to the original precision would yield an identical non-varying > range. and for non-multiples/unsupported values we'd get varying or something > not the same as the original value?. This would only work if the original > value doesn't come out varying.Although if its varying, maybe you dont > care > and a match is ok anyway?We could have may_overflow_p also return the > higher precision range for inspection if its true... I guess optimally multiple_of_p would check for each individual operation it looks at whether the op is transparent for the modulo query and only if not checks whether there's possible overflow (where ranges could help).
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 --- Comment #28 from Andrew Macleod --- (In reply to rguent...@suse.de from comment #27) > On Wed, 26 May 2021, aldyh at redhat dot com wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 > > > > --- Comment #26 from Aldy Hernandez --- > > On Wed, May 26, 2021 at 10:34 AM rguenther at suse dot de > > wrote: > > > > > It's probably too strict for multiple_of_p which is fine with > > > overflows that preserve modulo behavior. > > > > Could you provide an example? > > Like with DECL_SIZE being D.1234 * 8 as unsigned multiplication > and the query whether it's a multiple of 8. Once you have no > range for 'D.1234' you will signal overflow (correctly) but > even then it's still a mutliple of 8. Determining whether an arbitrary expression is a multiple of some number is not really something we can figure out via ranges. Well, that's not quite true. If we fully fleshed out the operations you care about, things like multiply or shift you could get some results. presumably things like multiply by 2,4,8 and 16.. if we created correct multi-ranges for those, a cast of the high precision range back to the original precision would yield an identical non-varying range. and for non-multiples/unsupported values we'd get varying or something not the same as the original value?. This would only work if the original value doesn't come out varying.Although if its varying, maybe you dont care and a match is ok anyway?We could have may_overflow_p also return the higher precision range for inspection if its true...
[Bug c++/100570] g++ does not suppress bitfield conversion warning even isystem flag is set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100570 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Thanks for the bug report. Could you upload a preprocessed source file that exhibits this problem?
[Bug c++/100368] Missing guaranteed elision in constexpr evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100368 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:88834c7d05acf5ce4eaccda56fb04436595e2a52 commit r12-1068-g88834c7d05acf5ce4eaccda56fb04436595e2a52 Author: Patrick Palka Date: Wed May 26 08:37:30 2021 -0400 c++: constexpr and copy elision within mem init [PR100368] In the testcase below, the member initializer b(f()) inside C's default constructor is encoded as a TARGET_EXPR wrapping the CALL_EXPR f() in C++17 mode. During massaging of this constexpr constructor, build_target_expr_with_type called from bot_manip on this initializer tries to add an extra copy using B's implicitly deleted copy constructor rather than just preserving the copy elision. Since it's wrong to introduce an extra copy when initializing a temporary from a CALL_EXPR, this patch makes build_target_expr_with_type avoid calling force_rvalue in this case. Additionally, bot_manip should be copying TARGET_EXPRs in a more oblivious manner, so this patch makes bot_manip use force_target_expr instead of build_target_expr_with_type. And since bot_manip is now no longer a caller, we can remove the void initializer handling in build_target_expr_with_type. PR c++/100368 gcc/cp/ChangeLog: * tree.c (build_target_expr_with_type): Don't call force_rvalue on CALL_EXPR initializer. Simplify now that bot_manip is no longer a caller. (bot_manip): Use force_target_expr instead of build_target_expr_with_type. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/elide6.C: New test.
[Bug c++/97420] [9/10/11/12 Regression] NTTP function reference cannot bind to noexcept function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97420 --- Comment #6 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:b4329e3dd6fb7c78948fcf9d2f5b9d873deec284 commit r12-1067-gb4329e3dd6fb7c78948fcf9d2f5b9d873deec284 Author: Patrick Palka Date: Wed May 26 08:35:31 2021 -0400 c++: Fix reference NTTP binding to noexcept fn [PR97420] Here, in C++17 mode, convert_nontype_argument_function is rejecting binding a non-noexcept function reference template parameter to a noexcept function (encoded as the template argument '*(int (&) (int)) '). The first roadblock to making this work is that the argument is wrapped an an implicit INDIRECT_REF, so we need to unwrap it before calling strip_fnptr_conv. The second roadblock is that the NOP_EXPR cast converts from a function pointer type to a reference type while simultaneously removing the noexcept qualification, and fnptr_conv_p doesn't consider this cast to be a function pointer conversion. This patch fixes this by making fnptr_conv_p treat REFERENCE_TYPEs and POINTER_TYPEs interchangeably. Finally, in passing, this patch also simplifies noexcept_conv_p by removing a bunch of redundant checks already performed by its only caller fnptr_conv_p. PR c++/97420 gcc/cp/ChangeLog: * cvt.c (noexcept_conv_p): Remove redundant checks and simplify. (fnptr_conv_p): Don't call non_reference. Use INDIRECT_TYPE_P instead of TYPE_PTR_P. * pt.c (convert_nontype_argument_function): Look through implicit INDIRECT_REFs before calling strip_fnptr_conv. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/noexcept68.C: New test.
[Bug tree-optimization/100653] usage of scalar_storage_order produces incorrect result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100653 --- Comment #5 from Eric Botcazou --- > Not at the moment, although this could probably be implemented. But a > simple rule of thumb is to avoid using scalar_storage_order with unions at > all. I'm going to implement a simple warning for unions.
[Bug target/100762] [mips+msa] ICE when comparing 64 bit vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100762 --- Comment #1 from Evan Nemerson --- It's not just comparisons. <<, >>, /, * also don't work. AFAICT only bitwise operations and +/- work, as well as everything with a 64-bit element type (i.e., a vector of one element)… 8/16/32-bit elements all fail.
[Bug tree-optimization/100653] usage of scalar_storage_order produces incorrect result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100653 --- Comment #4 from Eric Botcazou --- > Is there some way there can be warned against such invalid usages? Because > these things are really hard to see on a 'macro' level. Not at the moment, although this could probably be implemented. But a simple rule of thumb is to avoid using scalar_storage_order with unions at all.
[Bug tree-optimization/100653] usage of scalar_storage_order produces incorrect result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100653 --- Comment #3 from Jan Smets --- Is there some way there can be warned against such invalid usages? Because these things are really hard to see on a 'macro' level.
[Bug libstdc++/100768] New: Range iterator operations should be function objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100768 Bug ID: 100768 Summary: Range iterator operations should be function objects Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rs2740 at gmail dot com Target Milestone: --- They are currently implemented as plain function templates, which don't meet the requirements in http://eel.is/c++draft/range.iter.ops.general#2
[Bug c++/100766] Template type deduction fails with vector extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100766 --- Comment #2 from chris.a.ferguson at gmail dot com --- (In reply to Jonathan Wakely from comment #1) > Is this a duplicate of PR 100765 ? Yes, this seems to be the same exact issue.
