[Bug libgomp/87995] [9 regression] libgomp.c/../libgomp.c-c++-common/cancel-taskgroup-3.c fails consistently after r265930
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87995 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Sat Dec 8 08:58:24 2018 New Revision: 266904 URL: https://gcc.gnu.org/viewcvs?rev=266904&root=gcc&view=rev Log: PR libgomp/87995 * testsuite/libgomp.c-c++-common/cancel-taskgroup-3.c: Require tls_runtime effective target. (t): New threadprivate variable. (main): Set t in threads which execute iterations of the worksharing loop. Propagate that to the task after the loop and don't abort if the current taskgroup hasn't been cancelled. Modified: trunk/libgomp/ChangeLog trunk/libgomp/testsuite/libgomp.c-c++-common/cancel-taskgroup-3.c
[Bug libgomp/87995] [9 regression] libgomp.c/../libgomp.c-c++-common/cancel-taskgroup-3.c fails consistently after r265930
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87995 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug rtl-optimization/88390] [9 regression] g++.dg/tree-prof/pr57451.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88390 Eric Botcazou changed: What|Removed |Added Component|c++ |rtl-optimization --- Comment #4 from Eric Botcazou --- Recategorizing.
[Bug c++/88410] [8/9 Regression] internal compiler error: output_operand: invalid expression as operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88410
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-12-08
CC||jakub at gcc dot gnu.org
Target Milestone|--- |8.3
Summary|internal compiler error:|[8/9 Regression] internal
|output_operand: invalid |compiler error:
|expression as operand |output_operand: invalid
||expression as operand
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Reduced testcase:
typedef __UINTPTR_TYPE__ uintptr_t;
const uintptr_t a = 2;
struct C { int b; };
uintptr_t c { uintptr_t (&reinterpret_cast(a)->b) };
Started with my r259458.
[Bug c++/88410] [8/9 Regression] internal compiler error: output_operand: invalid expression as operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88410 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 45190 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45190&action=edit gcc9-pr88410.patch Untested fix. Why doesn't libdart use offsetof though?
[Bug rtl-optimization/88390] [9 regression] g++.dg/tree-prof/pr57451.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88390 --- Comment #5 from Eric Botcazou --- Author: ebotcazou Date: Sat Dec 8 11:07:53 2018 New Revision: 266906 URL: https://gcc.gnu.org/viewcvs?rev=266906&root=gcc&view=rev Log: PR rtl-optimization/88390 * dwarf2cfi.c (struct dw_cfi_row): Add window_save field. (cfi_row_equal_p): Compare it. (dwarf2out_frame_debug_cfa_window_save): Add FAKE parameter. If FAKE is false, set window_save of the current row. (dwarf2out_frame_debug) : Call above function with FAKE parameter set to true. : Likewise but with FAKE parameter set to false. (change_cfi_row): Emit a DW_CFA_GNU_window_save if necessary. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2cfi.c
[Bug rtl-optimization/88390] [9 regression] g++.dg/tree-prof/pr57451.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88390 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Eric Botcazou --- Thanks for reporting the problem.
[Bug c++/87861] [9 regression] ICE in output_constructor_regular_field, at varasm.c:5165
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87861 --- Comment #10 from Andreas Schwab --- http://gcc.gnu.org/ml/gcc-testresults/2018-12/msg00950.html
[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304 --- Comment #17 from Jakub Jelinek --- Author: jakub Date: Sat Dec 8 13:37:49 2018 New Revision: 266907 URL: https://gcc.gnu.org/viewcvs?rev=266907&root=gcc&view=rev Log: PR fortran/88304 * tree-nested.c (convert_local_reference_stmt): Handle clobbers where lhs is not a decl normally, don't call use_pointer_in_frame on that lhs. * gfortran.fortran-torture/compile/pr88304-2.f90: New test. Added: trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr88304-2.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-nested.c
[Bug c++/86228] ordered comparison between pointer and zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86228
eracpp changed:
What|Removed |Added
CC||eracpp at eml dot cc
--- Comment #2 from eracpp ---
This bug was observed in the following example:
https://gcc.godbolt.org/z/p1VreP
#include
#include
int main()
{
std::array arr;
// Mistake: meant to use std::generate.
std::generate_n(arr.begin(), arr.end(), []{ return 0; });
}
This code successfully compiles (unexpectedly) with GCC due to `size > 0` being
treated as well-formed in the case where the type of second parameter `size` is
deduced to be a pointer type such as `int*`. The contrary behavior is observed
with Clang, as seen in the provided Compiler Explorer link above.
The mistake manifests as an unexpected segmentation fault at runtime, rather
thana compile-time error:
http://coliru.stacked-crooked.com/a/2dc4ae877233c9b2
[Bug libfortran/88411] [9 Regression] Random crashes for ASYNCHRONOUS writes (bad locking?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88411 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #3 from Thomas Koenig --- Here is some debugging info. Does not happen every time: $ gfortran a.f90 -pthread $ valgrind --tool=drd ./a.out ==4274== drd, a thread error detector ==4274== Copyright (C) 2006-2017, and GNU GPL'd, by Bart Van Assche. ==4274== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==4274== Command: ./a.out ==4274== ==4274== Thread 3: ==4274== Conflicting load by thread 3 at 0x05fe2268 size 4 ==4274==at 0x5075A80: buf_flush (unix.c:533) ==4274==by 0x5072D62: sflush (unix.h:89) ==4274==by 0x5072D62: _gfortrani_data_transfer_init_worker (transfer.c:3176) ==4274==by 0x507D213: async_io (async.c:135) ==4274==by 0x4C30CC3: vgDrd_thread_wrapper (drd_pthread_intercepts.c:444) ==4274==by 0x5A22723: start_thread (in /lib64/libpthread-2.22.so) ==4274==by 0x5D23E8C: clone (in /lib64/libc-2.22.so) ==4274== Address 0x5fe2268 is at offset 56 from 0x5fe2230. Allocation context: ==4274==at 0x4C2F830: calloc (vg_replace_malloc.c:711) ==4274==by 0x4E69BB2: _gfortrani_xcalloc (memory.c:83) ==4274==by 0x5075790: fd_to_stream (unix.c:1096) ==4274==by 0x5076501: _gfortrani_open_external (unix.c:1572) ==4274==by 0x506C0AA: _gfortrani_new_unit (open.c:535) ==4274==by 0x506C9F5: already_open (open.c:711) ==4274==by 0x506C9F5: _gfortran_st_open (open.c:888) ==4274==by 0x400F82: MAIN__ (in /home/ig25/Krempel/A2/a.out) ==4274==by 0x401302: main (in /home/ig25/Krempel/A2/a.out) ==4274== Other segment start (thread 1) ==4274==at 0x4C34AB8: pthread_mutex_unlock_intercept (drd_pthread_intercepts.c:978) ==4274==by 0x4C34AB8: pthread_mutex_unlock (drd_pthread_intercepts.c:991) ==4274==by 0x507351E: data_transfer_init (transfer.c:3147) ==4274==by 0x400FC4: MAIN__ (in /home/ig25/Krempel/A2/a.out) ==4274==by 0x401302: main (in /home/ig25/Krempel/A2/a.out) ==4274== Other segment end (thread 1) ==4274==at 0x5A29DCD: ??? (in /lib64/libpthread-2.22.so) ==4274==by 0x507598A: raw_write (unix.c:366) ==4274==by 0x5075AB9: buf_flush (unix.c:540) ==4274==by 0x5075AB9: buf_flush (unix.c:526) ==4274==by 0x5075BCD: buf_write (unix.c:653) ==4274==by 0x5075BCD: buf_write (unix.c:626) ==4274==by 0x506F186: swrite (unix.h:59) ==4274==by 0x506F186: write_buf (transfer.c:865) ==4274==by 0x506F280: unformatted_write (transfer.c:1150) ==4274==by 0x506FC09: _gfortrani_transfer_array_inner (transfer.c:2486) ==4274==by 0x506FCCA: _gfortran_transfer_array (transfer.c:2535) ==4274==by 0x401079: MAIN__ (in /home/ig25/Krempel/A2/a.out) ==4274==by 0x401302: main (in /home/ig25/Krempel/A2/a.out) ==4274== =
[Bug libfortran/88411] [9 Regression] Random crashes for ASYNCHRONOUS writes (bad locking?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88411 --- Comment #4 from Thomas Koenig --- The problem appears to be that the record length is set to zero a file with the same unit number is opened again. Hmm... some more digging is needed.
[Bug libfortran/88411] [9 Regression] Random crashes for ASYNCHRONOUS writes (bad locking?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88411 --- Comment #5 from Thomas Koenig --- Hm, maybe something else. It seems we're actually writing direct access files in the main thread, even when using asynchronous I/O. Hmm...
[Bug fortran/87937] [8 Regression] LHS reallocation broken inside "select type" and "associate"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87937 Martin Diehl changed: What|Removed |Added CC||m.diehl at mpie dot de --- Comment #15 from Martin Diehl --- *** Bug 88412 has been marked as a duplicate of this bug. ***
[Bug fortran/88412] Associate segmentation fault assigning to derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88412 Martin Diehl changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Martin Diehl --- Looks like a duplicate to me too. *** This bug has been marked as a duplicate of bug 87937 ***
[Bug c++/87951] GCC warns about reaching end of non-void function when all switch is completely handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87951
Askar Safin changed:
What|Removed |Added
CC||safinaskar at mail dot ru
--- Comment #7 from Askar Safin ---
"g++ -fstrict-enums" doesn't disable warning if I use "enum class" instead of
plain enum.
This is test code:
///
enum class Enum {
A,
B,
};
int CoverMyBases(Enum x) {
switch (x) {
case Enum::A:
return 1;
case Enum::B:
return 0;
}
}
int main(int argc, const char **argv) {
CoverMyBases(Enum::A);
CoverMyBases(Enum::B);
return 0;
}
///
This is command line:
g++ -fstrict-enums a.cpp
This is gcc version: gcc version 8.2.0 (Debian 8.2.0-10)
And I get this:
a.cpp: In function ‘int CoverMyBases(Enum)’:
a.cpp:13:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
[Bug fortran/88357] ICE in parse_associate, at fortran/parse.c:4568
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88357 --- Comment #8 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Dec 8 18:09:05 2018 New Revision: 266908 URL: https://gcc.gnu.org/viewcvs?rev=266908&root=gcc&view=rev Log: 2018-12-08 Steven G. Kargl PR fortran/88357 * class.c (insert_component_ref): Check for NULL pointer and previous error message issued. * parse.c (parse_associate): Check for NULL pointer. * resolve.c (resolve_assoc_var): Check for NULL pointer. 2018-12-08 Steven G. Kargl * gfortran.dg/pr88357_1.f90: New test. * gfortran.dg/pr88357_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr88357_1.f90 trunk/gcc/testsuite/gfortran.dg/pr88357_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/88357] ICE in parse_associate, at fortran/parse.c:4568
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88357 kargl at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |9.0 --- Comment #9 from kargl at gcc dot gnu.org --- Fixes for z1.f90 and z3.f90 have been committed.
[Bug fortran/88357] ICE in parse_associate, at fortran/parse.c:4568
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88357 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from kargl at gcc dot gnu.org --- Closing.
[Bug c++/87951] GCC warns about reaching end of non-void function when all switch is completely handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87951 --- Comment #8 from Andrew Pinski --- (In reply to Askar Safin from comment #7) > "g++ -fstrict-enums" doesn't disable warning if I use "enum class" instead > of plain enum. Yes because they have different semantics ...
[Bug fortran/88304] [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #18 from Jakub Jelinek --- Fixed.
[Bug fortran/88364] [9 Regression] Wrong-code due to CLOBBER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88364 Bug 88364 depends on bug 88304, which changed state. Bug 88304 Summary: [9 Regression] ICE in use_pointer_in_frame, at tree-nested.c:267 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/88417] New: partial specialization of static template variable inside class template gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88417
Bug ID: 88417
Summary: partial specialization of static template variable
inside class template gives wrong result
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lts-rudolph at gmx dot de
Target Milestone: ---
If I do a partial template variable specialization inside a template class I
got the wrong results and/or if no unspecialised version is provided I got a
linker error.
template < typename T>
class X
{
public:
T i;
X(T _i): i{_i}{}
operator T(){ return i; }
};
template < typename T2 >
class Y
{
public:
template
static X x_in_y;
};
template< typename T2>
template< typename T>
X Y::x_in_y{200};
template<>
template<>
X Y::x_in_y{100};
template<>
template<>
X Y::x_in_y{101};
// this partial specialization is never seen, but compiles without error
template< >
template< typename T >
X Y::x_in_y{77};
int main()
{
std::cout << Y::x_in_y << std::endl;
std::cout << Y::x_in_y << std::endl;
std::cout << Y::x_in_y << std::endl;
std::cout << Y::x_in_y << std::endl;
}
expected result:
101
100
200
77
[Bug c++/87951] GCC warns about reaching end of non-void function when all switch is completely handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87951 --- Comment #9 from Askar Safin --- (In reply to Andrew Pinski from comment #8) > Yes because they have different semantics ... So, you mean that "enum class" is less strict than normal enums? This is very strange. Today I normally use "enum class", because they are advertised as "better". And now I see that, well, they are *less* strict, than normal enums, and thus (to get better compiler warnings) I need to switch to "old bad" enums, right?! This is very-very strange. So if I want good compiler messages I need to convert my code from "good modern" enum class to "bad old" enums, right?! Is there some hack to get better compiler warnings for "enum class"? Something like -fstrict-enums, but for "enum class"?
[Bug fortran/88025] [7/8/9 Regression] ICE in gfc_apply_init, at fortran/expr.c:4468
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88025 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Sun Dec 9 01:02:41 2018 New Revision: 266913 URL: https://gcc.gnu.org/viewcvs?rev=266913&root=gcc&view=rev Log: 2018-12-08 Steven G. Kargl PR fortran/88025 * expr.c (gfc_apply_init): Remove asserts that cannot trigger. Check for a NULL pointer. 2018-12-08 Steven G. Kargl PR fortran/88025 * gfortran.dg/pr88025.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr88025.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/88025] [7/8/9 Regression] ICE in gfc_apply_init, at fortran/expr.c:4468
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88025 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Sun Dec 9 03:10:41 2018 New Revision: 266914 URL: https://gcc.gnu.org/viewcvs?rev=266914&root=gcc&view=rev Log: 2018-12-08 Steven G. Kargl PR fortran/88025 * expr.c (gfc_apply_init): Remove asserts that cannot trigger. Check for a NULL pointer. 2018-12-08 Steven G. Kargl PR fortran/88025 * gfortran.dg/pr88025.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88025.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/expr.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/88025] [7/8/9 Regression] ICE in gfc_apply_init, at fortran/expr.c:4468
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88025 kargl at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|7.5 |8.4 --- Comment #5 from kargl at gcc dot gnu.org --- Closing. Fixed on trunk and branch-8. Patch does not apply to branch-7.
[Bug fortran/87945] [9 Regression] ICE in var_element, at fortran/decl.c:281
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87945 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Sun Dec 9 04:02:44 2018 New Revision: 266915 URL: https://gcc.gnu.org/viewcvs?rev=266915&root=gcc&view=rev Log: 20180-12-08 Steven G. Kargl PR fortran/87945 * decl.c (var_element): Inquiry parameters cannit be data objects. 20180-12-08 Steven G. Kargl PR fortran/87945 * gfortran.dg/pr87945_1.f90: New test. * gfortran.dg/pr87945_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr87945_1.f90 trunk/gcc/testsuite/gfortran.dg/pr87945_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/87945] [9 Regression] ICE in var_element, at fortran/decl.c:281
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87945 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #5 from kargl at gcc dot gnu.org --- Fixed on trunk. Closing
[Bug target/88418] New: [7/8/9 Regression] ICE in extract_insn, at recog.c:2305 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88418
Bug ID: 88418
Summary: [7/8/9 Regression] ICE in extract_insn, at
recog.c:2305 (error: unrecognizable insn)
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-unknown-linux-gnu
gcc-9.0.0-alpha20181202 snapshot (r266729) ICE when compiling the following
snippet at any optimization level except -Og and w/ -msse4.1 -fpack-struct:
typedef long int __attribute__ ((__vector_size__ (2 * sizeof (long int
v2si;
union df {
v2si se[2];
};
void
qg (union df *jz, union df *pl)
{
jz->se[0] = jz->se[0] == pl->se[0];
}
% x86_64-unknown-linux-gnu-gcc-9.0.0-alpha20181202 -msse4.1 -O1 -fpack-struct
-c eysik9hz.c
eysik9hz.c: In function 'qg':
eysik9hz.c:11:1: error: unrecognizable insn:
11 | }
| ^
(insn 8 7 9 2 (set (reg:V2DI 89)
(eq:V2DI (reg:V2DI 87)
(mem/j:V2DI (reg/v/f:DI 86 [ pl ]) [1 *pl_6(D)+0 S16 A8])))
"eysik9hz.c":10:25 -1
(nil))
during RTL pass: vregs
eysik9hz.c:11:1: internal compiler error: in extract_insn, at recog.c:2305
0x668df7 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/rtl-error.c:108
0x668e13 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/rtl-error.c:116
0x666f6d extract_insn(rtx_insn*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/recog.c:2305
0xa3d813 instantiate_virtual_regs_in_insn
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/function.c:1650
0xa3d813 instantiate_virtual_regs
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/function.c:2020
0xa3d813 execute
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/function.c:2069
[Bug target/46250] ICE: in extract_insn, at recog.c:2110 (unrecognizable insn) with -fPIC -mcmodel=large and __thread variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46250 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #6 from Arseny Solokha --- It is likely a duplicate of PR58067 which was fixed for gcc 4.9.
[Bug target/58067] ICE in GFortran recog.c:2158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #12 from Arseny Solokha --- At least the C testcase in comment 8 was fixed for 4.9 and subsequent releases.
[Bug target/49670] internal compiler error: in extract_insn, at recog.c:2104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #11 from Arseny Solokha --- I believe this is irrelevant by now.
[Bug target/82887] ICE: in extract_insn, at recog.c:2287 (unrecognizable insn) with _mm512_extracti64x4_epi64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82887 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #3 from Arseny Solokha --- Since gcc 6 EOL the issue is fixed on all active branches and thus this PR can be closed.
[Bug target/49670] internal compiler error: in extract_insn, at recog.c:2104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670 --- Comment #12 from Jeffrey Walton --- (In reply to Arseny Solokha from comment #11) > I believe this is irrelevant by now. Yeah, no doubt. May as well close it.
[Bug target/49670] internal compiler error: in extract_insn, at recog.c:2104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670 Jeffrey Walton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #13 from Jeffrey Walton --- Obsolete.
[Bug c++/88419] New: [9 Regression] [ICE] "Same canonical type node for different types" for CTAD in noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88419
Bug ID: 88419
Summary: [9 Regression] [ICE] "Same canonical type node for
different types" for CTAD in noexcept
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Created attachment 45191
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45191&action=edit
Repro
This TU:
template struct ref_view {
template ref_view(T&&);
};
template ref_view(R&) -> ref_view;
struct ref_fn {
template auto operator()(R r) const
noexcept(noexcept(ref_view{r}));
};
template struct indirect_view {
indirect_view(R);
};
struct indirect_fn {
template auto operator()(R r) const
noexcept(noexcept(indirect_view{r}));
};
ICEs when compiled with "g++ -std=c++17 -c":
/home/casey/casey/Desktop/repro.cpp:18:40: internal compiler error: same
canonical type node for different types ‘indirect_view’ and ‘ref_view’
18 | noexcept(noexcept(indirect_view{r}));
|^
0x9fd2af comptypes(tree_node*, tree_node*, int)
/home/casey/repos/gcc/gcc/cp/typeck.c:1486
0x9f3076 cp_tree_equal(tree_node*, tree_node*)
/home/casey/repos/gcc/gcc/cp/tree.c:3558
0x9f3d6f cp_tree_equal(tree_node*, tree_node*)
/home/casey/repos/gcc/gcc/cp/tree.c:3816
0x9e3772 cp_check_qualified_type
/home/casey/repos/gcc/gcc/cp/tree.c:2135
0x9e7557 build_cp_fntype_variant(tree_node*, cp_ref_qualifier, tree_node*,
bool)
/home/casey/repos/gcc/gcc/cp/tree.c:2568
0x9e7647 build_cp_fntype_variant(tree_node*, cp_ref_qualifier, tree_node*,
bool)
/home/casey/repos/gcc/gcc/cp/tree.c:2599
0x8b9aeb grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
/home/casey/repos/gcc/gcc/cp/decl.c:11527
0x8caa3e grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
/home/casey/repos/gcc/gcc/cp/decl2.c:814
0x95b2f1 cp_parser_init_declarator
/home/casey/repos/gcc/gcc/cp/parser.c:20306
0x95ef04 cp_parser_single_declaration
/home/casey/repos/gcc/gcc/cp/parser.c:27954
0x95f04c cp_parser_template_declaration_after_parameters
/home/casey/repos/gcc/gcc/cp/parser.c:27546
0x95f98d cp_parser_explicit_template_declaration
/home/casey/repos/gcc/gcc/cp/parser.c:27792
0x95f98d cp_parser_template_declaration_after_export
/home/casey/repos/gcc/gcc/cp/parser.c:27811
0x960cbd cp_parser_member_declaration
/home/casey/repos/gcc/gcc/cp/parser.c:24070
0x93b07a cp_parser_member_specification_opt
/home/casey/repos/gcc/gcc/cp/parser.c:23997
0x93b07a cp_parser_class_specifier_1
/home/casey/repos/gcc/gcc/cp/parser.c:23141
0x93d049 cp_parser_class_specifier
/home/casey/repos/gcc/gcc/cp/parser.c:23403
0x93d049 cp_parser_type_specifier
/home/casey/repos/gcc/gcc/cp/parser.c:17259
0x93e03b cp_parser_decl_specifier_seq
/home/casey/repos/gcc/gcc/cp/parser.c:13982
0x93e773 cp_parser_simple_declaration
/home/casey/repos/gcc/gcc/cp/parser.c:13287
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug fortran/88048] [8/9 Regression] ICE in check_data_variable, at fortran/resolve.c:15491
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88048 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Sun Dec 9 06:09:47 2018 New Revision: 266916 URL: https://gcc.gnu.org/viewcvs?rev=266916&root=gcc&view=rev Log: 2018-12-08 Steven G. Kargl PR fortran/88048 * resolve.c (check_data_variable): Named constant cannot be a data object. 2018-12-08 Steven G. Kargl PR fortran/88048 * gfortran.dg/pr88048.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr88048.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/88048] [8/9 Regression] ICE in check_data_variable, at fortran/resolve.c:15491
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88048 --- Comment #6 from kargl at gcc dot gnu.org --- Author: kargl Date: Sun Dec 9 06:29:17 2018 New Revision: 266917 URL: https://gcc.gnu.org/viewcvs?rev=266917&root=gcc&view=rev Log: 2018-12-08 Steven G. Kargl PR fortran/88048 * resolve.c (check_data_variable): Named constant cannot be a data object. 2018-12-08 Steven G. Kargl PR fortran/88048 * gfortran.dg/pr88048.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88048.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/resolve.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/88048] [8/9 Regression] ICE in check_data_variable, at fortran/resolve.c:15491
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88048 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from kargl at gcc dot gnu.org --- Fixed on trunk and branch-8.
[Bug target/88035] missing _mm512_reduce_round_pd() et al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88035 MCCCS changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #1 from MCCCS --- Only the `_mm_` reduce-intrinsics don't exist. You can still call them from GCC by 1) Opening the table https://github.com/llvm-mirror/clang/blob/master/lib/Headers/avx512dqintrin.h 2) Ctrl + F for the function (e.g. _mm512_reduce_round_pd) 3) Call the function in the definition (e.g. __builtin_ia32_reducepd512_mask) But this is only a workaround, those `_mm_` functions/macros should be added, I agree.
