[Bug target/94504] On powerpc, -ffunction-sections -fdata-sections is not as effective as expected for PIE executables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94504 Richard Biener changed: What|Removed |Added CC||amodra at gcc dot gnu.org --- Comment #2 from Richard Biener --- Huh, looking at the assembly & the object file this seems to be fully a linker issue who seems to be responsible for building the GOT. I suggest to move this over to sourceware. Alan?
[Bug target/94509] wrong code with -mavx512bw and __builtin_shuffle()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94509 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-04-07
[Bug target/61837] missed loop invariant expression optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61837 luoxhu at gcc dot gnu.org changed: What|Removed |Added CC||luoxhu at gcc dot gnu.org --- Comment #3 from luoxhu at gcc dot gnu.org --- "addi 8,4,-1" and "subf 9,8,5" could not be hoisted out as there are dependency to "lbzu 9,1(8)". r8 need be initialized to p2-1 in each iteration of outer loop. Only the result of subf 9,8,5 is loop invariant (p2+s-1)-(p2-1). But the latest GCC code could be optimized as A, B, C is loop invariant. foo: .LFB0: .cfi_startproc cmpwi 7,5,0 li 6,0 rldicl 5,5,0,32 li 7,0 .p2align 4,,15 .L2: ble 7,.L7 addi 8,5,-1 // A addi 10,4,-1 rldicl 8,8,0,32 // B mr 9,3 addi 8,8,1// C mtctr 8 .p2align 5 .L4: lbzu 8,1(10) cmpw 0,8,7 bne 0,.L3 stw 6,0(9) .L3: addi 9,9,4 bdnz .L4 .L7: addi 6,6,88 addi 7,7,1 cmpwi 0,6, extsw 7,7 extsw 6,6 bne 0,.L2 blr
[Bug d/94425] [D] Consider always settings ASM_VOLATILE_P on asm statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94425 --- Comment #4 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:30d26118f96fa542ee078834bc3cb4eef6730451 commit r10-7583-g30d26118f96fa542ee078834bc3cb4eef6730451 Author: Iain Buclaw Date: Tue Mar 31 00:24:13 2020 +0200 d: Always set ASM_VOLATILE_P on asm statements (PR94425) gcc/d/ChangeLog: PR d/94425 * toir.cc (IRVisitor::visit (GccAsmStatement *)): Set ASM_VOLATILE_P on all asm statements.
[Bug target/94488] [AArch64] ICE on right shift of V2DImode by DImode shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94488
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:7a6588fe65432c0f1a8b5fdefba81700ebf88711
commit r10-7584-g7a6588fe65432c0f1a8b5fdefba81700ebf88711
Author: Jakub Jelinek
Date: Tue Apr 7 10:01:16 2020 +0200
aarch64: Fix {ash[lr],lshr}3 expanders [PR94488]
The following testcase ICEs on aarch64 apparently since the introduction of
the aarch64 port. The reason is that the {ashl,ashr,lshr}3 expanders
completely unnecessarily FAIL; if operands[2] is something other than
a CONST_INT or REG or MEM and the middle-end code can't cope with the
pattern giving up in these cases. All the expanders use general_operand
predicate for the shift amount operand, but then have just a special case
for CONST_INT (if in-bound, emit an immediate shift, otherwise force into
REG), or MEM (force into REG), or REG (that is the case it handles).
In the testcase, operands[2] is a lowpart SUBREG of a REG, which is valid
general_operand.
I don't see any reason what is magic about MEMs that it should be forced
into REG and others like SUBREGs that it shouldn't, there isn't even a
reason to check for !REG_P because force_reg will do nothing if the operand
is already a REG, and otherwise can handle general_operand just fine.
2020-04-07 Jakub Jelinek
PR target/94488
* config/aarch64/aarch64-simd.md (ashl3, lshr3,
ashr3): Force operands[2] into reg whenever it is not
CONST_INT.
Assume it is a REG after that instead of testing it and doing FAIL
otherwise. Formatting fix.
* gcc.c-torture/compile/pr94488.c: New test.
[Bug c++/94510] New: nullptr_t implicitly cast to zero twice in std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94510
Bug ID: 94510
Summary: nullptr_t implicitly cast to zero twice in std::array
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kndevl at outlook dot com
Target Milestone: ---
`std::array arr{ nullptr, 0, 0 };` is expected to fail to compile
similar to how `std::array arr{ nullptr, 0, 1 };` fails. What I infer
is that if all elements are effectively zero, type conversions are not checked.
This makes sense if a variable of static storage duration is initialized to
zero and std::array constructor can ignore the arguments in the initializer if
all arguments are implicitly zero.
Is there anything on the C++ standard that allows this optimization I am
missing here?
# This works fine, as expected
`g++ -save-temps -c not-bug.cpp`
> not-bug.cpp: In function ‘void test()’:
> not-bug.cpp:4:43: error: cannot convert ‘std::nullptr_t’ to ‘int’ in
> initialization
> 4 | std::array arr{ nullptr, 0, 1 };
# This compiles fine, but this should error out
`g++ -save-temps -c bug.cpp`
I built the tip of gcc yesterday. It had the same bug.
Any pointers on how I can go about debugging this?
- Does type checking happen during GENERIC stage?
- How do I print the source string corresponding to a TREE struct?
[Bug c++/94510] nullptr_t implicitly cast to zero twice in std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94510 --- Comment #1 from Karthik Nishanth --- Created attachment 48218 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48218&action=edit preprocessed source for bug.cpp
[Bug c++/94510] nullptr_t implicitly cast to zero twice in std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94510 --- Comment #3 from Karthik Nishanth --- Created attachment 48220 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48220&action=edit complete command line invocations
[Bug c++/94510] nullptr_t implicitly cast to zero twice in std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94510 --- Comment #2 from Karthik Nishanth --- Created attachment 48219 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48219&action=edit bug.cpp
[Bug c++/94510] nullptr_t implicitly cast to zero twice in std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94510 --- Comment #5 from Karthik Nishanth --- Created attachment 48222 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48222&action=edit machine type
[Bug c++/94510] nullptr_t implicitly cast to zero twice in std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94510 --- Comment #4 from Karthik Nishanth --- Created attachment 48221 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48221&action=edit gcc version string
[Bug c++/94510] nullptr_t implicitly cast to zero twice in std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94510 --- Comment #6 from Karthik Nishanth --- Created attachment 48223 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48223&action=edit not a bug
[Bug c++/94510] nullptr_t implicitly cast to zero twice in std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94510 --- Comment #7 from Karthik Nishanth --- Created attachment 48224 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48224&action=edit not a bug, preprocessed
[Bug target/94509] wrong code with -mavx512bw and __builtin_shuffle()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94509
--- Comment #1 from Jakub Jelinek ---
Created attachment 48225
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48225&action=edit
gcc10-pr94509.patch
Untested fix.
The
if (vmode == V32QImode)
{
/* vpshufb only works intra lanes, it is not
possible to shuffle bytes in between the lanes. */
for (i = 0; i < nelt; ++i)
if ((d->perm[i] ^ i) & (nelt / 2))
return false;
}
intra-lane check which has been correct has been copied and adjusted for
64-byte modes into:
if (vmode == V64QImode)
{
/* vpshufb only works intra lanes, it is not
possible to shuffle bytes in between the lanes. */
for (i = 0; i < nelt; ++i)
if ((d->perm[i] ^ i) & (nelt / 4))
return false;
}
which is not correct, because 64-byte modes have 4 lanes rather than just two
and the above is only testing that the permutation grabs even lane elts from
even lanes and odd lane elts from odd lanes, but not that they are from the
same 256-bit half.
[Bug c++/94511] New: User-defined type in non-type template parameter yields an incorrect value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94511
Bug ID: 94511
Summary: User-defined type in non-type template parameter
yields an incorrect value
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pacoarjonilla at yahoo dot es
Target Milestone: ---
g++ --std=c++2a code.cc && ./a.out
The following snippet misbehaves with GCC9 and GCC10 master
<<<
#include
#include
struct A {
std::byte data [6] {static_cast(0x00)};
constexpr A(char ch) {
data[ch/8] |= static_cast(0x01 << (ch % 8));
}
};
template struct B { char ch; };
void print(A a) {
for (int i = 0; i < 6; i++)
std::cout << (unsigned)a.data[i] << ' ';
std::cout << std::endl;
}
using Bn = B<{'\n'}>; // XXX Replacing \n by any other character less than 48
corrects the issue XXX
using Ba = B<{'.'}>;
template void foo () {
print(T);
}
int main() {
foo<'*'>(); // XXX Replacing the * also corrects the issue XXX
print(A{'*'});
}
<<
Expected output
0 0 0 0 0 4
0 0 0 0 0 4
Actual output
0 4 0 0 0 0
0 0 0 0 0 4
[Bug c++/94512] New: [10 Regression] ICE in tsubst_expr, at cp/pt.c:18210
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94512
Bug ID: 94512
Summary: [10 Regression] ICE in tsubst_expr, at cp/pt.c:18210
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code, openmp
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++-10.0.1-alpha20200405 snapshot (g:2a1a0c8c0db0aae50a2cebce59bd64334cd6ba2a)
ICEs when compiling the following testcase, extracted from
test/OpenMP/parallel_master_taskloop_simd_collapse_messages.cpp from the clang
10.0.0 test suite, w/ -fopenmp:
void
ow ();
template
void
ho ()
{
#pragma omp parallel master taskloop
ow ();
}
void
th ()
{
ho<0> ();
}
% g++-10.0.1 -fopenmp -c e4oc5ifw.cpp
e4oc5ifw.cpp: In function 'void ho()':
e4oc5ifw.cpp:9:3: error: for statement expected before 'ow'
9 | ow ();
| ^~
e4oc5ifw.cpp: In instantiation of 'void ho() [with int = 0]':
e4oc5ifw.cpp:15:10: required from here
e4oc5ifw.cpp:9:3: internal compiler error: in tsubst_expr, at cp/pt.c:18210
0x659911 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200405/work/gcc-10-20200405/gcc/cp/pt.c:18210
0x9ed1e2 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200405/work/gcc-10-20200405/gcc/cp/pt.c:17696
0x9ed997 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200405/work/gcc-10-20200405/gcc/cp/pt.c:18014
0x9eaad6 instantiate_decl(tree_node*, bool, bool)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200405/work/gcc-10-20200405/gcc/cp/pt.c:25538
0xa1b7eb instantiate_pending_templates(int)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200405/work/gcc-10-20200405/gcc/cp/pt.c:25654
0x920d33 c_parse_final_cleanups()
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200405/work/gcc-10-20200405/gcc/cp/decl2.c:4874
[Bug c++/94511] User-defined type in non-type template parameter yields an incorrect value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94511
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Adjusted testcase without system headers:
namespace std {
enum class byte : unsigned char {};
constexpr byte
operator| (byte __l, byte __r) noexcept
{ return (byte)(unsigned char)((unsigned)__l | (unsigned)__r); }
constexpr byte&
operator|= (byte& __l, byte __r) noexcept
{ return __l = __l | __r; }
}
struct A {
std::byte data [6] {static_cast (0x00)};
constexpr A (char ch) { data[ch/8] |= static_cast(0x01 << (ch %
8)); }
};
template struct B { char ch; };
void
check (A a)
{
for (int i = 0; i < 6; i++)
if ((unsigned) a.data[i] != (i == 5 ? 4 : 0))
__builtin_abort ();
}
using Bn = B<{'\n'}>;
template
void
foo ()
{
check (T);
}
int
main ()
{
foo<'*'> ();
check (A{'*'});
}
[Bug c++/94512] [10 Regression] ICE in tsubst_expr, at cp/pt.c:18210
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94512 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |10.0
[Bug c++/94511] User-defined type in non-type template parameter yields an incorrect value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94511 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-04-07 CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #2 from Jakub Jelinek --- This is miscompiled since r9-5271-g96e768c3fecf0f65af3f289293145d5740971e2a when it started to be accepted.
[Bug c++/94511] User-defined type in non-type template parameter yields an incorrect value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94511
--- Comment #3 from Jakub Jelinek ---
Note, the testcase isn't portable, so either would need to be restricted for
ascii compatible execution charsets only, or the check would need to be
replaced with i == ('*' / 8) ? 1U << ('*' % 8) : 0
(and deal with '*' >= 64 where it would be a compile time error).
Or use '\x0a' and '\x2a' instead of '\n' and '*'.
namespace std {
enum class byte : unsigned char {};
constexpr byte
operator| (byte __l, byte __r) noexcept
{ return (byte)(unsigned char)((unsigned)__l | (unsigned)__r); }
constexpr byte&
operator|= (byte& __l, byte __r) noexcept
{ return __l = __l | __r; }
}
struct A {
std::byte data [6] {static_cast (0x00)};
constexpr A (char ch) { data[ch/8] |= static_cast(0x01 << (ch %
8)); }
};
template struct B { char ch; };
void
check (A a)
{
for (int i = 0; i < 6; i++)
if ((unsigned) a.data[i] != (i == 5 ? 4 : 0))
__builtin_abort ();
}
using Bn = B<{'\x0a'}>;
template
void
foo ()
{
check (T);
}
int
main ()
{
foo<'\x2a'> ();
check (A{'\x2a'});
}
[Bug go/94513] New: [10 Regression] go buildid and cgo tools require symbols in GLIBC_PRIVATE namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94513 Bug ID: 94513 Summary: [10 Regression] go buildid and cgo tools require symbols in GLIBC_PRIVATE namespace Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: rguenth at gcc dot gnu.org CC: cmang at google dot com Target Milestone: --- > readelf -s buildid | grep GLIBC_PRIVATE 25: 0 FUNCGLOBAL DEFAULT UND __mmap@GLIBC_PRIVATE (3) 32: 0 FUNCGLOBAL DEFAULT UND __munmap@GLIBC_PRIVATE (3) > readelf -s cgo | grep GLIBC_PRIVATE 60: 0 FUNCGLOBAL DEFAULT UND __mmap@GLIBC_PRIVATE (3) 204: 0 FUNCGLOBAL DEFAULT UND __munmap@GLIBC_PRIVATE (3) this makes them uninstallable on SUSE systems. It also looks like a recent regression.
[Bug go/94513] [10 Regression] go buildid and cgo tools require symbols in GLIBC_PRIVATE namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94513 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0 CC||hjl.tools at gmail dot com --- Comment #1 from Richard Biener --- Caused by 710d54ed4e343a08d2fa0abc6b63c53dec0d9bcb
[Bug go/94513] [10 Regression] go buildid and cgo tools require symbols in GLIBC_PRIVATE namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94513 --- Comment #2 from Richard Biener --- I guess the proper solution is to invoke the syscalls directly rather than going through the libc wrappers?
[Bug libgcc/94513] [10 Regression] morestack require symbols in GLIBC_PRIVATE namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94513 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Assignee|ian at airs dot com|unassigned at gcc dot gnu.org Component|go |libgcc Target||*-linux-gnu Keywords||build Last reconfirmed||2020-04-07 Summary|[10 Regression] go buildid |[10 Regression] morestack |and cgo tools require |require symbols in |symbols in GLIBC_PRIVATE|GLIBC_PRIVATE namespace |namespace | Ever confirmed|0 |1
[Bug libgcc/94513] [10 Regression] go buildid and cgo tools require symbols in GLIBC_PRIVATE namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94513 Richard Biener changed: What|Removed |Added Last reconfirmed||2020-04-07 Status|UNCONFIRMED |NEW Assignee|ian at airs dot com|unassigned at gcc dot gnu.org Component|go |libgcc Ever confirmed|0 |1
[Bug go/94513] [10 Regression] go buildid and cgo tools require symbols in GLIBC_PRIVATE namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94513 Richard Biener changed: What|Removed |Added Keywords|build | Status|NEW |UNCONFIRMED Target|*-linux-gnu | Component|libgcc |go Ever confirmed|1 |0 Assignee|unassigned at gcc dot gnu.org |ian at airs dot com Last reconfirmed|2020-04-07 00:00:00 | Summary|[10 Regression] morestack |[10 Regression] go buildid |require symbols in |and cgo tools require |GLIBC_PRIVATE namespace |symbols in GLIBC_PRIVATE ||namespace Known to work||9.3.1 --- Comment #3 from Richard Biener --- For configurability generic-morestack.c should likely use a private wrapper for mmap and munmap used in the single place of actual allocation/deallocation (and maybe declared always_inline) while the "probing" uses in __morestack_load_mmap can refer back to the libc variants. This still works "correctly" on the GCC 9 branch.
[Bug c++/94512] [9/10 Regression] ICE in tsubst_expr, at cp/pt.c:18210
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94512 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Last reconfirmed||2020-04-07 Status|UNCONFIRMED |ASSIGNED Target Milestone|10.0|9.4 Summary|[10 Regression] ICE in |[9/10 Regression] ICE in |tsubst_expr, at |tsubst_expr, at |cp/pt.c:18210 |cp/pt.c:18210 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- ICEs since r9-3941-g28567c40e2c7c88e424283e8a1a6ff8cb7ba440c
[Bug c++/94512] [9/10 Regression] ICE in tsubst_expr, at cp/pt.c:18210
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94512 --- Comment #2 from Jakub Jelinek --- Created attachment 48226 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48226&action=edit gcc10-pr94512.patch Untested fix.
[Bug libgcc/94513] [10 Regression] go buildid and cgo tools require symbols in GLIBC_PRIVATE namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94513 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org
[Bug target/94514] New: aarch64: unwinding across mixed pac-ret and non-pac-ret frames is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94514
Bug ID: 94514
Summary: aarch64: unwinding across mixed pac-ret and
non-pac-ret frames is broken
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
libgcc unwinder on aarch64 fails to keep track of pauth state and may try to
authenticate return addresses that were not signed causing a runtime crash.
example c++ code that segfaults in the unwinder on a pauth enabled system:
__attribute__((noinline, target("branch-protection=pac-ret")))
static void do_throw (void)
{
throw 42;
__builtin_abort ();
}
__attribute__((noinline, target("branch-protection=none")))
static void no_pac_ret (void)
{
do_throw ();
__builtin_abort ();
}
int main ()
{
try {
no_pac_ret ();
} catch (...) {
return 0;
}
__builtin_abort ();
}
[Bug target/94515] New: aarch64: broken unwind information for pac-ret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94515
Bug ID: 94515
Summary: aarch64: broken unwind information for pac-ret
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
pac-ret uses the .cfi_window_save directive to toggle between signed/unsigned
return address, alternatively .cfi_remember_state and .cfi_restore_state pair
can be used to keep track of the "return address signedness" state.
in some cases, when there are several return paths, gcc fails to generate
the correct cfi directives for all return paths which can cause the unwinder
not to authenticate a signed return address leading to a runtime crash on
pauth enabled systems.
example c++ test that segfaults (after fixing bug 94514 ):
volatile int zero = 0;
__attribute__((noinline))
void unwind (void)
{
if (zero == 0)
throw 42;
}
__attribute__((noinline,noipa))
static int test (int z)
{
if (z) {
asm volatile("":::"x20","x21");
unwind();
return 1;
} else {
unwind();
return 2;
}
}
int main ()
{
try {
test (zero);
__builtin_abort ();
} catch (...) {
return 0;
}
__builtin_abort ();
}
the test() function with -mbranch-protection=standard -O2 compiles to
_ZL4testi:
.LFB1:
.cfi_startproc
hint25 // paciasp
.cfi_window_save // pauth on
stp x29, x30, [sp, -32]!
.cfi_def_cfa_offset 32
.cfi_offset 29, -32
.cfi_offset 30, -24
mov x29, sp
cbz w0, .L9
stp x20, x21, [sp, 16]
.cfi_offset 21, -8
.cfi_offset 20, -16
bl _Z6unwindv
mov w0, 1
ldp x20, x21, [sp, 16]
.cfi_restore 21
.cfi_restore 20
ldp x29, x30, [sp], 32
.cfi_restore 30
.cfi_restore 29
.cfi_def_cfa_offset 0
hint29 // autiasp
.cfi_window_save // pauth off
ret
.p2align 2,,3
.L9:
ret addr pauth state is wrong here !
.cfi_def_cfa_offset 32
.cfi_offset 29, -32
.cfi_offset 30, -24
bl _Z6unwindv
ldp x29, x30, [sp], 32
.cfi_restore 30
.cfi_restore 29
.cfi_def_cfa_offset 0
hint29 // autiasp
.cfi_window_save
mov w0, 2
ret
.cfi_endproc
.LFE1:
.size _ZL4testi, .-_ZL4testi
[Bug rtl-optimization/94516] New: [10 Regression] gnutls test ./psk-file fails since r10-7515-g2c0fa3ecf70d199af18785702e9e0548fd3ab793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94516 Bug ID: 94516 Summary: [10 Regression] gnutls test ./psk-file fails since r10-7515-g2c0fa3ecf70d199af18785702e9e0548fd3ab793 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- The following release: https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/gnutls-3.6.12.tar.xz fails with: $ export CFLAGS="-O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -fPIE" $ ./configure $ make $ cd tests $ make check $ valgrind ./psk-file ==22044== Memcheck, a memory error detector ==22044== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==22044== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==22044== Command: ./psk-file ==22044== ntest NORMAL:-KX-ALL:+PSK (user:non-hex) ==22045== ==22045== HEAP SUMMARY: ==22045== in use at exit: 337 bytes in 7 blocks ==22045== total heap usage: 1,371 allocs, 1,364 frees, 203,699 bytes allocated ==22045== ==22045== LEAK SUMMARY: ==22045==definitely lost: 0 bytes in 0 blocks ==22045==indirectly lost: 0 bytes in 0 blocks ==22045== possibly lost: 0 bytes in 0 blocks ==22045==still reachable: 337 bytes in 7 blocks ==22045== suppressed: 0 bytes in 0 blocks ==22045== Rerun with --leak-check=full to see details of leaked memory ==22045== ==22045== For lists of detected and suppressed errors, rerun with: -s ==22045== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) test NORMAL:-VERS-ALL:+VERS-TLS1.3:-CIPHER-ALL:+AES-128-GCM:+DHE-PSK:+PSK:-GROUP-DH-ALL (user:jas) ==22046== ==22046== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==22046== General Protection Fault ==22046==at 0x48D291A: UnknownInlinedFun (pk.c:1925) ==22046==by 0x48D291A: wrap_nettle_pk_generate_keys.lto_priv.0 (pk.c:2509) ==22046==by 0x48F53FB: client_gen_key_share (key_share.c:95) ==22046==by 0x48F59CC: key_share_send_params.lto_priv.0 (key_share.c:725) ==22046==by 0x4998F6B: hello_ext_send (hello_ext.c:368) ==22046==by 0x49660D5: UnknownInlinedFun (extv.c:218) ==22046==by 0x49660D5: _gnutls_extv_append (extv.c:200) ==22046==by 0x4999301: _gnutls_gen_hello_extensions (hello_ext.c:436) ==22046==by 0x49B2731: UnknownInlinedFun (handshake.c:2265) ==22046==by 0x49B2731: UnknownInlinedFun (handshake.c:2895) ==22046==by 0x49B2731: gnutls_handshake (handshake.c:2727) ==22046==by 0x402C1F: client (psk-file.c:102) ==22046==by 0x4030B3: run_test3 (psk-file.c:349) ==22046==by 0x4031FE: run_test2 (psk-file.c:358) ==22046==by 0x4031FE: doit (psk-file.c:407)
[Bug rtl-optimization/94516] [10 Regression] gnutls test ./psk-file fails since r10-7515-g2c0fa3ecf70d199af18785702e9e0548fd3ab793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94516 --- Comment #1 from Martin Liška --- Created attachment 48227 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48227&action=edit Reducing patch for psk-file.c I tried both ASAN and UBSAN, and also valgrind with -O0 and it seems all fine.
[Bug rtl-optimization/94516] [10 Regression] gnutls test ./psk-file fails since r10-7515-g2c0fa3ecf70d199af18785702e9e0548fd3ab793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94516 --- Comment #2 from Martin Liška --- Created attachment 48228 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48228&action=edit pre-processed source file It's compiled with: $ gcc -fdiagnostics-show-option -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -fPIE -MT psk-file.o psk-file.i -c The assembly diff is quite small (it's doit function): $ diff -u /tmp/psk-file.good.s /tmp/psk-file.bad.s --- /tmp/psk-file.good.s2020-04-07 13:40:35.985428368 +0200 +++ /tmp/psk-file.bad.s 2020-04-07 13:38:27.658722637 +0200 @@ -1036,37 +1036,33 @@ pushq $0 .cfi_def_cfa_offset 80 callrun_test3 - addq$24, %rsp - .cfi_def_cfa_offset 56 + pushq $0 + .cfi_def_cfa_offset 64 xorl%r9d, %r9d xorl%r8d, %r8d pushq $0 - .cfi_def_cfa_offset 64 + .cfi_def_cfa_offset 72 movq%r12, %rcx leaq.LC42(%rip), %rdx leaq.LC43(%rip), %rsi - pushq $0 - .cfi_def_cfa_offset 72 - leaq.LC44(%rip), %rdi pushq $9 .cfi_def_cfa_offset 80 + leaq.LC44(%rip), %rdi callrun_test3 - addq$24, %rsp - .cfi_def_cfa_offset 56 - xorl%r9d, %r9d - movq%r12, %rcx pushq $-32 .cfi_def_cfa_offset 64 + xorl%r9d, %r9d movl$1, %r8d - leaq.LC42(%rip), %rdx - xorl%esi, %esi pushq $-12 .cfi_def_cfa_offset 72 - leaq.LC45(%rip), %rdi + movq%r12, %rcx + leaq.LC42(%rip), %rdx + xorl%esi, %esi pushq $0 .cfi_def_cfa_offset 80 + leaq.LC45(%rip), %rdi callrun_test3 - addq$32, %rsp + movq%r12, %rsp .cfi_def_cfa_offset 48 movq24(%rsp), %rax subq%fs:40, %rax
[Bug c++/94510] [9/10 Regression] nullptr_t implicitly cast to zero twice in std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94510
Jonathan Wakely changed:
What|Removed |Added
Known to fail||10.0, 9.3.0
Known to work||8.4.0
Last reconfirmed||2020-04-07
Summary|nullptr_t implicitly cast |[9/10 Regression] nullptr_t
|to zero twice in std::array |implicitly cast to zero
||twice in std::array
Ever confirmed|0 |1
Target Milestone|--- |9.4
Status|UNCONFIRMED |NEW
CC||msebor at gcc dot gnu.org
--- Comment #8 from Jonathan Wakely ---
(In reply to Karthik Nishanth from comment #4)
> Created attachment 48221 [details]
> gcc version string
There's no need to create attachments for each tiny bit of text, comments are
fine, and much easier for us to see, without having to click through a separate
page. (Your attachment in comment 3 just duplicates what you already said in
comment 0 anyway!)
Relevant info from the comment 4 attachment:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-pkgversion='Arch Linux 9.3.0-1'
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-shared
--enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
gcc version 9.3.0 (Arch Linux 9.3.0-1)
Reduced testcase:
int arr[3] = { nullptr, 0, 0 };
This is a regression introduced by r270155
PR c++/89974 - ICE on a definition of a non-type specialization on a struct
object with pointer to member function
PR c++/89974 - ICE on a definition of a non-type specialization on a struct
object with pointer to member function
PR c++/89878 - same specializations on a zero-initialized struct object as
a non-type parameter treated as distinct
PR c++/89833 - sorry, unimplemented: string literal in function template
signature
PR c++/47488 - sorry, unimplemented: string literal in function template
signature
gcc/cp/ChangeLog:
PR c++/89974
PR c++/89878
PR c++/89833
PR c++/47488
* decl.c (reshape_init_array_1): Strip trailing zero-initializers
from arrays of trivial type and known size.
* mangle.c (write_expression): Convert braced initializer lists
to STRING_CSTs.
(write_expression): Trim trailing zero-initializers from arrays
of trivial type.
(write_template_arg_literal): Mangle strings the same as braced
initializer lists.
gcc/testsuite/ChangeLog:
PR c++/89974
PR c++/89878
PR c++/89833
PR c++/47488
* gcc/testsuite/g++.dg/abi/mangle69.C: New test.
* gcc/testsuite/g++.dg/abi/mangle70.C: New test.
* gcc/testsuite/g++.dg/abi/mangle71.C: New test.
* gcc/testsuite/g++.dg/abi/mangle72.C: New test.
* gcc/testsuite/g++.dg/cpp0x/constexpr-array19.C: New test.
* gcc/testsuite/g++.dg/cpp2a/nontype-class15.C: New test.
* gcc/testsuite/g++.dg/cpp2a/nontype-class16.C: New test.
* gcc/testsuite/g++.dg/init/array51.C: New test.
[Bug rtl-optimization/94516] [10 Regression] gnutls test ./psk-file fails since r10-7515-g2c0fa3ecf70d199af18785702e9e0548fd3ab793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94516 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug debug/94469] lto abstract variable emitted as concrete decl (ada test-case)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94469
--- Comment #11 from Tom de Vries ---
(In reply to Richard Biener from comment #9)
> (In reply to Tom de Vries from comment #8)
> > (In reply to Richard Biener from comment #7)
> > > (In reply to Richard Biener from comment #6)
> > > > Btw, I still wonder how it works with abstract functions, inline and
> > > > concrete instances. Works in gdb, that is - will dig into it a bit
> > > > after
> > > > lunch.
> > >
> > > So here I see us (without LTO) putting DW_AT_location attributes on the
> > > abstract instance copy. That kind-of makes it not abstract anymore, no?
> > > But that way we avoid emitting multiple DIEs for local statics. With
> > > -flto the same problem appears there because we cannot annotate the
> > > early CUs DIE with a location so the concrete instance copy
> > > gets [generated and] the location.
> > >
> > > So while I intended to have the early CUs behave like fully abstract
> > > the actual DWARF is different. I understand that if I emit the early CU
> > > as
> > > partial unit it becomes abstract?
> >
> > Well, that's my theory.
> >
> > I've created a minimal dwarf assembler variant corresponding to the C
> > test-case (with only var aaa), and I could reproduce the problem, however
> > after changing the tag to DW_TAG_partial_unit still a symbol table for that
> > partial unit was created. It seems that the inter-cu ref handling code is
> > responsible for that. I'll try to fix this.
> >
> > > Note we do emit DW_AT_const_value
> > > to early optimized out decls - would those still be found when the early
> > > CU
> > > is partial [and not imported anywhere]?
> >
> > I think so, but I could check with the dwarf assembler test-case.
>
> OK, so that doesn't work anymore.
>
> static const int i = 1;
>
> int main()
> {
> return i;
> }
>
> with -O2 -flto -g and DW_TAG_compile_unit I see
>
> (gdb) start
> Temporary breakpoint 1 at 0x4003a0: file t.c, line 5.
> Starting program: /home/abuild/rguenther/obj-gcc-g/gcc/a.out
>
> Temporary breakpoint 1, main () at t.c:5
> 5 return i;
> (gdb) p i
> 1
>
> while when using DW_TAG_partial_unit:
>
> (gdb) p i
> No symbol "i" in current context.
>
> Compilation Unit @ offset 0xc7:
>Length:0x3d (32-bit)
>Version: 4
>Abbrev Offset: 0x64
>Pointer Size: 8
> <0>: Abbrev Number: 1 (DW_TAG_compile_unit)
>DW_AT_producer: (indirect string, offset: 0x1d0): GNU GIMPLE
> 10.0
> .1 20200406 (experimental) -mtune=generic -march=x86-64 -g -g -O2 -O2
> -fno-openm
> p -fno-openacc -fno-pie -fltrans
>DW_AT_language: 12 (ANSI C99)
>DW_AT_name: (indirect string, offset: 0x250):
>DW_AT_comp_dir: (indirect string, offset: 0x25d):
> /abuild/rguenth
> er/obj-gcc-g/gcc
>DW_AT_ranges : 0x40
>DW_AT_low_pc : 0x0
>DW_AT_stmt_list : 0xe9
> <1>: Abbrev Number: 2 (DW_TAG_subprogram)
>DW_AT_abstract_origin: <0x13c>
>DW_AT_low_pc : 0x4003a0
>DW_AT_high_pc : 0x6
> <105> DW_AT_frame_base : 1 byte block: 9c
> (DW_OP_call_frame_cfa)
> <107> DW_AT_GNU_all_call_sites: 1
> <1><107>: Abbrev Number: 0
> Compilation Unit @ offset 0x108:
>Length:0x3d (32-bit)
>Version: 4
>Abbrev Offset: 0x88
>Pointer Size: 8
> <0><113>: Abbrev Number: 1 (DW_TAG_partial_unit)
> <114> DW_AT_producer: (indirect string, offset: 0x27d): GNU C17
> 10.0.1
> 20200406 (experimental) -mtune=generic -march=x86-64 -g -O2 -flto
> <118> DW_AT_language: 12 (ANSI C99)
> <119> DW_AT_name: t.c
> <11d> DW_AT_comp_dir: (indirect string, offset: 0x25d):
> /abuild/rguent
> her/obj-gcc-g/gcc
> <121> DW_AT_stmt_list : 0x127
> <1><125>: Abbrev Number: 2 (DW_TAG_variable)
> <126> DW_AT_name: i
> <128> DW_AT_decl_file : 1
> <129> DW_AT_decl_line : 1
> <12a> DW_AT_decl_column : 18
> <12b> DW_AT_type: <0x137>
> <12f> DW_AT_const_value : 1
> <1><130>: Abbrev Number: 3 (DW_TAG_base_type)
> <131> DW_AT_byte_size : 4
> <132> DW_AT_encoding: 5 (signed)
> <133> DW_AT_name: int
> <1><137>: Abbrev Number: 4 (DW_TAG_const_type)
> <138> DW_AT_type: <0x130>
> <1><13c>: Abbrev Number: 5 (DW_TAG_subprogram)
> <13d> DW_AT_external: 1
> <13d> DW_AT_name: (indirect string, offset: 0x2ce): main
> <141> DW_AT_decl_file : 1
> <142> DW_AT_decl_line : 3
> <143> DW_AT_decl_column : 5
> <144> DW_AT_type: <0x130>
> <1><148>: Abbrev Number: 0
>
Ack, I've managed to reproduce this using a dwarf assembly test-case (PR
gdb/25796 - "Symbol with inherited DW_AT_const_value not found" @
https://sourceware.org/bugzilla/show_bug.cgi?id=25796), and submitted a gdb
patch for this.
Note that the problem is specific to gdb's partial symbol tables feat
[Bug debug/94469] lto abstract variable emitted as concrete decl (ada test-case)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94469
--- Comment #12 from rguenther at suse dot de ---
On Tue, 7 Apr 2020, vries at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94469
>
> --- Comment #11 from Tom de Vries ---
> (In reply to Richard Biener from comment #9)
> > (In reply to Tom de Vries from comment #8)
> > > (In reply to Richard Biener from comment #7)
> > > > (In reply to Richard Biener from comment #6)
> > > > > Btw, I still wonder how it works with abstract functions, inline and
> > > > > concrete instances. Works in gdb, that is - will dig into it a bit
> > > > > after
> > > > > lunch.
> > > >
> > > > So here I see us (without LTO) putting DW_AT_location attributes on the
> > > > abstract instance copy. That kind-of makes it not abstract anymore, no?
> > > > But that way we avoid emitting multiple DIEs for local statics. With
> > > > -flto the same problem appears there because we cannot annotate the
> > > > early CUs DIE with a location so the concrete instance copy
> > > > gets [generated and] the location.
> > > >
> > > > So while I intended to have the early CUs behave like fully abstract
> > > > the actual DWARF is different. I understand that if I emit the early
> > > > CU as
> > > > partial unit it becomes abstract?
> > >
> > > Well, that's my theory.
> > >
> > > I've created a minimal dwarf assembler variant corresponding to the C
> > > test-case (with only var aaa), and I could reproduce the problem, however
> > > after changing the tag to DW_TAG_partial_unit still a symbol table for
> > > that
> > > partial unit was created. It seems that the inter-cu ref handling code is
> > > responsible for that. I'll try to fix this.
> > >
> > > > Note we do emit DW_AT_const_value
> > > > to early optimized out decls - would those still be found when the
> > > > early CU
> > > > is partial [and not imported anywhere]?
> > >
> > > I think so, but I could check with the dwarf assembler test-case.
> >
> > OK, so that doesn't work anymore.
> >
> > static const int i = 1;
> >
> > int main()
> > {
> > return i;
> > }
> >
> > with -O2 -flto -g and DW_TAG_compile_unit I see
> >
> > (gdb) start
> > Temporary breakpoint 1 at 0x4003a0: file t.c, line 5.
> > Starting program: /home/abuild/rguenther/obj-gcc-g/gcc/a.out
> >
> > Temporary breakpoint 1, main () at t.c:5
> > 5 return i;
> > (gdb) p i
> > 1
> >
> > while when using DW_TAG_partial_unit:
> >
> > (gdb) p i
> > No symbol "i" in current context.
> >
> > Compilation Unit @ offset 0xc7:
> >Length:0x3d (32-bit)
> >Version: 4
> >Abbrev Offset: 0x64
> >Pointer Size: 8
> > <0>: Abbrev Number: 1 (DW_TAG_compile_unit)
> >DW_AT_producer: (indirect string, offset: 0x1d0): GNU GIMPLE
> > 10.0
> > .1 20200406 (experimental) -mtune=generic -march=x86-64 -g -g -O2 -O2
> > -fno-openm
> > p -fno-openacc -fno-pie -fltrans
> >DW_AT_language: 12 (ANSI C99)
> >DW_AT_name: (indirect string, offset: 0x250):
> >
> >DW_AT_comp_dir: (indirect string, offset: 0x25d):
> > /abuild/rguenth
> > er/obj-gcc-g/gcc
> >DW_AT_ranges : 0x40
> >DW_AT_low_pc : 0x0
> >DW_AT_stmt_list : 0xe9
> > <1>: Abbrev Number: 2 (DW_TAG_subprogram)
> >DW_AT_abstract_origin: <0x13c>
> >DW_AT_low_pc : 0x4003a0
> >DW_AT_high_pc : 0x6
> > <105> DW_AT_frame_base : 1 byte block: 9c
> > (DW_OP_call_frame_cfa)
> > <107> DW_AT_GNU_all_call_sites: 1
> > <1><107>: Abbrev Number: 0
> > Compilation Unit @ offset 0x108:
> >Length:0x3d (32-bit)
> >Version: 4
> >Abbrev Offset: 0x88
> >Pointer Size: 8
> > <0><113>: Abbrev Number: 1 (DW_TAG_partial_unit)
> > <114> DW_AT_producer: (indirect string, offset: 0x27d): GNU C17
> > 10.0.1
> > 20200406 (experimental) -mtune=generic -march=x86-64 -g -O2 -flto
> > <118> DW_AT_language: 12 (ANSI C99)
> > <119> DW_AT_name: t.c
> > <11d> DW_AT_comp_dir: (indirect string, offset: 0x25d):
> > /abuild/rguent
> > her/obj-gcc-g/gcc
> > <121> DW_AT_stmt_list : 0x127
> > <1><125>: Abbrev Number: 2 (DW_TAG_variable)
> > <126> DW_AT_name: i
> > <128> DW_AT_decl_file : 1
> > <129> DW_AT_decl_line : 1
> > <12a> DW_AT_decl_column : 18
> > <12b> DW_AT_type: <0x137>
> > <12f> DW_AT_const_value : 1
> > <1><130>: Abbrev Number: 3 (DW_TAG_base_type)
> > <131> DW_AT_byte_size : 4
> > <132> DW_AT_encoding: 5 (signed)
> > <133> DW_AT_name: int
> > <1><137>: Abbrev Number: 4 (DW_TAG_const_type)
> > <138> DW_AT_type: <0x130>
> > <1><13c>: Abbrev Number: 5 (DW_TAG_subprogram)
> > <13d> DW_AT_external: 1
> > <13d> DW_AT_name: (indirect string, offset: 0x2ce): main
> > <141> DW_AT_decl_file : 1
> > <142> DW_AT_decl_line :
[Bug c++/94512] [9/10 Regression] ICE in tsubst_expr, at cp/pt.c:18210
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94512 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4df50a059fbd4d4a1cb067bd43caccdfca0327a8 commit r10-7585-g4df50a059fbd4d4a1cb067bd43caccdfca0327a8 Author: Jakub Jelinek Date: Tue Apr 7 14:30:53 2020 +0200 openmp: Fix parallel master error recovery [PR94512] We need to set OMP_PARALLEL_COMBINED only if the parsing of omp_master succeeded, because otherwise there is no nested master construct in the parallel. 2020-04-07 Jakub Jelinek PR c++/94512 * c-parser.c (c_parser_omp_parallel): Set OMP_PARALLEL_COMBINED if c_parser_omp_master succeeded. * parser.c (cp_parser_omp_parallel): Set OMP_PARALLEL_COMBINED if cp_parser_omp_master succeeded. * g++.dg/gomp/pr94512.C: New test.
[Bug target/94509] wrong code with -mavx512bw and __builtin_shuffle()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94509
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:d51af82b4cf4c95c4a7451df2180cc6ebb44856b
commit r10-7586-gd51af82b4cf4c95c4a7451df2180cc6ebb44856b
Author: Jakub Jelinek
Date: Tue Apr 7 14:39:24 2020 +0200
i386: Fix V{64QI,32HI}mode constant permutations [PR94509]
The following testcases are miscompiled, because expand_vec_perm_pshufb
incorrectly thinks it can use vpshufb instruction for the permutations
when it can't.
The
if (vmode == V32QImode)
{
/* vpshufb only works intra lanes, it is not
possible to shuffle bytes in between the lanes. */
for (i = 0; i < nelt; ++i)
if ((d->perm[i] ^ i) & (nelt / 2))
return false;
}
intra-lane check which is correct has been copied and adjusted for 64-byte
modes into:
if (vmode == V64QImode)
{
/* vpshufb only works intra lanes, it is not
possible to shuffle bytes in between the lanes. */
for (i = 0; i < nelt; ++i)
if ((d->perm[i] ^ i) & (nelt / 4))
return false;
}
which is not correct, because 64-byte modes have 4 lanes rather than just
two and the above is only testing that the permutation grabs even lane elts
from even lanes and odd lane elts from odd lanes, but not that they are
from the same 256-bit half.
The following patch fixes it by using 3 * nelt / 4 instead of nelt / 4,
so we actually check the most significant 2 bits rather than just one.
2020-04-07 Jakub Jelinek
PR target/94509
* config/i386/i386-expand.c (expand_vec_perm_pshufb): Fix the check
for inter-lane permutation for 64-byte modes.
* gcc.target/i386/avx512bw-pr94509-1.c: New test.
* gcc.target/i386/avx512bw-pr94509-2.c: New test.
[Bug rtl-optimization/94516] [10 Regression] gnutls test ./psk-file fails since r10-7515-g2c0fa3ecf70d199af18785702e9e0548fd3ab793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94516
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2020-04-07
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #3 from Jakub Jelinek ---
The problem is during postreload-gcse.c, which changed:
@@ -4749,23 +4758,7 @@ Dataflow summary:
(expr_list:SI (use (reg:SI 36 r8))
(expr_list:SI (use (reg:SI 37 r9))
(nil
-(insn 22 21 24 2 (parallel [
-(set (reg/f:DI 7 sp)
-(plus:DI (reg/f:DI 7 sp)
-(const_int 32 [0x20])))
-(clobber (reg:CC 17 flags))
-]) "pr94516.c":6747:2 186 {*adddi_1}
- (expr_list:REG_ARGS_SIZE (const_int 0 [0])
-(nil)))
-(insn 24 22 25 2 (parallel [
-(set (reg/f:DI 7 sp)
-(plus:DI (reg/f:DI 7 sp)
-(const_int -8 [0xfff8])))
-(clobber (reg:CC 17 flags))
-]) "pr94516.c":6747:2 186 {*adddi_1}
- (expr_list:REG_ARGS_SIZE (const_int 8 [0x8])
-(nil)))
-(insn 25 24 26 2 (set (mem:SI (pre_modify:DI (reg/f:DI 7 sp)
+(insn 25 21 26 2 (set (mem:SI (pre_modify:DI (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int -8 [0xfff8]))) [3 S4 A32])
(const_int 0 [0])) "pr94516.c":6747:2 46 {*pushsi2_rex64}
...
@@ -4815,23 +4808,7 @@ Dataflow summary:
(expr_list:SI (use (reg:SI 36 r8))
(expr_list:SI (use (reg:SI 37 r9))
(nil
-(insn 35 34 37 2 (parallel [
-(set (reg/f:DI 7 sp)
-(plus:DI (reg/f:DI 7 sp)
-(const_int 32 [0x20])))
-(clobber (reg:CC 17 flags))
-]) "pr94516.c":6780:2 186 {*adddi_1}
- (expr_list:REG_ARGS_SIZE (const_int 0 [0])
-(nil)))
-(insn 37 35 38 2 (parallel [
-(set (reg/f:DI 7 sp)
-(plus:DI (reg/f:DI 7 sp)
-(const_int -8 [0xfff8])))
-(clobber (reg:CC 17 flags))
-]) "pr94516.c":6780:2 186 {*adddi_1}
- (expr_list:REG_ARGS_SIZE (const_int 8 [0x8])
-(nil)))
-(insn 38 37 39 2 (set (mem:SI (pre_modify:DI (reg/f:DI 7 sp)
+(insn 38 34 39 2 (set (mem:SI (pre_modify:DI (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int -8 [0xfff8]))) [3 S4 A32])
(const_int -32 [0xffe0])) "pr94516.c":6780:2 46
{*pushsi2_rex64}
...
@@ -4881,12 +4858,8 @@ Dataflow summary:
(expr_list:SI (use (reg:SI 36 r8))
(expr_list:SI (use (reg:SI 37 r9))
(nil
-(insn 48 47 51 2 (parallel [
-(set (reg/f:DI 7 sp)
-(plus:DI (reg/f:DI 7 sp)
-(const_int 32 [0x20])))
-(clobber (reg:CC 17 flags))
-]) "pr94516.c":6783:1 186 {*adddi_1}
+(insn 48 47 51 2 (set (reg/f:DI 7 sp)
+(reg/f:DI 40 r12 [84])) "pr94516.c":6783:1 66 {*movdi_internal}
(expr_list:REG_ARGS_SIZE (const_int 0 [0])
(nil)))
(insn 51 48 52 2 (parallel [
because cselib now provides the sp based equalities it didn't before.
I believe the final value of sp is correct, there is r12 = rsp assignment in
the prologue, but the problem is that by throwing away the intermediate sp
adjustments in the calls in between the stack is misaligned.
We have the csa pass for combining stack adjustments, perhaps postreload-gcse
should just refrain from adjusting the stack pointer adjustments?
[Bug rtl-optimization/94516] [10 Regression] gnutls test ./psk-file fails since r10-7515-g2c0fa3ecf70d199af18785702e9e0548fd3ab793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94516 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1
[Bug c++/90996] [8/9/10 Regression] ICE in gimplify_expr, at gimplify.c:13495
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90996
--- Comment #4 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:23f1f679141bbb4720ca195cb758605dc017b7fd
commit r10-7587-g23f1f679141bbb4720ca195cb758605dc017b7fd
Author: Patrick Palka
Date: Mon Apr 6 14:05:44 2020 -0400
c++: Fix usage of CONSTRUCTOR_PLACEHOLDER_BOUNDARY inside array
initializers [PR90996]
This PR reports that ever since the introduction of the
CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag, we are sometimes failing to resolve
PLACEHOLDER_EXPRs inside array initializers that refer to some inner
constructor. In the testcase in the PR, we have as the initializer for "S
c[];"
the following
{{.a=(int &) &_ZGR1c_, .b={*(&)->a}}}
where CONSTRUCTOR_PLACEHOLDER_BOUNDARY is set on the middle constructor.
When
calling replace_placeholders from store_init_value, we pass the entire
initializer to it, and as a result we fail to resolve the PLACEHOLDER_EXPR
within due to the CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag on the middle
constructor blocking replace_placeholders_r from reaching it.
To fix this, we could perhaps either call replace_placeholders in more
places,
or we could change where we set CONSTRUCTOR_PLACEHOLDER_BOUNDARY. This
patch
takes this latter approach -- when building up an array initializer, we now
bubble any CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag from the element
initializers
up to the array initializer so that the boundary doesn't later impede us
when we
call replace_placeholders from store_init_value.
Besides fixing the kind of code like in the testcase, this shouldn't cause
any
other differences in PLACEHOLDER_EXPR resolution because we don't create or
use
PLACEHOLDER_EXPRs of array type in the frontend, as far as I can tell.
gcc/cp/ChangeLog:
PR c++/90996
* tree.c (replace_placeholders): Look through all handled
components,
not just COMPONENT_REFs.
* typeck2.c (process_init_constructor_array): Propagate
CONSTRUCTOR_PLACEHOLDER_BOUNDARY up from each element initializer
to
the array initializer.
gcc/testsuite/ChangeLog:
PR c++/90996
* g++.dg/cpp1y/pr90996.C: New test.
[Bug c++/90996] [8/9 Regression] ICE in gimplify_expr, at gimplify.c:13495
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90996 Patrick Palka changed: What|Removed |Added Summary|[8/9/10 Regression] ICE in |[8/9 Regression] ICE in |gimplify_expr, at |gimplify_expr, at |gimplify.c:13495|gimplify.c:13495 --- Comment #5 from Patrick Palka --- Fixed for GCC 10 so far.
[Bug target/94479] NetBSD: internal compiler error: in recompute_tree_invariant_for_addr_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94479
--- Comment #6 from Thomas Klausner ---
I can most easily test 8.3.0. I adapted your patch:
--- gcc/gimplify.c.orig 2019-02-07 14:44:31.0 +
+++ gcc/gimplify.c
@@ -6074,7 +6074,10 @@ gimplify_addr_expr (tree *expr_p, gimple
an incomplete type. Re-build ADDR_EXPRs in canonical form
here. */
if (!types_compatible_p (TREE_TYPE (op0), TREE_TYPE (TREE_TYPE (expr
+ {
*expr_p = build_fold_addr_expr (op0);
+ STRIP_USELESS_TYPE_CONVERSION (*expr_p);
+ }
/* Make sure TREE_CONSTANT and TREE_SIDE_EFFECTS are set properly. */
recompute_tree_invariant_for_addr_expr (*expr_p);
but it still fails:
rebase.i: In function ‘e’:
rebase.i:7:23: warning: initialization of ‘char’ from ‘char *’ makes integer
from pointer without a cast [-Wint-conversion]
struct b f[] = {{}, "", f, a};
^~
rebase.i:7:23: note: (near initialization for ‘f[1].c’)
rebase.i:7:27: internal compiler error: in
recompute_tree_invariant_for_addr_expr, at tree.c:4487
struct b f[] = {{}, "", f, a};
^
0x12d5503 recompute_tree_invariant_for_addr_expr(tree_node*)
../../gcc-8.3.0/gcc/tree.c:4487
0x7d57be gimplify_addr_expr
../../gcc-8.3.0/gcc/gimplify.c:6083
0x7d57be gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-8.3.0/gcc/gimplify.c:11580
0x7dd9c8 gimplify_modify_expr
../../gcc-8.3.0/gcc/gimplify.c:5649
0x7d4c56 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-8.3.0/gcc/gimplify.c:11533
0x7d6f58 gimplify_stmt(tree_node**, gimple**)
../../gcc-8.3.0/gcc/gimplify.c:6689
0x7d70e6 gimplify_and_add(tree_node*, gimple**)
../../gcc-8.3.0/gcc/gimplify.c:441
0x7d70e6 gimplify_init_ctor_eval
../../gcc-8.3.0/gcc/gimplify.c:4602
0x7d6ff4 gimplify_init_ctor_eval
../../gcc-8.3.0/gcc/gimplify.c:4597
0x7da0fc gimplify_init_constructor
../../gcc-8.3.0/gcc/gimplify.c:4998
0x7daa72 gimplify_modify_expr_rhs
../../gcc-8.3.0/gcc/gimplify.c:5261
0x7dd941 gimplify_modify_expr_rhs
../../gcc-8.3.0/gcc/gimplify.c:5149
0x7dd941 gimplify_modify_expr
../../gcc-8.3.0/gcc/gimplify.c:5604
0x7d4c56 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-8.3.0/gcc/gimplify.c:11533
0x7d6f58 gimplify_stmt(tree_node**, gimple**)
../../gcc-8.3.0/gcc/gimplify.c:6689
0x7dca90 gimplify_and_add(tree_node*, gimple**)
../../gcc-8.3.0/gcc/gimplify.c:441
0x7dca90 gimplify_decl_expr
../../gcc-8.3.0/gcc/gimplify.c:1711
0x7d5512 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-8.3.0/gcc/gimplify.c:11730
0x7d6f58 gimplify_stmt(tree_node**, gimple**)
../../gcc-8.3.0/gcc/gimplify.c:6689
0x7d77fe gimplify_bind_expr
../../gcc-8.3.0/gcc/gimplify.c:1331
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/94517] New: incorrect use of enable_if compiles but should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94517
Bug ID: 94517
Summary: incorrect use of enable_if compiles but should not
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: soko.slav at yandex dot ru
Target Milestone: ---
Following code https://godbolt.org/z/Zfazdt
compiles with GCC
and does not compile (as expected) if the class becomes a template:
https://godbolt.org/z/2KRRin
It should not compile in the first case either because there is no template
parameter being deduced.
Sources:
#include
struct NoDefault
{
NoDefault() = delete;
};
// compiles while should not
struct X : public NoDefault
{
template
<
std::enable_if_t
<
std::is_default_constructible_v
<
NoDefault
>
>* = nullptr
> X() : NoDefault{}
{
}
};
template
struct Y : public NoDefault
{
template
<
std::enable_if_t
<
std::is_default_constructible_v
<
NoDefault
>
>* = nullptr
> Y() : NoDefault{}
{
}
};
// expectedly does not compile
template struct Y;
[Bug rtl-optimization/94516] [10 Regression] gnutls test ./psk-file fails since r10-7515-g2c0fa3ecf70d199af18785702e9e0548fd3ab793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94516
Jakub Jelinek changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
So, I see there actually two separate undesirable changes. One is that during
reload_cse_regs_1 because of the cselib.c changes it optimized 3 times:
-(insn 22 21 24 2 (parallel [
-(set (reg/f:DI 7 sp)
-(plus:DI (reg/f:DI 7 sp)
-(const_int 32 [0x20])))
-(clobber (reg:CC 17 flags))
-]) "pr94516.c":6747:2 186 {*adddi_1}
- (expr_list:REG_ARGS_SIZE (const_int 0 [0])
-(nil)))
+(insn 22 21 24 2 (parallel [
+(set (reg/f:DI 7 sp)
+(reg/f:DI 40 r12 [84]))
+]) "pr94516.c":6747:2 66 {*movdi_internal}
+ (expr_list:REG_ARGS_SIZE (const_int 0 [0])
+(nil)))
That in itself isn't a wrong-code change, the question is if it is actually
beneficial (maybe for -Os it could).
The second change happens in the reload_cse_move2add
/* Try to transform (set (REGX) (REGY))
(set (REGX) (PLUS (REGX) (CONST_INT A)))
...
(set (REGX) (REGY))
(set (REGX) (PLUS (REGX) (CONST_INT B)))
to
(set (REGX) (REGY))
(set (REGX) (PLUS (REGX) (CONST_INT A)))
...
(set (REGX) (plus (REGX) (CONST_INT B-A)))
*/
transformation, where REGX is sp and REGY is this r12 register that happens to
contain a copy of rsp with REG_ARGS_SIZE of 0 and this one is the wrong-code
one, because it ignores the fact that REGX is used in various other
instructions in between.
[Bug debug/94469] lto abstract variable emitted as concrete decl (ada test-case)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94469
--- Comment #13 from Tom de Vries ---
(In reply to rguent...@suse.de from comment #12)
> > Ack, I've managed to reproduce this using a dwarf assembly test-case (PR
> > gdb/25796 - "Symbol with inherited DW_AT_const_value not found" @
> > https://sourceware.org/bugzilla/show_bug.cgi?id=25796), and submitted a gdb
> > patch for this.
>
> Note compared to your gdb bug the case above does not have a
> reference to 'i' from the "real" DW_TAG_compile_unit.
Ah, sorry, I've misread that, thanks for pointing that out. For that case, I
think gdb behaves as expected.
That is, my mental model is:
- a PU represents a dwarf repository
- a CU represents a symtab (as well as a dwarf repository)
- an import imports dwarf from one dwarf repository into another
- an inter-cu ref does not represent an implicit import
So, if we have only i declared in a PU, and the PU is not imported, there's no
symtab with an 'i', and gdb can't find it.
If you want a symtab with an 'i', you have to add a DW_TAG_variable DIE to a
CU, with DW_AT_abstract_origin referencing the DIE in the PU (as my dwarf
assembly test-case does).
> A an extreme dwarf
> testcase would probably contain a partial unit with the optimized
> out variable and a main unit with just a 'main' and no reference to
> the partial unit at all.
>
In my interpretation as decribed above, that boils down to the same: no symbol
'i' declared in any symtab.
> > Note that the problem is specific to gdb's partial symbol tables feature, so
> > that problem doesn't occur when using -readnow.
>
> > > I understand that if I would again add imports this would likely be
> > > resolved
> > > but at the expense of re-creating the original issue (but just with two
> > > instances rather than three)?
> >
> > Agreed.
>
> OK. So I understand the DWARF standard doesn't really say how consumers
> should work but how do partial vs. full units differ as to "name lookup"?
> I've originally placed imports of original units where I instantiated
> something from that original unit so to make things "visible" at that
> point (as in, all global statics are visible by name lookup). But of
> course consumers do not really follow name lookup rules since I
> can perfectly well lookup 'i' from 'foo' for
>
> void foo() {}
> int i;
>
> where it is obviously not visible (but consumers do need to do
> something resembling name lookup when interpreting user expressions
> written in the source language).
I hope I managed to explained above how I see the difference.
---
It's perhaps good to follow-up at this point to the discussion related to
DW_AT_declaration (see PR94450 comment 5).
As mentioned in comment 8, I've created a minimal dwarf assembler variant
corresponding to the C test-case (with only var aaa), and I could reproduce the
problem. Then by tagging the abstract DIE with DW_AT_declaration, I managed to
fix the problem of "info variables" listing the variable twice. But well, the
fact that we keep decl in symtabs for gdb comes with a number of known issues
(which are tracked here:
https://sourceware.org/bugzilla/show_bug.cgi?id=25755).
In particular, there's PR24985 - "Cannot print value of global variable because
decl in one CU shadows def in other CU", and I was thinking we might run into
that for VLAs when we start using DW_AT_declaration.
So, I was hoping to avoid those issue by using PUs, but it seems also that
comes with its own set of issues in gdb :)
[Bug debug/94469] lto abstract variable emitted as concrete decl (ada test-case)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94469 --- Comment #14 from Richard Biener --- OK, so I think your interpretation of PUs and CUs and using PUs for the early DWARF and CUs for the late DWARF fits the LTO model "good enough" with the caveat of losing info about things that are not in any way referenced by the late CUs. Note what the LTO DWARF currently represents is a) early CUs represent the source at parsing time (thus no locations) b) late CUs represent generated code and data of the early CUs with caveats: 1) not all early objects get instantiated 2) there's not a simple correspondence between early and late CUs but a late CU instantiates selected items from multiple early CUs and there are multiple late CUs doing that I have patches to mitigate b) 2) a bit making it a 1:N correspondence, that is, there are N late CUs instantiating objects from a single early CU (with the exception of inline instances). Not sure if that helps mapping LTO reality to DWARF terms. So the early and late CUs together represent the program and the late CU merely provides additional information. For functions the mental model of abstract instances in the early CUs plus inline and concrete instances in the late CUs works quite well since there's nothing (yet) a consumer can do with an abstract instance that isn't instantiated in any way (well - it could say 'it is there but optimized out', sth we lose with the PU apporach as well). For global variables it works as long as we annotate it (with the symbol for example). For optimized out variables with a constant value or for things like enumeral types members it breaks (I guess esp. that is worriesome). And to restate - with PUs but DW_TAG_imported_unit of the same PU in multiple places we don't win anything esp. since the instantiations via abstract origins remain. Using DW_AT_declaration for variables and CUs instead of PUs is IMHO the most promising approach then.
[Bug target/94518] New: [9 Regression] ICE: RTL check: expected code 'const_int', have 'reg' in output_3774, at config/aarch64/atomics.md:758
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94518
Bug ID: 94518
Summary: [9 Regression] ICE: RTL check: expected code
'const_int', have 'reg' in output_3774, at
config/aarch64/atomics.md:758
Product: gcc
Version: 9.3.1
Status: UNCONFIRMED
Keywords: ice-checking
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: aarch64-unknown-linux-gnu
Created attachment 48229
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48229&action=edit
reduced testcase
This looks like a recent regression on the 9-branch.
Compiler output:
$ $ /repo/build-gcc-9-branch-aarch64/./gcc/cc1plus tsan_interface_atomic.ii
void b()
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data>
Streaming LTO
Assembling functions:
void b()during RTL pass: final
tsan_interface_atomic.ii: In function 'void b()':
tsan_interface_atomic.ii:2:41: internal compiler error: RTL check: expected
code 'const_int', have 'reg' in output_3774, at config/aarch64/atomics.md:758
2 | void b() { __sync_fetch_and_xor(&a, c); }
| ^
0x776cd1 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
/repo/gcc-9-branch/gcc/rtl.c:888
0x9206f4 output_3774
/repo/gcc-9-branch/gcc/config/aarch64/atomics.md:758
0xdc764b final_scan_insn_1
/repo/gcc-9-branch/gcc/final.c:3040
0xdc7f7b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/repo/gcc-9-branch/gcc/final.c:3153
0xdc8267 final_1
/repo/gcc-9-branch/gcc/final.c:2021
0xdc90c6 rest_of_handle_final
/repo/gcc-9-branch/gcc/final.c:4659
0xdc90c6 execute
/repo/gcc-9-branch/gcc/final.c:4737
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug rtl-optimization/94516] [10 Regression] gnutls test ./psk-file fails since r10-7515-g2c0fa3ecf70d199af18785702e9e0548fd3ab793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94516 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 48230 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48230&action=edit gcc10-pr94516.patch Untested flag to fix the wrong-code issue. The problem was that move2add_note_store didn't handle PRE_MODIFY and POST_MODIFY, but it also seemed misplaced to me, because autoinc doesn't have to appear in a MEM that is stored into, could be also in a MEM that is read from (pop). This doesn't disable the sp += 32; sp -= 8; to sp = r12; sp -= 8; transformation which correct from correctness POV, but actually isn't really beneficial even from size POV, because the csa pass later on optimizes sp += 32; sp -= 8; into sp += 24;, but the latter can't be optimized that way.
[Bug target/94479] NetBSD: internal compiler error: in recompute_tree_invariant_for_addr_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94479 --- Comment #7 from Richard Biener --- OK, built a cross to x86_64-netbsd and I see we go from Breakpoint 8, gimplify_addr_expr (expr_p=0x76cdec28, pre_p=0x7fffd8b0, post_p=0x7fffcc40) at /space/rguenther/src/gcc/gcc/gimplify.c:6171 6171 ret = gimplify_expr (&TREE_OPERAND (expr, 0), pre_p, post_p, (gdb) p debug_tree (expr) BLK align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x76ce2e70 pointer_to_this > unsigned DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x76ce23f0> arg:0 sizes-gimplified BLK size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x76ce2498 domain pointer_to_this > addressable used read BLK t.c:7:14 size unit-size align:64 warn_if_not_align:0 context value-expr nothrow arg:0 >> t.c:7:29 start: t.c:7:29 finish: t.c:7:29> to 6178 prepare_gimple_addressable (&TREE_OPERAND (expr, 0), pre_p); (gdb) p debug_tree (expr) BLK align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x76ce2e70 pointer_to_this > unsigned DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x76ce23f0> arg:0 sizes-gimplified BLK size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x76ce2498 domain pointer_to_this > nothrow arg:0 used unsigned DI t.c:7:14 size unit-size align:64 warn_if_not_align:0 context > arg:1 t.c:7:29 start: t.c:7:29 finish: t.c:7:29> t.c:7:29 start: t.c:7:29 finish: t.c:7:29> via the DECL_VALUE_EXPR of 'f'. Now we're basically the do_indirect_ref case but via MEM_REF but we're only checking for INDIRECT_REF here. The following fixes the cross compilation for me: diff --git a/gcc/gimplify.c b/gcc/gimplify.c index 787435c38cd..8cdfae26510 100644 --- a/gcc/gimplify.c +++ b/gcc/gimplify.c @@ -6181,7 +6181,9 @@ gimplify_addr_expr (tree *expr_p, gimple_seq *pre_p, gimple_seq *post_p) /* For various reasons, the gimplification of the expression may have made a new INDIRECT_REF. */ - if (TREE_CODE (op0) == INDIRECT_REF) + if (TREE_CODE (op0) == INDIRECT_REF + || (TREE_CODE (op0) == MEM_REF + && integer_zerop (TREE_OPERAND (op0, 1 goto do_indirect_ref; mark_addressable (TREE_OPERAND (expr, 0));
[Bug target/94519] New: PPC: ICE: Segmentation fault on -DBL_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94519
Bug ID: 94519
Summary: PPC: ICE: Segmentation fault on -DBL_MAX
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.seifert at de dot ibm.com
Target Milestone: ---
Input:
#include
static const double dsmall[] = { -DBL_MAX };
gcc ccerr.C
ccerr.C:3:1: internal compiler error: Segmentation fault
static const double dsmall[] = { -DBL_MAX };
^~
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Preprocessed source stored into /tmp/cc3rsmv0.out file, please attach this to
your bugreport.
[Bug rtl-optimization/94516] [10 Regression] gnutls test ./psk-file fails since r10-7515-g2c0fa3ecf70d199af18785702e9e0548fd3ab793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94516 --- Comment #6 from Martin Liška --- (In reply to Jakub Jelinek from comment #5) > Created attachment 48230 [details] > gcc10-pr94516.patch > I can confirm the patch fixes the gnutls. Would you be able to come up with a test-case?
[Bug rtl-optimization/94516] [10 Regression] gnutls test ./psk-file fails since r10-7515-g2c0fa3ecf70d199af18785702e9e0548fd3ab793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94516 Jakub Jelinek changed: What|Removed |Added Attachment #48230|0 |1 is obsolete|| --- Comment #7 from Jakub Jelinek --- Created attachment 48231 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48231&action=edit gcc10-pr94516.patch Sure, here it is with a testcase.
[Bug target/94519] PPC: ICE: Segmentation fault on -DBL_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94519 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 94297 ***
[Bug target/94297] PPCLE std::replace internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94297 --- Comment #6 from Andrew Pinski --- *** Bug 94519 has been marked as a duplicate of this bug. ***
[Bug c++/94507] [8/9/10 Regression] internal compiler error: tree check: expected template_decl, have error_mark in tsubst_lambda_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94507 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Keywords||patch --- Comment #3 from Marek Polacek --- I posted a patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543391.html
[Bug target/94519] PPC: ICE: Segmentation fault on -DBL_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94519 Jens Seifert changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #2 from Jens Seifert --- Environmental issue. gcc was compiled with GMP 6.0.0 support but is picking up a GMP 5.0.1
[Bug target/94518] [9 Regression] ICE: RTL check: expected code 'const_int', have 'reg' in output_3774, at config/aarch64/atomics.md:758
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94518 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.4
[Bug rtl-optimization/94516] [10 Regression] gnutls test ./psk-file fails since r10-7515-g2c0fa3ecf70d199af18785702e9e0548fd3ab793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94516 --- Comment #8 from Martin Liška --- (In reply to Jakub Jelinek from comment #7) > Created attachment 48231 [details] > gcc10-pr94516.patch > > Sure, here it is with a testcase. Great job!
[Bug target/94504] On powerpc, -ffunction-sections -fdata-sections is not as effective as expected for PIE executables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94504 --- Comment #3 from Michael Karcher --- (In reply to Richard Biener from comment #2) > Huh, looking at the assembly & the object file this seems to be fully a linker > issue who seems to be responsible for building the GOT. I suggest to move > this over to sourceware. Alan? I'm not so sure about this. I think it might actually be a limitation of ELF on ppc32: If I compare the code generated by gcc on ppc32, gcc does output a GOT fragment in the .got2 section that references all globals that are used in the current object: $ objdump -r -j .got2 bla32.o bla32.o: file format elf32-powerpc RELOCATION RECORDS FOR [.got2]: OFFSET TYPE VALUE R_PPC_ADDR32 fptr 0004 R_PPC_ADDR32 x This section can not be elided, because it is referenced from main: $ objdump -r -j .text.main bla32.o bla32.o: file format elf32-powerpc RELOCATION RECORDS FOR [.text.main]: OFFSET TYPE VALUE 0022 R_PPC_REL16_HA.got2+0x8006 0026 R_PPC_REL16_LO.got2+0x800a The linker has no obvious way to detect which GOT slots are actually used inside main, because the offset(s) of the slot(s) inside .got2 used by main are hardcoded inside main. On the other hand, on ppc64, there is no GOT fragment generated by the compiler, but instead the compiler just asks the linker to create a GOT slot and fill in the necessary information: $ objdump -r -j .text.main bla64.o bla64.o: file format elf64-powerpc RELOCATION RECORDS FOR [.text.main]: OFFSET TYPE VALUE 000e R_PPC64_TOC16_HA x 0012 R_PPC64_TOC16_LO x
[Bug rtl-optimization/94516] [10 Regression] gnutls test ./psk-file fails since r10-7515-g2c0fa3ecf70d199af18785702e9e0548fd3ab793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94516 --- Comment #9 from Jakub Jelinek --- For the optimization issue, we could have a hack like: --- gcc/postreload.c.jj 2020-04-07 16:54:23.638924247 +0200 +++ gcc/postreload.c2020-04-07 17:06:44.055964581 +0200 @@ -328,6 +328,17 @@ reload_cse_simplify_set (rtx set, rtx_in else continue; + /* Prefer stack pointer adjustment over copies from a register +that happens to hold the right value already (unless it is +much higher cost), because in the sp += const case the +pass_stack_adjustments pass can merge it with other stack +adjustments. */ + if (SET_DEST (set) == stack_pointer_rtx + && GET_CODE (SET_SRC (set)) == PLUS + && XEXP (SET_SRC (set), 0) == stack_pointer_rtx + && CONST_INT_P (XEXP (SET_SRC (set), 1))) + this_cost *= 4; + /* If equal costs, prefer registers over anything else. That tends to lead to smaller instructions on some machines. */ if (this_cost < old_cost Dunno... :( Or do such a change only if there are no following sp adjustments that could be combined with it (e.g. remember we've done such a change, and when we process next stack pointer adjustment with no sp uses in between or what exactly csa does, and don't manage to optimize that one into sp = reg, try to undo the previous change.
[Bug target/94518] [9 Regression] ICE: RTL check: expected code 'const_int', have 'reg' in output_3774, at config/aarch64/atomics.md:758
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94518 ktkachov at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2020-04-07 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||ktkachov at gcc dot gnu.org --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed. Looks like a missing backport of: http://gcc.gnu.org/g:3a30d2558b3a199fe346479e6140cddae7fba5ed
[Bug debug/94469] lto abstract variable emitted as concrete decl (ada test-case)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94469 --- Comment #15 from Tom de Vries --- (In reply to Tom de Vries from comment #8) > > So while I intended to have the early CUs behave like fully abstract > > the actual DWARF is different. I understand that if I emit the early CU as > > partial unit it becomes abstract? > > Well, that's my theory. > > I've created a minimal dwarf assembler variant corresponding to the C > test-case (with only var aaa), and I could reproduce the problem, however > after changing the tag to DW_TAG_partial_unit still a symbol table for that > partial unit was created. It seems that the inter-cu ref handling code is > responsible for that. I'll try to fix this. > Filed PR gdb/25798 - "symbol in non-imported PU should not appear in symtabs.
[Bug libstdc++/94520] [10 Regression] no longer compiles in C++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94520 Jonathan Wakely changed: What|Removed |Added Known to fail||10.0 Ever confirmed|0 |1 Known to work||9.3.0 Target Milestone|--- |10.0 Last reconfirmed||2020-04-07 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED
[Bug libstdc++/94520] New: [10 Regression] no longer compiles in C++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94520
Bug ID: 94520
Summary: [10 Regression] no longer compiles in C++14
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
This is supposed to be supported in C++14 as an extension:
#include
int main() { }
But since r272695 it no longer works:
/home/jwakely/gcc/10/include/c++/10.0.1/charconv:71:21: error: '__or_v' was not
declared in this scope; did you mean '__or_'?
71 | = enable_if_t<__or_v<__is_signed_integer<_Tp>,
| ^~
| __or_
[Bug debug/94469] lto abstract variable emitted as concrete decl (ada test-case)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94469 --- Comment #16 from Tom de Vries --- (In reply to Richard Biener from comment #14) > Using DW_AT_declaration for variables and CUs instead of PUs is IMHO the > most promising approach then. I managed to reproduce the "Multiple matches" problem by switching the language for the dwarf assembly test-case to ada (and using -readnow). And adding the DW_AT_declaration at the concrete DIE fixed that problem. So yeah, that looks promising.
[Bug bootstrap/93398] PGO bootstrap is not reproducible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93398 Martin Liška changed: What|Removed |Added Resolution|WORKSFORME |--- Status|RESOLVED|REOPENED --- Comment #10 from Martin Liška --- It's so easy to end up with a different binary for GCC: @@ -174,7 +174,7 @@ .//objdir/gcc/c/c-decl.gcda:01ab: 0:COUNTERS average 0 counts .//objdir/gcc/c/c-decl.gcda:01ad: 0:COUNTERS ior 0 counts .//objdir/gcc/c/c-decl.gcda:01af: 2:COUNTERS time_profiler 1 counts -.//objdir/gcc/c/c-decl.gcda: 0: 2419 +.//objdir/gcc/c/c-decl.gcda: 0: 2420 .//objdir/gcc/c/c-decl.gcda: 0100: 3:FUNCTION ident=1446792123, lineno_checksum=0x069e6627, cfg_checksum=0x4c361918 .//objdir/gcc/c/c-decl.gcda:01a1: 28:COUNTERS arcs 14 counts .//objdir/gcc/c/c-decl.gcda: 0: 29954 2 2 28793 0 0 873 0 @@ -184,7 +184,7 @@ .//objdir/gcc/c/c-decl.gcda:01ab: 0:COUNTERS average 0 counts .//objdir/gcc/c/c-decl.gcda:01ad: 0:COUNTERS ior 0 counts .//objdir/gcc/c/c-decl.gcda:01af: 2:COUNTERS time_profiler 1 counts -.//objdir/gcc/c/c-decl.gcda: 0: 2421 +.//objdir/gcc/c/c-decl.gcda: 0: 2422 .//objdir/gcc/c/c-decl.gcda: 0100: 3:FUNCTION ident=1033776594, lineno_checksum=0x0314bcea, cfg_checksum=0xa707611a .//objdir/gcc/c/c-decl.gcda:01a1: 16:COUNTERS arcs 8 counts .//objdir/gcc/c/c-decl.gcda: 0: 50 16 0 50 0 50 0 0 So a slightly different tp_first_run can cause different function order: $ objfolderdiff.py /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-reproducible/base/objdir/gcc/ /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-reproducible/next/objdir/gcc/ -d 103/ 624: c/c-decl.o: different --- /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-reproducible/base/objdir/gcc/c/c-decl.o.s.txt 2020-04-07 17:43:18.280993473 +0200 +++ /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-reproducible/next/objdir/gcc/c/c-decl.o.s.txt 2020-04-07 17:43:18.280993473 +0200 @@ -34570,15 +34570,6 @@ 36: 89 f8 mov%edi,%eax 38: c3 retq -Disassembly of section .text._Z17ggc_cleared_allocI9lang_typeEPT_v: - - <_Z17ggc_cleared_allocI9lang_typeEPT_v>: - 0: b9 01 00 00 00 mov$0x1,%ecx - 5: 31 d2 xor%edx,%edx - 7: 31 f6 xor%esi,%esi - 9: bf 20 00 00 00 mov$0x20,%edi - e: e9 00 00 00 00 jmpq 13 - Disassembly of section .text.hot._Z15hash_table_mod2jj: <_Z15hash_table_mod2jj>: @@ -34618,6 +34609,15 @@ } 3c: c3 retq +Disassembly of section .text._Z17ggc_cleared_allocI9lang_typeEPT_v: + + <_Z17ggc_cleared_allocI9lang_typeEPT_v>: + 0: b9 01 00 00 00 mov$0x1,%ecx + 5: 31 d2 xor%edx,%edx + 7: 31 f6 xor%esi,%esi + 9: bf 20 00 00 00 mov$0x20,%edi + e: e9 00 00 00 00 jmpq 13 + Disassembly of section .text.hot._ZN2wi5neg_pI16generic_wide_intI20wide_int_ref_storageILb1ELb0EbRKT_6signop: <_ZN2wi5neg_pI16generic_wide_intI20wide_int_ref_storageILb1ELb0EbRKT_6signop>:
[Bug c++/94521] New: Infinite loop with decltype of function parameter of type decltype([]{})
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94521
Bug ID: 94521
Summary: Infinite loop with decltype of function parameter of
type decltype([]{})
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
$ cat testcase.C
template
void spam(decltype([]{}) *s)
{
static_assert(__is_same(int, decltype(s)));
}
void foo()
{
spam(nullptr);
}
$ g++ -std=c++2a testcase.C
^C
[Bug c++/94480] [10 Regression] ICE in cp_parser_abort_tentative_parse, at cp/parser.c:31858
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94480 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/94521] Infinite loop with decltype of function parameter of type decltype([]{})
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94521 Marek Polacek changed: What|Removed |Added Last reconfirmed||2020-04-07 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Confirmed. Looks like it never worked.
[Bug c/94522] New: Enhancement request: asm goto with outputs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94522
Bug ID: 94522
Summary: Enhancement request: asm goto with outputs
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bp at alien8 dot de
Target Milestone: ---
Hi all,
this came up recently on the kernel ML (see
https://lkml.kernel.org/r/20200402134051.gc9...@zn.tnic) and we thought it
might be a good idea to support it. In the same "fallthrough" fashion like
clang:
https://reviews.llvm.org/rG50cac248773
Micha (CCed) says that it should be relatively easy to do that in gcc too so in
case someone feels bored in the future... :)
Some other useful scenarios, courtesy of Linus, would be exception handling, to
avoid register pressure and in the alternatives patching we do in the kernel.
And in general, an output value from the asm goto("") in the fallthrough case
might come in handy.
Thx.
[Bug c++/94510] [9/10 Regression] nullptr_t implicitly cast to zero twice in std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94510
Martin Sebor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #9 from Martin Sebor ---
The changed code in reshape_init_array_1 checks for integer/pointer mismatches
via the following test:
/* Pointers initialized to strings must be treated as non-zero
even if the string is empty. */
tree init_type = TREE_TYPE (elt_init);
if (POINTER_TYPE_P (elt_type) != POINTER_TYPE_P (init_type)
|| !type_initializer_zero_p (elt_type, elt_init))
last_nonzero = index;
...and a test case involving an ordinary pointer is diagnosed:
$ cat t.C && gcc -S -Wall t.C
int a[2] = { nullptr };
int b[2] = { (void*)0 };
t.C:2:23: error: invalid conversion from ‘void*’ to ‘int’ [-fpermissive]
2 | int b[2] = { (void*)0 };
| ^
| |
| void*
but a nullptr use is not.
(gdb) p debug_tree (init_type)
$6 = (tree) 0x7fffea9521f8
constant 64>
unit-size constant 8>
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea9521f8>
I would expect POINTER_TYPE_P (init_type) to be non-zero but it's not:
(gdb) p POINTER_TYPE_P (init_type)
$7 = false
[Bug d/94240] [D] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:215
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94240 --- Comment #2 from CVS Commits --- The releases/gcc-9 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:e926d076f28a91f3ea30bd0bcfa1f25958fdb59e commit r9-8460-ge926d076f28a91f3ea30bd0bcfa1f25958fdb59e Author: Iain Buclaw Date: Tue Apr 7 18:02:47 2020 +0200 d: Fix ICE in add_symbol_to_partition_1, at lto/lto-partition.c:215 This patch addresses two problems with TypeInfo initializer generation. 1. D array fields pointing to compiler generated data are referencing public symbols with no unique prefix, which can lead to duplicate definition errors in some hard to reduce cases. To avoid name clashes, all symbols that are generated for TypeInfo initializers now use the assembler name of the TypeInfo decl as a prefix. 2. An ICE would occur during LTO pass because these same decls are considered to be part of the same comdat group as the TypeInfo decl that it's referred by, despite itself being neither marked public nor comdat. This resulted in decls being added to the LTRANS partition out of order, triggering an assert when add_symbol_to_partition_1 attempted to add them again. To remedy, TREE_PUBLIC and DECL_COMDAT are now set on all generated symbols. gcc/d/ChangeLog: PR d/94240 * typeinfo.cc (class TypeInfoVisitor): Replace type_ field with decl_. (TypeInfoVisitor::TypeInfoVisitor): Set decl_. (TypeInfoVisitor::result): Update. (TypeInfoVisitor::internal_reference): New function. (TypeInfoVisitor::layout_string): Use internal_reference. (TypeInfoVisitor::visit (TypeInfoTupleDeclaration *)): Likewise. (layout_typeinfo): Construct TypeInfoVisitor with typeinfo decl. (layout_classinfo): Likewise.
[Bug libstdc++/94520] [10 Regression] no longer compiles in C++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94520 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c104e8f1b67a75ea82c62f1fd2aac69c09127562 commit r10-7601-gc104e8f1b67a75ea82c62f1fd2aac69c09127562 Author: Jonathan Wakely Date: Tue Apr 7 17:18:21 2020 +0100 libstdc++: Restore ability to use in C++14 (PR 94520) This C++17 header is supported in C++14 as a GNU extension, but stopped working last year because I made it depend on an internal helper which is only defined for C++17 and up. PR libstdc++/94520 * include/std/charconv (__integer_to_chars_result_type) (__integer_from_chars_result_type): Use __or_ instead of __or_v_ to allow use in C++14. * testsuite/20_util/from_chars/1.cc: Run test as C++14 and replace use of std::string_view with std::string. * testsuite/20_util/from_chars/2.cc: Likewise. * testsuite/20_util/to_chars/1.cc: Likewise. * testsuite/20_util/to_chars/2.cc: Likewise.
[Bug d/94240] [D] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:215
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94240 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Iain Buclaw --- Applied to releases/gcc-9
[Bug d/94425] [D] Consider always settings ASM_VOLATILE_P on asm statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94425 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Iain Buclaw --- Done.
[Bug libstdc++/94520] [10 Regression] no longer compiles in C++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94520 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Jonathan Wakely --- Fixed.
[Bug target/61837] missed loop invariant expression optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61837 --- Comment #4 from Segher Boessenkool --- If the ble 7,.L7 is taken once, it will be taken all of the time, since cr7 isn't assigned to any more -- and then the whole loop does nothing.
[Bug c++/94478] [10 Regression] ICE in comptypes, at cp/typeck.c:1486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94478 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org CC||mpolacek at gcc dot gnu.org
[Bug target/94488] [AArch64] ICE on right shift of V2DImode by DImode shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94488
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:2daa92ac4b51387e55e88ee48bdc2fab7ba25981
commit r10-7602-g2daa92ac4b51387e55e88ee48bdc2fab7ba25981
Author: Jakub Jelinek
Date: Tue Apr 7 19:04:31 2020 +0200
aarch64: Fix {ash[lr],lshr}3 expanders [PR94488]
The following testcase ICEs on aarch64 apparently since the introduction of
the aarch64 port. The reason is that the {ashl,ashr,lshr}3 expanders
completely unnecessarily FAIL; if operands[2] is something other than
a CONST_INT or REG or MEM and the middle-end code can't cope with the
pattern giving up in these cases. All the expanders use general_operand
predicate for the shift amount operand, but then have just a special case
for CONST_INT (if in-bound, emit an immediate shift, otherwise force into
REG), or MEM (force into REG), or REG (that is the case it handles).
In the testcase, operands[2] is a lowpart SUBREG of a REG, which is valid
general_operand.
I don't see any reason what is magic about MEMs that it should be forced
into REG and others like SUBREGs that it shouldn't, there isn't even a
reason to check for !REG_P because force_reg will do nothing if the operand
is already a REG, and otherwise can handle general_operand just fine.
2020-04-07 Jakub Jelinek
PR target/94488
* config/aarch64/aarch64-simd.md (ashl3, lshr3,
ashr3): Force operands[2] into reg whenever it is not
CONST_INT.
Assume it is a REG after that instead of testing it and doing FAIL
otherwise. Formatting fix.
* gcc.c-torture/compile/pr94488.c: New test.
[Bug target/94297] PPCLE std::replace internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94297 Jens Seifert changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jens Seifert --- Too old libgmp got picked up. Setting LD_LIBRARY_PATH=/lib64 solved the issue.
[Bug target/94518] [9 Regression] ICE: RTL check: expected code 'const_int', have 'reg' in output_3774, at config/aarch64/atomics.md:758
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94518 --- Comment #2 from CVS Commits --- The releases/gcc-9 branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:470626394ab7779cb663258048da821a502a1e82 commit r9-8461-g470626394ab7779cb663258048da821a502a1e82 Author: Kyrylo Tkachov Date: Tue Apr 7 18:10:02 2020 +0100 [AArch64] PR target/94518: Fix memmodel index in aarch64_store_exclusive_pair 2020-04-07 Kyrylo Tkachov PR target/94518 2019-09-23 Richard Sandiford * config/aarch64/atomics.md (aarch64_store_exclusive_pair): Fix memmodel index.
[Bug target/94518] [9 Regression] ICE: RTL check: expected code 'const_int', have 'reg' in output_3774, at config/aarch64/atomics.md:758
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94518 ktkachov at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from ktkachov at gcc dot gnu.org --- Should be fixed now on the branch
[Bug target/94297] PPCLE std::replace internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94297 --- Comment #8 from Jens Seifert --- Too old libgmp got picked up. Setting LD_LIBRARY_PATH=/lib64 solved the issue.
[Bug target/94297] PPCLE std::replace internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94297 Jens Seifert changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #9 from Jens Seifert --- Too old libgmp got picked up. Setting LD_LIBRARY_PATH=/lib64 solved the issue.
[Bug target/94504] On powerpc, -ffunction-sections -fdata-sections is not as effective as expected for PIE executables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94504 --- Comment #4 from rguenther at suse dot de --- On April 7, 2020 5:09:02 PM GMT+02:00, "gcc-bugzilla at mkarcher dot dialup.fu-berlin.de" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94504 > >--- Comment #3 from Michael Karcher dialup.fu-berlin.de> --- >(In reply to Richard Biener from comment #2) >> Huh, looking at the assembly & the object file this seems to be fully >a linker >> issue who seems to be responsible for building the GOT. I suggest to >move >> this over to sourceware. Alan? > >I'm not so sure about this. I think it might actually be a limitation >of ELF on >ppc32: > >If I compare the code generated by gcc on ppc32, gcc does output a GOT >fragment >in the .got2 section that references all globals that are used in the >current >object: > >$ objdump -r -j .got2 bla32.o > >bla32.o: file format elf32-powerpc > >RELOCATION RECORDS FOR [.got2]: >OFFSET TYPE VALUE > R_PPC_ADDR32 fptr >0004 R_PPC_ADDR32 x > >This section can not be elided, because it is referenced from main: > >$ objdump -r -j .text.main bla32.o > >bla32.o: file format elf32-powerpc > >RELOCATION RECORDS FOR [.text.main]: >OFFSET TYPE VALUE >0022 R_PPC_REL16_HA.got2+0x8006 >0026 R_PPC_REL16_LO.got2+0x800a > >The linker has no obvious way to detect which GOT slots are actually >used >inside main, because the offset(s) of the slot(s) inside .got2 used by >main are >hardcoded inside main. > >On the other hand, on ppc64, there is no GOT fragment generated by the >compiler, but instead the compiler just asks the linker to create a GOT >slot >and fill in the necessary information: > >$ objdump -r -j .text.main bla64.o > >bla64.o: file format elf64-powerpc > >RELOCATION RECORDS FOR [.text.main]: >OFFSET TYPE VALUE >000e R_PPC64_TOC16_HA x >0012 R_PPC64_TOC16_LO x Ah, I tried with -m32 and a cross to ppc64 which might end up using a different ABI
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #45 from CVS Commits ---
The master branch has been updated by Fritz Reese :
https://gcc.gnu.org/g:57391ddaf39f7cb85825c32e83feb1435889da51
commit r10-7603-g57391ddaf39f7cb85825c32e83feb1435889da51
Author: Fritz Reese
Date: Tue Apr 7 11:59:36 2020 -0400
Fix PR fortran/93871 and re-implement degree-valued trigonometric
intrinsics.
2020-04-01 Fritz Reese
Steven G. Kargl
gcc/fortran/ChangeLog
PR fortran/93871
* gfortran.h (GFC_ISYM_ACOSD, GFC_ISYM_ASIND, GFC_ISYM_ATAN2D,
GFC_ISYM_ATAND, GFC_ISYM_COSD, GFC_ISYM_COTAND, GFC_ISYM_SIND,
GFC_ISYM_TAND): New.
* intrinsic.c (add_functions): Remove check for flag_dec_math.
Give degree trig functions simplification and name resolution
functions (e.g, gfc_simplify_atrigd () and gfc_resolve_atrigd ()).
(do_simplify): Remove special casing of degree trig functions.
* intrinsic.h (gfc_simplify_acosd, gfc_simplify_asind,
gfc_simplify_atand, gfc_simplify_cosd, gfc_simplify_cotand,
gfc_simplify_sind, gfc_simplify_tand, gfc_resolve_trigd2): Add new
prototypes.
(gfc_simplify_atrigd, gfc_simplify_trigd, gfc_resolve_cotan,
resolve_atrigd): Remove prototypes of deleted functions.
* iresolve.c (is_trig_resolved, copy_replace_function_shallow,
gfc_resolve_cotan, get_radians, get_degrees, resolve_trig_call,
gfc_resolve_atrigd, gfc_resolve_atan2d): Delete functions.
(gfc_resolve_trigd, gfc_resolve_trigd2): Resolve to library
functions.
* simplify.c (rad2deg, deg2rad, gfc_simplify_acosd,
gfc_simplify_asind,
gfc_simplify_atand, gfc_simplify_atan2d, gfc_simplify_cosd,
gfc_simplify_sind, gfc_simplify_tand, gfc_simplify_cotand): New
functions.
(gfc_simplify_atan2): Fix error message.
(simplify_trig_call, gfc_simplify_trigd, gfc_simplify_atrigd,
radians_f): Delete functions.
* trans-intrinsic.c: Add LIB_FUNCTION decls for sind, cosd, tand.
(rad2deg, gfc_conv_intrinsic_atrigd, gfc_conv_intrinsic_cotan,
gfc_conv_intrinsic_cotand, gfc_conv_intrinsic_atan2d): New
functions.
(gfc_conv_intrinsic_function): Handle ACOSD, ASIND, ATAND, COTAN,
COTAND, ATAN2D.
* trigd_fe.inc: New file. Included by simplify.c to implement
simplify_sind, simplify_cosd, simplify_tand with code common to the
libgfortran implementation.
gcc/testsuite/ChangeLog
PR fortran/93871
* gfortran.dg/dec_math.f90: Extend coverage to real(10) and
real(16).
* gfortran.dg/dec_math_2.f90: New test.
* gfortran.dg/dec_math_3.f90: Likewise.
* gfortran.dg/dec_math_4.f90: Likewise.
* gfortran.dg/dec_math_5.f90: Likewise.
libgfortran/ChangeLog
PR fortran/93871
* Makefile.am, Makefile.in: New make rule for intrinsics/trigd.c.
* gfortran.map: New routines for {sind, cosd, tand}X{r4, r8, r10,
r16}.
* intrinsics/trigd.c, intrinsics/trigd_lib.inc,
intrinsics/trigd.inc:
New files. Defines native degree-valued trig functions.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 Fritz Reese changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #46 from Fritz Reese --- Fixed on trunk.
[Bug target/94479] NetBSD: internal compiler error: in recompute_tree_invariant_for_addr_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94479 Richard Biener changed: What|Removed |Added Known to work||10.0 --- Comment #9 from Richard Biener --- Fixed on trunk sofar.
[Bug target/94479] NetBSD: internal compiler error: in recompute_tree_invariant_for_addr_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94479 --- Comment #8 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:3d947f1f27188e3a61ba7f42399b1c348469fe13 commit r10-7604-g3d947f1f27188e3a61ba7f42399b1c348469fe13 Author: Richard Biener Date: Tue Apr 7 16:29:37 2020 +0200 middle-end/94479 - fix gimplification of address When gimplifying an address operand we may expose an indirect ref via DECL_VALUE_EXPR for example. This is dealt with in the code already but it fails to consider that INDIRECT_REFs get gimplified to MEM_REFs. Fixed which makes the ICE observed on x86_64-netbsd go away. 2020-04-07 Richard Biener PR middle-end/94479 * gimplify.c (gimplify_addr_expr): Also consider generated MEM_REFs. * gcc.dg/torture/pr94479.c: New testcase.
[Bug target/94297] PPCLE std::replace internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94297 Andreas Schwab changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug libgcc/94513] [10 Regression] go buildid and cgo tools require symbols in GLIBC_PRIVATE namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94513 --- Comment #4 from CVS Commits --- The master branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:50c7853216e8511971c55b51d7fe29173db4749b commit r10-7605-g50c7853216e8511971c55b51d7fe29173db4749b Author: Ian Lance Taylor Date: Tue Apr 7 11:29:41 2020 -0700 libgcc: use syscall rather than __mmap/__munmap PR libgcc/94513 * generic-morestack.c: Give up trying to use __mmap/__munmap, use syscall instead.
[Bug libgcc/94513] [10 Regression] go buildid and cgo tools require symbols in GLIBC_PRIVATE namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94513 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Ian Lance Taylor --- At least this specific problem should be fixed now. Perhaps there will be other problems, but they will be different. Sorry for the difficulties.
[Bug c++/94510] [9/10 Regression] nullptr_t implicitly cast to zero twice in std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94510
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #10 from Martin Sebor ---
POINTER_TYPE_P() is zero because while nullptr is specified to be "the pointer
literal is the keyword nullptr" it also "...is a prvalue of type
std::nullptr_t. [Note: std::nullptr_t is a distinct type that is neither a
pointer type nor a pointer-to-member type; ..." Of course -- a pointer literal
that doesn't have a pointer type, makes perfect sense.
Another closely related regression r270155 introduced is the missing warning
for the following test case:
$ cat t.C && gcc-8 -S -Wall t.C
#include
int a[2] = { NULL };
t.C:3:19: warning: converting to non-pointer type ‘int’ from NULL
[-Wconversion-null]
int a[2] = { NULL };
^
The patch at the link below restores both diagnostics:
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543482.html
[Bug c/94239] [10 regression] cc1 SEGV in get_location_from_adhoc_loc with gcc.dg/pr20245-1.c etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94239
--- Comment #10 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:f83c2d2991a762f729741a409a1ac7871733ee40
commit r9-8467-gf83c2d2991a762f729741a409a1ac7871733ee40
Author: Jakub Jelinek
Date: Mon Mar 23 19:44:58 2020 +0100
c: Fix up cfun->function_end_locus on invalid function bodies [PR94239]
Unfortunately the patch broke
+FAIL: gcc.dg/pr20245-1.c (internal compiler error)
+FAIL: gcc.dg/pr20245-1.c (test for excess errors)
+FAIL: gcc.dg/pr28419.c (internal compiler error)
+FAIL: gcc.dg/pr28419.c (test for excess errors)
on some targets (and under valgrind on the rest of them).
Those functions don't have the opening { and so c_parser_compound_statement
returned error_mark_node before initializing *endlocp.
So, either we can initialize it in that case too:
--- gcc/c/c-parser.c2020-03-20 22:09:39.659411721 +0100
+++ gcc/c/c-parser.c2020-03-21 09:36:44.455705261 +0100
@@ -5611,6 +5611,8 @@ c_parser_compound_statement (c_parser *p
if we have just prepared to enter a function body. */
stmt = c_begin_compound_stmt (true);
c_end_compound_stmt (brace_loc, stmt, true);
+ if (endlocp)
+ *endlocp = brace_loc;
return error_mark_node;
}
stmt = c_begin_compound_stmt (true);
or perhaps simpler initialize it to the function_start_locus at the
beginning and have those functions without { have function_start_locus ==
function_end_locus like the __GIMPLE functions (where propagating the
closing } seemed too difficult).
2020-03-23 Jakub Jelinek
PR gcov-profile/94029
PR c/94239
* c-parser.c (c_parser_declaration_or_fndef): Initialize endloc to
the function_start_locus location. Don't do that afterwards for
the
__GIMPLE body parsing.
[Bug c++/90995] [8/9 Regression] ICE in grokdeclarator, at cp/decl.c:12024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90995
--- Comment #9 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:980a7a0be5a114e285c49ab05ac70881e4f27fc3
commit r9-8462-g980a7a0be5a114e285c49ab05ac70881e4f27fc3
Author: Jakub Jelinek
Date: Tue Mar 17 21:21:16 2020 +0100
c++: Fix parsing of invalid enum specifiers [PR90995]
The testcase shows some accepts-invalid (the ones without alignas) and
ice-on-invalid-code (the ones with alignas) cases.
If the enum doesn't have an underlying type and is not a definition,
the caller retries to parse it as elaborated type specifier.
E.g. for enum struct S s it will then pedwarn that elaborated type
specifier
shouldn't have the struct/class keywords.
The problem is if the enum specifier is not followed by { when it has
underlying type. In that case we have already called
cp_parser_parse_definitely to end the tentative parsing started at the
beginning of cp_parser_enum_specifier. But the
cp_parser_error (parser, "expected %<;%> or %<{%>");
doesn't emit any error because the whole function is called from yet
another
tentative parse and the caller starts parsing the elaborated type
specifier where the cp_parser_enum_specifier stopped (i.e. after the
underlying type token(s)). The ultimate caller than commits the tentative
parsing (and even if it wouldn't, it wouldn't know what kind of error
to report). I think after seeing enum {,struct,class} : type not being
followed by { or ;, there is no reason not to report it right away, as it
can't be valid C++, which is what the patch does. Not sure if we shouldn't
also return error_mark_node instead of NULL_TREE, so that the caller
doesn't
try to parse it as elaborated type specifier (the patch doesn't do that
right now).
Furthermore, while reading the code, I've noticed that
parser->colon_corrects_to_scope_p is saved and set to false at the start
of the function, but not restored back in some cases. Don't have a
testcase
where this would be a problem, but it just seems wrong. Either we can in
the two spots replace return NULL_TREE; with { type = NULL_TREE; goto out;
}
or we could perhaps abuse warning_sentinel or create a special class with
dtor to clean the flag up.
And lastly, I've fixed some formatting issues in the function while reading
it.
2020-03-17 Jakub Jelinek
PR c++/90995
* parser.c (cp_parser_enum_specifier): Use temp_override for
parser->colon_corrects_to_scope_p, replace goto out with return.
If scoped enum or enum with underlying type is not followed by
{ or ;, call cp_parser_commit_to_tentative_parse before calling
cp_parser_error and make sure to return error_mark_node instead of
NULL_TREE. Formatting fixes.
* g++.dg/cpp0x/enum40.C: New test.
[Bug gcov-profile/94029] [9 Regression] gcc crash in coverage.c:655 since r9-4216-g390e529e2b98983d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94029
--- Comment #21 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:f83c2d2991a762f729741a409a1ac7871733ee40
commit r9-8467-gf83c2d2991a762f729741a409a1ac7871733ee40
Author: Jakub Jelinek
Date: Mon Mar 23 19:44:58 2020 +0100
c: Fix up cfun->function_end_locus on invalid function bodies [PR94239]
Unfortunately the patch broke
+FAIL: gcc.dg/pr20245-1.c (internal compiler error)
+FAIL: gcc.dg/pr20245-1.c (test for excess errors)
+FAIL: gcc.dg/pr28419.c (internal compiler error)
+FAIL: gcc.dg/pr28419.c (test for excess errors)
on some targets (and under valgrind on the rest of them).
Those functions don't have the opening { and so c_parser_compound_statement
returned error_mark_node before initializing *endlocp.
So, either we can initialize it in that case too:
--- gcc/c/c-parser.c2020-03-20 22:09:39.659411721 +0100
+++ gcc/c/c-parser.c2020-03-21 09:36:44.455705261 +0100
@@ -5611,6 +5611,8 @@ c_parser_compound_statement (c_parser *p
if we have just prepared to enter a function body. */
stmt = c_begin_compound_stmt (true);
c_end_compound_stmt (brace_loc, stmt, true);
+ if (endlocp)
+ *endlocp = brace_loc;
return error_mark_node;
}
stmt = c_begin_compound_stmt (true);
or perhaps simpler initialize it to the function_start_locus at the
beginning and have those functions without { have function_start_locus ==
function_end_locus like the __GIMPLE functions (where propagating the
closing } seemed too difficult).
2020-03-23 Jakub Jelinek
PR gcov-profile/94029
PR c/94239
* c-parser.c (c_parser_declaration_or_fndef): Initialize endloc to
the function_start_locus location. Don't do that afterwards for
the
__GIMPLE body parsing.
[Bug c/94172] [arm-none-eabi] ICE in expand_debug_locations, at cfgexpand.c:5403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94172
--- Comment #12 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:87ce34fa00cd6b87452d747235da40dfe5b6e00f
commit r9-8463-g87ce34fa00cd6b87452d747235da40dfe5b6e00f
Author: Jakub Jelinek
Date: Tue Mar 17 22:32:34 2020 +0100
c: Handle C_TYPE_INCOMPLETE_VARS even for ENUMERAL_TYPEs [PR94172]
The following testcases ICE, because they contain extern variable
declarations with incomplete enum types that is later completed and after
that those variables are accessed. The ICEs are because the vars then may
have
incorrect DECL_MODE etc., e.g. in the first case the var has SImode
DECL_MODE (the guessed mode for the enum), but the enum then actually has
DImode because its enumerators don't fit into unsigned int.
The following patch fixes it by using C_TYPE_INCOMPLETE_VARS not just on
incomplete struct/union types, but also incomplete enum types.
TYPE_VFIELD can't be used as it is TYPE_MIN_VALUE on ENUMERAL_TYPE,
thankfully TYPE_LANG_SLOT_1 has been used in the C FE only on
FUNCTION_TYPEs.
2020-03-17 Jakub Jelinek
PR c/94172
* c-tree.h (C_TYPE_INCOMPLETE_VARS): Define to TYPE_LANG_SLOT_1
instead of TYPE_VFIELD, and support it on
{RECORD,UNION,ENUMERAL}_TYPE.
(TYPE_ACTUAL_ARG_TYPES): Check that it is only used on
FUNCTION_TYPEs.
* c-decl.c (pushdecl): Push C_TYPE_INCOMPLETE_VARS also to
ENUMERAL_TYPEs.
(finish_incomplete_vars): New function, moved from finish_struct.
Use
relayout_decl instead of layout_decl.
(finish_struct): Remove obsolete comment about
C_TYPE_INCOMPLETE_VARS
being TYPE_VFIELD. Use finish_incomplete_vars.
(finish_enum): Clear C_TYPE_INCOMPLETE_VARS. Call
finish_incomplete_vars.
* c-typeck.c (c_build_qualified_type): Clear C_TYPE_INCOMPLETE_VARS
also on ENUMERAL_TYPEs.
* gcc.dg/pr94172-1.c: New test.
* gcc.dg/pr94172-2.c: New test.
