[Bug fortran/54753] assumed-rank dummies: Reject assumed-size actuals in in some cases (C535c; in F2018: C839)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54753 Tobias Burnus changed: What|Removed |Added Summary|assumed-rank dummies: |assumed-rank dummies: |Reject assumed-size actuals |Reject assumed-size actuals |in in some cases (C535c)|in in some cases (C535c; in ||F2018: C839) --- Comment #2 from Tobias Burnus --- In F2018: C839 If an assumed-size or nonallocatable nonpointer assumed-rank array is an actual argument that corres-19ponds to a dummy argument that is an INTENT (OUT) assumed-rank array, it shall not be polymorphic,20finalizable, of a type with an allocatable ultimate component, or of a type for which default initialization21is specified.
[Bug fortran/94289] Assumed-rank array bounds resuscitate on the second call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94289 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus --- I find the testcase confusing – but I think it works now correctly on mainline (GCC 11), thanks to the fix for PR99043 (committed to both GCC 11 and GCC 10) and possibly some other prior fixes. Namely: - if the dummy argument is a pointer/allocatable, it has the same bounds as the dummy argument - if is is nonallocatable nonpointer, the lower bounds are [1, 1, 1]. Can you check? (GCC 10 or GCC 11) Can you also check whether your PR95196 is fixed with mainline (GCC 11)?
[Bug fortran/94070] Assumed-rank arrays – bounds mishandled, SIZE/SHAPE/UBOUND/LBOUND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070 --- Comment #6 from Tobias Burnus --- Some bound issues were fixed with PR99043 – but my bet is that the BIND(C) issues still exist. (→ testcase (C + Fortran) attached to this PR). * * * Additionally: PR 94020 (duplicate of this PR) with attachment 47960 seems to be mostly fixed, however for the following case, the result is wrong. if 'lb' (or second argument to 'foo') is >= 0, size2 == 0 – otherwise, size2 > 0'. Expected: same result as for PRODUCT(SHAPE(ARRAY,KIND)) (→ 16.9.179 SIZE (ARRAY [, DIM, KIND])) That is: lb = 5 → shape = [5 -1] → -5 lb = -12 → shape = [5 - 1] → -5 implicit none integer :: A(5,5) call foo(a,-12) call foo(a,0) call foo(a,5) contains subroutine foo(x,lb) integer :: lb integer :: x(5,lb:*) print *, size2(x) if (size2(x) /= -5) stop 1 end integer function size2(y) integer :: y(..) size2 = size(y) end end
[Bug fortran/97694] ICE with optional assumed rank class(*) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97694 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #8 from Tobias Burnus --- Paul – what's the state of this PR? I see a mainline/GCC 11 commit from end of December. Is there more to do?
[Bug other/99288] xgettext does not get HOST_WIDE_INT_PRINT_UNSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99288 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 Bug 40883 depends on bug 99288, which changed state. Bug 99288 Summary: xgettext does not get HOST_WIDE_INT_PRINT_UNSIGNED https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99288 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug testsuite/99292] FAIL: gcc.c-torture/compile/pr98096.c -O0 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99292 --- Comment #1 from Richard Biener --- IIRC it requires LRA, maybe add a dg target selector for LRA (or reload, that's likely smaller now)?
[Bug c/99295] [11 Regression] documentation on __attribute__((malloc)) is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99295 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/99299] Need a recoverable version of __builtin_trap()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299 Richard Biener changed: What|Removed |Added Keywords||missed-optimization CC||rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener --- 'enhancement' Importance is the magic we use, in the end it's a missed optimization since you refer to sub-optimal code gen. I'm not sure what your proposed not noreturn trap() would do in terms of IL semantics compared to a not specially annotated general call? "recoverable" likely means resuming after the trap, not on an exception path (so it'll not be a throw())? The only thing that might be useful to the middle-end would be marking the function as not altering the memory state. But I suppose it should still serve as a barrier for code motion of both loads and stores, even of those loads/stores are known to not trap. The only magic we'd have for this would be __attribute__((const,returns_twice)). Which likely will be more detrimental to general optimization. So - what's the "sub-optimal code generation" you refer to from the (presumably) volatile asm() you use for the trap? [yeah, asm() on GIMPLE is less optimized than a call]
[Bug rtl-optimization/99305] [11 Regression] range condition simplification after inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99305
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization,
||needs-bisection
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Target Milestone|--- |11.0
Last reconfirmed||2021-03-01
--- Comment #1 from Richard Biener ---
Confirmed. Some forwprop/match.pd prevents phiopt to trigger:
GCC 10 (forwprop->phiopt):
[local count: 1073741824]:
_7 = (unsigned char) c_2(D);
_8 = _7 + 208;
- if (_8 <= 9)
-goto ; [50.00%]
- else
-goto ; [50.00%]
-
- [local count: 536870913]:
-
- [local count: 1073741824]:
- # iftmp.1_1 = PHI <1(3), 0(2)>
- return iftmp.1_1;
+ _9 = _8 <= 9;
+ return _9;
forwprop difference GCC 10/11:
- Replaced '_9 != 0' with '_8 <= 9'
-bar (char c)
+bool bar (char c)
{
bool iftmp.1_1;
- unsigned char _7;
- unsigned char _8;
+ unsigned char c.0_4;
+ unsigned char _5;
+ bool _6;
+ bool _7;
[local count: 1073741824]:
- _7 = (unsigned char) c_2(D);
- _8 = _7 + 208;
- if (_8 <= 9)
+ if (c_2(D) != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
+ c.0_4 = (unsigned char) c_2(D);
+ _5 = c.0_4 + 208;
+ _6 = _5 <= 9;
+ _7 = -_6;
[local count: 1073741824]:
- # iftmp.1_1 = PHI <1(3), 0(2)>
+ # iftmp.1_1 = PHI <_7(3), 0(2)>
return iftmp.1_1;
[Bug libstdc++/99306] cross compiler bootstrap failure on msdosdjgpp: error: alignment of 'm' is greater than maximum object file alignment 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99306
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2021-03-01
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #2 from Richard Biener ---
__gnu_cxx::__mutex&
get_mutex(unsigned char i)
{
// increase alignment to put each lock on a separate cache line
struct alignas(64) M : __gnu_cxx::__mutex { };
static M m[mask + 1];
return m[i];
there's __BIGGEST_ALIGNMENT__ one could use as bound but that will usually
be lower than the max ofile alignment and on most targets likely less
than 64. That value (64) looks like it should be target dependent anyway
(configury?)
[Bug c++/99309] [10/11 Regression] Segmentation fault with __builtin_constant_p usage at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99309 Richard Biener changed: What|Removed |Added Known to fail||11.0 Target Milestone|--- |10.3 Summary|Segmentation fault with |[10/11 Regression] |__builtin_constant_p usage |Segmentation fault with |at -O2 |__builtin_constant_p usage ||at -O2 Known to work||9.3.1 Priority|P3 |P2 Last reconfirmed||2021-03-01 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||wrong-code --- Comment #1 from Richard Biener --- confirmed.
[Bug c++/99310] [11 Regression] ICE: canonical types differ for identical types 'void (A::)(void*)' and 'void (A::)(void*)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99310 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |11.0 Keywords||error-recovery, ||ice-checking
[Bug c++/99309] [10/11 Regression] Segmentation fault with __builtin_constant_p usage at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99309
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Testcase without headers:
struct T {
int val;
explicit constexpr operator int() const { return val; }
constexpr T(long v):val(v){}
void operator*=(T m) {
if(__builtin_constant_p(m.val)){
__builtin_printf ("normal\n");
return;
}else if(__builtin_constant_p(val)){
__builtin_printf ("recursive\n");
return;
}else{
__builtin_printf ("return\n");
return;
}
}
};
int main(){
T constexpr step=610334368;
T value=1;
for(int _=0; _<100; ++_){
__builtin_printf ("%d %d\n", (int) value, (int) step);
value*=step;
__builtin_printf ("%d %d\n", (int) value, (int) step);
}
}
Bet yet another IPA/inlining bug, like e.g. PR98834, the __builtin_unreachable
call is added during inlining:
Introduced new external node (void __builtin_unreachable()/11).
[Bug preprocessor/99313] New: ICE while changing global target options via pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99313
Bug ID: 99313
Summary: ICE while changing global target options via pragma
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
#pragma GCC push_options
#pragma GCC target ("arch=z13")
#pragma GCC pop_options
$ gcc t.c -c -march=z900
test.c:3:9: internal compiler error: 'global_options' are modified in local
context
3 | #pragma GCC pop_options
| ^~~
0x20035cf cl_optimization_compare(gcc_options*, gcc_options*)
/devel/build/gcc/options-save.c:12836
0x1720b4b handle_pragma_pop_options
/devel/src/gcc/c-family/c-pragma.c:1092
0x17218a5 c_invoke_pragma_handler(unsigned int)
/devel/src/gcc/c-family/c-pragma.c:1515
0x1636ed7 c_parser_pragma
/devel/src/gcc/c/c-parser.c:12519
0x1617165 c_parser_external_declaration
/devel/src/gcc/c/c-parser.c:1758
0x1616c51 c_parser_translation_unit
/devel/src/gcc/c/c-parser.c:1650
0x1660487 c_parse_file()
/devel/src/gcc/c/c-parser.c:21984
0x1718aab c_common_parse_file()
/devel/src/gcc/c-family/c-opts.c:1218
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/99314] New: [Patch] [RISC-V] g++.dg/opt/memcpy1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99314
Bug ID: 99314
Summary: [Patch] [RISC-V] g++.dg/opt/memcpy1.C
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sinan.lin at aalto dot fi
Target Milestone: ---
Created attachment 50272
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50272&action=edit
Patch for fixing negative length problem in riscv_expand_block_move
The problem was that the argument 'length' in function
'riscv_expand_block_move' can be a negative value, and this leads to a crash.
original code in riscv.c:
bool
riscv_expand_block_move (rtx dest, rtx src, rtx length)
{
if (CONST_INT_P (length))
{
HOST_WIDE_INT factor, align;
align = MIN (MIN (MEM_ALIGN (src), MEM_ALIGN (dest)), BITS_PER_WORD);
factor = BITS_PER_WORD / align;
... ...
Bug shooting step in gdb for g++.dg/opt/memcpy1.C:
gdb$ break riscv_expand_block_move
gdb$ r
gdb$ print length->u.hwint[0] # INTVAL(length)
gdb$ $1 = -4
My patch for this testcase:
diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
index d489717b2a5..737902faea8 100644
--- a/gcc/config/riscv/riscv.c
+++ b/gcc/config/riscv/riscv.c
@@ -3234,7 +3234,7 @@ riscv_block_move_loop (rtx dest, rtx src, HOST_WIDE_INT
length,
bool
riscv_expand_block_move (rtx dest, rtx src, rtx length)
{
- if (CONST_INT_P (length))
+ if (CONST_INT_P (length) && INTVAL (length) >= 0)
{
HOST_WIDE_INT factor, align;
Result of regression test before my patch on riscv-gcc-10.2.0:
/home/open/riscv-gnu-toolchain/scripts/testsuite-filter gcc newlib
/home/open/riscv-gnu-toolchain/test/allowlist `find
build-gcc-newlib-stage2/gcc/testsuite/ -name *.sum |paste -sd "," -`
=== g++: Unexpected fails for rv32imac ilp32 medlow ===
FAIL: g++.dg/opt/memcpy1.C -std=gnu++14 (internal compiler error)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++17 (internal compiler error)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++17 (test for excess errors)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++2a (internal compiler error)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++2a (test for excess errors)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++98 (internal compiler error)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++98 (test for excess errors)
=== g++: Unexpected fails for rv32im ilp32 medlow ===
FAIL: g++.dg/opt/memcpy1.C -std=gnu++14 (internal compiler error)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++17 (internal compiler error)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++17 (test for excess errors)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++2a (internal compiler error)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++2a (test for excess errors)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++98 (internal compiler error)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++98 (test for excess errors)
=== g++: Unexpected fails for rv32imafc ilp32f medlow ===
FAIL: g++.dg/opt/memcpy1.C -std=gnu++14 (internal compiler error)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++17 (internal compiler error)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++17 (test for excess errors)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++2a (internal compiler error)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++2a (test for excess errors)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++98 (internal compiler error)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++98 (test for excess errors)
=== g++: Unexpected fails for rv32iac ilp32 medlow ===
FAIL: g++.dg/opt/memcpy1.C -std=gnu++14 (internal compiler error)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++17 (internal compiler error)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++17 (test for excess errors)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++2a (internal compiler error)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++2a (test for excess errors)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++98 (internal compiler error)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++98 (test for excess errors)
=== g++: Unexpected fails for rv32i ilp32 medlow ===
FAIL: g++.dg/opt/memcpy1.C -std=gnu++14 (internal compiler error)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++17 (internal compiler error)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++17 (test for excess errors)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++2a (internal compiler error)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++2a (test for excess errors)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++98 (internal compiler error)
FAIL: g++.dg/opt/memcpy1.C -std=gnu++98 (test for excess errors)
= Summary of gcc testsuite =
| # of u
[Bug tree-optimization/99296] [11 Regression] ICE:in irange_set_anti_range, at value-range.cc:205 with "-Os -fno-toplevel-reorder -fno-tree-bit-ccp" since r11-5105-ga5f9c27bfc441722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99296 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Known to work||10.2.0 Summary|ICE:in |[11 Regression] ICE:in |irange_set_anti_range, at |irange_set_anti_range, at |value-range.cc:205 with |value-range.cc:205 with |"-Os -fno-toplevel-reorder |"-Os -fno-toplevel-reorder |-fno-tree-bit-ccp" |-fno-tree-bit-ccp" since ||r11-5105-ga5f9c27bfc441722 Known to fail||11.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-03-01 --- Comment #1 from Martin Liška --- Confirmed, started with r11-5105-ga5f9c27bfc441722. Minimal options: gcc pr99296.c -fno-tree-bit-ccp -Os.
[Bug preprocessor/99315] New: #pragma GCC warning does not concatenate string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99315 Bug ID: 99315 Summary: #pragma GCC warning does not concatenate string literals Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: fweimer at redhat dot com Target Milestone: --- This: #pragma GCC warning "foo" "bar" #pragma GCC error "foo" "bar" produces: /tmp/t.c:1:21: warning: foo 1 | #pragma GCC warning "foo" "bar" | ^ /tmp/t.c:2:19: error: foo 2 | #pragma GCC error "foo" "bar" | ^ It is an oversight in the processing of the pragma arguments. Clang produces this, which is closer to developer expectations: /tmp/t.c:1:13: warning: foobar [-W#pragma-messages] /tmp/t.c:2:13: error: foobar (Another option would be to error out on multiple arguments to the pragma.) This is not a regression, it's a bug that's always been present.
[Bug preprocessor/99313] ICE while changing global target options via pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99313 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- g:dc6d15eaa23cbae1468a6ef92371b1c856c14819
[Bug middle-end/99299] Need a recoverable version of __builtin_trap()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299 Franz Sirl changed: What|Removed |Added CC||sirl at gcc dot gnu.org --- Comment #5 from Franz Sirl --- For the naming I suggest __builtin_debugtrap() to align with clang. Maybe with an aliased __debugbreak() on Windows platforms.
[Bug preprocessor/99315] #pragma GCC warning does not concatenate string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99315 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-03-01 CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Note, string literal concatenation is implemented in c_parser_string_literal in the C FE and in cp_parser_string_literal in the C++ FE. Pragma processing is during translation phase 4 while string literal concatenation is translation phase 6, plus these pragmas are GCC extension, so we can do whatever we want, but perhaps handling the string literal concatenation and erroring out on other arguments after it wouldn't be a bad idea for GCC 12+. As the pragmas handle just CPP_STRING, it wouldn't have to handle e.g. mixing of the various string literal types etc. Note, currently we diagnose as error #pragma GCC warning "" but we should error just on that form and not e.g. on #pragma GCC warning "" "" "" "foobar"
[Bug preprocessor/99313] ICE while changing global target options via pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99313
Martin Liška changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2021-03-01
--- Comment #2 from Martin Liška ---
The diff comes from here:
(gdb) p ptr1->x_param_max_completely_peel_times
$3 = 16
(gdb) p ptr2->x_param_max_completely_peel_times
$4 = 64
Which comes from here:
if (opts->x_s390_tune >= PROCESSOR_2097_Z10)
{
SET_OPTION_IF_UNSET (opts, opts_set, param_max_unrolled_insns,
100);
SET_OPTION_IF_UNSET (opts, opts_set, param_max_unroll_times, 32);
SET_OPTION_IF_UNSET (opts, opts_set, param_max_completely_peeled_insns,
2000);
SET_OPTION_IF_UNSET (opts, opts_set, param_max_completely_peel_times,
64);
}
So this is an obvious situation where a target option modified optimization
options that is global.
I'm going to add exceptions for it.
[Bug c/99316] New: ICE: in final_scan_insn_1, at final.c:3073 (error: could not split insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99316
Bug ID: 99316
Summary: ICE: in final_scan_insn_1, at final.c:3073 (error:
could not split insn)
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: andrew.goodbody at linaro dot org
Target Milestone: ---
Created attachment 50273
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50273&action=edit
Preprocessed source
gcc 10.2.0 built from tarball
In file included from
external/eigen_archive/unsupported/Eigen/CXX11/Tensor:144,
from ./third_party/eigen3/unsupported/Eigen/CXX11/Tensor:1,
from ./tensorflow/core/framework/numeric_types.h:20,
from ./tensorflow/core/framework/allocator.h:26,
from ./tensorflow/core/framework/op_kernel.h:25,
from ./tensorflow/core/kernels/histogram_op.h:19,
from tensorflow/core/kernels/histogram_op.cc:20:
external/eigen_archive/unsupported/Eigen/CXX11/src/Tensor/TensorExecutor.h: In
static member function 'static void Eigen::internal::EvalRange::run(Evaluator*, StorageIndex, StorageIndex) [with
Evaluator = Eigen::TensorEvaluator, 16,
Eigen::MakePointer>, const Eigen::TensorConversionOp,
const
Eigen::TensorCwiseUnaryOp >, const Eigen::TensorConversionOp, const
Eigen::TensorCwiseBinaryOp, const Eigen::TensorMap, 16, Eigen::MakePointer>, const
Eigen::TensorCwiseNullaryOp, const Eigen::TensorMap, 16, Eigen::MakePointer> > >, const
Eigen::TensorCwiseNullaryOp, const Eigen::TensorMap, 16, Eigen::MakePointer> > > > >, const
Eigen::TensorCwiseNullaryOp, const
Eigen::TensorCwiseUnaryOp >, const Eigen::TensorConversionOp, const
Eigen::TensorCwiseBinaryOp, const Eigen::TensorMap, 16, Eigen::MakePointer>, const
Eigen::TensorCwiseNullaryOp, const Eigen::TensorMap, 16, Eigen::MakePointer> > >, const
Eigen::TensorCwiseNullaryOp, const Eigen::TensorMap, 16, Eigen::MakePointer> > > > > > > > >, Eigen::ThreadPoolDevice>;
StorageIndex = long int]':
external/eigen_archive/unsupported/Eigen/CXX11/src/Tensor/TensorExecutor.h:349:3:
error: could not split insn
349 | }
| ^
(insn 1615 2102 1433 (set (reg:VNx4SF 34 v2 [orig:554 _1597 ] [554])
(unspec:VNx4SF [
(reg:VNx4BI 72 p4 [orig:376 vec_mask_and_1413 ] [376])
(unspec:VNx4SF [
(reg:VNx4BI 78 p10 [orig:376 vec_mask_and_1413 ] [376])
(const_int 1 [0x1])
(reg:VNx4SF 49 v17 [2017])
(reg:VNx4SF 32 v0 [2049])
] UNSPEC_COND_FADD)
(reg:VNx4SF 39 v7 [orig:392 vect__ifc__887.8029 ] [392])
] UNSPEC_SEL)) 5628 {*cond_addvnx4sf_any}
(expr_list:REG_DEAD (reg:VNx4BI 78 p10 [orig:376 vec_mask_and_1413 ]
[376])
(expr_list:REG_DEAD (reg:VNx4BI 72 p4 [orig:376 vec_mask_and_1413 ]
[376])
(expr_list:REG_DEAD (reg:VNx4SF 39 v7 [orig:392 vect__ifc__887.8029
] [392])
(expr_list:REG_EQUAL (unspec:VNx4SF [
(reg:VNx4BI 78 p10 [orig:376 vec_mask_and_1413 ]
[376])
(unspec:VNx4SF [
(reg:VNx4BI 78 p10 [orig:376
vec_mask_and_1413 ] [376])
(const_int 1 [0x1])
(reg:VNx4SF 49 v17 [2017])
(const_vector:VNx4SF [
(const_double:SF -6.103515625e-5
[-0x0.8p-13])
])
] UNSPEC_COND_FADD)
(subreg:VNx4SF (reg:VNx4SI 39 v7 [orig:392
vect__ifc__887.8029 ] [392]) 0)
] UNSPEC_SEL)
(nil))
during RTL pass: final
external/eigen_archive/unsupported/Eigen/CXX11/src/Tensor/TensorExecutor.h:349:3:
internal compiler error: in final_scan_insn_1, at final.c:3073
0x69255f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/builder/src/gcc/10.2.0/gcc-10.2.0/gcc/rtl-error.c:108
0x9debcf final_scan_insn_1
/home/builder/src/gcc/10.2.0/gcc-10.2.0/gcc/final.c:3073
0x9dede3 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/home/builder/src/gcc/10.2.0/gcc-10.2.0/gcc/final.c:3152
0x9df0a7 final_1
/home/builder/src/gcc/10.2.0/gcc-10.2.0/gcc/final.c:2020
0x9df823 rest_of_handle_final
/home/builder/src/gcc/10.2.0/gcc-10.2.0/gcc/final.c:4658
0x9df823 execute
/home/builder/src/gcc/10.2.0/gcc-10.2.0/gcc/final.c:4736
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/99316] ICE: in final_scan_insn_1, at final.c:3073 (error: could not split insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99316 --- Comment #1 from andrew.goodbody at linaro dot org --- Command line used was this /usr/local/bin/gcc-U_FORTIFY_SOURCE -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -g0 -O2 '-D_FORTIFY_SOURCE=1' -DNDEBUG -ffunction-sections -fdata-sections '-std=c++0x'-MD -MF bazel-out/aarch64-opt/bin/tensorflow/core/kernels/_objs/histogram_op/histogram_op.pic.d '-frandom-seed=bazel-out/aarch64-opt/bin/tensorflow/core/kernels/_objs/histogram_op/histogram_op.pic.o' -fPIC -D__CLANG_SUPPORT_DYN_ANNOTATION__ -DEIGEN_MPL2_ONLY '-DEIGEN_MAX_ALIGN_BYTES=64' '-DEIGEN_HAS_TYPE_TRAITS=0' -DEIGEN_USE_BLAS -DEIGEN_USE_LAPACK -iquote . -iquote bazel-out/aarch64-opt/bin -iquote external/com_google_absl -iquote bazel-out/aarch64-opt/bin/external/com_google_absl-iquote external/eigen_archive -iquote bazel-out/aarch64-opt/bin/external/eigen_archive -iquote external/local_config_sycl -iquote bazel-out/aarch64-opt/bin/external/local_config_sycl -iquote external/nsync -iquote bazel-out/aarch64-opt/bin/external/nsync -iquote external/com_googlesource_code_re2 -iquote bazel-out/aarch64-opt/bin/external/com_googlesource_code_re2 -iquote external/gif -iquote bazel-out/aarch64-opt/bin/external/gif -iquote external/libjpeg_turbo -iquote bazel-out/aarch64-opt/bin/external/libjpeg_turbo -iquote external/com_google_protobuf -iquote bazel-out/aarch64-opt/bin/external/com_google_protobuf -iquote external/farmhash_archive -iquote bazel-out/aarch64-opt/bin/external/farmhash_archive -iquote external/fft2d -iquote bazel-out/aarch64-opt/bin/external/fft2d -iquote external/highwayhash -iquote bazel-out/aarch64-opt/bin/external/highwayhash -iquote external/zlib_archive -iquote bazel-out/aarch64-opt/bin/external/zlib_archive -isystem third_party/eigen3/mkl_include -isystem bazel-out/aarch64-opt/bin/third_party/eigen3/mkl_include -isystem external/eigen_archive-isystem bazel-out/aarch64-opt/bin/external/eigen_archive -isystem external/nsync/public -isystem bazel-out/aarch64-opt/bin/external/nsync/public -isystem external/gif -isystem bazel-out/aarch64-opt/bin/external/gif -isystem external/com_google_protobuf/src -isystem bazel-out/aarch64-opt/bin/external/com_google_protobuf/src -isystem external/farmhash_archive/src -isystem bazel-out/aarch64-opt/bin/external/farmhash_archive/src -isystem external/zlib_archive -isystem bazel-out/aarch64-opt/bin/external/zlib_archive '-march=armv8.2-a+sve' -O3 '-std=c++14' '-march=armv8.2-a+sve' -O3 '-D_GLIBCXX_USE_CXX11_ABI=0' -DEIGEN_AVOID_STL_ARRAY -Iexternal/gemmlowp -Wno-sign-compare '-ftemplate-depth=900' -fno-exceptions '-DINTEL_MKL=1' -DEIGEN_USE_VML -DINTEL_MKL_DNN_ONLY -DENABLE_MKL -pthread '-DINTEL_MKL=1' -DINTEL_MKL_DNN_ONLY -DENABLE_MKL -fno-canonical-system-headers -Wno-builtin-macro-redefined '-D__DATE__="redacted"' '-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' -c tensorflow/core/kernels/histogram_op.cc -o bazel-out/aarch64-opt/bin/tensorflow/core/kernels/_objs/histogram_op/histogram_op.pic.o
[Bug c/99316] ICE: in final_scan_insn_1, at final.c:3073 (error: could not split insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99316 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktkachov at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from ktkachov at gcc dot gnu.org --- Dup. Fixed for GCC 10.3 *** This bug has been marked as a duplicate of bug 96357 ***
[Bug target/96357] [10/11 Regression] could not split insn UNSPEC_COND_FSUB with AArch64 SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96357 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||andrew.goodbody at linaro dot org --- Comment #5 from ktkachov at gcc dot gnu.org --- *** Bug 99316 has been marked as a duplicate of this bug. ***
[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99307 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus --- (In reply to Dominique d'Humieres from comment #1) > Reduced test While -fsanitize=address,undefined does not find anything on x86_64-gnu-linux, I do see with valgrind: ==98347== Invalid write of size 8 ==98347==at 0x40397E: test_t1_ (ijd.f90:43) ==98347==by 0x403A4E: MAIN__ (ijd.f90:60) ==98347==by 0x403A85: main (ijd.f90:61) ==98347== Address 0x4f55c98 is 8 bytes inside a block of size 12 alloc'd ==98347==at 0x483DFAF: realloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==98347==by 0x402A6D: test_t1_ (ijd.f90:40) ==98347==by 0x403A4E: MAIN__ (ijd.f90:60) ==98347==by 0x403A85: main (ijd.f90:61) That's: x = [t2(1,10.0),t2(2,20.0),t2(3,30.0)] y = x x = realloc_t1 (y) ! <<< line 40, 8 bytes alloc'd inside block of size 12 x = realloc_t1 (x) x = x(3:1:-1) + y x = [t2(1,10.0),t2(2,20.0),t2(3,30.0)] ! <<< line 43, invalid write of size 8 Looking at the Fortran code, x and y have the dynamic type T2 until 'realloc_t1', which turns this into the dynamic type T1. In the last line (line 43), the dynamic type changes again to T2. In terms of memory usage: 3*8bytes before the first realloc_t1 call, then 3*4bytes and for the last line again 3*8bytes. * * * It seems as if the reallocation does not work properly if the dynamic type changes – at least not if the required size increased in the assignment. (The valgrind message implies that shrinking did work in line 40.)
[Bug middle-end/99151] Missed optimization: Superfluous stack frame and code with noreturn or __builtin_unreachable()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WONTFIX
--- Comment #5 from Eric Botcazou ---
static void
sparc_asm_function_epilogue (FILE *file)
{
/* If the last two instructions of a function are "call foo; dslot;"
the return address might point to the first instruction in the next
function and we have to output a dummy nop for the sake of sane
backtraces in such cases. This is pointless for sibling calls since
the return address is explicitly adjusted. */
[Bug fortran/99308] [OOP] passing array of object as class(TYPE) to procedure leads to incorrect length of array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99308
Tobias Burnus changed:
What|Removed |Added
Keywords||missed-optimization
CC||burnus at gcc dot gnu.org
--- Comment #2 from Tobias Burnus ---
I think there are two errors:
(a) The value can be simplified at compile time as the size (8 or 2) is known
at compile time, but isn't.
I wonder whether this only a problem for 'size' or also for 'ubound','lbound'
or when doing
var(:)%idx = 0 – for the bounds of the generated do loop.
(b) The run-time version is wrong.
In my dump, (and output '2 2') I see for either variable
parm.10.span = spcs->_vptr->_size;
parm.10.dtype = {.elem_len=4, .rank=1, .type=5};
D.3995 = stride.5;
parm.10.dim[0].lbound = 1;
parm.10.dim[0].ubound = 2;
parm.10.dim[0].stride = NON_LVALUE_EXPR ;
parm.10.data = 0B;
parm.10.offset = -NON_LVALUE_EXPR ;
D.3996 = &parm.10;
D.3997 = (integer(kind=4)) MAX_EXPR <(D.3996->dim[0].ubound -
D.3996->dim[0].lbound) + 1, 0>;
Obviously, 'ubound = 2' is only valid for 'fuel' and not for 'spcs'.
[Bug target/99234] [10/11 regression] wrong result for 1.0/3.0 with -O2 -fno-omit-frame-pointer -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234 --- Comment #23 from Vadim Zeitlin --- (In reply to Eric Botcazou from comment #22) > Thanks for reporting the problem. Thanks a lot for fixing it so quickly! And I've also appreciated the explanation in the commit message, it's nice to understand what the problem really was, even if it's fixed now.
[Bug debug/99230] [11 Regression] gcc.dg/pr83527.c excess errors: '-fcompare-debug' failure (length)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99230
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-03-01
Ever confirmed|0 |1
--- Comment #3 from Jakub Jelinek ---
This can be seen also on
int a, b;
void fn1(int c, short d) {
if (d || c) {
do
;
while (0);
}
}
with -O2 --param logical-op-non-short-circuit=0 -fcompare-debug - differences
in *.gimple dump:
--- pr99230-2.c.006t.gimple 2021-03-01 12:46:25.715634310 +0100
+++ pr99230-2.gk.c.006t.gimple 2021-03-01 12:46:25.740634033 +0100
@@ -1,11 +1,13 @@
void fn1 (int c, short int d)
{
- if (d != 0) goto ; else goto ;
- :
- if (c != 0) goto ; else goto ;
+ # DEBUG BEGIN_STMT
+ if (d != 0) goto ; else goto ;
:
- :
+ if (c != 0) goto ; else goto ;
:
+ # DEBUG BEGIN_STMT
+ # DEBUG BEGIN_STMT
+ :
}
I'm afraid it is the same issue as PR93786.
The difference is that when shortcut_cond_expr is run, in one case
then_se is false, because then_ is
>
constant
arg:0 constant 0>
pr99230-2.c:11:7 start: pr99230-2.c:11:7 finish: pr99230-2.c:11:7>
but in another case is
>
side-effects head 0x7fffea189168 tail 0x7fffea1891c8 stmts 0x7fffea189150
0x7fffea186240
stmt
pr99230-2.c:10:5 start: pr99230-2.c:10:5 finish: pr99230-2.c:10:6>
stmt
head 0x7fffea189240 tail 0x7fffea189240 stmts 0x7fffea189228
stmt
pr99230-2.c:11:7 start: pr99230-2.c:11:7 finish:
pr99230-2.c:11:7>>>
and only the latter has TREE_SIDE_EFFECTS set.
In PR93786 I've tried several possibilities and had to gave up.
Alex, any thoughts?
Unless we want to remove the statement frontiers support, I'm not sure what
else we can do, we'd need some new trees to hold just the debug statements that
would preserve what exactly would be the behavior without -g.
Not sure if this needs to be P1 though, the statement frontiers issues are old,
and cris is not a primary or secondary target, so if we have a testcase that in
the end only fails there...
[Bug c/99291] maybe_warn_pass_by_reference uses outdated format string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99291 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||msebor at gcc dot gnu.org --- Comment #5 from Martin Liška --- The '%<%s%>' is currently supported, but not triggered for some reason. Martin?
[Bug bootstrap/98338] [10/11 Regression] profiledbootstrap failure on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98338 --- Comment #23 from Jakub Jelinek --- The make check results also looked ok on all 3 arches.
[Bug middle-end/99151] Missed optimization: Superfluous stack frame and code with noreturn or __builtin_unreachable()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151
--- Comment #6 from Sebastian Huber ---
(In reply to Eric Botcazou from comment #5)
> static void
> sparc_asm_function_epilogue (FILE *file)
> {
> /* If the last two instructions of a function are "call foo; dslot;"
> the return address might point to the first instruction in the next
> function and we have to output a dummy nop for the sake of sane
> backtraces in such cases. This is pointless for sibling calls since
> the return address is explicitly adjusted. */
This nop behaviour could be a bit inconsistent across architectures. For
example, arm and powerpc don't generate a nop here.
I still think that the profiling counter increment in the
__builtin_unreachable() path is a bug.
[Bug debug/99230] [11 Regression] gcc.dg/pr83527.c excess errors: '-fcompare-debug' failure (length)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99230
--- Comment #4 from Jakub Jelinek ---
I can actually reproduce e.g. on x86_64-linux with:
extern void fn2(void);
extern void fn3(int);
int a, b;
void fn1() {
int c;
short d;
switch (a) {
case 22000:
fn2();
case 22300:
b = 0;
case 22600:
case 22601:
case 22900:
fn3(1);
case 20100:
fn3(2);
case 20200:
fn3(3);
case 20300:
fn3(4);
case 20400:
fn3(5);
case 20310:
fn3(4);
case 20410:
fn3(5);
}
if (d || c) {
do
;
while (0);
}
}
and -O2 --param logical-op-non-short-circuit=0 -fcompare-debug
--param=jump-table-max-growth-ratio-for-speed=5000
And the difference is the same:
--- pr99230-4.c.gkd 2021-03-01 13:44:32.625879468 +0100
+++ pr99230-4.gk.c.gkd 2021-03-01 13:44:32.731878292 +0100
@@ -9,7 +9,7 @@ Declarations used by fn1, sorted by DECL
5: void ;
4: void ;
6: void ;
-1: void ;
+1: void ;
;; Function fn1 (fn1, funcdef_no=0, cgraph_uid=1, symbol_order=2)
[Bug middle-end/99151] Missed optimization: Superfluous stack frame and code with noreturn or __builtin_unreachable()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151 --- Comment #7 from Eric Botcazou --- > This nop behaviour could be a bit inconsistent across architectures. For > example, arm and powerpc don't generate a nop here. Well, it's low-level trickery so architecture-dependent by definition. > I still think that the profiling counter increment in the > __builtin_unreachable() path is a bug. How so? I only see a missed optimization, but with -fprofile-arcs -ftest-coverage you're splitting hairs IMO.
[Bug middle-end/99151] Missed optimization: Superfluous stack frame and code with noreturn or __builtin_unreachable()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151 --- Comment #8 from Sebastian Huber --- (In reply to Eric Botcazou from comment #7) > > I still think that the profiling counter increment in the > > __builtin_unreachable() path is a bug. > > How so? I only see a missed optimization, but with -fprofile-arcs > -ftest-coverage you're splitting hairs IMO. The __builtin_unreachable() explicitly mentions the use case with a function which doesn't return in the documentation: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html I would expect from the compiler that it generates then similar code. Having a profiling counter increment in one case and not in the other is not really a nice behaviour.
[Bug middle-end/99151] Missed optimization: Superfluous stack frame and code with noreturn or __builtin_unreachable()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151 Jakub Jelinek changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- We certainly don't claim it is the exact same thing as using the noreturn attribute, it is not. We could in profile.c ignore edges that lead to basic blocks that start with __builtin_unreachable () call as the first non-debug stmt after labels if it was really important, but I'm not convinced it is.
[Bug bootstrap/98338] [10/11 Regression] profiledbootstrap failure on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98338 --- Comment #24 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:150bde36c119eff4b8a74667c9d728d6a8a5e8a1 commit r11-7440-g150bde36c119eff4b8a74667c9d728d6a8a5e8a1 Author: Jan Hubicka Date: Mon Mar 1 14:36:11 2021 +0100 Fix ICE in compute_fn_summary PR ipa/98338 * ipa-fnsummary.c (compute_fn_summary): Fix sanity check.
[Bug bootstrap/98338] [10/11 Regression] profiledbootstrap failure on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98338 Jan Hubicka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #25 from Jan Hubicka --- Fixed. Sorry for the delay - next time I should not commit into a private branch :(
[Bug c++/99294] [modules] tdef-inst-1 fails with -fno-module-lazy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99294 --- Comment #1 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:2e0bb9eec2d455840bc4773391b3313a320b3c23 commit r11-7441-g2e0bb9eec2d455840bc4773391b3313a320b3c23 Author: Nathan Sidwell Date: Mon Mar 1 05:41:10 2021 -0800 c++: Completeness of typedef structs [PR 99294] When we read in a class definition, we use fixup_type_variants to propagate the now-completed fields of the class's TYPE to other variants. Unfortunately that doesn't propagate all of them, and in this case we had a typedef to an (incomplete) instantiation. That typedef ended up with a VOIDmode, which blew up gimple expansion as the type itself isn't VOID. Without modules, that information is propagated in finalize_type_size when laying out the class. But that doesn't happen with stream-in -- we already know the layout. There is already some overlap between the two functions, now there's a bit more. In fixup_type_variants, I pay attention to the TYPE_NAME to decide whether to override a user's TYPE_ALIGN -- variants of the main-variant typedef just copy the main-variant. Other variants recalculate. Overaligning is still permitted. I also added a TYPE_ALIGN_RAW accessor, and fixed a bug in the alignment streaming I noticed. I did not refactor TYPE_ALIGN beyond using the new accessor. (It could be written as ((1 << align_raw) >> 1), rather than use the conditional.) PR c++/99294 gcc/ * tree.h (TYPE_ALIGN_RAW): New accessor. (TYPE_ALIGN): Use it. gcc/cp/ * class.c (fixup_type_variants): Propagate mode, precision, alignment & emptiness. * module.cc (trees_out::type_node): Use TYPE_ALIGN_RAW. (trees_in::tree_node): Rematerialize alignment here. gcc/testsuite/ * g++.dg/modules/pr99294.h: New. * g++.dg/modules/pr99294_a.C: New. * g++.dg/modules/pr99294_b.C: New.
[Bug c++/99294] [modules] tdef-inst-1 fails with -fno-module-lazy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99294 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Nathan Sidwell --- 2e0bb9eec2d 2021-03-01 | c++: Completeness of typedef structs [PR 99294]
[Bug preprocessor/99313] ICE while changing global target options via pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99313 --- Comment #3 from Richard Biener --- But this results in unexpected behavior when there's functions with arch=z13 vs. arch=z9 and depending on "luck" we then inherit the wrong params where we should not? That said, when unifying target/optimize options these should be handled and stored once, right?
[Bug preprocessor/99313] ICE while changing global target options via pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99313 --- Comment #4 from Martin Liška --- (In reply to Richard Biener from comment #3) > But this results in unexpected behavior when there's functions with arch=z13 > vs. arch=z9 and depending on "luck" we then inherit the wrong params where > we should not? Yes. > > That said, when unifying target/optimize options these should be handled > and stored once, right? Exactly, that's the original motivation for merging of them.
[Bug c/99317] New: Missed warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99317
Bug ID: 99317
Summary: Missed warning
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pj at hugeone dot co.uk
Target Milestone: ---
The code:
int *foo(void *v, void *w, int x) {
float * f = v;
int * i = w;
return (x ? f : i);
}
int *foo1(void *v, void *w, int x) {
float * f = v;
int * i = w;
return (1 ? f : (void *)i);
}
int *bar(void *v, void *w, int x) {
float * f = v;
int * i = w;
return (x ? f : (void *)i);
}
Function foo correctly emits the warning:
source>: In function 'foo':
:7:19: warning: pointer type mismatch in conditional expression
7 | return (x ? f : i);
| ^
Casting removes that warming even in the trivial foo1 example.
https://godbolt.org/z/ozsPPY
[Bug ada/99020] ICE in record containing discriminated accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99020 Eric Botcazou changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-03-01 CC||ebotcazou at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Eric Botcazou --- I can reproduce.
[Bug target/99313] ICE while changing global target options via pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99313 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:4ed0a92f6cfc647e2ad8ceaa1e5709545c915465 commit r11-7442-g4ed0a92f6cfc647e2ad8ceaa1e5709545c915465 Author: Martin Liska Date: Mon Mar 1 15:41:14 2021 +0100 s390: add exceptions for param modified by target pragma gcc/ChangeLog: PR target/99313 * optc-save-gen.awk: Add 4 more exceptions. gcc/testsuite/ChangeLog: PR target/99313 * gcc.target/s390/target-attribute/pr99313.c: New test.
[Bug target/99313] ICE while changing global target options via pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99313 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Martin Liška --- Fixed on master.
[Bug target/99314] [Patch] [RISC-V] g++.dg/opt/memcpy1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99314 --- Comment #1 from Kito Cheng --- I didn't see this testcase failed before, and I can't reproduce that on my work environment, do you mind share your build environment, e.g. the version of gcc or the distribution version?
[Bug middle-end/95757] [11 regression] missing warning in gcc.dg/Wstringop-overflow-25.c since r11-1517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95757
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
||jakub at gcc dot gnu.org
--- Comment #8 from Jakub Jelinek ---
We get only 3 warnings on the last function with
-O2 -Wall -Wno-array-bounds --param=logical-op-non-short-circuit=0
-ftrack-macro-expansion=0
while we get 4 with
-O2 -Wall -Wno-array-bounds --param=logical-op-non-short-circuit=1
-ftrack-macro-expansion=0
I think the important differences are that while we have in *.optimized pretty
much the same IL - I only see differences between SSA_NAME versions, in the
--param=logical-op-non-short-circuit=1 case we have more accurate
SSA_NAME_RANGE_INFO on 3 SSA_NAMEs
[local count: 1073741824]:
- _51 ={v} unsigned_value_source;
- if (_51 > 1)
+ _57 ={v} unsigned_value_source;
+ if (_57 > 1)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870912]:
# RANGE [1, 2] NONZERO 3
- _55 = _51 + 1;
+ _55 = _57 + 1;
[local count: 1073741824]:
# RANGE [1, 2] NONZERO 3
- # prephitmp_54 = PHI <_55(3), 1(2)>
- _49 ={v} unsigned_value_source;
- _48 = _49 + 18446744073709551615;
- if (_48 > 1)
+ # prephitmp_50 = PHI <1(2), _55(3)>
+ _52 ={v} unsigned_value_source;
+ _59 = _52 + 18446744073709551615;
+ if (_59 > 1)
goto ; [50.00%]
else
goto ; [50.00%]
- [local count: 268435457]:
- _53 = _49 + 1;
+ [local count: 536870913]:
+ # RANGE [2, 3] NONZERO 3
+ _53 = _52 + 1;
[local count: 1073741824]:
- # prephitmp_57 = PHI <2(4), _53(5)>
+ # RANGE [2, 3] NONZERO 3
+ # prephitmp_54 = PHI <2(4), _53(5)>
_47 ={v} unsigned_value_source;
- _52 = _47 + 18446744073709551614;
- if (_52 > 1)
+ _61 = _47 + 18446744073709551614;
+ if (_61 > 1)
goto ; [50.00%]
else
goto ; [50.00%]
- [local count: 268435457]:
- _59 = _47 + 1;
+ [local count: 536870913]:
+ # RANGE [3, 4] NONZERO 7
+ _48 = _47 + 1;
[local count: 1073741824]:
...
I mean the _53, prephitmp_54 and _48 ranges above in the + lines (i.e. =1).
Early during optimizations we have the usual short-circuit vs.
non-short-circuit differences like:
- # iftmp.0_52 = PHI <_51(3), 0(2)>
- _49 ={v} unsigned_value_source;
- if (_49 == 0)
-goto ; [50.00%]
+ # iftmp.0_58 = PHI <0(2), _57(3)>
+ _52 ={v} unsigned_value_source;
+ _53 = _52 == 0;
+ _54 = _52 > 2;
+ _55 = _53 | _54;
+ if (_55 != 0)
+goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
- if (_49 > 2)
-goto ; [50.00%]
- else
-goto ; [50.00%]
-
- [local count: 268435456]:
- [local count: 1073741824]:
- # iftmp.0_50 = PHI <1(4), 1(5), _49(6)>
+ [local count: 1073741824]:
+ # iftmp.0_56 = PHI <1(4), _52(5)>
but they gradually disappear.
Right before *.dom3 the IL is already pretty much the same when ignoring
SSA_NAME version differences,
except:
- # prephitmp_54 = PHI <_55(3), 1(2)>
- _49 ={v} unsigned_value_source;
- _48 = _49 + 18446744073709551615;
- _1 = _48 > 1;
- if (_1 != 0)
+ # prephitmp_50 = PHI <1(2), _55(3)>
+ _52 ={v} unsigned_value_source;
+ _59 = _52 + 18446744073709551615;
+ if (_59 > 1)
and
_47 ={v} unsigned_value_source;
- _52 = _47 + 18446744073709551614;
- _50 = _52 > 1;
- if (_50 != 0)
+ _61 = _47 + 18446744073709551614;
+ if (_61 > 1)
i.e. the - version (=0) doesn't have the comparisons folded into GIMPLE_CONDs
while the + version (=1) does.
And I believe that is the trigger on why during dom3 adds the more precise
ranges in the --param=logical-op-non-short-circuit=1 case and not in the
--param=logical-op-non-short-circuit=0 case.
[Bug c++/99318] New: [10/11 Regression] -Wdeprecated-declarations where non-should be?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99318
Bug ID: 99318
Summary: [10/11 Regression] -Wdeprecated-declarations where
non-should be?
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
Target Milestone: ---
Hello gcc-team,
since gcc 10 the following code throws a deprecation warning, even though it
doesn't use any deprecated code.
```c++
template
class alphabet_base
{
[[deprecated("message")]] unsigned char_to_rank_table(char const chr)
{
using index_t = unsigned;
return derived_type::char_to_rank[static_cast(chr)];
}
};
```
gives the following warning:
```
: In member function 'unsigned int
alphabet_base::char_to_rank_table(char)':
:7:55: warning: 'unsigned int
alphabet_base::char_to_rank_table(char)' is deprecated: message
[-Wdeprecated-declarations]
7 | return derived_type::char_to_rank[static_cast(chr)];
| ^~~
:4:40: note: declared here
4 | [[deprecated("message")]] unsigned char_to_rank_table(char const
chr)
|^~
Compiler returned: 0
```
See https://godbolt.org/z/4cWzMr
Thank you!
[Bug debug/99319] New: DW_MACRO_define_strp uses uleb128 for second operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99319 Bug ID: 99319 Summary: DW_MACRO_define_strp uses uleb128 for second operand Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- Consider compiling hello world, with macro info: ... $ gcc-11 -ggdb3 -g hello.c -dA -save-temps ... In a-hello.s, we have: ... .section.debug_macro,"",@progbits .Ldebug_macro0: .value 0x5 # DWARF macro version number .byte 0x2 # Flags: 32-bit, lineptr present .long .Ldebug_line0 .byte 0x3 # Start new file .uleb128 0 # Included from line number 0 .uleb128 0x1# file hello.c .byte 0x5 # Define macro strp .uleb128 0 # At line number 0 .long .LASF2 # The macro: "__STDC__ 1" ... So, the DW_MACRO_define_strp entry (starting with .byte 0x5) has two operands, a uleb128 and a .long. AFAIU, this is in accordance with the spec: ... A DW_MACRO_define_strp or DW_MACRO_undef_strp entry has two operands. The first operand encodes the source line number of the #define or #undef macro directive. The second operand consists of an offset into a string table contained in the .debug_str section of the object file. The size of the operand is given in the header offset_size_flag field. ... Now add -gsplit-dwarf: ... $ gcc-11 -ggdb3 -g hello.c -dA -save-temps -gsplit-dwarf ... Now we have instead: ... .section.debug_macro.dwo,"e",@progbits .Ldebug_macro0: .value 0x5 # DWARF macro version number .byte 0x2 # Flags: 32-bit, lineptr present .long .Lskeleton_debug_line0 .byte 0x3 # Start new file .uleb128 0 # Included from line number 0 .uleb128 0x1# file hello.c .byte 0x5 # Define macro strp .uleb128 0 # At line number 0 .uleb128 0x191 # The macro: "__STDC__ 1" ... The second operand is now also a .uleb128. AFAIU, this goes against the spec.
[Bug debug/99319] DW_MACRO_define_strp uses uleb128 for second operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99319 --- Comment #1 from Tom de Vries --- Related readelf PR: https://sourceware.org/bugzilla/show_bug.cgi?id=27387
[Bug debug/99319] DW_MACRO_define_strp uses uleb128 for second operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99319 --- Comment #2 from Tom de Vries --- (In reply to Tom de Vries from comment #0) > The second operand is now also a .uleb128. AFAIU, this goes against the > spec. Also, gdb doesn't get it: ... $ gdb -q -batch -readnow a.out DW_FORM_strp pointing outside of .debug_str section [in module /home/vries/hello/a.out] ... Debugging shows that the error is due to a large str_offset: ... (gdb) p /x str_offset $14 = 0x8c0502cd ... which matches this: ... .byte 0x5 # Define macro strp .uleb128 0x8b # At line number 139 .uleb128 0x14d # The macro: "stdin stdin" .byte 0x5 # Define macro strp .uleb128 0x8c # At line number 140 .uleb128 0x24 # The macro: "stdout stdout" ... Note that the uleb128 representation of 0x14d is "cd02".
[Bug rtl-optimization/99320] New: constexpr defined arrays within constexpr functions would benefit from lookup-tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99320
Bug ID: 99320
Summary: constexpr defined arrays within constexpr functions
would benefit from lookup-tables
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
Target Milestone: ---
Hi gcc-team,
first of all, sorry if this is the wrong component, but I guess that this is a
"missed-optimization" issue rather than a regular C++ issue, so I wasn't sure
which component fit the most.
I have the following code (which can be further reduced, but I kept it as
original as possible to reflect my use case):
```c++
#include
struct foo
{
static constexpr char bar(unsigned idx)
{
constexpr std::array lookup_table
{
[] () constexpr
{
std::array ret{};
// reverse mapping for characters and their lowercase
for (unsigned rnk = 0u; rnk < 15; ++rnk)
{
ret[rnk + 'A'] = rnk;
}
// set U equal to T
ret['U'] = ret['T']; ret['u'] = ret['t'];
// iupac characters get special treatment, because there is no N
ret['R'] = ret['A']; ret['r'] = ret['A']; // A or G
ret['Y'] = ret['C']; ret['y'] = ret['C']; // C or T
ret['S'] = ret['C']; ret['s'] = ret['C']; // C or G
ret['W'] = ret['A']; ret['w'] = ret['A']; // A or T
ret['K'] = ret['G']; ret['k'] = ret['G']; // G or T
ret['M'] = ret['A']; ret['m'] = ret['A']; // A or T
ret['B'] = ret['C']; ret['b'] = ret['C']; // C or G or T
ret['D'] = ret['A']; ret['d'] = ret['A']; // A or G or T
ret['H'] = ret['A']; ret['h'] = ret['A']; // A or C or T
ret['V'] = ret['A']; ret['v'] = ret['A']; // A or C or G
return ret;
}()
};
return lookup_table[idx];
}
};
int main(int argc, char const ** argv)
{
return foo::bar(argc);
}
```
I wanted to switch from defining that lookup-table within the class (e.g.
`static constexpr ... lookup_table = ...`) to define the lookup-table within
the function directly, and I noticed that I had some performance regression in
my benchmarks. Some micro benchmarks went from ~80ns to ~3000ns, but I also saw
an impact on more "realistic" macro benchmarks.
After looking at the assembly https://godbolt.org/z/n9bo7W, I noticed that the
table is "constructed" on each function call rather than a single
lookup-instruction.
So I compared it to what clang does, and it seems that they are actually
generating a static lookup table.
I know that this use case is quite niche, but it would be cool to have it
nevertheless :)
Thank you!
[Bug debug/99319] DW_MACRO_define_strp uses uleb128 for second operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99319 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2021-03-01 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 50274 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50274&action=edit gcc11-pr99319.patch Ugh, this is a mess. Seems r0-120109-g99ea153e45c86a1b0318e3f5e983624c3336445e that introduced the DWARF 4 -gsplit-dwarf extension came after I've introduced .debug_macro also as DWARF 4 extension, but not too long after it so it hasn't thought out interactions very well. So, I'm afraid for version 4 .debug_macro.dwo consumers should expect 2 leb128 arguments instead of one + offse. And for DWARF 5 we have the standardized DW_MACRO_*_strx which make those explicit, so this patch changes GCC to emit that.
[Bug rtl-optimization/99320] constexpr defined arrays within constexpr functions would benefit from lookup-tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99320 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Looks like a dup of PR99091 to me.
[Bug target/99321] New: [11 Regression] ICE: in extract_constrain_insn, at recog.c:2670: insn does not satisfy its constraints: {*uminv16qi3}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99321
Bug ID: 99321
Summary: [11 Regression] ICE: in extract_constrain_insn, at
recog.c:2670: insn does not satisfy its constraints:
{*uminv16qi3}
Product: gcc
Version: 11.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: x86_64-pc-linux-gnu
Created attachment 50275
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50275&action=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -mtune=btver2 -fno-tree-dce -mavx512vl testcase.c
testcase.c: In function 'foo0':
testcase.c:68:1: error: insn does not satisfy its constraints:
68 | }
| ^
(insn 2646 2645 2188 2 (set (reg/v:V16QI 27 xmm7 [orig:428 v128u8_0 ] [428])
(umin:V16QI (reg/v:V16QI 27 xmm7 [orig:428 v128u8_0 ] [428])
(reg/v:V16QI 53 xmm17 [orig:428 v128u8_0 ] [428])))
"testcase.c":28:50 3810 {*uminv16qi3}
(nil))
during RTL pass: cprop_hardreg
testcase.c:68:1: internal compiler error: in extract_constrain_insn, at
recog.c:2670
0x703506 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.c:108
0x703593 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.c:118
0x6f1f3f extract_constrain_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.c:2670
0xfae7cc copyprop_hardreg_forward_1
/repo/gcc-trunk/gcc/regcprop.c:831
0xfaf9fe execute
/repo/gcc-trunk/gcc/regcprop.c:1396
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.
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-7439-20210301075850-g074226d5aa8-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
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 --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r11-7439-20210301075850-g074226d5aa8-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.1 20210301 (experimental) (GCC)
[Bug rtl-optimization/99320] constexpr defined arrays within constexpr functions would benefit from lookup-tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99320 --- Comment #2 from gcc-bugs at marehr dot dialup.fu-berlin.de --- You are right, it seems to be the same issue except that my function is constexpr, and I can't use `static constexpr ...` within the function, but Barry mentioned that use case already. You mentioned something that gcc needs to prove that this is safe, but I think my use case is "safe" since it is constexpr :)
[Bug rtl-optimization/99320] constexpr defined arrays within constexpr functions would benefit from lookup-tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99320 --- Comment #3 from Jakub Jelinek --- constexpr doesn't imply anything like that. constexpr variables can still be odr-used, their address taken, compared etc.
[Bug c++/98432] [coroutine] leaked frame created using await_transform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98432 Tomáš Hering changed: What|Removed |Added Attachment #49839|0 |1 is obsolete|| --- Comment #3 from Tomáš Hering --- Created attachment 50276 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50276&action=edit unprocessed source
[Bug libstdc++/99306] cross compiler bootstrap failure on msdosdjgpp: error: alignment of 'm' is greater than maximum object file alignment 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99306 --- Comment #3 from Jonathan Wakely --- It's intended to be the cacheline size, so would use std::hardware_destructive_interference_size, but that's not implemented yet for the reasons given in PR 88466. And also because it's just a very verbose way to say 64 :-P
[Bug middle-end/99299] Need a recoverable version of __builtin_trap()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299 --- Comment #6 from Segher Boessenkool --- (In reply to Richard Biener from comment #4) > I'm not sure what your proposed not noreturn trap() would do in terms of > IL semantics compared to a not specially annotated general call? Nothing I think? But __builtin_trap *is* very different: it ends BBs. > "recoverable" likely means resuming after the trap, not on an exception > path (so it'll not be a throw())? "recoverable" is super unclear. For example, on Power the hardware has a concept "recoverable interrupt", which set MSR[RI]=1, and traps never do. This is a very different concept as what is wanted here, which has nothing to do with recoverability, and is simply about not being an abort() (which __builtin_trap *is*!) > The only thing that might be useful to the middle-end would be marking > the function as not altering the memory state. But I suppose it should > still serve as a barrier for code motion of both loads and stores, even > of those loads/stores are known to not trap. The only magic we'd have > for this would be __attribute__((const,returns_twice)). Which likely > will be more detrimental to general optimization. > > So - what's the "sub-optimal code generation" you refer to from the > (presumably) volatile asm() you use for the trap? > > [yeah, asm() on GIMPLE is less optimized than a call] The rs6000 backend can optimise the used instructions: we have trap_if instructions, both with registers and with immediates. A single instruction can do a comparison and a conditional trap. This works great with __builtin_trap, *if* the kernel's trap handler has abort() semantics. __builtin_trap_no_abort() maybe?
[Bug middle-end/99299] Need a recoverable version of __builtin_trap()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299 --- Comment #7 from Segher Boessenkool --- (In reply to Franz Sirl from comment #5) > For the naming I suggest __builtin_debugtrap() to align with clang. Maybe > with an aliased __debugbreak() on Windows platforms. Those are terrible names. This would *not* be used more often than __builtin_trap, for debugging. In general, builtins should say what they *do*, nott what you imagine they will be used for.
[Bug c++/98432] [coroutine] leaked frame created using await_transform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98432 --- Comment #4 from Iain Sandoe --- (In reply to Tomáš Hering from comment #3) > Created attachment 50276 [details] > unprocessed source thanks! but ... (on x86_64-linux-gnu and x86_64-darwin16): $ gcc-10-2/bin/g++ -std=c++20 -fcoroutines pr98432.C -o t -O3 -Wall -Wextra $ ./t allocated frames 1 allocated frames 2 allocated frames 3 allocated frames: 2 allocated frames: 1 hello coro-world allocated frames: 0 === same on 10.x and master. [ I will try on some older platforms, and on a 32b host too, later ]. So I'm still a bit stuck - given that coroutines is pretty much a Front End code base, it seems odd that there would be some platform dependence here (I guess there could be a an allocation/deallocation bug). Maybe we could try to find some difference in the initial gimple [-fdump-tree-gimple].
[Bug c/99322] New: [11 Regression] ICE in change_scope, at final.c:1480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99322
Bug ID: 99322
Summary: [11 Regression] ICE in change_scope, at final.c:1480
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20201018 and 20201108 :
$ cat z1.c
void g ();
void f ()
{
#pragma omp parallel
for (;;)
for (int i = 0; i < 8; ++i)
g ();
{ L1: }
&&L1;
}
$ gcc-11-20210228 -c z1.c -fopenmp -O2 -g
$ gcc-11-20210228 -c z1.c -fopenmp -O3
$
$ gcc-11-20210228 -c z1.c -fopenmp -O3 -g
during RTL pass: final
z1.c: In function 'f._omp_fn.0':
z1.c:4:11: internal compiler error: Segmentation fault
4 | #pragma omp parallel
| ^~~
0xb5eeff crash_signal
../../gcc/toplev.c:327
0x87295d change_scope
../../gcc/final.c:1480
0x8792c1 reemit_insn_block_notes
../../gcc/final.c:1581
0x8792c1 final_start_function_1
../../gcc/final.c:1785
0x879549 rest_of_handle_final
../../gcc/final.c:4675
0x879549 execute
../../gcc/final.c:4754
---
z1.c: In function 'f._omp_fn.0':
z1.c:10:1: error: location references block not in block tree
10 | }
| ^
L1:
during IPA pass: *free_lang_data
z1.c:10:1: internal compiler error: verify_gimple failed
0xd94884 verify_gimple_in_cfg(function*, bool)
../../gcc/tree-cfg.c:5477
0xc45d3e execute_function_todo
../../gcc/passes.c:2042
0xc46b7d do_per_function
../../gcc/passes.c:1694
0xc46be2 execute_todo
../../gcc/passes.c:2096
[Bug c/99323] New: [9/10/11 Regression] ICE in add_hint, at diagnostic-show-locus.c:2234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99323
Bug ID: 99323
Summary: [9/10/11 Regression] ICE in add_hint, at
diagnostic-show-locus.c:2234
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
With testfile gcc.c-torture/compile/limits-externdecl.c
and options -Wall -no-integrated-cpp, started with r8 :
$ gcc-11-20210228 -c limits-externdecl.c -no-integrated-cpp
$
$ gcc-11-20210228 -c limits-externdecl.c -Wall -no-integrated-cpp
limits-externdecl.c:55:26: warning: missing braces around initializer
[-Wmissing-braces]
55 | REFERENCE references[] = {
| ^
56 | LIM5 (X)
limits-externdecl.c:58:1: internal compiler error: in add_hint, at
diagnostic-show-locus.c:2234
58 | };
| ^
0x15769cf add_hint
../../gcc/diagnostic-show-locus.c:2233
0x15769cf print_trailing_fixits
../../gcc/diagnostic-show-locus.c:2316
0x15769cf print_line
../../gcc/diagnostic-show-locus.c:2555
0x15769cf diagnostic_show_locus(diagnostic_context*, rich_location*,
diagnostic_t)
../../gcc/diagnostic-show-locus.c:2637
0x6e9ef5 c_diagnostic_finalizer
../../gcc/c-family/c-opts.c:175
0x157029b diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.c:1251
0x157091e diagnostic_impl
../../gcc/diagnostic.c:1406
0x1572272 warning_at(rich_location*, int, char const*, ...)
../../gcc/diagnostic.c:1558
0x662913 pop_init_level(unsigned int, int, obstack*, unsigned int)
../../gcc/c/c-typeck.c:8839
0x684a0a c_parser_braced_init
../../gcc/c/c-parser.c:5280
0x686d1e c_parser_initializer
../../gcc/c/c-parser.c:5201
0x694e3a c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2276
0x69c717 c_parser_external_declaration
../../gcc/c/c-parser.c:1777
0x69d239 c_parser_translation_unit
../../gcc/c/c-parser.c:1650
0x69d239 c_parse_file()
../../gcc/c/c-parser.c:21984
0x6ed0a2 c_common_parse_file()
../../gcc/c-family/c-opts.c:1218
[Bug target/99321] [11 Regression] ICE: in extract_constrain_insn, at recog.c:2670: insn does not satisfy its constraints: {*uminv16qi3} since r11-7121-g37876976b0511ec9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99321
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |11.0
Last reconfirmed||2021-03-01
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Summary|[11 Regression] ICE: in |[11 Regression] ICE: in
|extract_constrain_insn, at |extract_constrain_insn, at
|recog.c:2670: insn does not |recog.c:2670: insn does not
|satisfy its constraints:|satisfy its constraints:
|{*uminv16qi3} |{*uminv16qi3} since
||r11-7121-g37876976b0511ec9
CC||jakub at gcc dot gnu.org,
||marxin at gcc dot gnu.org
--- Comment #1 from Martin Liška ---
Confirmed, started with r11-7121-g37876976b0511ec9.
[Bug target/99321] [11 Regression] ICE: in extract_constrain_insn, at recog.c:2670: insn does not satisfy its constraints: {*uminv16qi3} since r11-7121-g37876976b0511ec9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99321 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
[Bug c/99324] New: ICE in mark_addressable, at gimple-expr.c:918
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99324
Bug ID: 99324
Summary: ICE in mark_addressable, at gimple-expr.c:918
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to r6, with missing ";" at /// :
$ cat z1.c
#include
void f (int x, ...)
{
va_list a;
va_arg (a, int);
int b () ///;
int c[va_arg (a, int)];
va_end (a);
return;
}
$ gcc-11-20210228 -c z1.c
z1.c: In function 'b':
z1.c:7:3: internal compiler error: Segmentation fault
7 | int c[va_arg (a, int)];
| ^~~
0xb5eeff crash_signal
../../gcc/toplev.c:327
0x8c6733 mark_addressable(tree_node*)
../../gcc/gimple-expr.c:918
0x6ce03c build_va_arg(unsigned int, tree_node*, tree_node*)
../../gcc/c-family/c-common.c:4630
0x6751b6 c_parser_postfix_expression
../../gcc/c/c-parser.c:9141
0x67e012 c_parser_unary_expression
../../gcc/c/c-parser.c:8224
0x67f03f c_parser_cast_expression
../../gcc/c/c-parser.c:8066
0x67f2f9 c_parser_binary_expression
../../gcc/c/c-parser.c:7869
0x680305 c_parser_conditional_expression
../../gcc/c/c-parser.c:7592
0x680861 c_parser_expr_no_commas
../../gcc/c/c-parser.c:7507
0x67d1f6 c_parser_direct_declarator_inner
../../gcc/c/c-parser.c:4095
0x694483 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2148
0x695709 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2498
0x693bb9 c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:5700
0x693ff3 c_parser_compound_statement
../../gcc/c/c-parser.c:5597
0x6958a8 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2539
0x69c717 c_parser_external_declaration
../../gcc/c/c-parser.c:1777
0x69d239 c_parser_translation_unit
../../gcc/c/c-parser.c:1650
0x69d239 c_parse_file()
../../gcc/c/c-parser.c:21984
0x6ed0a2 c_common_parse_file()
../../gcc/c-family/c-opts.c:1218
[Bug target/99143] Bad section alignment on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143 Richard Earnshaw changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #8 from Richard Earnshaw --- There is nothing in C (or other languages for that matter) that will guarantee that independent objects will be packed without space around them. So the premise of this bug report is simply invalid.
[Bug fortran/87127] External function not recognised from within an associate block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87127 Vladimir Fuka changed: What|Removed |Added CC||vladimir.fuka at gmail dot com --- Comment #8 from Vladimir Fuka --- I see a comment but at the same time the status is NEW. What is the actual status? In any case, the issue still exists in GCC 11. https://stackoverflow.com/questions/66424857/dlantr-at-1-is-not-a-function/66425244?noredirect=1#comment117432549_66425244
[Bug c/99325] New: [11 Regression] ICE in maybe_print_line_1, at c-family/c-ppoutput.c:454
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99325 Bug ID: 99325 Summary: [11 Regression] ICE in maybe_print_line_1, at c-family/c-ppoutput.c:454 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20201115 and 20201122 : $ cat z1.c #line 9223372036854775807 #pragma message "abc" $ gcc-11-20210228 -c z1.c -no-integrated-cpp z1.c:1:7: warning: line number out of range 1 | #line 9223372036854775807 | ^~~ z1.c:-1: internal compiler error: Segmentation fault 0xb5eeff crash_signal ../../gcc/toplev.c:327 0x6edd15 maybe_print_line_1 ../../gcc/c-family/c-ppoutput.c:454 0x6edd15 maybe_print_line ../../gcc/c-family/c-ppoutput.c:479 0x6ee7fe token_streamer::stream(cpp_reader*, cpp_token const*, unsigned int) ../../gcc/c-family/c-ppoutput.c:270 0x6eea03 scan_translation_unit ../../gcc/c-family/c-ppoutput.c:322 0x6eea03 preprocess_file(cpp_reader*) ../../gcc/c-family/c-ppoutput.c:102 0x6ecf90 c_common_init() ../../gcc/c-family/c-opts.c:1195 0x62f8bd lang_dependent_init ../../gcc/toplev.c:1889 0x62f8bd do_compile ../../gcc/toplev.c:2186
[Bug fortran/99326] New: [9/10/11 Regression] ICE in gfc_build_dummy_array_decl, at fortran/trans-decl.c:1299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99326 Bug ID: 99326 Summary: [9/10/11 Regression] ICE in gfc_build_dummy_array_decl, at fortran/trans-decl.c:1299 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with r9, changed between 20181014 and 20181021 : $ cat z1.f90 program p type t0 end type type t class(t0), allocatable :: a(:) end type contains subroutine s(x) class(t0) :: x(:) type(t) :: z associate (y => x) z%a = y end associate end end $ gfortran-9-20181014 -c z1.f90 z1.f90:11:23: 11 | associate (y => x) | 1 Error: Assumed shape array at (1) must be a dummy argument $ gfortran-11-20210228 -c z1.f90 z1.f90:1:9: 1 | program p | 1 internal compiler error: in gfc_build_dummy_array_decl, at fortran/trans-decl.c:1299 0x754a97 gfc_build_dummy_array_decl ../../gcc/fortran/trans-decl.c:1299 0x759043 gfc_get_symbol_decl(gfc_symbol*) ../../gcc/fortran/trans-decl.c:1697 0x75c05f generate_local_decl ../../gcc/fortran/trans-decl.c:5950 0x71af42 do_traverse_symtree ../../gcc/fortran/symbol.c:4170 0x75d004 generate_local_vars ../../gcc/fortran/trans-decl.c:6156 0x75d004 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6815 0x75cfe4 gfc_generate_contained_functions ../../gcc/fortran/trans-decl.c:5874 0x75cfe4 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6812 0x6e3a46 translate_all_program_units ../../gcc/fortran/parse.c:6351 0x6e3a46 gfc_parse_file() ../../gcc/fortran/parse.c:6620 0x72fd7f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug c++/99327] New: ENOTSUP macro does not exist on djgpp crt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99327 Bug ID: 99327 Summary: ENOTSUP macro does not exist on djgpp crt Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- libstdc++'s filesystem uses std::errc::not_supported but that does not exist on djgpp. Bootstrap failure What I did was just #define ENOTSUP 42 in errno.h and bootstrap succeed However, strerror will not work for this anymore. There is another solution for this. Replace all std::errc::not_supported to std::errc::invalid_argument since EINVAL should exist on all platforms.
[Bug libstdc++/99327] ENOTSUP macro does not exist on djgpp crt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99327 --- Comment #1 from cqwrteur --- Created attachment 50277 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50277&action=edit DJGPP's original errno This is djgpp crt's original errno.
[Bug rtl-optimization/99328] New: ICE: in verify_target_availability, at sel-sched.c:1557 with -fselective-scheduling2 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99328
Bug ID: 99328
Summary: ICE: in verify_target_availability, at
sel-sched.c:1557 with -fselective-scheduling2 on
aarch64
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
gcc11 has the following ICE:
$ cat t.c
long a;
double b, c;
double fn1(double);
void fn2(long *);
void fn3(int p1) {
fn2(&a);
if (fn1(0) >= p1)
b = c;
}
$ sh t
/data1/qing/Install/latest/bin/gcc -fprofile-generate -Ofast
-fselective-scheduling -fselective-scheduling2 -c -o t.o t.c
during RTL pass: sched2
t.c: In function 'fn3':
t.c:9:1: internal compiler error: in verify_target_availability, at
sel-sched.c:1557
9 | }
| ^
0xd86fbb verify_target_availability
../../latest_gcc/gcc/sel-sched.c:1553
0xd86fbb find_best_reg_for_expr
../../latest_gcc/gcc/sel-sched.c:1667
0xd89f33 fill_vec_av_set
../../latest_gcc/gcc/sel-sched.c:3784
0xd89f33 fill_ready_list
../../latest_gcc/gcc/sel-sched.c:4014
0xd89f33 find_best_expr
../../latest_gcc/gcc/sel-sched.c:4374
0xd89f33 fill_insns
../../latest_gcc/gcc/sel-sched.c:5535
0xd8ba17 schedule_on_fences
../../latest_gcc/gcc/sel-sched.c:7353
0xd8ba17 sel_sched_region_2
../../latest_gcc/gcc/sel-sched.c:7491
0xd8c517 sel_sched_region_1
../../latest_gcc/gcc/sel-sched.c:7533
0xd8e573 sel_sched_region(int)
../../latest_gcc/gcc/sel-sched.c:7634
0xd8f1b7 run_selective_scheduling()
../../latest_gcc/gcc/sel-sched.c:7720
0xd6a32f rest_of_handle_sched2
../../latest_gcc/gcc/sched-rgn.c:3738
0xd6a32f execute
../../latest_gcc/gcc/sched-rgn.c:3882
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/99317] Missed warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99317 --- Comment #1 from Andrew Pinski --- I dont think this is exactly a bug. The warning is a pedantic warning and with void*, things are implicitly converted by standard c rules.
[Bug c/99329] New: [OpenMP] device_type(nohost) & host code diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99329
Bug ID: 99329
Summary: [OpenMP] device_type(nohost) & host code diagnostic
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid, openmp
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Based on https://github.com/SOLLVE/sollve_vv/pull/304#issuecomment-788114379
not yet looked into it.
#pragma omp declare target
int a[N], b[N], c[N];
int i = 0;
#pragma omp end declare target
void update() {
for (i = 0; i < N; i++) {
a[i] += 1;
b[i] += 2;
c[i] += 3;
}
}
#pragma omp declare target to(update) device_type(nohost)
int test_declare_target_device_type_nohost() {
#pragma omp target update to(a,b,c)
#pragma omp target
{
// if (!omp_is_initial_device()) // < no change with this.
update();
}
...
CLANG gives for this:
nohost.c:42:6: error: function with 'device_type(nohost)' is not available on
host
update();
^
nohost.c:34:31: note: marked as 'device_type(nohost)' here
#pragma omp declare target to(update) device_type(nohost)
[Bug c++/99330] New: module ICE with -std=c++2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99330
Bug ID: 99330
Summary: module ICE with -std=c++2b
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: unlvsur at live dot com
Target Milestone: ---
module;
export module hello;
export inline void greeter()
{
}
cqwrteur@DESKTOP-DFHPDC1:/mnt/d/Desktop/hello$ g++ -c hello.cc -Ofast
-std=c++20 -s -flto -march=native -std=c++2b -fmodules-ts
hello.cc:2:8: internal compiler error: in get_cxx_dialect_name, at
cp/name-lookup.c:7027
2 | export module hello;
|^~
emit..
-std=c++2b triggers fmodules-ts to ICE
[Bug libstdc++/99327] ENOTSUP macro does not exist on djgpp crt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99327 Jonathan Wakely changed: What|Removed |Added Keywords||build Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-03-01 Target||*-pc-msdosdjgpp
[Bug target/99271] [10 regression] Wrong code for Arm-v8-m.main CMSE calling __gnu_cmse_nonsecure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99271 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:1b3bb23a576e6a864f540e3bea5097f47fea507c commit r10-9398-g1b3bb23a576e6a864f540e3bea5097f47fea507c Author: Richard Earnshaw Date: Mon Feb 22 15:00:53 2021 + arm: force use of r4 for __gnu_cmse_nonsecure_call when !FPCXT [PR99271] Commit r10-6017 relaxed the constraint on thumb2 calls to __gnu_cmse_nonsecure_call to allow any register for the call address. Although the initial code expansion continues to use r4 with the FPCXT extension is not enabled, the change was unsafe because subsequent optimizations could use the additional freedom to change which register was being used. To fix this we need to split the output patterns in the machine description to use distinct recognizers: one with the additional freedom when FPCXT is enabled an another that retains the original restrictions when the extension is not available. gcc: PR target/99271 * config/arm/thumb2.md (nonsecure_call_reg_thumb2_fpcxt): New pattern. (nonsecure_call_value_reg_thumb2_fpcxt): Likewise. (nonsecure_call_reg_thumb2): Restrict to using r4 for the callee address and disable when the FPCXT is not available. (nonsecure_call_value_reg_thumb2): Likewise. gcc/testsuite: * gcc.target/arm/cmse/cmse-18.c: New test.
[Bug c++/98432] [coroutine] leaked frame created using await_transform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98432 Tomáš Hering changed: What|Removed |Added Attachment #50276|0 |1 is obsolete|| --- Comment #5 from Tomáš Hering --- Created attachment 50278 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50278&action=edit unprocessed original source Oops, seems I uploaded a slightly different code. I apologize. It's strange you can't reproduce the issue, though. Please see the demo with the original code on godbolt (https://godbolt.org/z/Gao919) which is in accordance with my local output. Please note that the behavior now seems correct when setting the trunk version of gcc there. Perhaps it has been fixed in some recent commit.
[Bug target/99271] [10 regression] Wrong code for Arm-v8-m.main CMSE calling __gnu_cmse_nonsecure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99271 Richard Earnshaw changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Earnshaw --- Fixed on all affected branches.
[Bug c/99295] [9/10/11 Regression] documentation on __attribute__((malloc)) is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99295 Martin Sebor changed: What|Removed |Added Known to fail||10.2.1, 9.3.0 Summary|[11 Regression] |[9/10/11 Regression] |documentation on|documentation on |__attribute__((malloc)) is |__attribute__((malloc)) is |wrong |wrong Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Known to work|10.2.1 |8.3.0 Keywords||patch Status|NEW |ASSIGNED --- Comment #3 from Martin Sebor --- I agree the insertion of the sentence: Compiler predicts that a function with the attribute returns non-null in most cases. make the following sentence at least ambiguous if not incorrect. The sentence was added in r263355, in response to pr83023. I have posted the following change to avoid the unintended reading: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566030.html
[Bug middle-end/99299] Need a recoverable version of __builtin_trap()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299 --- Comment #8 from Franz Sirl --- (In reply to Segher Boessenkool from comment #7) > (In reply to Franz Sirl from comment #5) > > For the naming I suggest __builtin_debugtrap() to align with clang. Maybe > > with an aliased __debugbreak() on Windows platforms. > > Those are terrible names. This would *not* be used more often than > __builtin_trap, for debugging. > > In general, builtins should say what they *do*, nott what you imagine they > will be used for. Let me re-phrase it. If the result of this discussion will result in a builtin that will be eqivalent to an "int 3" (or was it ud2? on x86) without "noreturn" as it is with clang, I would really prefer it to be called __builtin_debugtrap() even if the name is not great. Having different naming between GCC and clang seems worse to me.
[Bug fortran/87127] External function not recognised from within an associate block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87127 --- Comment #9 from Vladimir Fuka --- I see now, it was fixed on the 8 branch, but not on the trunk! It ought to be applied at least to the 12.
[Bug middle-end/95757] [11 regression] missing warning in gcc.dg/Wstringop-overflow-25.c since r11-1517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95757 --- Comment #9 from Jakub Jelinek --- Created attachment 50279 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50279&action=edit gcc11-pr95757.patch Untested fix.
[Bug c++/99331] New: -Wconversion false-positive in immidiate context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99331
Bug ID: 99331
Summary: -Wconversion false-positive in immidiate context
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
template struct X {};
template X foo();
g++ -Wconversion -Werror src.cpp
:2:22: error: conversion from 'long unsigned int' to 'int' may change
value [-Werror=conversion]
2 | template X foo();
| ^
https://godbolt.org/z/d16WhG
[Bug c++/99331] [8/9/10/11 Regression] -Wconversion false-positive in immediate context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99331 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Summary|-Wconversion false-positive |[8/9/10/11 Regression] |in immidiate context|-Wconversion false-positive ||in immediate context Target Milestone|--- |8.5 Priority|P3 |P2 Last reconfirmed||2021-03-01 Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Confirmed. Started in GCC 7.
[Bug middle-end/99299] Need a recoverable version of __builtin_trap()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299
--- Comment #9 from Segher Boessenkool ---
The i386 port has
===
(define_insn "trap"
[(trap_if (const_int 1) (const_int 6))]
""
{
#ifdef HAVE_AS_IX86_UD2
return "ud2";
#else
return ASM_SHORT "0x0b0f";
#endif
}
[(set_attr "length" "2")])
===
which implements __builtin_trap, and can implement __builtin_trap_no_abort
just fine as well, if your OS kernel (or similar) can return after a ud2.
If clang uses terribly confusing names (or semantics, or syntax, etc.) we
should not copy that from them. *Especially* when that already conflicts
with names they copied from us.
[Bug c++/99331] [8/9/10/11 Regression] -Wconversion false-positive in immediate context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99331 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 --- Started with commit 16b61424dd309f61326f577a6deb8487c6c1f291 Author: Jason Merrill Date: Fri Oct 21 15:45:45 2016 -0400 re PR c++/77656 (64-bit integral template parameter gets incorrectly sized as 32-bits) PR c++/77656 * pt.c (convert_template_argument): Call convert_nontype_argument on value-dependent but not type-dependent arguments. (convert_nontype_argument): Handle value-dependent arguments. (canonicalize_expr_argument): New. (deducible_expression, unify): Skip CONVERT_EXPR. * error.c (dump_template_argument): Likewise. * mangle.c (write_expression): Likewise. From-SVN: r241425 think I'll have a look at this myself, though.
[Bug c++/99331] [8/9/10/11 Regression] -Wconversion false-positive in immediate context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99331
--- Comment #3 from Nikita Kniazev ---
This one most likely has the same root problem:
template struct X {};
template
struct foo { using t = X; };
:3:26: error: conversion from 'long unsigned int' to 'int' may change
value [-Werror=conversion]
3 | struct foo { using t = X; };
| ^
[Bug target/99321] [11 Regression] ICE: in extract_constrain_insn, at recog.c:2670: insn does not satisfy its constraints: {*uminv16qi3} since r11-7121-g37876976b0511ec9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99321
--- Comment #2 from Jakub Jelinek ---
I'm afraid we have multiple problems with -mavx512vl -mno-avx512bw (are there
any CPUs with that combination of ISA sets though?).
In r7-618-g9bdf001b7a2232753e4a92582218bb4f24c8d809 I've fixed the 16-byte
vp{min,max}ub to not allow v constraints when not AVX512BW.
But clearly many other patterns need something like that and don't have that.
E.g. vp{add,sub,{min,max},{u,s}}{b,w}, both 16-byte and 32-byte.
The result of that aren't ICEs, but code silently using AVX512BW features when
AVX512VL is enabled but AVX512BW is not.
Similarly, vpmullq needs AVX512DQ.
And, another thing is that the:
(define_peephole2
[(set (match_operand 0 "sse_reg_operand")
(match_operand 1 "sse_reg_operand"))
(set (match_dup 0)
(match_operator 3 "commutative_operator"
[(match_dup 0)
(match_operand 2 "memory_operand")]))]
"REGNO (operands[0]) != REGNO (operands[1])"
[(set (match_dup 0) (match_dup 2))
(set (match_dup 0)
(match_op_dup 3 [(match_dup 0) (match_dup 1)]))])
peephole2 doesn't work and results in ICEs if the patterns are correct (as is
the case of *uminv16qi3) if one is unlucky and operands[1] is [xy]mm16 or
higher register and operands[0] is not.
[Bug c/99322] [11 Regression] ICE in change_scope, at final.c:1480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99322 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.0 Keywords||openmp
[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107 --- Comment #34 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:491d5b3cf8216f9285a67aa213b9a66b0035137b commit r11-7443-g491d5b3cf8216f9285a67aa213b9a66b0035137b Author: Iain Sandoe Date: Mon Jan 18 20:09:10 2021 + dwarf2unwind : Force the CFA after remember/restore pairs [44107/48097]. This address one of the more long-standing and serious regressions for Darwin. GCC emits unwind code by default on the assumption that the unwinder will be (of have the same capability) as the one in the current libgcc_s. For Darwin platforms, this is not the case - some of them are based on the libgcc_s from GCC-4.2.1 and some are using the unwinder provided by libunwind (part of the LLVM project). The latter implementation has gradually adopted a section that deals with GNU unwind. The most serious problem for some of the platform versions is in handling DW_CFA_remember/restore_state pairs. The DWARF description talks about these in terms of saving/restoring register rows; this is what GCC originally did (and is what the unwinders do for the Darwin versions based on libgcc_s). However, in r118068, this was changed so that not only the registers but also the current frame address expression were saved. The unwind code assumes that the unwinder will do this; some of Darwin's unwinders do not, leading to lockups etc. To date, the only solution has been to replace the system libgcc_s with a newer one which is not a viable solution for many end-users (since that means overwritting the one provided with the system installation). The fix here provides a target hook that allows the target to specify that the CFA should be reinstated after a DW_CFA_restore. This fixes the issue (and also the closed WONTFIX of 44107). (As a matter of record, it also fixes reported Java issues if backported to GCC-5). gcc/ChangeLog: PR target/44107 PR target/48097 * config/darwin-protos.h (darwin_should_restore_cfa_state): New. * config/darwin.c (darwin_should_restore_cfa_state): New. * config/darwin.h (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New. * doc/tm.texi: Regenerated. * doc/tm.texi.in: Document TARGET_ASM_SHOULD_RESTORE_CFA_STATE. * dwarf2cfi.c (connect_traces): If the target requests, restore the CFA expression after a DW_CFA_restore. * target.def (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New hook.
[Bug target/48097] gcc sometimes generates code that uses the buggy libgcc_s unwinder on darwin (originally exposed by Throw_2 failures in libjava testsuite under Xcode 4.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097 --- Comment #18 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:491d5b3cf8216f9285a67aa213b9a66b0035137b commit r11-7443-g491d5b3cf8216f9285a67aa213b9a66b0035137b Author: Iain Sandoe Date: Mon Jan 18 20:09:10 2021 + dwarf2unwind : Force the CFA after remember/restore pairs [44107/48097]. This address one of the more long-standing and serious regressions for Darwin. GCC emits unwind code by default on the assumption that the unwinder will be (of have the same capability) as the one in the current libgcc_s. For Darwin platforms, this is not the case - some of them are based on the libgcc_s from GCC-4.2.1 and some are using the unwinder provided by libunwind (part of the LLVM project). The latter implementation has gradually adopted a section that deals with GNU unwind. The most serious problem for some of the platform versions is in handling DW_CFA_remember/restore_state pairs. The DWARF description talks about these in terms of saving/restoring register rows; this is what GCC originally did (and is what the unwinders do for the Darwin versions based on libgcc_s). However, in r118068, this was changed so that not only the registers but also the current frame address expression were saved. The unwind code assumes that the unwinder will do this; some of Darwin's unwinders do not, leading to lockups etc. To date, the only solution has been to replace the system libgcc_s with a newer one which is not a viable solution for many end-users (since that means overwritting the one provided with the system installation). The fix here provides a target hook that allows the target to specify that the CFA should be reinstated after a DW_CFA_restore. This fixes the issue (and also the closed WONTFIX of 44107). (As a matter of record, it also fixes reported Java issues if backported to GCC-5). gcc/ChangeLog: PR target/44107 PR target/48097 * config/darwin-protos.h (darwin_should_restore_cfa_state): New. * config/darwin.c (darwin_should_restore_cfa_state): New. * config/darwin.h (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New. * doc/tm.texi: Regenerated. * doc/tm.texi.in: Document TARGET_ASM_SHOULD_RESTORE_CFA_STATE. * dwarf2cfi.c (connect_traces): If the target requests, restore the CFA expression after a DW_CFA_restore. * target.def (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New hook.
[Bug rtl-optimization/99332] New: ICE:inreset_sched_cycles_in_current_ebb, at sel-sched.c:7147 with -fprofile-generate -O3 -fselective-scheduling -fselective-scheduling2 -fsel-sched-pipelining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99332
Bug ID: 99332
Summary: ICE:inreset_sched_cycles_in_current_ebb, at
sel-sched.c:7147 with -fprofile-generate -O3
-fselective-scheduling -fselective-scheduling2
-fsel-sched-pipelining
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
This testing case is reduced from CPU2017 511.povray, it appears on aarch64
with both gcc11 and gcc10:
$ cat t.C
class OStream {
public:
void printf(...);
};
typedef double VECTOR[3];
enum { X, Y, Z };
typedef struct ot_block_struct OT_BLOCK;
typedef int OT_NODE;
struct ot_block_struct {
OT_BLOCK *next;
VECTOR Point, S_Normal;
VECTOR To_Nearest_Surface;
short Bounce_Depth;
};
bool ot_write_block(OT_BLOCK *, void *);
bool ot_traverse(OT_NODE *, bool function(OT_BLOCK *, void *), void *handle) {
bool oksofar;
OT_BLOCK *this_block;
while (this_block) {
function(this_block, handle);
this_block = this_block->next;
}
return oksofar;
}
bool ot_save_tree() {
int *fd, *root;
ot_traverse(root, ot_write_block, fd);
}
bool ot_write_block(OT_BLOCK *bl, void *fd) {
((OStream *)fd)->printf(
bl[Z], bl->S_Normal[X] * int(bl->S_Normal[Z] * .5 * 254. + .49),
bl[Z], int(bl->To_Nearest_Surface[X]),
int((bl->To_Nearest_Surface[Y] + 1.) * .5 * 254. + .49),
int((bl->To_Nearest_Surface[Z] + 1.) * .5 * 254. + .49));
return true;
}
[qzlocal@ca-dev-arm06 bug_2]$ sh t
/data1/qing/Install/latest/bin/g++ -fprofile-generate -O3
-fselective-scheduling -fselective-scheduling2 -fsel-sched-pipelining -c -o t.o
t.C
t.C: In function 'bool ot_save_tree()':
t.C:29:1: warning: no return statement in function returning non-void
[-Wreturn-type]
29 | }
| ^
during RTL pass: sched2
t.C:29:1: internal compiler error: in reset_sched_cycles_in_current_ebb, at
sel-sched.c:7147
0x1063387 reset_sched_cycles_in_current_ebb
../../latest_gcc/gcc/sel-sched.c:7147
0x1063387 sel_region_target_finish
../../latest_gcc/gcc/sel-sched.c:7220
0x1063387 sel_region_finish
../../latest_gcc/gcc/sel-sched.c:7276
0x1063387 sel_sched_region(int)
../../latest_gcc/gcc/sel-sched.c:7645
0x1063593 run_selective_scheduling()
../../latest_gcc/gcc/sel-sched.c:7720
0x103e70b rest_of_handle_sched2
../../latest_gcc/gcc/sched-rgn.c:3738
0x103e70b execute
../../latest_gcc/gcc/sched-rgn.c:3882
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/99276] grammar in diagnostics for overflowing the destination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99276 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-03-01 Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Confirmed.
[Bug c/99276] grammar in diagnostics for overflowing the destination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99276 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|NEW |ASSIGNED
