[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475 Dimitar Dimitrov changed: What|Removed |Added CC||dinuxbg at gmail dot com --- Comment #16 from Dimitar Dimitrov --- Patch is also causing ICE in a few test cases on pru-elf target: during RTL pass: ce3 /home/dinux/projects/pru/testbot-workspace/gcc/gcc/testsuite/gcc.c-torture/compile/pr46107.c: In function 'bar': /home/dinux/projects/pru/testbot-workspace/gcc/gcc/testsuite/gcc.c-torture/compile/pr46107.c:18:1: internal compiler error: in calc_dfs_tree, at dominance.c:458 0x598a77 calc_dfs_tree /home/dinux/projects/pru/testbot-workspace/gcc/gcc/dominance.c:458 0x96f509 calculate_dominance_info(cdi_direction) /home/dinux/projects/pru/testbot-workspace/gcc/gcc/dominance.c:734 0x90d292 flow_loops_find(loops*) /home/dinux/projects/pru/testbot-workspace/gcc/gcc/cfgloop.c:431 0xbb39ce loop_optimizer_init(unsigned int) /home/dinux/projects/pru/testbot-workspace/gcc/gcc/loop-init.c:93 0x1453d90 if_convert /home/dinux/projects/pru/testbot-workspace/gcc/gcc/ifcvt.c:5382 0x14562fd execute /home/dinux/projects/pru/testbot-workspace/gcc/gcc/ifcvt.c:5566
[Bug fortran/97037] New: ICE on user-defined derived-type output of an intermediate ancestor type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97037
Bug ID: 97037
Summary: ICE on user-defined derived-type output of an
intermediate ancestor type
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
The code below effectively has an abstract parent type ("object"), abstract
child type ("oracle"), and a non-abstract grandchild type ("results_t") in
which the parent has a derived-type output binding, the child has a type-bound
operator(-) associated with a deferred binding ("negative"), and the grandchild
implements both deferred bindings. An ICE results when attempting to write the
result of the operator. Presumably the issue is that the grandchild's operator
result must be of the child type. The child type inherits the derived-type
output binding from the parent, but it doesn't itself explicitly state such a
binding. I lean toward thinking the code is valid, but I haven't yet consulted
the standard.
$ cat uddtio-ice.f90
module object_interface
implicit none
type, abstract :: object
contains
procedure(write_formatted_interface), deferred :: write_formatted
generic :: write(formatted) => write_formatted
end type
abstract interface
subroutine write_formatted_interface(this, unit, iotype, vlist, iostat,
iomsg)
import object
implicit none
class(object), intent(in) :: this
integer, intent(in) :: unit, vlist(:)
character(len=*), intent(in) :: iotype
integer, intent(out) :: iostat
character(len=*), intent(inout) :: iomsg
end subroutine
end interface
type, abstract, extends(object) :: oracle
contains
procedure(negative_interface), deferred :: negative
generic :: operator(-) => negative
end type
abstract interface
function negative_interface(this)
import oracle
implicit none
class(oracle), intent(in) :: this
class(oracle), allocatable :: negative_interface
end function
end interface
type, extends(oracle) :: results_t
contains
procedure write_formatted
procedure negative
end type
interface
module subroutine write_formatted(this, unit, iotype, vlist, iostat, iomsg)
implicit none
class(results_t), intent(in) :: this
integer, intent(in) :: unit, vlist(:)
character(len=*), intent(in) :: iotype
integer, intent(out) :: iostat
character(len=*), intent(inout) :: iomsg
end subroutine
module function negative(this)
implicit none
class(results_t), intent(in) :: this
class(oracle), allocatable :: negative
end function
end interface
end module
use object_interface
write(*,*) -results_t()
end program
$ gfortran -c uddtio-ice.f90
uddtio-ice.f90:61:0:
61 | write(*,*) -results_t()
|
internal compiler error: Segmentation fault: 11
$ gfortran --version
GNU Fortran (GCC) 11.0.0 20200804 (experimental)
[Bug fortran/97036] New: [F2018] ELEMENTAL RECURSIVE subprogram prefix combination rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97036 Bug ID: 97036 Summary: [F2018] ELEMENTAL RECURSIVE subprogram prefix combination rejected Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ian_harvey at bigpond dot com Target Milestone: --- F2018 removed the previous syntax restriction (F2008 C1245) on a subprogram definition with both ELEMENTAL and RECURSIVE. MODULE m IMPLICIT NONE CONTAINS ELEMENTAL RECURSIVE SUBROUTINE foo END SUBROUTINE foo END MODULE m $ gfortran --version GNU Fortran (GCC) 11.0.0 20200905 (experimental) $ gfortran -c 2020-09-13\ elemental-recursive.f90 -std=f2018 2020-09-13 elemental-recursive.f90:4:22: 4 | ELEMENTAL RECURSIVE SUBROUTINE foo | 1 Error: ELEMENTAL attribute conflicts with RECURSIVE attribute at (1) 2020-09-13 elemental-recursive.f90:5:5: 5 | END SUBROUTINE foo | 1 Error: Expecting END MODULE statement at (1)
[Bug analyzer/97029] [11 Regression] ICE in wide_int_to_tree_1, at tree.c:1612
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97029 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-09-12 --- Comment #1 from David Malcolm --- Thanks for filing this; confirmed.
[Bug d/97002] d: Promote types in d_type_promotes_to when linkage is not D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97002 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Iain Buclaw --- Done.
[Bug d/97002] d: Promote types in d_type_promotes_to when linkage is not D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97002 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:707e9159ed25d19c174e4da18b194e530878d450 commit r11-3178-g707e9159ed25d19c174e4da18b194e530878d450 Author: Iain Buclaw Date: Sat Sep 12 16:48:58 2020 +0200 d: Return promoted types in d_type_promotes_to when linkage is not D This enables warnings to be shown when a bad type is passed to va_arg inside an extern(C) or extern(C++) function. gcc/d/ChangeLog: PR d/97002 * d-codegen.cc (d_build_call): Set input_location on CALL_EXPR. * d-lang.cc: Include function.h. (d_type_promotes_to): Do default conversions for C and C++ functions. * intrinsics.cc (expand_intrinsic_vaarg): Use build1_loc to build VA_ARG_EXPR. gcc/testsuite/ChangeLog: PR d/97002 * gdc.dg/pr97002.d: New test.
[Bug fortran/97021] [OpenMP] copy out of allocatable scalars does not work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97021 Tobias Burnus changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Tobias Burnus --- This testcase is INVALID – I mixed up target vs. target data. And it works as written. There is some issues – but either only as covered by PR96668, if not, I will create a new testcase.
[Bug c++/97033] g++ hangs on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97033
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Andrew Pinski ---
>inline int F1 (){}
That is undefined code.
[Bug target/97032] [8/9/10/11 Regression] ICE output_operand: invalid use of register 'frame' since r8-1911
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97032 H.J. Lu changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-Septemb ||er/553792.html Keywords||patch --- Comment #3 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553792.html
[Bug fortran/97031] the content of a comment line breaks compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97031 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to jean-pierre.flament from comment #0) > Created attachment 49211 [details] > contains fortran pgm, system and compile info and output > > I would like to signal to you a compilation problem that I have solved. > > the following comment line > > ! some text... DIR/*/) > > seems to put the compiler into trouble. (see attachment) > > changing the line to > > ! some text... DIR/d2) > > solves the problem > > The attached file contains > > 1) the fortran (self contained) > The faulty line is marked ==> FAULTY LINE, > it is followed by the line ===> LINE OK > 2) the system name (centos 6.10) and kernel > 3) the command to compile > 4) the output > > all these parts are sepaated by == lines > > I have also tested gfortran 6.3 (from devtoolset of centos) on the same > computer (As far as I remember the errors are different but the compilation > fails), and gfortran 4.9.3 also on a centos machine: same as 4.4.7). > Sorry I have not access to newer versions of gfortran This should be closed as INVALID. You are preprocessing your code with cpp in traditional mode, and therefore the '/*' in your code is the start of a C comment. This is an user error. Not a problem with gfortran.
[Bug c++/96780] debuginfo for std::move and std::forward isn't useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96780 --- Comment #2 from Patrick Palka --- I wonder if it would be worthwhile to fold calls to std::move and std::forward altogether in the frontend.
[Bug c++/96780] debuginfo for std::move and std::forward isn't useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96780 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- I wonder if
[Bug target/97035] New: csky-linux-gnuabiv2 won't build with binutils master branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97035 Bug ID: 97035 Summary: csky-linux-gnuabiv2 won't build with binutils master branch Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: rjiejie at me dot com Target Milestone: --- Target: csky-linux-gnuabiv2 GCC 10 branch won't won't build with binutils master branch for csky-linux-gnuabiv2 target: /tmp/cc2eE0GB.s: Assembler messages: /tmp/cc2eE0GB.s:24: Error: The instruction is not recognized. /tmp/cc2eE0GB.s:28: Error: The instruction is not recognized. /tmp/cc2eE0GB.s:42: Error: The instruction is not recognized. /tmp/cc2eE0GB.s:52: Error: The instruction is not recognized. /tmp/cc2eE0GB.s:63: Error: The instruction is not recognized. /tmp/cc2eE0GB.s:67: Error: The instruction is not recognized. /tmp/cc2eE0GB.s:73: Error: The instruction is not recognized. make[4]: *** [Makefile:501: _powisf2.o] Error 1 make[4]: Leaving directory '/export/build/gnu/tools-build/glibc-many/build/compilers/csky-linux-gnuabiv2/gcc-first/csky-glibc-linux-gnuabiv2/libgcc' make[3]: *** [Makefile:11990: all-target-libgcc] Error 2
[Bug c++/97034] New: ICE on C++20 code: gcc_assert failure in return type deduction (gcc/cp/pt.c:26984 in type_dependent_expression_p(tree_node*))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97034
Bug ID: 97034
Summary: ICE on C++20 code: gcc_assert failure in return type
deduction (gcc/cp/pt.c:26984 in
type_dependent_expression_p(tree_node*))
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dimitri.gorokhovik at free dot fr
Target Milestone: ---
The code:
#include
template
struct s
{
template
struct ss
{
R _1;
unsigned _2;
};
constexpr auto f ()
{
return ss { std::pair { 'a', 1 }, 1 };
};
};
when compiled as:
g++ -std=c++20 -o bug-3.o -c bug-3.cpp
produces:
bug-3.cpp: In member function ‘constexpr auto s::f()’:
bug-3.cpp:15:65: internal compiler error: in type_dependent_expression_p, at
cp/pt.c:26984
15 | return ss { std::pair { 'a', 1 }, 1 };
| ^
0x680638 type_dependent_expression_p(tree_node*)
../../src/gcc/cp/pt.c:26984
0xa22cf9 maybe_instantiate_noexcept(tree_node*, int)
../../src/gcc/cp/pt.c:25290
0x9598c2 mark_used(tree_node*, int)
../../src/gcc/cp/decl2.c:5552
0xaa8d36 cp_build_addr_expr_1
../../src/gcc/cp/typeck.c:6384
0x8ab692 build_over_call
../../src/gcc/cp/call.c:8522
0x8ae85a build_new_function_call(tree_node*, vec**, int)
../../src/gcc/cp/call.c:4641
0xa1a4ed do_class_deduction
../../src/gcc/cp/pt.c:29027
0xa1a4ed do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../src/gcc/cp/pt.c:29085
0xa6def9 finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
../../src/gcc/cp/semantics.c:2934
0x9ca12a cp_parser_functional_cast
../../src/gcc/cp/parser.c:29690
0x9e26d7 cp_parser_postfix_expression
../../src/gcc/cp/parser.c:7251
0x9c443a cp_parser_binary_expression
../../src/gcc/cp/parser.c:9648
0x9c61ce cp_parser_assignment_expression
../../src/gcc/cp/parser.c:9953
0x9c64e2 cp_parser_expression
../../src/gcc/cp/parser.c:10121
0x9d5527 cp_parser_jump_statement
../../src/gcc/cp/parser.c:13192
0x9d5527 cp_parser_statement
../../src/gcc/cp/parser.c:11455
0x9d6a8d cp_parser_statement_seq_opt
../../src/gcc/cp/parser.c:11928
0x9d6b68 cp_parser_compound_statement
../../src/gcc/cp/parser.c:11878
0x9eecb5 cp_parser_function_body
../../src/gcc/cp/parser.c:23177
0x9eecb5 cp_parser_ctor_initializer_opt_and_function_body
../../src/gcc/cp/parser.c:23228
Please submit a full bug report,
GCC version:
g++ (GCC) 11.0.0 20200910 (experimental)
[Bug c++/97033] New: g++ hangs on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97033
Bug ID: 97033
Summary: g++ hangs on valid code
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tangyixuan at mail dot dlut.edu.cn
Target Milestone: ---
Hi, g++ hangs when executing the following code with -Os, while clang++ is ok.
$ cat s.cpp
namespace A {
inline int F1 (){}
}
int F2 ( int (* p )()){
return p ();
}
int main (){
return F2 ( A :: F1 );
}
$ g++ -Os s.cpp && ./a.out
$ g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-20200906/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-20200906/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-11-20200906/configure --prefix=/usr/local/gcc-20200906
--enable-checking=release --enable-languages=c,c++ --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200906 (experimental) (GCC)
[Bug target/97032] [8/9/10/11 Regression] ICE output_operand: invalid use of register 'frame' since r8-1911
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97032 --- Comment #2 from H.J. Lu --- Created attachment 49212 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49212=edit A patch I am testing this.
[Bug target/97032] [8/9/10/11 Regression] ICE output_operand: invalid use of register 'frame' since r8-1911
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97032 --- Comment #1 from Jakub Jelinek --- Note, eliminating the bogus deprecated "esp" clobber makes it compile correctly.
[Bug target/97032] [8/9/10/11 Regression] ICE output_operand: invalid use of register 'frame' since r8-1911
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97032 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |8.5 Priority|P3 |P2 Keywords||ice-on-valid-code CC||hjl.tools at gmail dot com, ||uros at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Last reconfirmed||2020-09-12 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug target/97032] New: [8/9/10/11 Regression] ICE output_operand: invalid use of register 'frame' since r8-1911
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97032
Bug ID: 97032
Summary: [8/9/10/11 Regression] ICE output_operand: invalid use
of register 'frame' since r8-1911
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Since r8-1911-g35c95658180e67503f9de96567ab4d6e71b10a6e the following testcase
distilled from firefox:
#include
extern int *__errno_location (void);
long
sys_socketcall (int op, ...)
{
long int res;
va_list ap;
va_start (ap, op);
asm volatile ("push %%ebx; movl %2, %%ebx; int $0x80; pop %%ebx"
: "=a" (res) : "0" (102), "ri" (16), "c" (ap) : "memory",
"esp");
if (__builtin_expect (res > 4294963200UL, 0))
*__errno_location () = -res;
va_end (ap);
return res;
}
ICEs on x86_64-linux or i686-linux with
-O2 -m32 -mincoming-stack-boundary=2 -fstack-protector-all
test.c: In function ‘sys_socketcall’:
test.c:11:3: warning: listing the stack pointer register ‘esp’ in a clobber
list is deprecated [-Wdeprecated]
11 | asm volatile ("push %%ebx; movl %2, %%ebx; int $0x80; pop %%ebx"
| ^~~
test.c:11:3: note: the value of the stack pointer after an ‘asm’ statement must
be the same as it was before the statement
during RTL pass: final
test.c:17:1: internal compiler error: output_operand: invalid use of register
'frame'
17 | }
| ^
0xd3b872 output_operand_lossage(char const*, ...)
../../gcc/final.c:3609
0x17e0869 print_reg(rtx_def*, int, _IO_FILE*)
../../gcc/config/i386/i386.c:12274
0x17e2fa1 ix86_print_operand_address_as
../../gcc/config/i386/i386.c:13311
0x17e22d2 ix86_print_operand(_IO_FILE*, rtx_def*, int)
../../gcc/config/i386/i386.c:13060
0xd3c92a output_operand(rtx_def*, int)
../../gcc/final.c:4051
0xd3c550 output_asm_insn(char const*, rtx_def**)
../../gcc/final.c:3963
0x1f325e1 output_1129
../../gcc/config/i386/i386.md:20656
0xd38b91 get_insn_template(int, rtx_insn*)
../../gcc/final.c:2070
0xd3a8b6 final_scan_insn_1
../../gcc/final.c:3039
0xd3ad3e final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc/final.c:3152
0xd389c0 final_1
../../gcc/final.c:2020
0xd3dd0d rest_of_handle_final
../../gcc/final.c:4658
0xd3e06c execute
../../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 target/97030] [nvptx] Need strategy for nvidia JIT bug workarounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97030 --- Comment #1 from Tom de Vries --- (In reply to Tom de Vries from comment #0) > ATM, we have the following in the nvptx.c source code: > ... > #define WORKAROUND_PTXJIT_BUG 1 > #define WORKAROUND_PTXJIT_BUG_2 1 > #define WORKAROUND_PTXJIT_BUG_3 1 > ... > > Having the workaround hardcoded in the sources has the benefit that when > people report a problem with a certain gcc version, you can reasonably > assume that you know which workarounds were applied. > > OTOH, it might unnecessarily slow down real apps on JIT versions that are > fixed. > > So, it could be good to have these runtime switchable. > OTOH, some of these may not have been acknowledged as JIT bug by nvidia, and actually be PTX ISA documentation bugs. In which case it's probably a bad idea to expose the possibility to disable the workaround.
[Bug fortran/97031] New: the content of a comment line breaks compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97031 Bug ID: 97031 Summary: the content of a comment line breaks compilation Product: gcc Version: 4.4.7 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jean-pierre.flam...@univ-lille.fr Target Milestone: --- Created attachment 49211 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49211=edit contains fortran pgm, system and compile info and output I would like to signal to you a compilation problem that I have solved. the following comment line ! some text... DIR/*/) seems to put the compiler into trouble. (see attachment) changing the line to ! some text... DIR/d2) solves the problem The attached file contains 1) the fortran (self contained) The faulty line is marked ==> FAULTY LINE, it is followed by the line ===> LINE OK 2) the system name (centos 6.10) and kernel 3) the command to compile 4) the output all these parts are sepaated by == lines I have also tested gfortran 6.3 (from devtoolset of centos) on the same computer (As far as I remember the errors are different but the compilation fails), and gfortran 4.9.3 also on a centos machine: same as 4.4.7). Sorry I have not access to newer versions of gfortran
[Bug target/97030] New: [nvptx] Need strategy for nvidia JIT bug workarounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97030 Bug ID: 97030 Summary: [nvptx] Need strategy for nvidia JIT bug workarounds Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- ATM, we have the following in the nvptx.c source code: ... #define WORKAROUND_PTXJIT_BUG 1 #define WORKAROUND_PTXJIT_BUG_2 1 #define WORKAROUND_PTXJIT_BUG_3 1 ... Having the workaround hardcoded in the sources has the benefit that when people report a problem with a certain gcc version, you can reasonably assume that you know which workarounds were applied. OTOH, it might unnecessarily slow down real apps on JIT versions that are fixed. So, it could be good to have these runtime switchable. A possible scheme could be: - -mworkaround- - -mworkaround- - -mworkaround- Then, the question is what should the defaults settings be. Perhaps a good strategy is that the workarounds should be on by default, unless there's a fix in the nvidia driver long lived branch. It would also be good to have canary tests in the testsuite, that verify whether the used driver is fixed or not. Then, a patch changing the default from on to off should report the driver version and card used to make the canary fail, and the driver version used to make it pass on that same card. Ideally we'd automate the testsuite to use the workaround if the canary test fails.
[Bug target/96932] [nvptx] atomic_exchange missing barrier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96932 Tom de Vries changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #2 from Tom de Vries --- It could be interesting to use a ptx simulator, perhaps that one could trigger this.
[Bug analyzer/97029] New: [11 Regression] ICE in wide_int_to_tree_1, at tree.c:1612
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97029
Bug ID: 97029
Summary: [11 Regression] ICE in wide_int_to_tree_1, at
tree.c:1612
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-11.0.0-alpha20200906 snapshot (g:23f8b90c401842afcbaa50a7fd3c2f37818f4396)
ICEs when compiling the following testcase w/ -fanalyzer:
struct vj {};
void
setjmp (struct vj pl)
{
setjmp (pl);
}
% gcc-11.0.0 -fanalyzer -c mytxbhhn.c
during IPA pass: analyzer
mytxbhhn.c: In function 'setjmp':
mytxbhhn.c:6:3: internal compiler error: in wide_int_to_tree_1, at tree.c:1612
6 | setjmp (pl);
| ^~~
0x7093a4 wide_int_to_tree_1
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/tree.c:1612
0x104edef wide_int_to_tree(tree_node*, poly_int<1u,
generic_wide_int > > const&)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/tree.c:1724
0x104edef build_int_cst(tree_node*, poly_int<1u, long>)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/tree.c:1364
0x111662d ana::region_model::deref_rvalue(ana::svalue const*, tree_node*,
ana::region_model_context*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/region-model.cc:1406
0x1121d6f ana::region_model::on_setjmp(gcall const*, ana::exploded_node const*,
ana::region_model_context*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/region-model.cc:895
0x10fb261 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*) const
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/engine.cc:1076
0x10fc10d ana::exploded_graph::process_node(ana::exploded_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/engine.cc:2526
0x10fcbfa ana::exploded_graph::process_worklist()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/engine.cc:2341
0x10fed4f ana::impl_run_checkers(ana::logger*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/engine.cc:4107
0x10ff97c ana::run_checkers()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/engine.cc:4175
0x10f42f8 execute
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/analyzer-pass.cc:84
