[Bug bootstrap/67128] Makefile.in, libcc1 and --enable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67128 Szőts Ákos changed: What|Removed |Added CC||szotsaki at gmail dot com --- Comment #3 from Szőts Ákos --- Option "--with-pic" doesn't work, but the suggested workaround in the original post does. However, I ended up disabling libcc1 (as I see most of the distribs do it, anyway) with --disable-libcc1 which, as well, solved this issue. Version: 8.2.0
[Bug c++/89297] New: ICE: unexpected expression 'id' of kind overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89297
Bug ID: 89297
Summary: ICE: unexpected expression 'id' of kind overload
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: flast at flast dot jp
Target Milestone: ---
ICE caused by list-initializer within template function that contains call of
overloads, like following.
```
int id(int v) { return v; }
float id(float v) { return v; }
template
int foo(int v)
{
return int{id(v)}; // ICE on here
}
```
https://wandbox.org/permlink/XtHobAXA7lQ1jPTy
I encountered this issue after upgrade from 8 to 9, so I think it's a 9's
regression.
[Bug tree-optimization/89296] New: tree copy-header masking uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89296
Bug ID: 89296
Summary: tree copy-header masking uninitialized warning
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
void test_func(void) {
int loop; // uninitialized and "garbage"
while (!loop) {
loop = get_a_value(); // <- must be for this test
printk("...");
}
}
from Linaro bug report https://bugs.linaro.org/show_bug.cgi?id=4134
-fno-tree-ch gets the required warning
diff --git a/gcc/tree-ssa-loop-ch.c b/gcc/tree-ssa-loop-ch.c
index c876d62..d405d00 100644
--- a/gcc/tree-ssa-loop-ch.c
+++ b/gcc/tree-ssa-loop-ch.c
@@ -393,7 +393,7 @@ ch_base::copy_headers (function *fun)
{
gimple *stmt = gsi_stmt (bsi);
if (gimple_code (stmt) == GIMPLE_COND)
- gimple_set_no_warning (stmt, true);
+ ;//gimple_set_no_warning (stmt, true);
else if (is_gimple_assign (stmt))
{
enum tree_code rhs_code = gimple_assign_rhs_code (stmt);
also gets the required warning. Looking into it.
[Bug target/88834] [SVE] Poor addressing mode choices for LD2 and ST2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834 --- Comment #4 from kugan at gcc dot gnu.org --- Created attachment 45661 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45661&action=edit ivopt patch v1
[Bug target/88834] [SVE] Poor addressing mode choices for LD2 and ST2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834
--- Comment #3 from kugan at gcc dot gnu.org ---
I added iv-use for MASKED_LOAD_LANE and the result is
cmp w3, 0
ble .L1
sub w5, w3, #1
mov x4, 0
lsr w5, w5, 1
add w5, w5, 1
whilelo p0.s, xzr, x5
.p2align 3,,7
.L3:
lsl x3, x4, 3
incwx4
add x7, x1, x3
add x6, x2, x3
ld2w{z4.s - z5.s}, p0/z, [x7]
ld2w{z2.s - z3.s}, p0/z, [x6]
add x3, x0, x3
add z0.s, z4.s, z2.s
sub z1.s, z5.s, z3.s
st2w{z0.s - z1.s}, p0, [x3]
whilelo p0.s, x4, x5
bne .L3
.L1:
ret
No base plus scaled index addressing mode. This is because in ivopt
When called from ivopt:
Breakpoint 4, aarch64_classify_address (info=0x7fffcba0, x=0x76c44f30,
mode=E_DImode, strict_p=false, type=ADDR_QUERY_M)
at
/home/kugan/work/abe/snapshots/gcc.git~origin~aarch64~sve-acle-branch/gcc/config/aarch64/aarch64.c:5689
5689{
(gdb) p debug_rtx (x)
(plus:DI (mult:DI (reg:DI 91)
(const_int 8 [0x8]))
(reg:DI 90))
it accepts it.
When in cfgexpand:
Breakpoint 5, aarch64_classify_address (info=0x7fffcca0, x=0x76c5b840,
mode=E_VNx8SImode, strict_p=false, type=ADDR_QUERY_M)
at
/home/kugan/work/abe/snapshots/gcc.git~origin~aarch64~sve-acle-branch/gcc/config/aarch64/aarch64.c:5689
5689{
(gdb) p debug_rtx (x)
(plus:DI (mult:DI (reg:DI 92 [ ivtmp_28 ])
(const_int 8 [0x8]))
(reg/v/f:DI 110 [ y ]))
This is not accepted because of aarch64_classify_index (info, op1, mode,
strict_p) failing (as it should).
Note the difference in mode for aarch64_classify_address. Not sure if this is
because of the way my patch changes ivopt.
[Bug c/88993] [9 Regression] GCC 9 -Wformat-overflow=2 should reflect real libc limits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #10 from Eric Gallager --- anyone know where/how I'd find out what the real limit is for Darwin's libc?
[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793 --- Comment #20 from Eric Gallager --- Should this really have the middle-end for its component? It seems like this is more of a target issue...
[Bug target/84626] powerpc toc register is reloaded unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84626 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||amodra at gmail dot com Resolution|--- |INVALID --- Comment #1 from Alan Modra --- No, the r2 load can't be moved. The ppc64 ABIs say the restore of r2 must occur immediately after the call. This is necessary for exception unwinding.
[Bug fortran/87689] PowerPC64 ELFv2 function parameter passing violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689
--- Comment #12 from Alan Modra ---
A little more sophisticated.
* fortran/trans-types.c (gfc_get_function_type): Use a varargs decl
unless we have args other than hidden ones.
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -3066,6 +3066,7 @@ gfc_get_function_type (gfc_symbol * sym)
actual parameters for a dummy procedure. */
vec_safe_push (typelist, type);
+ is_varargs = false;
}
else
{
@@ -3092,8 +3093,7 @@ gfc_get_function_type (gfc_symbol * sym)
}
}
- if (!vec_safe_is_empty (typelist)
- || sym->attr.is_main_program
+ if (sym->attr.is_main_program
|| sym->attr.if_source != IFSRC_UNKNOWN)
is_varargs = false;
[Bug fortran/87689] PowerPC64 ELFv2 function parameter passing violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689 Alan Modra changed: What|Removed |Added Summary|Memory corruption on Power |PowerPC64 ELFv2 function |8 |parameter passing violation --- Comment #11 from Alan Modra --- This patch avoids the failure. Be warned, I shouldn't be let loose anywhere near the gcc fortran support. I'm just presenting it in the hope that someone who does know what they're doing can develop a proper fix. --- a/gcc/fortran/trans-types.c +++ b/gcc/fortran/trans-types.c @@ -3092,8 +3092,7 @@ gfc_get_function_type (gfc_symbol * sym) } } - if (!vec_safe_is_empty (typelist) - || sym->attr.is_main_program + if (sym->attr.is_main_program || sym->attr.if_source != IFSRC_UNKNOWN) is_varargs = false;
[Bug rtl-optimization/87761] [9 regression][MIPS] New FAIL: gcc.target/mips/fix-r4000-10.c -O1 start with r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87761 --- Comment #5 from Paul Hua --- (In reply to Jakub Jelinek from comment #4) > Can you please recheck with current trunk, many RA improvements related to > r265398 change went into trunk since then. all those test still fails on trunk.
[Bug middle-end/89294] [9 regression] ICE in valid_constant_size_p, at tree.c:7524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89294 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #3 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00857.html
[Bug lto/88147] [9 Regression] ICE in linemap_line_start, at libcpp/line-map.c:781 starting from r265875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88147 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #22 from David Malcolm --- Should be fixed by r268789.
[Bug lto/88147] [9 Regression] ICE in linemap_line_start, at libcpp/line-map.c:781 starting from r265875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88147 --- Comment #21 from David Malcolm --- Author: dmalcolm Date: Tue Feb 12 01:09:31 2019 New Revision: 268789 URL: https://gcc.gnu.org/viewcvs?rev=268789&root=gcc&view=rev Log: linemap_line_start: protect against location_t overflow (PR lto/88147) PR lto/88147 reports an assertion failure due to a bogus location_t value when adding a line to a pre-existing line map, when there's a large difference between the two line numbers. For some "large differences", this leads to a location_t value that exceeds LINE_MAP_MAX_LOCATION, in which case linemap_line_start returns 0. This isn't ideal, but at least should lead to safe degradation of location information. However, if the difference is very large, it's possible for the line number offset (relative to the start of the map) to be sufficiently large that overflow occurs when left-shifted by the column-bits, and hence the check against the LINE_MAP_MAX_LOCATION limit fails, leading to a seemingly-valid location_t value, but encoding the wrong location. This triggers the assertion failure: linemap_assert (SOURCE_LINE (map, r) == to_line); The fix (thanks to Martin) is to check for overflow when determining whether to reuse an existing map, and to not reuse it if it would occur. gcc/ChangeLog: David Malcolm PR lto/88147 * input.c (selftest::test_line_offset_overflow): New selftest. (selftest::input_c_tests): Call it. libcpp/ChangeLog: Martin Liska PR lto/88147 * line-map.c (linemap_line_start): Don't reuse the existing line map if the line offset is sufficiently large to cause overflow when computing location_t values. Modified: trunk/gcc/ChangeLog trunk/gcc/input.c trunk/libcpp/ChangeLog trunk/libcpp/line-map.c
[Bug middle-end/89294] [9 regression] ICE in valid_constant_size_p, at tree.c:7524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89294 Martin Sebor changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-02-12 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- This is due to r268774 introducing the assumption that the valid_constant_size_p() argument is a constant expression. I got a new machine recently and apparently didn't install Gnat properly, so wasn't building it despite configuring with --enable-languages=all. I think the Fedora instructions for Ada are wrong: https://fedoraproject.org/wiki/Features/Ada_developer_tools.
[Bug rtl-optimization/89295] New: [9 regression] compilation of gcc.dg-struct-layout-1/t001_x.c takes 30 times as long after r268404
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89295 Bug ID: 89295 Summary: [9 regression] compilation of gcc.dg-struct-layout-1/t001_x.c takes 30 times as long after r268404 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- Executing on host: /home/seurer/gcc/build/gcc-trunk/gcc/xgcc -B/home/seurer/gcc/build/gcc-trunk/gcc/-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -w -I/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compat -Wno-abi -c -o c_compat_x_tst.o /home/seurer/gcc/build/gcc-trunk/gcc/testsuite/gcc5/gcc.dg-struct-layout-1//t001_x.c (timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-trunk/gcc/xgcc -B/home/seurer/gcc/build/gcc-trunk/gcc/ -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -w -I/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compat -Wno-abi -c -o c_compat_x_tst.o /home/seurer/gcc/build/gcc-trunk/gcc/testsuite/gcc5/gcc.dg-struct-layout-1//t001_x.c WARNING: program timed out compiler exited with status 1 FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o compile I started noticing this occasional timeout issue with this test case recently on some of our test machines. Note that the timeout value is 300 seconds when run during a make check. Trying the same test with some older revisions showed (when it is compiled alone) that the compilation finishes in about 2s. With recent revisions it takes 60+s. This may not be the only test that slows down of course. "make -k check-gcc RUNTESTFLAGS=struct-layout-1.exp" which runs many tests including the above test takes about 4m30s at r268403 and about 7m at r268404. Looking at the ftime-report outputs the big differences are in LRA Before: LRA non-specific : 0.25 ( 10%) 0.01 ( 4%) 0.24 ( 9%) 4168 kB ( 5%) LRA virtuals elimination : 0.03 ( 1%) 0.00 ( 0%) 0.05 ( 2%) 355 kB ( 0%) LRA reload inheritance : 0.03 ( 1%) 0.00 ( 0%) 0.03 ( 1%) 1618 kB ( 2%) LRA create live ranges : 0.04 ( 2%) 0.00 ( 0%) 0.04 ( 1%) 538 kB ( 1%) LRA hard reg assignment: 0.07 ( 3%) 0.00 ( 0%) 0.06 ( 2%) 0 kB ( 0%) After: LRA non-specific : 7.34 ( 12%) 0.04 ( 9%) 7.59 ( 13%) 14335 kB ( 13%) LRA virtuals elimination : 26.07 ( 43%) 0.06 ( 13%) 25.26 ( 42%) 3613 kB ( 3%) LRA reload inheritance : 0.04 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 1618 kB ( 2%) LRA create live ranges : 16.84 ( 28%) 0.06 ( 13%) 17.30 ( 29%) 1735 kB ( 2%) LRA hard reg assignment: 7.53 ( 13%) 0.02 ( 4%) 7.72 ( 13%) 0 kB ( 0%) Note: I tried this on x86 and did not see the same slowdown between r268403 and r268404. The trigger revision was r268404 | vmakarov | 2019-01-30 15:49:23 -0600 (Wed, 30 Jan 2019) | 12 lines 2019-01-30 Vladimir Makarov PR rtl-optimization/87246 * lra-constraints.c (simplify_operand_subreg): Reload memory in subreg if the address became invalid. 2019-01-30 Vladimir Makarov PR rtl-optimization/87246 * gcc.target/i386/pr87246.c: New.
[Bug c++/89144] [9 Regression] GCC emits undefined references when a constexpr initializer_list appears in a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89144 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/89241] [9 Regression] ICE in enclosing_instantiation_of, at cp/pt.c:13380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89241 --- Comment #4 from Jason Merrill --- Author: jason Date: Mon Feb 11 23:05:16 2019 New Revision: 268784 URL: https://gcc.gnu.org/viewcvs?rev=268784&root=gcc&view=rev Log: PR c++/89241 - ICE with __func__ in lambda in template. When we're instantiating a generic lambda, its enclosing context will have already been instantiated, so we need to look for that as well. * pt.c (enclosing_instantiation_of): Also check instantiated_lambda_fn_p for the template context. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-func1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/89241] [9 Regression] ICE in enclosing_instantiation_of, at cp/pt.c:13380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89241 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Merrill --- Fixed.
[Bug c++/86252] Abstract class in function return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86252
--- Comment #2 from Jonathan Wakely ---
Another testcase, reduced from Boost.Rational:
template
struct sfinae
{
static const bool value = false;
static T zero() { return T(); }
};
template
struct enable_if { typedef T type; };
template struct enable_if { };
struct Abstract {
virtual void f() = 0;
};
struct X {
template
X(const T&, typename enable_if::value>::type* = 0)
{ }
};
Abstract* a();
int f(const Abstract&);
void f(X);
int i = f(*a());
[Bug c++/86252] Abstract class in function return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86252 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-11 Ever confirmed|0 |1
[Bug fortran/88299] [F18] COMMON in a legacy module produces bogus warnings in dependent code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88299 --- Comment #5 from Harald Anlauf --- Patch passed regtesting and was submitted: https://gcc.gnu.org/ml/fortran/2019-02/msg00097.html
[Bug tree-optimization/42970] Missed unused function return value elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42970 Martin Jambor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org --- Comment #5 from Martin Jambor --- I have posted a WIP patch as: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01765.html I am in the process of cleaning it up for final submission once stage 1 opens again.
[Bug tree-optimization/85762] [8/9 Regression] range-v3 abstraction overhead not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85762 --- Comment #4 from Martin Jambor --- My apologies, I forgot about this bug. I will have a look this week.
[Bug fortran/88299] [F18] COMMON in a legacy module produces bogus warnings in dependent code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88299
--- Comment #4 from Harald Anlauf ---
I'm currently regtesting the following patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 268778)
+++ gcc/fortran/resolve.c (working copy)
@@ -940,7 +940,11 @@
have been ignored to continue parsing.
We do the checks again here. */
if (!csym->attr.use_assoc)
- gfc_add_in_common (&csym->attr, csym->name, &common_block->where);
+ {
+ gfc_add_in_common (&csym->attr, csym->name, &common_block->where);
+ gfc_notify_std (GFC_STD_F2018_OBS, "COMMON block at %L",
+ &common_block->where);
+ }
if (csym->value || csym->attr.data)
{
@@ -998,10 +1002,6 @@
resolve_common_vars (common_root->n.common, true);
- if (!gfc_notify_std (GFC_STD_F2018_OBS, "COMMON block at %L",
- &common_root->n.common->where))
-return;
-
/* The common name is a global name - in Fortran 2003 also if it has a
C binding name, since Fortran 2008 only the C binding name is a global
identifier. */
[Bug c++/88752] [8 Regression] ICE in enclosing_instantiation_of, at cp/pt.c:13328
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88752 --- Comment #9 from Jason Merrill --- Author: jason Date: Mon Feb 11 21:49:37 2019 New Revision: 268783 URL: https://gcc.gnu.org/viewcvs?rev=268783&root=gcc&view=rev Log: Revert "PR c++/88752 - ICE with lambda and constexpr if." This reverts commit 2a97dfc988a695e44f759099f74e4a18c01fa9a5. Removed: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1z/constexpr-if26.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/cp-tree.h branches/gcc-8-branch/gcc/cp/pt.c
[Bug middle-end/89294] [9 regression] ICE in valid_constant_size_p, at tree.c:7524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89294 Rainer Orth changed: What|Removed |Added Target|i386-pc-solaris2.11 |i386-pc-solaris2.11, ||x86_64-pc-linux-gnu Host|i386-pc-solaris2.11 |i386-pc-solaris2.11, ||x86_64-pc-linux-gnu Build|i386-pc-solaris2.11 |i386-pc-solaris2.11, ||x86_64-pc-linux-gnu --- Comment #1 from Rainer Orth --- Seeing the same on Linux/x86_64.
[Bug c++/89241] [9 Regression] ICE in enclosing_instantiation_of, at cp/pt.c:13380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89241 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug middle-end/89292] [9 regression] test case gcc.target/powerpc/rs6000-fpint.c fails after r268705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89292 --- Comment #2 from Bill Schmidt --- So, dup of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271?
[Bug middle-end/89294] [9 regression] ICE in valid_constant_size_p, at tree.c:7524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89294 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug middle-end/89294] New: [9 regression] ICE in valid_constant_size_p, at tree.c:7524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89294 Bug ID: 89294 Summary: [9 regression] ICE in valid_constant_size_p, at tree.c:7524 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: msebor at gcc dot gnu.org Target Milestone: --- Host: i386-pc-solaris2.11 Target: i386-pc-solaris2.11 Build: i386-pc-solaris2.11 Between 20190210 (r268749) and 20190211 (r268774), a couple of Ada testcases regressed on Solaris/x86 (both 32 and 64-bit): +FAIL: gnat.dg/vect1.adb (test for excess errors) +FAIL: gnat.dg/vect1.adb 3 blank line(s) in output +UNRESOLVED: gnat.dg/vect1.adb scan-tree-dump-times vect "vectorized 1 loops" 15 +FAIL: gnat.dg/vect2.adb (test for excess errors) +FAIL: gnat.dg/vect2.adb 3 blank line(s) in output +UNRESOLVED: gnat.dg/vect2.adb scan-tree-dump-times vect "vectorized 1 loops" 15 +FAIL: gnat.dg/vect3.adb (test for excess errors) +FAIL: gnat.dg/vect3.adb 3 blank line(s) in output +UNRESOLVED: gnat.dg/vect3.adb scan-tree-dump-times vect "vectorized 1 loops" 15 +FAIL: gnat.dg/vect4.adb (test for excess errors) +FAIL: gnat.dg/vect4.adb 3 blank line(s) in output +UNRESOLVED: gnat.dg/vect4.adb scan-tree-dump-times vect "vectorized 1 loops" 15 +FAIL: gnat.dg/vect5.adb (test for excess errors) +FAIL: gnat.dg/vect5.adb 3 blank line(s) in output +UNRESOLVED: gnat.dg/vect5.adb scan-tree-dump-times vect "vectorized 1 loops" 15 +FAIL: gnat.dg/vect6.adb (test for excess errors) +FAIL: gnat.dg/vect6.adb 3 blank line(s) in output +UNRESOLVED: gnat.dg/vect6.adb scan-tree-dump-times vect "vectorized 1 loops" 15 FAIL: gnat.dg/vect2.adb 3 blank line(s) in output FAIL: gnat.dg/vect2.adb (test for excess errors) Excess errors: +===GNAT BUG DETECTED==+ | 9.0.1 20190211 (experimental) [trunk revision 268774] (i386-pc-solaris2.11) GCC error:| | tree check: expected class 'constant', have 'binary' (mult_expr) in | | valid_constant_size_p, at tree.c:7524| | Error detected at vect2.ads:24:51 I'm not seeing this failure on sparc-sun-solaris2.11.
[Bug c++/89285] [8/9 Regression] ICE after casting the this pointer in the constructor in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89285
--- Comment #9 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #4)
> + /* Preserve REINTERPRET_CAST_P. */
> + if (code == NOP_EXPR && REINTERPRET_CAST_P (org_x))
> + {
> + if (TREE_CODE (x) == NOP_EXPR && REINTERPRET_CAST_P (x))
> + break;
> + if (TREE_CODE (x) == NOP_EXPR)
> + {
> + x = copy_node (x);
> + REINTERPRET_CAST_P (x) = 1;
> + }
> + else
> + {
> + x = build1_loc (loc, code, TREE_TYPE (x), x);
> + REINTERPRET_CAST_P (x) = 1;
> + }
> + }
>break;
Looks good, though can't we assume that if x != org_x it's a new NOP_EXPR so we
can just set REINTERPRET_CAST_P?
> and with that we reject the testcase again (like we've done in 8.x, so this
> part is [9 Regression] accepts-invalid).
> But that also means we ICE again on the:
> C bar {};
I'm not seeing this.
> So, maybe we want to ignore that:
> if (REINTERPRET_CAST_P (t))
> {
> if (!ctx->quiet)
> error_at (cp_expr_loc_or_loc (t, input_location),
> "a reinterpret_cast is not a constant expression");
> *non_constant_p = true;
> return t;
> }
> for perhaps !ctx->manifestly_const_eval , as in when we really don't require
> constant expression.
That should depend on ctx->strict, not manifestly_const_eval.
(In reply to Jakub Jelinek from comment #7)
> Ah, so one problem is that while we save the inline bodies of functions
> before cp_fold_function, cp_fold_function is destructive and clobbers the
> saved copy.
> cp_fold itself is (hopefully) not destructive and creates new trees, but
> cp_fold_function is destructive and happily modifies the trees shared with
> something else (in this case with the constexpr funcdef table).
>
> Jason, any preferences here?
My theory has been to switch to saving pre-gimplification bodies of constexpr
functions and doing constant evaluation using them.
[Bug c/66970] Add __has_builtin() macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED CC||msebor at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #13 from Martin Sebor --- Let me look into this request for GCC 10.
[Bug fortran/84135] [8/9 Regression] ICE in gfc_trans_array_cobounds, at fortran/trans-array.c:6033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84135 --- Comment #6 from Thomas Koenig --- $ cat z1.f90 > program p >integer :: i >integer, dimension(3) :: x[2,*] >data (x(i:i+2:i+1), i=1,2) /1,2,3/ This should be caught, there is no normal dimension here, just a codimension.
[Bug c++/89285] [8/9 Regression] ICE after casting the this pointer in the constructor in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89285 --- Comment #8 from Jakub Jelinek --- I'll try to copy & adjust (mostly kill almost everything) copy_tree_body_r and use that in register_constexpr_fundef. As we don't need to remap decls or types, I think we just need copy_statement_list for STATEMENT_LIST, remap_save_expr for SAVE_EXPR/TARGET_EXPR, copy_tree_r for the rest?
[Bug c++/53036] [c++11] trivial class fails std::is_trivial test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53036 --- Comment #7 from Jonathan Wakely --- Bug 85723 deals with the problem mentioned in comment 5.
[Bug c++/85723] [C++17][DR 1496] __is_trivial intrinsic fails with no trivial non-deleted default c'tor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85723
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-02-11
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=53036
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
Confirmed.
We also don't yet implement the earlier change to that wording, from
https://wg21.link/cwg1363
struct A {
A() = default;
A(int i = 0) { }
};
static_assert(!__is_trivial(A), "");
This fails because G++ considers the class trivial, even though
default-initialization would fail as ambiguous.
[Bug fortran/89266] ICE with TRANSFER of len=0 character array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89266 --- Comment #8 from Harald Anlauf --- It's not as trivial as I had hoped. The point is that gfc_element_size() and gfc_target_expr_size() are returning size 0 for the source expression, which is an entirely correct value. However, they also return value 0 also for cases where the sizes could not be determined to be a constant. I have a 'half-patch' that tries to change gfc_target_expr_size() to return a bool which is true for success and false for failure, and then deal with this return value. It seems that this also needs to be done for gfc_element_size(). However, there is this occurrence in class.c of gfc_element_size(): /* Build a minimal expression to make use of target-memory.c/gfc_element_size for 'size'. Special handling for character arrays, that are not constant sized: to support len (str) * kind, only the kind information is stored in the vtab. */ e = gfc_get_expr (); e->ts = *ts; e->expr_type = EXPR_VARIABLE; c->initializer = gfc_get_int_expr (gfc_size_kind, NULL, ts->type == BT_CHARACTER ? ts->kind : gfc_element_size (e)); I am not yet sure how to safely rewrite this.
[Bug c++/58074] [C++11][DR 1333] __is_trivial intrinsic fails for deleted members and for non-trivial copy-c'tors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58074 --- Comment #9 from Jonathan Wakely --- (In reply to Daniel Krügler from comment #0) > The deleted default constructor should not prevent type Trivial of being > trivial (Maybe this part of the problem is related to bug 52707, but I'm not > sure). I think DR 1363 changed that (and DR 1496 reconfirmed it) so the first test is wrong. But G++ now passes that assertion, so that's also wrong (that is Bug 85723 though).
[Bug d/89293] New: libphobos: core.atomic should have fallback for no atomic library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89293 Bug ID: 89293 Summary: libphobos: core.atomic should have fallback for no atomic library Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gdcproject dot org Target Milestone: --- Currently there's a static assert that fails if GNU_Have_LibAtomic is false. In the absence of atomics, a statically allocated core.sync.mutex.Mutex could be used instead to lock/unlock between operations, making sure there's no risk of using it before D runtime has been initialized.
[Bug middle-end/89292] [9 regression] test case gcc.target/powerpc/rs6000-fpint.c fails after r268705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89292 --- Comment #1 from seurer at gcc dot gnu.org --- gcc.target/powerpc/vsx-simode2.c also fails after this revision: # of expected passes2 # of unexpected failures1 FAIL: gcc.target/powerpc/vsx-simode2.c scan-assembler mtvsrwz
[Bug c++/89212] [8 Regression] ICE in fold_convert_loc at fold-const.c:2552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89212 Marek Polacek changed: What|Removed |Added Summary|[8/9 Regression] ICE in |[8 Regression] ICE in |fold_convert_loc at |fold_convert_loc at |fold-const.c:2552 |fold-const.c:2552 --- Comment #8 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/88977] __builtin_is_constant_evaluated() as function template argument causes substitution failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88977 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug c++/89212] [8/9 Regression] ICE in fold_convert_loc at fold-const.c:2552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89212 --- Comment #7 from Marek Polacek --- Author: mpolacek Date: Mon Feb 11 20:03:43 2019 New Revision: 268781 URL: https://gcc.gnu.org/viewcvs?rev=268781&root=gcc&view=rev Log: PR c++/89212 - ICE converting nullptr to pointer-to-member-function. * pt.c (tsubst_copy_and_build) : Return early for null member pointer value. * g++.dg/cpp0x/nullptr40.C: New test. * g++.dg/cpp0x/nullptr41.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/nullptr40.C trunk/gcc/testsuite/g++.dg/cpp0x/nullptr41.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/88977] __builtin_is_constant_evaluated() as function template argument causes substitution failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88977 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Mon Feb 11 20:00:16 2019 New Revision: 268780 URL: https://gcc.gnu.org/viewcvs?rev=268780&root=gcc&view=rev Log: PR c++/88977 * pt.c (convert_nontype_argument): Pass true as manifestly_const_eval to maybe_constant_value calls. * g++.dg/cpp2a/is-constant-evaluated7.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug lto/88147] [9 Regression] ICE in linemap_line_start, at libcpp/line-map.c:781 starting from r265875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88147 --- Comment #20 from David Malcolm --- (In reply to David Malcolm from comment #19) > (In reply to David Malcolm from comment #17) > > Created attachment 45660 [details] > > Selftest coverage > > > > The attached reproduces the problem via a minimal selftest, and is also > > fixed by attachment 45653 [details]. > > Thanks for creating this patch. I like that it imposes an upper limit on > the value of a line number within an ordinary linemap relative to the line > map's starting line, but I wonder if that upper limit needs to be lower than > the one in your patch (e.g. what happens if the resulting location_t value > hit limits like LINE_MAP_MAX_LOCATION etc). I constructed a selftest that does that, but it doesn't lead to corrupt location_t values: it hits this check, and returns 0 (aka UNKNOWN_LOCATION): 771 /* Locations of ordinary tokens are always lower than locations of 772 macro tokens. */ 773 if (r >= LINE_MAP_MAX_LOCATION) 774 return 0; So I think your fix is the one we should use. I'm testing a combined patch with your fix + my selftest.
[Bug target/89290] [8/9 Regression] ICE in change_address_1, at emit-rtl.c:2286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89290 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-11 CC||uros at gcc dot gnu.org Target Milestone|--- |8.3 Ever confirmed|0 |1
[Bug target/89290] [8/9 Regression] ICE in change_address_1, at emit-rtl.c:2286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89290
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
The problem is that adjust_address with
(mem/c:TI (const:DI (unspec:DI [
(symbol_ref:DI ("s") [flags 0x2a] )
] UNSPEC_NTPOFF)) [1 s+0 S16 A64 AS1])
as first argument, E_DImode and 8 as last two doesn't validate.
We have originally:
(insn 7 6 10 2 (set (mem/c:TI (plus:DI (unspec:DI [
(const_int 0 [0])
] UNSPEC_TP)
(const:DI (unspec:DI [
(symbol_ref:DI ("s") [flags 0x2a] )
] UNSPEC_NTPOFF))) [1 s+0 S16 A64])
(reg:TI 83)) "pr89290.c":7:5 65 {*movti_internal}
(nil))
then the ix86_rewrite_tls_address splitter rewrites this into:
(insn 12 6 10 2 (set (mem/c:TI (const:DI (unspec:DI [
(symbol_ref:DI ("s") [flags 0x2a] )
] UNSPEC_NTPOFF)) [1 s+0 S16 A64 AS1])
(reg:TI 83)) "pr89290.c":7:5 -1
(nil))
and finally we ICE in the split_double_move splitter.
[Bug fortran/89291] internal compiler error: in gfc_trans_use_stmts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89291 --- Comment #2 from zwieflhofer --- Installed gcc-5.5.0 and built the identical WRF version. No ICE encountered with 5.5.0. Attempted to extract a reduced test version but this is non-trivial due to the large source code base and complex make files. I am happy for now that 5.5.0 gives me a working solution. I tried the reproducer attached to bug report 41062 but that one compiled fine under 7.4.0. Please regard this bug report as a courtesy rather than a request for action and feel free to close it due to the missing reproducer. Alternatively, I can forward this report to NCAR to see whether there is any interest in pre-emptive investigations as part of their regression testing. Many thanks for the prompt reply.
[Bug middle-end/89292] New: [9 regression] test case gcc.target/powerpc/rs6000-fpint.c fails after r268705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89292 Bug ID: 89292 Summary: [9 regression] test case gcc.target/powerpc/rs6000-fpint.c fails after r268705 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- Slightly different assembler is generated after r268705 spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/rs6000-fpint.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -mno-powerpc-gfxopt -ffat-lto-objects -fno-ident -S -o rs6000-fpint.s PASS: gcc.target/powerpc/rs6000-fpint.c (test for excess errors) FAIL: gcc.target/powerpc/rs6000-fpint.c scan-assembler-not stfiwx Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ vmx_hw_available72259.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -mno-vsx -lm -o vmx_hw_available72259.exe (timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ vmx_hw_available72259.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -mno-vsx -lm -o vmx_hw_available72259.exe Setting LD_LIBRARY_PATH to :/home/seurer/gcc/build/gcc-test2/gcc::/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.2.0/lib64 Execution timeout is: 300 spawn [open ...] testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/powerpc.exp completed in 0 seconds === gcc Summary === # of expected passes1 # of unexpected failures1 Comparing the assembler before and after the change: 24,25c24,25 < mfvsrwz 9,0 < stw 9,48(31) --- > addi 9,31,48 > stfiwx 0,0,9 28,29c28,29 < mfvsrwz 9,0 < stw 9,52(31) --- > addi 9,31,52 > stfiwx 0,0,9
[Bug middle-end/89288] [9 Regression] ICE in tree_code_size, at tree.c:865
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89288 Martin Sebor changed: What|Removed |Added Keywords||ice-on-valid-code, patch Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-11 Depends on||88383 Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- The trivial patch for bug 88383 that you objected to for reasons unrelated to the fix and that Jeff likewise declined to approve has a solution for this. The fix is incomplete so it still ICEs on this test case but that's just a small oversight. I have reposted the patch: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00793.html Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88383 [Bug 88383] ICE calling _builtin_has_attribute with an expression
[Bug target/89289] ICE in extract_insn, at recog.c:2310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89289 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-11 CC||ak at gcc dot gnu.org, ||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- So, either we need to make the calls direct (that could be e.g. adding another predicate and constraint similar to const_call_address_operand/Bz that wouldn't check flag_force_indirect_call, or do what we do e.g. for -fpic -mcmodel=large (but we don't have a got pointer), or add completely new patterns for TLS_GD/LD models.
[Bug fortran/89286] Intrinsic sign and GNU Extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89286 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-02-11 Ever confirmed|0 |1 --- Comment #5 from Dominique d'Humieres --- Patch should go to the fort...@gcc.gnu.org and gcc-patc...@gcc.gnu.org mailing lists for review. >From a quick look at the patch it does seem that the extension is rejected when compiling with -std=f*. I don't see the need to add this extension (read: I am opposed to this extension).
[Bug fortran/89291] internal compiler error: in gfc_trans_use_stmts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89291 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-02-11 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Please provide a reproducer.
[Bug middle-end/89288] [9 Regression] ICE in tree_code_size, at tree.c:865
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89288 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||msebor at gcc dot gnu.org Target Milestone|--- |9.0 --- Comment #1 from Jakub Jelinek --- 4033 if (TYPE_P (oper)) 4034tmpdecl = build_decl (atloc, TYPE_DECL, tmpid, oper); 4035 else 4036tmpdecl = build_decl (atloc, TREE_CODE (oper), tmpid, TREE_TYPE (oper)); when oper is INTEGER_CST (or any expression other than TYPE_P or DECL_P) is not going to work at all. Other issues: /* An alias cannot be a defintion so declare the symbol extern. */ s/defintion/definition/ if (has_attribute (atloc, oper, attr, default_conversion)) result.value = boolean_true_node; else result.value = boolean_false_node; too large whitespace between = and boolean.
[Bug fortran/89291] New: internal compiler error: in gfc_trans_use_stmts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89291 Bug ID: 89291 Summary: internal compiler error: in gfc_trans_use_stmts Product: gcc Version: 7.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: walter.zwieflhofer at ineosteamuk dot com Target Milestone: --- Internal compiler error when compiling WRF 4.0.3 from NCAR Standard compile of gcc 7.4.0 uname -a: Linux ws2bar 2.6.32-696.18.7.el6.x86_64 #1 SMP Thu Jan 4 17:31:22 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Processor type: Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz Backtrace: module_ra_rrtmg_lw.f90:7870:0: use rrlw_tbl, only: ntbl, tblint, pade, bpade, tau_tbl, exp_tbl, tfn_tbl internal compiler error: in gfc_trans_use_stmts, at fortran/trans-decl.c:4959 0x6bb88e gfc_trans_use_stmts ../../gcc-7.4.0-src/gcc/fortran/trans-decl.c:4958 0x6bbe92 gfc_generate_function_code(gfc_namespace*) ../../gcc-7.4.0-src/gcc/fortran/trans-decl.c:6528 0x69a0f9 gfc_generate_module_code(gfc_namespace*) ../../gcc-7.4.0-src/gcc/fortran/trans.c:2202 0x64f75b translate_all_program_units ../../gcc-7.4.0-src/gcc/fortran/parse.c:6062 0x64f75b gfc_parse_file() ../../gcc-7.4.0-src/gcc/fortran/parse.c:6275 0x692eaf gfc_be_parse_file ../../gcc-7.4.0-src/gcc/fortran/f95-lang.c:204 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. Possible code regression - see bug report 41062 from 13 Aug 2009
[Bug libbacktrace/81983] libbacktrace calls bsearch with NULL base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81983 --- Comment #5 from Ian Lance Taylor --- I would be inclined to just skip the bsearch when the count is zero.
[Bug c++/89267] [8 Regression] FAIL: g++.dg/cpp1z/constexpr-lambda8.C (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89267 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jason Merrill --- Fixed.
[Bug tree-optimization/86637] [9 Regression] ICE: tree check: expected block, have in inlining_chain_to_json, at optinfo-emit-json.cc:293
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86637 --- Comment #14 from Wilco --- Author: wilco Date: Mon Feb 11 18:14:37 2019 New Revision: 268777 URL: https://gcc.gnu.org/viewcvs?rev=268777&root=gcc&view=rev Log: [COMMITTED] Fix pthread errors in pr86637-2.c Fix test errors on targets which do not support pthreads. Committed as obvious. testsuite/ PR tree-optimization/86637 * gcc.c-torture/compile/pr86637-2.c: Test pthread and graphite target. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/compile/pr86637-2.c
[Bug c++/53036] [c++11] trivial class fails std::is_trivial test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53036 Martin Sebor changed: What|Removed |Added Keywords||rejects-valid Status|NEW |RESOLVED CC||msebor at gcc dot gnu.org Known to work||6.3.0, 7.4.0, 8.2.0, 9.0 Resolution|--- |FIXED Known to fail||4.7.4, 4.8.5, 4.9.4 --- Comment #6 from Martin Sebor --- This bug has been fixed since GCC 5. If there are outstanding issues as comment #5 suggests that aren't being tracked by any open bugs let's open new issues for them. I'm going to resolve this as fixed. r215771 | jason | 2014-10-01 13:21:01 -0400 (Wed, 01 Oct 2014) | 11 lines PR c++/63362 * class.c (type_has_non_user_provided_default_constructor): Rename from type_has_user_provided_default_constructor, reverse sense. (default_init_uninitialized_part, explain_non_literal_class): Adjust. (check_bases_and_members): Set TYPE_HAS_COMPLEX_DFLT. * call.c (build_new_method_call_1): Adjust. * cp-tree.h: Adjust. * decl.c (grok_special_member_properties): Don't set TYPE_HAS_COMPLEX_DFLT. * init.c (build_value_init_noctor): Don't use type_has_user_provided_default_constructor.
[Bug c++/89285] [8/9 Regression] ICE after casting the this pointer in the constructor in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89285 --- Comment #7 from Jakub Jelinek --- Ah, so one problem is that while we save the inline bodies of functions before cp_fold_function, cp_fold_function is destructive and clobbers the saved copy. cp_fold itself is (hopefully) not destructive and creates new trees, but cp_fold_function is destructive and happily modifies the trees shared with something else (in this case with the constexpr funcdef table). One way out of this is throwing away cp_fold_r/cp_fold_function and teaching cp_fold to handle all the trees that cp_walk_tree can walk (dunno if we want to cache everything or not). That means handling e.g. STATEMENT_LIST, BIND_EXPR, *_STMT etc. Another possibility is to use cp_fold_r the way it is for non-constexpr functions, and for constexpr functions use instead a hand written walker that will handle everything that can appear in constexpr functions with copy on write behavior, say if it is processing a STATEMENT_LIST and determines a recursive call wants to fold one of the statements, unshare the whole STATEMENT_LIST, modify it on the copy (and the parent would notice and unshare etc.). Yet another possibility is to use the inliner's copy_tree_body_r for this in register_constexpr_fundef, but in a way that we don't create new decls. I'm afraid it would still create new VLA types, can those appear in constexpr functions? Jason, any preferences here? Note, the above would fix the [9 Regression] part of this PR, that we don't reject that #c4 testcase. We'd still need to figure out a fix for the [8 Regression] part that once this [9 Regression] part is fixed would become [8/9 Regression]. I guess it could fix various other accepts-invalid cases where the cp_folding which modifies the saved tree makes us accept invalid constexpr code.
[Bug c++/53181] static_assert sees as non constant the comparison between a constexpr and a template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53181 Martin Sebor changed: What|Removed |Added Known to fail|6.0 |6.3.0, 7.3.0, 8.2.0, 9.0 --- Comment #5 from Martin Sebor --- No change in GCC 9.
[Bug c++/89267] [8 Regression] FAIL: g++.dg/cpp1z/constexpr-lambda8.C (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89267 --- Comment #3 from Jason Merrill --- Author: jason Date: Mon Feb 11 17:57:41 2019 New Revision: 268776 URL: https://gcc.gnu.org/viewcvs?rev=268776&root=gcc&view=rev Log: PR c++/89267 - change of error location. * pt.c (tsubst_copy_and_build): Do still clear expr location for instantiated thunk calls. Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/pt.c
[Bug tree-optimization/88771] [9 Regression] Misleading -Werror=array-bounds error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|NEW
--- Comment #20 from Martin Sebor ---
The patch to make the warning less misleading has been committed in r268775.
With the test case from comment #0 cleaned up a bit, the warning looks like
this:
$ cat pr88771.c && gcc -O2 -S -Wall pr88771.c
int f (char *d, const char *s, int n)
{
int i = n + 1 ? n + 1 : 1;
__builtin_strncpy (d, s, n);
if (i)
return 1;
return 0;
}
pr88771.c: In function ‘f’:
pr88771.c:5:3: warning: ‘__builtin_strncpy’ specified bound
18446744073709551615 exceeds maximum object size 9223372036854775807
[-Wstringop-overflow=]
5 | __builtin_strncpy (d, s, n);
| ^~~
It's interesting to note that the test after the (n + 1) addition relies on
signed integer overflow having wrapping semantics. With that invalid
assumption removed by making n's and i's type unsigned the warning is gone
because doing so prevents jump threading from inserting the additional strncpy
call. (But there are other, valid cases where the invalid call still is
introduced and the warning triggers.)
[Bug tree-optimization/88771] [9 Regression] Misleading -Werror=array-bounds error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771 --- Comment #19 from Martin Sebor --- Author: msebor Date: Mon Feb 11 17:44:05 2019 New Revision: 268775 URL: https://gcc.gnu.org/viewcvs?rev=268775&root=gcc&view=rev Log: PR tree-optimization/88771 - Misleading -Werror=array-bounds error gcc/ChangeLog: PR tree-optimization/88771 * gimple-ssa-warn-restrict.c (pass_wrestrict::gate): Also enable when -Wstringop-overflow is set. (builtin_memref::builtin_memref): Adjust excessive upper bound only when lower bound is not excessive. (maybe_diag_overlap): Detect and diagnose excessive bounds via -Wstringop-ovefflow. (maybe_diag_offset_bounds): Rename... (maybe_diag_access_bounds): ...to this. (check_bounds_or_overlap): Adjust for name change above. gcc/testsuite/ChangeLog: PR tree-optimization/88771 * gcc.dg/Wstringop-overflow-8.c: New test. * gcc.dg/Wstringop-overflow-9.c: New test. * gcc.dg/Warray-bounds-40.c: New test. * gcc.dg/builtin-stpncpy.c: Adjust. * gcc.dg/builtin-stringop-chk-4.c: Adjust. * g++.dg/opt/memcpy1.C: Adjust. Added: trunk/gcc/testsuite/gcc.dg/Warray-bounds-40.c trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-8.c trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-warn-restrict.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/opt/memcpy1.C trunk/gcc/testsuite/gcc.dg/builtin-stpncpy.c trunk/gcc/testsuite/gcc.dg/builtin-stringop-chk-4.c
[Bug c++/89267] [8 Regression] FAIL: g++.dg/cpp1z/constexpr-lambda8.C (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89267 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/89222] [7/8/9 regression] ARM thumb-2 misoptimisation of func ptr call with -O2 or -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222 --- Comment #7 from Wilco --- Patch: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00780.html
[Bug c++/89287] Array declaration fails to use template conversion operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89287 --- Comment #1 from Marek Polacek --- This doesn't seem to ever work with G++ (even 4.8 rejects it).
[Bug c++/87996] [8 Regression] "size of array is negative" error when SIZE_MAX/2 < sizeof(array) <= SIZE_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87996 Martin Sebor changed: What|Removed |Added Known to work||9.0 Summary|[8/9 Regression] "size of |[8 Regression] "size of |array is negative" error|array is negative" error |when SIZE_MAX/2 < |when SIZE_MAX/2 < |sizeof(array) <= SIZE_MAX |sizeof(array) <= SIZE_MAX Known to fail|9.0 | --- Comment #6 from Martin Sebor --- Fixed via r268774 in GCC 9.0.
[Bug c++/87996] [8/9 Regression] "size of array is negative" error when SIZE_MAX/2 < sizeof(array) <= SIZE_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87996 --- Comment #5 from Martin Sebor --- Author: msebor Date: Mon Feb 11 17:35:17 2019 New Revision: 268774 URL: https://gcc.gnu.org/viewcvs?rev=268774&root=gcc&view=rev Log: PR c++/87996 - size of array is negative error when SIZE_MAX/2 < sizeof(array) <= SIZE_MAX gcc/ChangeLog: PR c++/87996 * builtins.c (max_object_size): Move from here... * builtins.h (max_object_size): ...and here... * tree.c (max_object_size): ...to here... * tree.h (max_object_size): ...and here. gcc/c-family/ChangeLog: PR c++/87996 * c-common.c (invalid_array_size_error): New function. (valid_array_size_p): Call it. Handle size as well as type. * c-common.h (valid_constant_size_p): New function. (enum cst_size_error): New type. gcc/cp/ChangeLog: PR c++/87996 * decl.c (compute_array_index_type_loc): Preserve signed sizes for diagnostics. Call valid_array_size_p instead of error. * init.c (build_new_1): Compute size for diagnostic. Call invalid_array_size_error (build_new): Call valid_array_size_p instead of error. gcc/testsuite/ChangeLog: PR c++/87996 * c-c++-common/array-5.c: New test. * c-c++-common/pr68107.c: Adjust text of diagnostics. * g++.dg/init/new38.C: Same. * g++.dg/init/new43.C: Same. * g++.dg/init/new44.C: Same. * g++.dg/init/new46.C: Same. * g++.dg/other/large-size-array.C: Same. * g++.dg/other/new-size-type.C: Same. * g++.dg/template/array30.C: Same. * g++.dg/template/array32.C: New test. * g++.dg/template/dependent-name3.C: Adjust. * gcc.dg/large-size-array-3.c: Same. * gcc.dg/large-size-array-5.c: Same. * gcc.dg/large-size-array.c: Same. * g++.old-deja/g++.brendan/array1.C: Same. * g++.old-deja/g++.mike/p6149.C: Same. Added: trunk/gcc/testsuite/c-c++-common/array-5.c trunk/gcc/testsuite/g++.dg/template/array32.C Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/builtins.h trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/c-family/c-common.h trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/pr68107.c trunk/gcc/testsuite/g++.dg/init/new38.C trunk/gcc/testsuite/g++.dg/init/new43.C trunk/gcc/testsuite/g++.dg/init/new44.C trunk/gcc/testsuite/g++.dg/init/new46.C trunk/gcc/testsuite/g++.dg/other/large-size-array.C trunk/gcc/testsuite/g++.dg/other/new-size-type.C trunk/gcc/testsuite/g++.dg/template/array30.C trunk/gcc/testsuite/g++.dg/template/dependent-name3.C trunk/gcc/testsuite/g++.dg/ubsan/pr81530.C trunk/gcc/testsuite/g++.old-deja/g++.brendan/array1.C trunk/gcc/testsuite/g++.old-deja/g++.mike/p6149.C trunk/gcc/testsuite/gcc.dg/large-size-array-3.c trunk/gcc/testsuite/gcc.dg/large-size-array-5.c trunk/gcc/testsuite/gcc.dg/large-size-array.c trunk/gcc/tree.c trunk/gcc/tree.h
[Bug c/89290] New: [8/9 Regression] ICE in change_address_1, at emit-rtl.c:2286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89290
Bug ID: 89290
Summary: [8/9 Regression] ICE in change_address_1, at
emit-rtl.c:2286
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
With options -O0 -mcmodel=large on x86_64-pc-linux-gnu :
$ cat pr56847.c
struct S { long int a, b; } e;
__thread struct S s;
void
foo (void)
{
s = e;
}
$ gcc-7 -c pr56847.c -O0 -mcmodel=large
$ gcc-9-20190210 -c pr56847.c -O2 -mcmodel=large
$ gcc-9-20190210 -c pr56847.c -O0
$
$ gcc-9-20190210 -c pr56847.c -O0 -mcmodel=large
during RTL pass: split2
pr56847.c: In function 'foo':
pr56847.c:8:1: internal compiler error: in change_address_1, at emit-rtl.c:2286
8 | }
| ^
0x7a18d0 change_address_1
../../gcc/emit-rtl.c:2286
0x7a4896 adjust_address_1(rtx_def*, machine_mode, poly_int<1u, long>, int, int,
int, poly_int<1u, long>)
../../gcc/emit-rtl.c:2420
0xd5c619 split_double_mode(machine_mode, rtx_def**, int, rtx_def**, rtx_def**)
../../gcc/config/i386/i386.c:18661
0xd5ca5b ix86_split_to_parts
../../gcc/config/i386/i386.c:25393
0xd671cd ix86_split_long_move(rtx_def**)
../../gcc/config/i386/i386.c:25483
0xf88d20 gen_split_8(rtx_insn*, rtx_def**)
../../gcc/config/i386/i386.md:2267
0x10ccd04 split_10
../../gcc/config/i386/i386.md:9883
0x112b377 split_insns(rtx_def*, rtx_insn*)
../../gcc/config/i386/i386.md:13184
0x7a6331 try_split(rtx_def*, rtx_insn*, int)
../../gcc/emit-rtl.c:3851
0xa00281 split_insn
../../gcc/recog.c:2901
0xa043a2 split_all_insns()
../../gcc/recog.c:3005
0xa044a8 execute
../../gcc/recog.c:3905
[Bug c/89289] New: ICE in extract_insn, at recog.c:2310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89289
Bug ID: 89289
Summary: ICE in extract_insn, at recog.c:2310
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
A combination of __thread with option -mforce-indirect-call
and -fpic or -fPIC gives an ICE starting with early gcc-8
for pr24428, pr47715, pr68986 and others :
$ cat z1.c
extern __thread int a;
int f ()
{
return a;
}
$ gcc-9-20190210 -c z1.c -fpic
$ gcc-9-20190210 -c z1.c -fpic -mforce-indirect-call
z1.c: In function 'f':
z1.c:5:1: error: unrecognizable insn:
5 | }
| ^
(call_insn/u 5 2 6 2 (parallel [
(set (reg:DI 0 ax)
(call:DI (mem:QI (symbol_ref:DI ("__tls_get_addr")) [0 S1 A8])
(const_int 0 [0])))
(unspec:DI [
(symbol_ref:DI ("a") [flags 0x50] )
(reg/f:DI 7 sp)
] UNSPEC_TLS_GD)
]) "z1.c":4:10 -1
(expr_list:REG_EH_REGION (const_int -2147483648 [0x8000])
(nil))
(nil))
during RTL pass: vregs
z1.c:5:1: internal compiler error: in extract_insn, at recog.c:2310
0x5aa7c0 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.c:108
0x5aa7df _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/rtl-error.c:116
0xa020e7 extract_insn(rtx_insn*)
../../gcc/recog.c:2310
0x817525 instantiate_virtual_regs_in_insn
../../gcc/function.c:1654
0x817525 instantiate_virtual_regs
../../gcc/function.c:1975
0x817525 execute
../../gcc/function.c:2024
[Bug lto/88147] [9 Regression] ICE in linemap_line_start, at libcpp/line-map.c:781 starting from r265875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88147 --- Comment #19 from David Malcolm --- (In reply to David Malcolm from comment #17) > Created attachment 45660 [details] > Selftest coverage > > The attached reproduces the problem via a minimal selftest, and is also > fixed by attachment 45653 [details]. Thanks for creating this patch. I like that it imposes an upper limit on the value of a line number within an ordinary linemap relative to the line map's starting line, but I wonder if that upper limit needs to be lower than the one in your patch (e.g. what happens if the resulting location_t value hit limits like LINE_MAP_MAX_LOCATION etc).
[Bug tree-optimization/80936] bcmp, bcopy, and bzero not declared nonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80936
Martin Sebor changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|INVALID |---
Known to fail||7.3.0, 8.2.0, 9.0
--- Comment #4 from Martin Sebor ---
POSIX says this about bcopy:
For maximum portability, it is recommended to replace the function call to
bcopy() as follows:
#define bcopy(b1,b2,len) (memmove((b2), (b1), (len)), (void) 0)
GCC lowers bcopy calls to memmove (and similarly for other bxxx calls), which I
think makes it even more important that the non-null attribute be applied to
their declarations, to detect bugs due to legacy code making the assumption
that bcopy et al are null-safe (e.g., on a target where they really are).
$ cat t.c && gcc -O0 -S -Wall -fdump-tree-lower=/dev/stdout t.c
void f (void *d, const void *s, __SIZE_TYPE__ n)
{
__builtin_bcopy (s, 0, n);
}
;; Function f (f, funcdef_no=0, decl_uid=1908, cgraph_uid=1, symbol_order=0)
f (void * d, const void * s, long unsigned int n)
{
__builtin_memmove (0B, s, n);
return;
}
[Bug c/89288] New: [9 Regression] ICE in tree_code_size, at tree.c:865
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89288
Bug ID: 89288
Summary: [9 Regression] ICE in tree_code_size, at tree.c:865
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20181118 and 20181125 :
$ cat z1.c
typedef int Assert [(__builtin_has_attribute (1, target("sse")) == 1)];
$ gcc-9-20190210 -c z1.c
z1.c:1:1: internal compiler error: in tree_code_size, at tree.c:865
1 | typedef int Assert [(__builtin_has_attribute (1, target("sse")) == 1)];
| ^~~
0xcbace1 tree_code_size(tree_code)
../../gcc/tree.c:865
0xcbae2c make_node(tree_code)
../../gcc/tree.c:1038
0xcbdd2b build_decl(unsigned int, tree_code, tree_node*, tree_node*)
../../gcc/tree.c:5023
0x692278 validate_attribute
../../gcc/c-family/c-attribs.c:4036
0x692278 has_attribute(unsigned int, tree_node*, tree_node*, tree_node*
(*)(tree_node*))
../../gcc/c-family/c-attribs.c:4069
0x61d28d c_parser_has_attribute_expression
../../gcc/c/c-parser.c:7665
0x61d28d c_parser_unary_expression
../../gcc/c/c-parser.c:7356
0x61d537 c_parser_cast_expression
../../gcc/c/c-parser.c:7222
0x61d7e3 c_parser_binary_expression
../../gcc/c/c-parser.c:7025
0x61e695 c_parser_conditional_expression
../../gcc/c/c-parser.c:6759
0x61ebe0 c_parser_expr_no_commas
../../gcc/c/c-parser.c:6676
0x61ee42 c_parser_expression
../../gcc/c/c-parser.c:9727
0x611c33 c_parser_postfix_expression
../../gcc/c/c-parser.c:8200
0x61c512 c_parser_unary_expression
../../gcc/c/c-parser.c:7380
0x61d537 c_parser_cast_expression
../../gcc/c/c-parser.c:7222
0x61d7e3 c_parser_binary_expression
../../gcc/c/c-parser.c:7025
0x61e695 c_parser_conditional_expression
../../gcc/c/c-parser.c:6759
0x61ebe0 c_parser_expr_no_commas
../../gcc/c/c-parser.c:6676
0x61b7c1 c_parser_direct_declarator_inner
../../gcc/c/c-parser.c:3844
0x62fbe1 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:1999
[Bug lto/88147] [9 Regression] ICE in linemap_line_start, at libcpp/line-map.c:781 starting from r265875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88147 --- Comment #18 from David Malcolm --- (In reply to Martin Liška from comment #15) > During the bug investigation I noticed a strange thing in line-map.c: > >700if (line_delta < 0 >701|| (line_delta > 10 >702&& line_delta * map->m_column_and_range_bits > 1000) >703|| (max_column_hint >= (1U << effective_column_bits)) >704|| (max_column_hint <= 80 && effective_column_bits >= 10) >705|| (highest > LINE_MAP_MAX_LOCATION_WITH_PACKED_RANGES >706&& map->m_range_bits > 0) >707|| (highest > LINE_MAP_MAX_LOCATION_WITH_COLS >708&& (set->max_column_hint || highest >= > LINE_MAP_MAX_LOCATION))) >709 add_map = true; > > m_column_and_range_bits > 1000 is always false as: > > /* Number of the low-order source_location bits used for column numbers > and ranges. */ > unsigned int m_column_and_range_bits : 8; > > and the sub-expression on lines 701 and 702 is ugly as well. > What's the purpose of the check? It's not: m_column_and_range_bits > 1000 it's: line_delta * map->m_column_and_range_bits > 1000 where line_delta is an int; presumably the 8 bits of the field get widened. The purpose of the check is impose a limit on the size of the jumps that occur within the location_t representation, so that if there's a big jump in line numbers, we start a linemap, where big is "> 1000" within the location_t value. The idea is to avoid wasting location_t values, without creating too many linemap instances.
[Bug lto/88147] [9 Regression] ICE in linemap_line_start, at libcpp/line-map.c:781 starting from r265875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88147 --- Comment #17 from David Malcolm --- Created attachment 45660 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45660&action=edit Selftest coverage The attached reproduces the problem via a minimal selftest, and is also fixed by attachment 45653.
[Bug c++/89285] [8/9 Regression] ICE after casting the this pointer in the constructor in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89285
--- Comment #6 from Jakub Jelinek ---
Bisected that to the finish_id_expression change, reverting the penultimate and
antepenultimate hunk of
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cp/semantics.c?limit_changes=0&r1=267272&r2=267271&pathrev=267272
makes gcc trunk reject the #c4 testcase again and ICE again with C bar {} which
should be valid. Ah, and likely that is the reason why the #c4 patch makes a
difference, previously it was just a REINTERPRET_CAST_P NOP_EXPR around
PARM_DECL, but now it is REINTERPRET_CAST_P NOP_EXPR around the location
wrapper nop and cp_fold optimizes that away.
[Bug middle-end/88560] [9 Regression] armv8_2-fp16-move-1.c and related regressions after r266385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560 --- Comment #15 from Tamar Christina --- Author: tnfchris Date: Mon Feb 11 16:54:18 2019 New Revision: 268772 URL: https://gcc.gnu.org/viewcvs?rev=268772&root=gcc&view=rev Log: Arm: Update tests after register allocation changes. (PR/target 88560) After the register allocator changes of r268705 we need to update a few tests with new output. In all cases the compiler is now generating the expected code, since the tests are all float16 testcases using a hard-floar abi, we expect that actual fp16 instructions are used rather than using integer loads and stores. Because of we also save on some mov.f16s that were being emitted before to move between the two. The aapcs cases now match the f32 cases in using floating point operations. gcc/testsuite/Changelog PR middle-end/88560 * gcc.target/arm/armv8_2-fp16-move-1.c: Update assembler scans. * gcc.target/arm/fp16-aapcs-1.c: Likewise. * gcc.target/arm/fp16-aapcs-3.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-1.c trunk/gcc/testsuite/gcc.target/arm/fp16-aapcs-1.c trunk/gcc/testsuite/gcc.target/arm/fp16-aapcs-3.c
[Bug c++/89287] New: Array declaration fails to use template conversion operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89287
Bug ID: 89287
Summary: Array declaration fails to use template conversion
operator
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: raphael.kubo.da.costa at intel dot com
Target Milestone: ---
(This is a reduction from a GCC + Chromium build issue)
Building the following excerpt with -std=gnu++14 causes GCC to fail, while
MSVC, clang and ICC work fine:
struct S {
template
constexpr operator U() const {
return static_cast(42);
}
};
void frob() {
new char[S()];
}
x.cc: In function ‘void frob()’:
x.cc:9:14: error: default type conversion can't deduce template argument for
‘template constexpr S::operator U() const’
new char[S()];
^
C++14 says in 8.3.4 Arrays that "If the constant-expression (5.20) is present,
it shall be a converted constant expression of type std::size_t and its value
shall be greater than zero", so I was expecting `new char[S()]' to end up
invoking S::operator size_t().
[Bug lto/88147] [9 Regression] ICE in linemap_line_start, at libcpp/line-map.c:781 starting from r265875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88147 --- Comment #16 from Martin Liška --- (In reply to Martin Liška from comment #14) > Created attachment 45653 [details] > Patch candidate > > Patch candidate that survives both reduced and not reduced test-cases. > David does the patch make sense? It survives regression tests and bootstrap on x86_64-linux-gnu.
[Bug c++/89285] [8/9 Regression] ICE after casting the this pointer in the constructor in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89285 --- Comment #5 from Jakub Jelinek --- Though, I wonder if something isn't wrong with the r267272 commit, I'd have thought that constexpr evaluation should be done on the pre-cp_folded bodies and cp_fold could be removing REINTERPRET_CAST_Ps.
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #24 from Bill Schmidt --- Why does this end up showing up after a test is run, rather than early like all the other target-supports checks? It would be less surprising if it acted like the others (and I would probably not have noticed to complain :).
[Bug c++/89285] [8/9 Regression] ICE after casting the this pointer in the constructor in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89285
Jakub Jelinek changed:
What|Removed |Added
Keywords||accepts-invalid
CC||jason at gcc dot gnu.org
Summary|[8 Regression] ICE after|[8/9 Regression] ICE after
|casting the this pointer in |casting the this pointer in
|the constructor in C++17|the constructor in C++17
|mode|mode
--- Comment #4 from Jakub Jelinek ---
Ok, so:
struct A {
int a {};
};
struct B {
int b {};
constexpr B (A *x) {
int *c = &x->a;
while (*c)
c = reinterpret_cast((reinterpret_cast(c) + *c));
*c = reinterpret_cast(this) - reinterpret_cast(c);
}
};
struct C : A {
B bar {this};
};
constexpr C foo {};
would then be accepts-invalid.
I've tried to fix that by doing:
--- gcc/cp/cp-gimplify.c(revision 268765)
+++ gcc/cp/cp-gimplify.c(working copy)
@@ -2307,6 +2307,22 @@ cp_fold (tree x)
&& TREE_OVERFLOW_P (x) && !TREE_OVERFLOW_P (op0))
TREE_OVERFLOW (x) = false;
+ /* Preserve REINTERPRET_CAST_P. */
+ if (code == NOP_EXPR && REINTERPRET_CAST_P (org_x))
+ {
+ if (TREE_CODE (x) == NOP_EXPR && REINTERPRET_CAST_P (x))
+ break;
+ if (TREE_CODE (x) == NOP_EXPR)
+ {
+ x = copy_node (x);
+ REINTERPRET_CAST_P (x) = 1;
+ }
+ else
+ {
+ x = build1_loc (loc, code, TREE_TYPE (x), x);
+ REINTERPRET_CAST_P (x) = 1;
+ }
+ }
break;
case INDIRECT_REF:
and with that we reject the testcase again (like we've done in 8.x, so this
part is [9 Regression] accepts-invalid).
But that also means we ICE again on the:
C bar {};
So, maybe we want to ignore that:
if (REINTERPRET_CAST_P (t))
{
if (!ctx->quiet)
error_at (cp_expr_loc_or_loc (t, input_location),
"a reinterpret_cast is not a constant expression");
*non_constant_p = true;
return t;
}
for perhaps !ctx->manifestly_const_eval , as in when we really don't require
constant expression. But we don't really call constexpr with zero
manifestly_const_eval anyway.
[Bug c++/89285] [8 Regression] ICE after casting the this pointer in the constructor in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89285 --- Comment #3 from Jonathan Wakely --- I think it's valid (but the constructor can't be used in a constant expression).
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #23 from Andrew Stubbs --- It's caused by the llvm_binutils check, which is used by pretty much every test to determine whether to complain about blank lines in compile output, or not. Right now the easiest way to determine if it's using that toolchain is to check if the target is amdgcn (that being the only target that needs it). I suppose llvm could also be detected by inspecting the --version output from -as, or some such. Your configuration isn't to blame.
[Bug fortran/89286] Intrinsic sign and GNU Extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89286 --- Comment #4 from MarkEggleston --- Missed some changes that should've gone in the change log. These included a couple of line that shouldn't have been there. Fixing patch and change log and will replace attachments when done.
[Bug fortran/89286] Intrinsic sign and GNU Extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89286 --- Comment #3 from MarkEggleston --- Created attachment 45659 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45659&action=edit Change Log for gcc/testsuite for patch Date to added later.
[Bug fortran/89286] Intrinsic sign and GNU Extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89286 --- Comment #2 from MarkEggleston --- Created attachment 45658 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45658&action=edit Change log for gcc/fortran for patch Date to added later.
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #22 from Bill Schmidt --- It also seems odd to me that all the other checks happen when reading powerpc.exp, prior to running my tests, but this one happens late: Running /home/wschmidt/gcc/gcc-mainline-test2/gcc/testsuite/gcc.target/powerpc/powerpc.exp ... [Test for linker_plugin] [Test for vsx_hw_available] Run my test [Test for offload_gcn]
[Bug c++/89285] [8 Regression] ICE after casting the this pointer in the constructor in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89285 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-11 CC||dmalcolm at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||redi at gcc dot gnu.org Target Milestone|--- |8.3 Summary|ICE after casting the this |[8 Regression] ICE after |pointer in the constructor |casting the this pointer in |in C++17 mode |the constructor in C++17 ||mode Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- This started to ICE with r259629 and stopped ICEing with r267272. Not really sure if this is ice-on-invalid (and thus accepts-invalid) on the trunk or just ice-on-valid on the branch, given the reinterpret_casts in the constexpr body.
[Bug fortran/87689] Memory corruption on Power 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689 --- Comment #10 from Alan Modra --- Replying to comment #4, yes, the function decl is wrong. It should have the full parameter list, or have none (ie. tree.c:prototype_p return false). The powerpc ELFv2 ABI works fine with non-prototyped function calls, but not with lying prototypes..
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #21 from Bill Schmidt --- Well, perhaps this is business as usual, but I'd still like to understand this a little better. What causes us to run the effective-target check for this thing in the first place? I've restricted my query with RUNTESTFLAGS to directories that contain powerpc.exp. To my knowledge, there's nothing in any such directory that cares about GPU offloading. So what causes the effective-target check? I'm okay with closing this, but would very much like to understand if we have an inefficiency here where we're running all sorts of checks that aren't needed for the tests being run. Or if we have something wrong in powerpc.exp that is causing this unnecessary effective-target check.
[Bug fortran/89286] Intrinsic sign and GNU Extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89286 --- Comment #1 from MarkEggleston --- Created attachment 45657 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45657&action=edit GNU extension to intrinsic SIGN Includes change to Intrinsic documentation.
[Bug fortran/89286] New: Intrinsic sign and GNU Extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89286 Bug ID: 89286 Summary: Intrinsic sign and GNU Extension Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mark.eggleston at codethink dot com Target Milestone: --- The GNU extension allows different kinds to used in the actual arguments to DIM, MOD, MODULO, MAX and MIN. The description of the arguments for SIGN are the same as for DIM, MOD and MODULO. I asked on this e-mail thread https://gcc.gnu.org/ml/fortran/2019-01/msg00301.html whether SIGN should also be covered by the GNU extension. Specifically in https://gcc.gnu.org/ml/fortran/2019-01/msg00303.html. I think it should hence this PR. Patch to follow.
[Bug fortran/87689] Memory corruption on Power 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #9 from Alan Modra --- The call in main is wrong. From comment #3 > Tree dump looks reasonable with 8.1: > > static integer(kind=4) C.2183 = 1; > static integer(kind=4) C.2184 = 2; > static integer(kind=4) C.2185 = 3; > static integer(kind=4) C.2186 = 4; > static integer(kind=4) C.2187 = 5; > static integer(kind=4) C.2188 = 6; > character(kind=1) str.0[20]; > > doesntwork_p8 ((character(kind=1)[1:20] *) &str.0, 20, &c, &C.2183, > &C.2184, &C.2185, &C.2186, &C.2187, &C.2188, 1); Looking at the assembly, I see r3 is &str.0, r4 is 20, r5 is &c, and so on up to r10 which is &C.2187. That's all good. The next arg, &C.2188 is stored on the stack at 32(1). That's wrong. It should be 96(1), ie. leaving 64 bytes of parameter save area. Similarly for the final "1", which is stored at 40(1) instead of 104(1). Debugging a little, it seems that the cause is that the fndecl found in expand_call is missing args. These lines in expand_call #ifdef REG_PARM_STACK_SPACE reg_parm_stack_space = REG_PARM_STACK_SPACE (!fndecl ? fntype : fndecl); #endif then calculate 0 for reg_parm_stack_space, which is correct for the given bogus fndecl. > SI size unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x768c19d8 attributes value >> arg-types chain chain >>> pointer_to_this > addressable used public external SI /home/alan/src/tmp/pr87689_main.f:7:0 align:32 warn_if_not_align:0 context chain >
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #20 from Jakub Jelinek --- Various effective targets are checked already in the initialization of various *.exp, etc. E.g. struct-layout-1.exp checks check_effective_target_short_enums, gomp.exp checks check_effective_target_fopenmp, dfp.exp checks dfp effective target, lto.exp lto, sso.exp int32, ubsan.exp that -fsanitize=undefined works, many others. That is again normal and happens a lot. I really don't understand why you care about this. The log file is indeed verbose and prints everything that has been executed. Are you upset that there is fatal error: in there, or even error: would upset you (as I said above, that happens e.g. with ilp32 or lp64 etc. if those fail).
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #19 from Bill Schmidt --- Specifially, I asked to compile only srad-modulo.c, but I end up with a compilation of offload_gcn7262.c in my log when I do not configure in any way to test for this.
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #18 from Bill Schmidt --- (In reply to Jakub Jelinek from comment #16) > I don't see why this should be reopened. Many of the effective target > procedures leave some output in the log files, that is completely normal. > Why should this one be an exception? This is running a test that nobody asked for. I don't understand why the effective target is even being checked!!
[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88920 --- Comment #17 from Andrew Stubbs --- If this is going to annoy a lot of people then I suppose I could add an additional message stating that the error can safely be ignored? Or, maybe there's a way to silence/hide the output from check_no_compiler_messages?
