[Bug target/87839] [9 Regression] ICE in final_scan_insn_1, at final.c:3070
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87839 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|2018-11-01 00:00:00 |2018-11-13 CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- --- gcc/config/aarch64/atomics.md.jj2018-11-01 12:06:43.469963662 +0100 +++ gcc/config/aarch64/atomics.md 2018-11-13 09:59:35.660185116 +0100 @@ -71,7 +71,7 @@ (match_operand:GPI 1 "aarch64_sync_memory_operand" "+Q")) ;; memory (set (match_dup 1) (unspec_volatile:GPI - [(match_operand:GPI 2 "aarch64_plus_operand" "rn") ;; expect + [(match_operand:GPI 2 "aarch64_plus_operand" "rIJ") ;; expect (match_operand:GPI 3 "aarch64_reg_or_zero" "rZ");; desired (match_operand:SI 4 "const_int_operand");; is_weak (match_operand:SI 5 "const_int_operand");; mod_s fixes this.
[Bug target/87762] [9 Regression] extract_constrain_insn, at recog.c:2206 on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87762 --- Comment #5 from Ilya Leoshkevich --- Martin, I believe I fixed this one. Could you please give it another try?
[Bug target/87839] [9 Regression] ICE in final_scan_insn_1, at final.c:3070
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87839 --- Comment #2 from Jakub Jelinek --- Created attachment 44994 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44994&action=edit gcc9-pr87839.patch Untested fix.
[Bug target/87762] [9 Regression] extract_constrain_insn, at recog.c:2206 on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87762 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Liška --- Fixed.
[Bug lto/87988] [9 regression] Streaming of ABSTRACT_ORIGIN is expensive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87988 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-11-13 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- The full TREE_DIE thing won't materialize but I have an idea to "hack" around the special case of BLOCK_ABSTRACT_ORIGIN.
[Bug rtl-optimization/88001] New: ASMCONS cannot handle properly UNSPEC(CONST)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88001
Bug ID: 88001
Summary: ASMCONS cannot handle properly UNSPEC(CONST)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: claziss at gmail dot com
Target Milestone: ---
ASMCONS cannot handle CONST (UNSPEC) properly, leading to a wrong
output.
I have the following rtl before asmcons pass:
(insn 8 13 9 2 (set (reg:SI 157 [ list ])
(asm_operands:SI ("") ("=g") 0 [
(const:SI (unspec:SI [
(symbol_ref:SI ("c_const") [flags 0x2] )
] ARC_UNSPEC_GOTOFFPC))
]
[
(asm_input:SI ("0") ../t02.c:9)
]
[] ../t02.c:9)) ../t02.c:9 -1
(nil))
Asmcons pass leads to this:
(insn 13 3 8 2 (set (reg:SI 157 [ list ])
(const:SI (unspec:SI [
(symbol_ref:SI ("c_const") [flags 0x2] )
] ARC_UNSPEC_GOTOFFPC))) ../t02.c:9 -1
(nil))
(insn 8 13 9 2 (set (reg:SI 157 [ list ])
(asm_operands:SI ("") ("=g") 0 [
(const:SI (unspec:SI [
(symbol_ref:SI ("c_const") [flags 0x2] )
] ARC_UNSPEC_GOTOFFPC))
]
[
(asm_input:SI ("0") ../t02.c:9)
]
[] ../t02.c:9)) ../t02.c:9 -1
(nil))
Which will lead latter on to an ICE when we verify the rtx sharing.
My test program is this one, and it needs to be compiled for ARC backend with
the following options: -mcpu=archs -O2 -fpic
typedef void (*func_ptr) (void);
static func_ptr __DTOR_LIST__[1] = { (func_ptr)(-1) };
void foo (int a)
{
func_ptr *dtor_list;
__asm ("" : "=g" (dtor_list) : "0" (__DTOR_LIST__));
dtor_list[a]();
}
[Bug c++/87989] [8/9 Regression] Calling operator T() invokes wrong conversion operator overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87989 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |8.3 Summary|Calling operator T()|[8/9 Regression] Calling |invokes wrong conversion|operator T() invokes wrong |operator overload |conversion operator ||overload
[Bug rtl-optimization/88001] ASMCONS cannot handle properly UNSPEC(CONST)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88001
Claudiu Zissulescu changed:
What|Removed |Added
CC||claziss at gmail dot com
--- Comment #1 from Claudiu Zissulescu ---
My solution, on a side branch, is this patch, but we need it to run also for
mainline gcc as we cannot build glibc or uclibc toolchains. Any help is
appreciated.
---
gcc/function.c | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/gcc/function.c b/gcc/function.c
index 302438323c8..36227f77074 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -6374,6 +6374,37 @@ make_pass_thread_prologue_and_epilogue (gcc::context
*ctxt)
}
+/* Helper match_asm_constraints_1. */
+static int
+constant_overlap_mentioned_p (const_rtx x, const_rtx in)
+{
+ const char *fmt;
+ int i, j;
+
+ if (CONST_INT_P (in))
+return 0;
+
+ if (!CONSTANT_P (in))
+return 0;
+
+ if (x == 0)
+return 0;
+
+ if (x == in)
+return 1;
+
+ fmt = GET_RTX_FORMAT (GET_CODE (x));
+ for (i = GET_RTX_LENGTH (GET_CODE (x)) - 1; i >= 0; i--)
+{
+ if (fmt[i] == 'e')
+return constant_overlap_mentioned_p (XEXP (x, i), in);
+ else if (fmt[i] == 'E')
+ for (j = XVECLEN (x, i) - 1; j >= 0; j--)
+ return constant_overlap_mentioned_p (XVECEXP (x, i, j), in);
+}
+ return 0;
+}
+
/* This mini-pass fixes fall-out from SSA in asm statements that have
in-out constraints. Say you start with
@@ -6509,7 +6540,8 @@ match_asm_constraints_1 (rtx_insn *insn, rtx *p_sets, int
noutputs)
SET_DEST (p_sets[j]) = replace_rtx (SET_DEST (p_sets[j]),
input, output);
for (j = 0; j < ninputs; j++)
- if (reg_overlap_mentioned_p (input, RTVEC_ELT (inputs, j)))
+ if (reg_overlap_mentioned_p (input, RTVEC_ELT (inputs, j))
+ || constant_overlap_mentioned_p (RTVEC_ELT (inputs, j), input))
RTVEC_ELT (inputs, j) = replace_rtx (RTVEC_ELT (inputs, j),
input, output);
--
2.19.1
[Bug rtl-optimization/87918] [9 Regression] ICE in simplify_binary_operation, at simplify-rtx.c:2153 since r264688
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87918 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Tue Nov 13 09:45:50 2018 New Revision: 266062 URL: https://gcc.gnu.org/viewcvs?rev=266062&root=gcc&view=rev Log: PR rtl-optimization/87918 * simplify-rtx.c (simplify_merge_mask): For COMPARISON_P, use simplify_gen_relational rather than simplify_gen_binary. * gcc.target/i386/pr87918.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr87918.c Modified: trunk/gcc/ChangeLog trunk/gcc/simplify-rtx.c trunk/gcc/testsuite/ChangeLog
[Bug target/77728] [5 Regression] Miscompilation multiple vector iteration on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728 Martin Beeger changed: What|Removed |Added CC||pizzard at online dot de --- Comment #63 from Martin Beeger --- A annoyance with the fix in GCC7 is that it produces a lot of warnings from the STL I can do very little about. As we are aiming for a warning-free build I would like to supress these warnings. The problem is, that i cannot specifically supress this warning without suppressing all warning about ABI breaks for every other reason too. Would it be useful to add a compiler switch for this problem specifically?
[Bug libstdc++/40380] class documentation should mention include file to use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40380 --- Comment #4 from Jonathan Wakely --- Busg like this make me wonder if we wouldn't be better simply replacing our Doxygen API docs with a link to cppreference.com which is far more complete and has better formatting and cross referencing.
[Bug libgomp/87995] [9 regression] libgomp.c/../libgomp.c-c++-common/cancel-taskgroup-3.c fails consistently after r265930
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87995 Richard Biener changed: What|Removed |Added Target Milestone|--- |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 Richard Biener changed: What|Removed |Added Keywords||diagnostic Target Milestone|--- |8.3
[Bug lto/87988] [9 regression] Streaming of ABSTRACT_ORIGIN is expensive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87988 --- Comment #2 from Richard Biener --- Created attachment 44995 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44995&action=edit untested patch It's surprisingly difficult to hack around things ... but the attached at least survives lto.exp testing. Can you see if it fixes the regression? I very much expect it to break FAT objects since I "wreck" abstract origins in a way others may not be hapoy about.
[Bug rtl-optimization/85925] [7/8/9 regression] Mis-compilation at -02, masking with 257 goes wrong in combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85925 --- Comment #14 from Eric Botcazou --- > (so pretty much the same, but the previous runs had some weird pollution). Thanks, slightly better though.
[Bug c++/87967] [9 Regression] ICE in slpeel_duplicate_current_defs_from_edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87967 --- Comment #3 from Richard Biener --- No, it's different. We somehow fail to make a 2nd PHI in the vectorization of the inner loop.
[Bug tree-optimization/87974] [9 Regression] ICE in vect_get_vec_def_for_stmt_copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87974 --- Comment #2 from Richard Biener --- No, it's different. We somehow fail to make a 2nd PHI in the vectorization of the inner loop.
[Bug testsuite/88002] New: libbacktrace and libiberty tests don't use dejagnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88002 Bug ID: 88002 Summary: libbacktrace and libiberty tests don't use dejagnu Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- When grepping "make check" output, we find a number of passes: ... $ grep ^PASS CHECKLOG PASS: test-expandargv-0. PASS: test-expandargv-1. PASS: test-expandargv-2. PASS: test-expandargv-3. PASS: test-expandargv-4. PASS: test-expandargv-5. PASS: test-expandargv-6. PASS: test-strtol-0. PASS: test-strtol-1. PASS: test-strtol-2. PASS: test-strtol-3. PASS: test-strtol-4. PASS: test-strtol-5. PASS: test-strtol-6. PASS: test-strtol-7. PASS: test-strtol-8. PASS: test-strtol-9. PASS: test-strtol-10. PASS: test-strtol-11. PASS: test-strtol-12. PASS: test-strtol-13. PASS: test-strtol-14. PASS: test-strtol-15. PASS: test-strtol-16. PASS: test-strtol-17. PASS: test-strtol-18. PASS: test-strtol-19. PASS: test-strtol-20. PASS: btest PASS: edtest PASS: stest PASS: ctestg PASS: ctesta PASS: dtest PASS: ttest PASS: btest PASS: stest PASS: ztest PASS: edtest PASS: ztest PASS: ctestg PASS: ttest PASS: ctesta ... The passes come from the test suites of libiberty and libbacktrace, which are not using dejagnu. Consequently the PASS/FAILs are not included in any .sum files, so when comparing test results using .sum files, a regression in these tests will go unnoticed. Also, a consequence of not using dejagnu is that RUNTESTFLAGS are ignored. [ Btw, note that the libbacktrace tests (btest etc) are run twice, once for build/libbacktrace and once for build//libbacktrace. ]
[Bug c++/87967] [9 Regression] ICE in slpeel_duplicate_current_defs_from_edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87967 --- Comment #4 from Richard Biener --- (In reply to Richard Biener from comment #3) > No, it's different. We somehow fail to make a 2nd PHI in the vectorization > of the inner loop. Err, wrong bug. (gdb) p debug_gimple_stmt (from_phi) prephitmp_86 = PHI $7 = void (gdb) p debug_gimple_stmt (to_phi) a_57 = PHI another case of a PHI mixup... :/ Simple omission in the cited rev.
[Bug c++/88003] New: ICE on outside definition of inner function-local class in poplevel_class, at cp/name-lookup.c:4325
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88003
Bug ID: 88003
Summary: ICE on outside definition of inner function-local
class in poplevel_class, at cp/name-lookup.c:4325
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eugvelesevich at gmail dot com
Target Milestone: ---
Source:
auto test() {
struct O {
struct N;
};
return O();
}
struct decltype(test())::N {};
Output:
g++ -std=c++14 -S -x c++ -
source>:8:29: internal compiler error: in poplevel_class, at
cp/name-lookup.c:2931
struct decltype(test())::N {};
^
All gcc versions supporting c++14 crash.
I'm not sure that decltype usage in this place is correct, but it can be
replaced with:
typedef decltype(test()) TN;
struct TN::N {};
Could be related to bug #84691?
[Bug lto/87988] [9 regression] Streaming of ABSTRACT_ORIGIN is expensive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87988 --- Comment #3 from Jan Hubicka --- Thanks, I will give it a try. Note that the numbers I posted are from trunk and trunk with abstract origin streaming disabled. Thanks to the type streaming reorg we do not have overall regression relative to gcc8: [WPA] read 14320726 SCCs of average size 1.594004 [WPA] 22827300 tree bodies read in total [WPA] tree SCC table: size 8388593, 3202920 elements, collision ratio: 0.923241 [WPA] tree SCC max chain length 173 (size 2) [WPA] Compared 4496372 SCCs, 3676586 collisions (0.817678) [WPA] Merged 4480405 SCCs [WPA] Merged 11209786 tree bodies [WPA] Merged 2602183 types [WPA] 1837633 types prevailed (3482639 associated trees) [WPA] GIMPLE canonical type table: size 32749, 22890 elements, 278542 searches, 119444 collisions (ratio: 0.428819) [WPA] GIMPLE canonical type pointer-map: 22890 elements, 629811 searches [WPA] # of input files: 2236 [WPA] Compression: 347027044 input bytes, 1054806677 uncompressed bytes (ratio: 3.039552) Overall size of streamed ltrans.o files is 1.7GB So abstract origins are definitely important to solve, but we are not in desperate situation for GCC9 unless other testcases turns out to behave worse than firefox (I am in progress of testing other stuff)
[Bug rtl-optimization/87817] [9 Regression] gcc.target/i386/bmi2-bzhi-2.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87817
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
The important question is if ZERO_EXTRACT is well defined with zero SIZE and
what it means. And another question is if SIGN_EXTRACT is well defined with
zero SIZE and if yes, how would we define it.
If it is defined, we could do something like:
--- gcc/combine.c.jj2018-11-12 16:18:28.656552899 +0100
+++ gcc/combine.c 2018-11-13 13:08:38.776716046 +0100
@@ -7271,6 +7271,15 @@ expand_compound_operation (rtx x)
if (len + pos > GET_MODE_PRECISION (inner_mode))
return x;
+ if (len == 0)
+ {
+ /* Extracting no bits for ZERO_EXTRACT always yields 0. */
+ if (unsignedp)
+ return CONST0_RTX (GET_MODE (x));
+ /* For SIGN_EXTRACT it is undefined. */
+ return x;
+ }
+
if (BITS_BIG_ENDIAN)
pos = GET_MODE_PRECISION (inner_mode) - len - pos;
which fixes this PR, but we have other spots that would need tweaking, e.g.
simplify-rtx.c, another spot in the combiner etc.
Another possibility is to say that both are UB with zero SIZE and define the
pattern differently.
[Bug lto/88004] [9 Regression] lto1: error: node differs from node->decl->decl_with_vis.symtab_node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88004 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Target Milestone|--- |9.0 Known to fail||9.0
[Bug lto/88004] New: [9 Regression] lto1: error: node differs from node->decl->decl_with_vis.symtab_node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88004 Bug ID: 88004 Summary: [9 Regression] lto1: error: node differs from node->decl->decl_with_vis.symtab_node Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Happens for a ObjC code in gnustep-base package. Unfortunately, I can't find a smaller test-case for it. I'll attach IPA dump file, hopefully Honza will see anything.
[Bug lto/88004] [9 Regression] lto1: error: node differs from node->decl->decl_with_vis.symtab_node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88004 --- Comment #1 from Martin Liška --- Created attachment 44996 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44996&action=edit Callgraph dump
[Bug rtl-optimization/87817] [9 Regression] gcc.target/i386/bmi2-bzhi-2.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87817
--- Comment #2 from Jakub Jelinek ---
E.g. in simplify-rtx.c we have:
case SIGN_EXTRACT:
case ZERO_EXTRACT:
if (CONST_INT_P (op0)
&& CONST_INT_P (op1)
&& CONST_INT_P (op2)
&& is_a (mode, &int_mode)
&& INTVAL (op1) + INTVAL (op2) <= GET_MODE_PRECISION (int_mode)
&& HWI_COMPUTABLE_MODE_P (int_mode))
{
/* Extracting a bit-field from a constant */
unsigned HOST_WIDE_INT val = UINTVAL (op0);
HOST_WIDE_INT op1val = INTVAL (op1);
HOST_WIDE_INT op2val = INTVAL (op2);
if (!BITS_BIG_ENDIAN)
val >>= op2val;
else if (is_a (op0_mode, &int_op0_mode))
val >>= GET_MODE_PRECISION (int_op0_mode) - op2val - op1val;
else
/* Not enough information to calculate the bit position. */
break;
if (HOST_BITS_PER_WIDE_INT != op1val)
{
/* First zero-extend. */
val &= (HOST_WIDE_INT_1U << op1val) - 1;
/* If desired, propagate sign bit. */
if (code == SIGN_EXTRACT
&& (val & (HOST_WIDE_INT_1U << (op1val - 1)))
!= 0)
val |= ~ ((HOST_WIDE_INT_1U << op1val) - 1);
}
return gen_int_mode (val, int_mode);
}
where for ZERO_EXTRACT we actually return CONST0_RTX (int_mode) if op1val == 0,
but can invoke UB before that in the big endian shift. For SIGN_EXTRACT we
invoke UB in any case, HOST_WIDE_INT_1U << (-1).
Note, the bzhi patterns aren't the only ones that rely on ZERO_EXTRACT being
defined for size 0, e.g. bextr does as well.
[Bug target/88005] New: [6/7/8/9] Regression GCC on hppa misoptimisation function pointer call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88005
Bug ID: 88005
Summary: [6/7/8/9] Regression GCC on hppa misoptimisation
function pointer call
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: skrll at netbsd dot org
Target Milestone: ---
Here's a testcase
typedef int (*pdcio_t)(int, int, ...);
pdcio_t pdc;
int pdcbuf[64] __attribute__ ((__aligned__(64)));
struct pagezero {
int (*mem_pdc)(void);
};
void
pdc_init(void)
{
int err;
pdc = (pdcio_t)((struct pagezero *)0)->mem_pdc;
err = (*pdc)(10, 2, pdcbuf, 0, 0);
}
Here's the generated code
.LEVEL 1.1
.text
.align 4
.globl pdc_init
.type pdc_init, @function
pdc_init:
.PROC
.CALLINFO FRAME=0,NO_CALLS
.ENTRY
ldw 0(%r0),%r28
addit,<> 1,%r0,%r0
.EXIT
.PROCEND
.size pdc_init, .-pdc_init
.comm pdcbuf,256,64
.comm pdc,4,4
.ident "GCC: (GNU) 9.0.0 20181112 (experimental)"
---
[Bug fortran/87994] ICE in match_data_constant, at fortran/decl.c:399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87994 Thomas Koenig changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-13 CC||tkoenig at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/87993] ICE in gfc_constructor_first, at fortran/constructor.c:234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87993 Thomas Koenig changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-13 CC||tkoenig at gcc dot gnu.org Blocks||87994 Ever confirmed|0 |1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87994 [Bug 87994] ICE in match_data_constant, at fortran/decl.c:399
[Bug fortran/87992] ICE in resolve_fl_variable, at fortran/resolve.c:12314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87992 Thomas Koenig changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-13 CC||tkoenig at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/87991] ICE in gfc_constructor_append_expr, at fortran/constructor.c:135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87991 Thomas Koenig changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-13 CC||tkoenig at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/87994] ICE in match_data_constant, at fortran/decl.c:399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87994 --- Comment #2 from Dominique d'Humieres --- Related to/duplicate of pr87881/pr87945/pr87993. > Changed between 20181028 and 20181104 (ICE). Parameter inquiry has been introduced at revision r265729: before it gave the error Error: Unexpected '%' for nonderived-type variable 'a' at (1) IMO you should give Paul a chance to fix pr87881 before filing new PRs.
[Bug tree-optimization/86991] [8/9 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6919
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86991 --- Comment #4 from Richard Biener --- So the reason in the end is failure to tear down a half-built reduction chain. I have a fix (finally).
[Bug fortran/87993] ICE in gfc_constructor_first, at fortran/constructor.c:234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87993 --- Comment #2 from Dominique d'Humieres --- Related to/duplicate of pr87881/pr87945/pr87994.
[Bug fortran/87881] gfortran.dg/inquiry_type_ref_(1.f08|3.f90) fail on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87881 --- Comment #6 from Dominique d'Humieres --- Related to/duplicate of pr87993 and pr87994.
[Bug c++/87967] [9 Regression] ICE in slpeel_duplicate_current_defs_from_edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87967 --- Comment #5 from Richard Biener --- Author: rguenth Date: Tue Nov 13 13:50:18 2018 New Revision: 266070 URL: https://gcc.gnu.org/viewcvs?rev=266070&root=gcc&view=rev Log: 2018-11-13 Richard Biener PR tree-optimization/87967 * tree-vect-loop.c (vect_transform_loop): Also copy PHIs for constants for the scalar loop. * g++.dg/opt/pr87967.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/opt/pr87967.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/87967] [9 Regression] ICE in slpeel_duplicate_current_defs_from_edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87967 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Component|c++ |tree-optimization Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug tree-optimization/87962] [9 Regression] ICE in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87962 --- Comment #5 from Richard Biener --- Author: rguenth Date: Tue Nov 13 13:51:34 2018 New Revision: 266071 URL: https://gcc.gnu.org/viewcvs?rev=266071&root=gcc&view=rev Log: 2018-11-13 Richard Biener PR tree-optimization/87962 * tree-vect-loop.c (vect_is_simple_reduction): More reliably detect outer reduction for disqualifying in-loop uses. * gcc.dg/pr87962.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr87962.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/87962] [9 Regression] ICE in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87962 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug target/88005] [7/8/9 Regression] GCC on hppa misoptimisation function pointer call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88005 Richard Biener changed: What|Removed |Added Target||hppa CC||danglin at gcc dot gnu.org Target Milestone|--- |7.4 Summary|[6/7/8/9] Regression GCC on |[7/8/9 Regression] GCC on |hppa misoptimisation|hppa misoptimisation |function pointer call |function pointer call
[Bug lto/87988] [9 regression] Streaming of ABSTRACT_ORIGIN is expensive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87988 --- Comment #4 from Richard Biener --- OK, I'd rather not put this hack on trunk. Iff then a very limited scope TREE_DIE (same cases as the hack) should be brought in.
[Bug debug/88006] New: -fdebug-types-section gives undefined reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88006 Bug ID: 88006 Summary: -fdebug-types-section gives undefined reference Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: nathan at gcc dot gnu.org Target Milestone: --- Created attachment 44997 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44997&action=edit testcase -O1 or -O2 cause the problem This program results in undefined ref to _ZN3Foo4mfunEv this is not the same bug as 87462, the breaking commit appears to be r241753 2016-11-01 Jakub Jelinek * dwarf2out.c (add_name_and_src_coords_attributes): Add NO_LINKAGE_NAME argument, don't call add_linkage_name if it is true. (gen_variable_die): For C++ inline static data members, consider the initial call when old_die is NULL to be declaration and call add_name_and_src_coords_attributes in that case with true as NO_LINKAGE_NAME. Add DW_AT_inline attribute if needed. (gen_member_die): For C++ inline static data members, emit a definition DIE right away in DW_TAG_compile_unit context.
[Bug testsuite/88002] libbacktrace and libiberty tests don't use dejagnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88002 --- Comment #1 from Ian Lance Taylor --- I really have no intention of running the libbacktrace tests under DejaGNU. But if someone wants to copy the .sum file generation out of libgo (which also does not use DejaGNU), that would be fine with me.
[Bug rtl-optimization/87817] [9 Regression] gcc.target/i386/bmi2-bzhi-2.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87817 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-11-13 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Jakub Jelinek --- Created attachment 44998 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44998&action=edit gcc9-pr87817.patch Untested patch to resolve this in the backend.
[Bug target/88005] [7/8/9 Regression] GCC on hppa misoptimisation function pointer call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88005 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #1 from Alexander Monakov --- Isn't simply because the code dereferences a null pointer when assigning to 'pdc'? Does it "work" as expected with -fno-delete-null-pointer-checks?
[Bug sanitizer/87930] [8/9 Regression] ICE in emit_library_call_value_1, at calls.c:5422 since r249903
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87930
--- Comment #4 from Martin Liška ---
Author: marxin
Date: Tue Nov 13 15:03:58 2018
New Revision: 266073
URL: https://gcc.gnu.org/viewcvs?rev=266073&root=gcc&view=rev
Log:
Do not allow -mabi=ms and -fsanitize={,kernel-}address (PR sanitizer/87930).
2018-11-13 Martin Liska
PR sanitizer/87930
* config/i386/i386.c (ix86_option_override_internal): Error
about usage -mabi=ms and -fsanitize={,kernel-}address.
2018-11-13 Martin Liska
PR sanitizer/87930
* gcc.target/i386/pr87930.c: New test.
Added:
trunk/gcc/testsuite/gcc.target/i386/pr87930.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/87930] [8/9 Regression] ICE in emit_library_call_value_1, at calls.c:5422 since r249903
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87930 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Liška --- Fixed.
[Bug tree-optimization/87931] [9 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6193 since r265876
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87931 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/87931] [9 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6193 since r265876
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87931 --- Comment #5 from Richard Biener --- Author: rguenth Date: Tue Nov 13 15:07:53 2018 New Revision: 266075 URL: https://gcc.gnu.org/viewcvs?rev=266075&root=gcc&view=rev Log: 2018-11-13 Richard Biener PR tree-optimization/87931 * tree-vect-loop.c (vect_is_simple_reduction): Restrict nested cycles we support to latch computations vectorizable_reduction handles. * gcc.dg/graphite/pr87931.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/graphite/pr87931.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/87885] ICE in release_ssa_name_fn with -fprofile-report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87885 --- Comment #5 from Martin Liška --- Author: marxin Date: Tue Nov 13 15:06:54 2018 New Revision: 266074 URL: https://gcc.gnu.org/viewcvs?rev=266074&root=gcc&view=rev Log: Improve -fprofile-report. 2018-11-13 Martin Liska PR tree-optimization/87885 * cfghooks.c (account_profile_record): Rename to ... (profile_record_check_consistency): ... this. Calculate missing num_mismatched_freq_in. (profile_record_account_profile): New function that calculates time and size of a function. * cfghooks.h (struct profile_record): Remove all tuples. (struct cfg_hooks): Remove after_pass flag. (account_profile_record): Rename to ... (profile_record_check_consistency): ... this. (profile_record_account_profile): New. * cfgrtl.c (rtl_account_profile_record): Remove after_pass flag. * passes.c (check_profile_consistency): Do only checking. (account_profile): Calculate size and time of function only. (pass_manager::dump_profile_report): Reformat output. (execute_one_ipa_transform_pass): Call consistency check before clean upand call account_profile after a clean up is done. (execute_one_pass): Call check_profile_consistency and account_profile instead of using after_pass flag.. * tree-cfg.c (gimple_account_profile_record): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/cfghooks.c trunk/gcc/cfghooks.h trunk/gcc/cfgrtl.c trunk/gcc/passes.c trunk/gcc/tree-cfg.c
[Bug tree-optimization/87885] ICE in release_ssa_name_fn with -fprofile-report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87885 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Liška --- Fixed.
[Bug lto/48200] Implement function attribute for symbol versioning (.symver)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 Martin Liška changed: What|Removed |Added Assignee|marxin at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #27 from Martin Liška --- Assigning to Honza at will require usage of transparent aliases, so some extra work will be needed.
[Bug target/88005] [7/8/9 Regression] GCC on hppa misoptimisation function pointer call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88005 --- Comment #2 from Nick Hudson --- yes, it does. Nick nick@zoom:~/gcc$ ./inst/bin/hppa--linux-gcc -O2 -fno-delete-null-pointer-checks -S -o pdc.s pdc.i nick@zoom:~/gcc$ cat pdc.s .LEVEL 1.1 .text .align 4 .globl pdc_init .type pdc_init, @function pdc_init: .PROC .CALLINFO FRAME=64,CALLS,SAVE_RP .ENTRY stw %r2,-20(%r30) addil LR'pdc-$global$,%r27 ldo 64(%r30),%r30 ldw 0(%r0),%r22 ldo RR'pdc-$global$(%r1),%r1 stw %r0,-52(%r30) ldi 0,%r23 stw %r22,0(%r1) addil LR'pdcbuf-$global$,%r27 ldi 2,%r25 ldo RR'pdcbuf-$global$(%r1),%r24 ldi 10,%r26 bb,>=,n %r22,30,.+12 ldw 2(%r22),%r19 ldw -2(%r22),%r22 ble 0(%sr4,%r22) copy %r31,%r2 ldw -84(%r30),%r2 bv %r0(%r2) ldo -64(%r30),%r30 .EXIT .PROCEND .size pdc_init, .-pdc_init .comm pdcbuf,256,64 .comm pdc,4,4 .ident "GCC: (GNU) 9.0.0 20181112 (experimental)" nick@zoom:~/gcc$ (In reply to Alexander Monakov from comment #1) > Isn't simply because the code dereferences a null pointer when assigning to > 'pdc'? Does it "work" as expected with -fno-delete-null-pointer-checks?
[Bug target/88005] [7/8/9 Regression] GCC on hppa misoptimisation function pointer call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88005 Alexander Monakov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Alexander Monakov --- Thus invalid.
[Bug target/88005] [7/8/9 Regression] GCC on hppa misoptimisation function pointer call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88005 --- Comment #4 from dave.anglin at bell dot net --- On 2018-11-13 10:21 a.m., skrll at netbsd dot org wrote: > yes, it does. So, the bug should be closed. Dave
[Bug tree-optimization/87898] [8/9 Regression] ICE in separate_decls_in_region_debug, at tree-parloops.c:961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87898 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-11-13 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 44999 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44999&action=edit gcc9-pr87898.patch Untested fix.
[Bug ipa/87955] [9 Regression] ICE in cl_target_option_print_diff at gcc/options-save.c:3803 since r265920
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87955 --- Comment #3 from David Malcolm --- Author: dmalcolm Date: Tue Nov 13 15:59:57 2018 New Revision: 266079 URL: https://gcc.gnu.org/viewcvs?rev=266079&root=gcc&view=rev Log: Fix ICE with -fopt-info-inline (PR ipa/87955) PR ipa/87955 reports a problem I introduced in r265920, where I converted the guard in report_inline_failed_reason from using: if (dump_file) to using if (dump_enabled_p ()). without updating the calls to cl_target_option_print_diff and cl_optimization_print_diff, which assume that dump_file is non-NULL. The functions are auto-generated. Rather than porting them to the dump API, this patch applies the workaround of adding the missing checks on dump_file before calling them. gcc/ChangeLog: PR ipa/87955 * ipa-inline.c (report_inline_failed_reason): Guard calls to cl_target_option_print_diff and cl_optimization_print_diff with if (dump_file). gcc/testsuite/ChangeLog: PR ipa/87955 * gcc.target/i386/pr87955.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr87955.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/87955] [9 Regression] ICE in cl_target_option_print_diff at gcc/options-save.c:3803 since r265920
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87955 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from David Malcolm --- Should be fixed by r266079.
[Bug rtl-optimization/87718] [9 Regression] FAIL: gcc.target/i386/avx512dq-concatv2si-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87718 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Vlad, could you please have a look?
[Bug rtl-optimization/87552] [9 regression] FAIL: gcc.c-torture/compile/20010102-1.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87552 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug other/88007] New: [9 Regression] ICE in gt_ggc_m_S, at ggc-page.c:1474
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88007 Bug ID: 88007 Summary: [9 Regression] ICE in gt_ggc_m_S, at ggc-page.c:1474 Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: GC, ice-on-valid-code Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: x86_64-unknown-linux-gnu gcc-9.0.0-alpha2018 snapshot (r266019) ICEs during GC when compiling gcc/testsuite/gcc.dg/pr84100.c w/ unusual --param ggc-min-expand=3 --param ggc-min-heapsize=1024: % x86_64-unknown-linux-gnu-gcc-9.0.0-alpha2018 --param ggc-min-expand=3 --param ggc-min-heapsize=1024 -c gcc/testsuite/gcc.dg/pr84100.c gcc/testsuite/gcc.dg/pr84100.c: In function 'foo': gcc/testsuite/gcc.dg/pr84100.c:15:1: internal compiler error: in gt_ggc_m_S, at ggc-page.c:1474 15 | } | ^ 0x5cf3b0 gt_ggc_m_S(void const*) /var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/ggc-page.c:1474 0xa989b7 gt_ggc_mx_cl_optimization(void*) /var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/build/gcc/gtype-desc.c:1471 0x7874f6 gt_ggc_mx_lang_tree_node(void*) ./gt-c-c-decl.h:487 0x786d83 gt_ggc_mx_lang_tree_node(void*) ./gt-c-c-decl.h:294 0x786f7e gt_ggc_mx_lang_tree_node(void*) ./gt-c-c-decl.h:381 0x786ed0 gt_ggc_mx_lang_tree_node(void*) ./gt-c-c-decl.h:360 0x786c72 gt_ggc_mx_lang_tree_node(void*) ./gt-c-c-decl.h:276 0xbedbc1 ggc_remove::ggc_mx(tree_node*&) /var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/hash-traits.h:235 0xbedbc1 ggc_remove::ggc_maybe_mx(tree_node*&) /var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/hash-traits.h:242 0xbedbc1 gt_ggc_mx /var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/hash-table.h:1053 0xbedbc1 gt_ggc_mx_hash_table_libfunc_decl_hasher_(void*) ./gt-optabs-libfuncs.h:28 0xbedbc1 gt_ggc_mx_hash_table_libfunc_decl_hasher_(void*) ./gt-optabs-libfuncs.h:23 0xa2e195 ggc_mark_root_tab /var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/ggc-common.c:77 0xa2e39c ggc_mark_roots() /var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/ggc-common.c:94 0x864046 ggc_collect() /var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/ggc-page.c:2201
[Bug tree-optimization/86991] [8/9 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6919
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86991 --- Comment #5 from Richard Biener --- Author: rguenth Date: Tue Nov 13 16:14:37 2018 New Revision: 266081 URL: https://gcc.gnu.org/viewcvs?rev=266081&root=gcc&view=rev Log: 2018-11-13 Richard Biener PR tree-optimization/86991 * tree-vect-loop.c (vect_is_slp_reduction): Delay reduction group building until we have successfully detected the SLP reduction. (vect_is_simple_reduction): Remove fixup code here. * gcc.dg/pr86991.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr86991.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/86991] [8 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6919
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86991 Richard Biener changed: What|Removed |Added Known to work||9.0 Summary|[8/9 Regression] ICE in |[8 Regression] ICE in |vectorizable_reduction, at |vectorizable_reduction, at |tree-vect-loop.c:6919 |tree-vect-loop.c:6919 Known to fail||8.2.1 --- Comment #6 from Richard Biener --- Fixed on trunk sofar.
[Bug c/88000] Different local vars regs order may produce different and so wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88000
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #4 from Martin Sebor ---
GCC could help by issuing a warning for unsupported uses, like in the prototype
patch below:
Index: gcc/c/c-typeck.c
===
--- gcc/c/c-typeck.c(revision 266033)
+++ gcc/c/c-typeck.c(working copy)
@@ -6505,6 +6505,14 @@ convert_for_assignment (location_t location, locat
objc_ok = objc_compare_types (type, rhstype, parmno, rname);
}
+ if (VAR_P (rhs) && DECL_HARD_REGISTER (rhs)
+ && warning_at (expr_loc, OPT_Wasm_register_var,
+"unsupported use of a hard register %qD as "
+"argument %d of %qE",
+rhs, parmnum, rname))
+inform (DECL_SOURCE_LOCATION (rhs),
+ "%qD declared here", rhs);
+
if (warn_cxx_compat)
{
tree checktype = origtype != NULL_TREE ? origtype : rhstype;
Index: gcc/c-family/c.opt
===
--- gcc/c-family/c.opt (revision 266033)
+++ gcc/c-family/c.opt (working copy)
@@ -338,6 +338,10 @@ Warray-bounds=
LangEnabledBy(C ObjC C++ LTO ObjC++,Wall,1,0)
; in common.opt
+Wasm-register-var
+ObjC ObjC++ Var(warn_asm_register_var) Warning LangEnabledBy(C ObjC C++
ObjC++, Wall)
+Warn for unsupported uses of variables declared asm register.
+
Wassign-intercept
ObjC ObjC++ Var(warn_assign_intercept) Warning
Warn whenever an Objective-C assignment is being intercepted by the garbage
collector.
[Bug other/88007] [9 Regression] ICE in gt_ggc_m_S, at ggc-page.c:1474
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88007 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Target Milestone|--- |9.0
[Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug middle-end/87899] [9 regression]r264897 cause mis-compiled native arm-linux-gnueabihf toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87899 Peter Bergner changed: What|Removed |Added URL|https://gcc.gnu.org/ml/gcc- |https://gcc.gnu.org/ml/gcc- |patches/2018-11/msg00890.ht |patches/2018-11/msg01118.ht |ml |ml --- Comment #7 from Peter Bergner --- Submitted updated patch that fixes the errors mentioned above.
[Bug rtl-optimization/87507] IRA unnecessarily uses non-volatile registers during register assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87507 Peter Bergner changed: What|Removed |Added URL|https://gcc.gnu.org/ml/gcc- |https://gcc.gnu.org/ml/gcc- |patches/2018-11/msg00887.ht |patches/2018-11/msg01120.ht |ml |ml --- Comment #10 from Peter Bergner --- Submitted a new patch that changes lower-subreg to decompose the problematic register pairs into separate regs which are easier to allocate.
[Bug bootstrap/87932] Missing profile count data file not found [-Wmissing-profile] during profiledbootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87932 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID --- Comment #2 from Martin Liška --- Ok, so apparently it's fine, note that we build libiberty twice (once in pic subfolder) and it looks some files are used only in of of these. Some files in libiberty have no coverage, e.g. : ../../libiberty/fdmatch.c:68:1: warning: ‘/home/mliska/Programming/gcc/objdir/libiberty/fdmatch.gcda’ profile count data file not found [-Wmissing-profile] ../../libiberty/fdmatch.c:68:1: warning: ‘/home/mliska/Programming/gcc/objdir/libiberty/pic/fdmatch.gcda’ profile count data file not found [-Wmissing-profile] For zlib and lto there's no coverage in train run. And gcc/gen*.c files are ok as these are used only in build, not in a built compiler. Thus closing..
[Bug c++/78244] Narrowing conversion is accepted in a function template, but it should be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78244 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- When we are tsubsting this it is from fold_nondependent_expr which is called with complain == tf_none and that is why nothing is reported.
[Bug fortran/79440] internal compiler error: in fold_convert_loc, at fold-const.c:2373
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79440 G. Steinmetz changed: What|Removed |Added CC||gs...@t-online.de --- Comment #3 from G. Steinmetz --- With slightly reduced example from comment 2 : $ cat z1.f90 program p type t end type type(t), allocatable :: x x = f() contains function f() result(z) class(t), allocatable :: z end end $ gfortran-9-2018 -c z1.f90 z1.f90:5:0: 5 |x = f() | internal compiler error: in fold_convert_loc, at fold-const.c:2548 0x8a9bb3 fold_convert_loc(unsigned int, tree_node*, tree_node*) ../../gcc/fold-const.c:2548 0x6c0fba gfc_allocate_using_malloc(stmtblock_t*, tree_node*, tree_node*, tree_node*) ../../gcc/fortran/trans.c:667 0x6fd9eb trans_class_assignment ../../gcc/fortran/trans-expr.c:10009 0x6fd9eb gfc_trans_assignment_1 ../../gcc/fortran/trans-expr.c:10400 0x6bfdaf trans_code ../../gcc/fortran/trans.c:1822 0x6e7674 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6509 0x6744d6 translate_all_program_units ../../gcc/fortran/parse.c:6125 0x6744d6 gfc_parse_file() ../../gcc/fortran/parse.c:6328 0x6bc89f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204 Compiles with type(t) instead.
[Bug middle-end/86718] [9 Regression] ICE during RTL pass: expand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86718 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jakub Jelinek --- Dup, already fixed. *** This bug has been marked as a duplicate of bug 86528 ***
[Bug fortran/87994] ICE in match_data_constant, at fortran/decl.c:399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87994 --- Comment #3 from G. Steinmetz --- Sure ...
[Bug middle-end/86528] [9 Regression] strlen of constant string malfunction -- had to back out fix for PR middle-end/77357
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86528 Jakub Jelinek changed: What|Removed |Added CC||zhonghao at pku dot org.cn --- Comment #8 from Jakub Jelinek --- *** Bug 86718 has been marked as a duplicate of this bug. ***
[Bug fortran/88008] New: [9 Regression] ICE in check_typebound_baseobject, at fortran/resolve.c:6058
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88008 Bug ID: 88008 Summary: [9 Regression] ICE in check_typebound_baseobject, at fortran/resolve.c:6058 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20181028 and 20181104 : $ cat z1.f90 module m type t integer, pointer :: z contains procedure :: g end type contains subroutine g(x) class(t) :: x call x%z%g() end end $ cat z2.f90 module m type t integer, pointer :: z contains procedure :: g end type contains recursive subroutine g(x) class(t) :: x call x%z%g() end end $ gfortran-9-20181028 -c z1.f90 z1.f90:10:14: 10 | call x%z%g() | 1 Error: Junk after CALL at (1) $ gfortran-9-2018 -c z1.f90 f951: internal compiler error: in check_typebound_baseobject, at fortran/resolve.c:6058 0x6902a8 check_typebound_baseobject ../../gcc/fortran/resolve.c:6058 0x69074a resolve_typebound_call ../../gcc/fortran/resolve.c:6303 0x685b53 resolve_typebound_subroutine ../../gcc/fortran/resolve.c:6625 0x685b53 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11474 0x6864af resolve_codes ../../gcc/fortran/resolve.c:16700 0x6863ee resolve_codes ../../gcc/fortran/resolve.c:16684 0x68657e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:16735 0x674132 gfc_parse_file() ../../gcc/fortran/parse.c:6266 0x6bc89f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug target/87870] ppc64le generates poor code when loading constants into TImode vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87870 Peter Bergner changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||https://gcc.gnu.org/ml/gcc- ||patches/2018-11/msg01124.ht ||ml Last reconfirmed||2018-11-13 Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/88009] New: [9 Regression] ICE in find_intrinsic_vtab, at fortran/class.c:2761
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88009 Bug ID: 88009 Summary: [9 Regression] ICE in find_intrinsic_vtab, at fortran/class.c:2761 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20180909 and 20180916 : $ cat z1.f90 module m class(*), allocatable :: z end block data use m z = 'z' end $ gfortran-9-20180909 -c z1.f90 z1.f90:6:10: 6 |z = 'z' | 1 Error: assignment statement is not allowed inside of BLOCK DATA at (1) z1.f90:6:10: 6 |z = 'z' | 1 Error: Unexpected assignment statement in BLOCK DATA at (1) $ gfortran-9-2018 -c z1.f90 f951: internal compiler error: Segmentation fault 0xb297bf crash_signal ../../gcc/toplev.c:325 0x5fe2b5 find_intrinsic_vtab ../../gcc/fortran/class.c:2761 0x5fe2b5 gfc_find_vtab(gfc_typespec*) ../../gcc/fortran/class.c:2845 0x64a482 gfc_match_assignment() ../../gcc/fortran/match.c:1378 0x66d020 match_word ../../gcc/fortran/parse.c:65 0x66d020 decode_statement ../../gcc/fortran/parse.c:361 0x66eb5a next_free ../../gcc/fortran/parse.c:1234 0x66eb5a next_statement ../../gcc/fortran/parse.c:1466 0x67016b parse_spec ../../gcc/fortran/parse.c:3858 0x6748b2 parse_block_data ../../gcc/fortran/parse.c:5845 0x6748b2 gfc_parse_file() ../../gcc/fortran/parse.c:6231 0x6bc89f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug middle-end/88010] New: noinline function alias unexpectedly inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88010
Bug ID: 88010
Summary: noinline function alias unexpectedly inlined
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC appears to ignore attribute noinline on aliases whose target is a function
declared inline and inline calls to those aliases even at -O0. (I noticed this
while testing Glibc's uses of attributes alias and always_inline.) If the
noinline attribute on the alias is deliberately ignored in favor of those on
its target GCC should issue a warning. Otherwise, if the attribute on the
alias should be respected then this is a codegen bug.
$ cat t.c && gcc -O0 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout t.c
__attribute__ ((always_inline)) static inline int
finline (void) { return 1; }
__attribute__ ((alias ("finline"))) int
alias_finline (void);
__attribute__ ((alias ("finline"))) inline int
inline_alias_finline (void);
__attribute__ ((alias ("finline"), noinline)) int
noinline_alias_finline (void);
int call_alias_finline (void)
{
return alias_finline (); // inlined (should it be?)
}
int call_inline_alias_finline (void)
{
return inline_alias_finline (); // inlined as expected
}
int call_noinline_alias_finline (void)
{
return noinline_alias_finline (); // unexpectedly inlined
}
;; Function finline (finline, funcdef_no=0, decl_uid=1906, cgraph_uid=1,
symbol_order=0)
__attribute__((always_inline))
finline ()
{
int D.1924;
int _1;
:
_1 = 1;
:
:
return _1;
}
;; Function call_alias_finline (call_alias_finline, funcdef_no=1,
decl_uid=1915, cgraph_uid=5, symbol_order=4)
call_alias_finline ()
{
int D.1937;
int D.1936;
int D.1926;
int _2;
int _3;
:
_3 = 1;
:
:
_4 = _3;
:
_2 = _4;
:
:
return _2;
}
;; Function call_inline_alias_finline (call_inline_alias_finline, funcdef_no=2,
decl_uid=1918, cgraph_uid=6, symbol_order=5)
call_inline_alias_finline ()
{
int D.1940;
int D.1939;
int D.1928;
int _2;
int _3;
:
_3 = 1;
:
:
_4 = _3;
:
_2 = _4;
:
:
return _2;
}
;; Function call_noinline_alias_finline (call_noinline_alias_finline,
funcdef_no=3, decl_uid=1921, cgraph_uid=7, symbol_order=6)
call_noinline_alias_finline ()
{
int D.1943;
int D.1942;
int D.1930;
int _2;
int _3;
:
_3 = 1;
:
:
_4 = _3;
:
_2 = _4;
:
:
return _2;
}
[Bug middle-end/88010] noinline function alias unexpectedly inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88010 Martin Sebor changed: What|Removed |Added Known to fail||4.1.0, 8.2.0, 9.0 --- Comment #1 from Martin Sebor --- All GCC versions appear to behave this way.
[Bug bootstrap/86739] [9 Regression] Bootstrap broken with host GCC 4.1.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86739 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- https://godbolt.org/z/DcywdN Apparently std::pair with reference template arguments (either of them) just doesn't work in 4.1 at all because of that missing CWG. So, do we require that hash_map's iterator's operator * returns std::pair, or can it return some other class that has first and second members?
[Bug tree-optimization/88011] New: [9 regression] r266028 causes a bunch of go failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88011 Bug ID: 88011 Summary: [9 regression] r266028 causes a bunch of go failures Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- Something in this revision is causing a whole bunch of new failures in go. Failures found in new revision r266028 versus failures found in previous revision r266027 > FAIL: crypto/dsa > FAIL: crypto/ecdsa > FAIL: crypto/elliptic > FAIL: crypto/rsa > FAIL: crypto/tls > FAIL: crypto/x509 > FAIL: golang_org/x/net/http/httpguts > FAIL: golang_org/x/net/idna > FAIL: golang_org/x/net/lex/httplex > FAIL: image/draw > FAIL: math/big > FAIL: net/http/cookiejar > FAIL: net/http/httptest > FAIL: net/smtp Here are some of the failures from the crypto tests: PASS: crypto/des --- FAIL: TestSignAndVerify (0.01s) dsa_test.go:22: 0: Verify failed FAIL FAIL: crypto/dsa --- FAIL: TestSignAndVerify (0.04s) ecdsa_test.go:115: p224: Verify failed --- FAIL: TestZeroHashSignature (0.91s) ecdsa_test.go:364: zero hash signature verify failed for elliptic.p224Curve ecdsa_test.go:364: zero hash signature verify failed for elliptic.p256Curve ecdsa_test.go:364: zero hash signature verify failed for *elliptic.CurveParams ecdsa_test.go:364: zero hash signature verify failed for *elliptic.CurveParams FAIL FAIL: crypto/ecdsa --- FAIL: TestGenericBaseMult (0.00s) elliptic_test.go:353: 1: bad output for k=2: got (50fa5c697e7e478d1dc75c8ed9db2f213b6cac76a2a5d28c4dfc23a0, c58064d02d6eb345c221d36b316ff90cab075179d5da905953a67915), want (706a46dc76dcb76798e60e6d89474788d16dc18032d268fd1a704fa6, 1c2b76a7bc25e7702a704fa986892849fca629487acf3709d2e4e8bb) elliptic_test.go:353: 2: bad output for k=3: got (b9021391eff7055c164d22d235c2b9c027b0e7e8423ef22c7bb30738, 61d6f7d3639abe0f7660f9c5a1b4cbd1cd9453352220b232220dabe4), want (df1b1d66a551d0d31eff822558b9d2cc75c2180279fe0d08fd896d04, a3f7f03cadd0be444c0aa56830130ddf77d317344e1af3591981a925) elliptic_test.go:353: 3: bad output for k=4: got (18cacde124ceee4ca657ea54a08a6b219400b4254d7304ffcfd65dfe, 6d8e184fb3d10187a047e3b10ccb5c6df04233f403766838fd490cfb), want (ae99feebb5d26945b54892092a8aee02912930fa41cd114e40447301, 482580a0ec5bc47e88bc8c378632cd196cb3fa058a7114eb03054c9) elliptic_test.go:353: 4: bad output for k=5: got (e4e9c1bfcf62d575bb0bee249ae34eb6a3a1a48a0013d9e9efb954f9, a2db3f90e989f8a7c02fca77875c47698e71811febe9f57637e12fe4), want (31c49ae75bce7807cdff22055d94ee9021fedbb5ab51c57526f011aa, 27e8bff1745635ec5ba0c9f1c2ede15414c6507d29ffe37e790a079b) elliptic_test.go:353: 5: bad output for k=6: got (acda3b0bc4486561c0c12a09cab385b6a00200eac9f949811c57ec6e, b0aee36d893fd27461babccaaac9c603c034458ee9e4e353bc50cd74), want (1f2483f82572251fca975fea40db821df8ad82a3c002ee6c57112408, 89faf0ccb750d99b553c574fad7ecfb0438586eb3952af5b4b153c7e) elliptic_test.go:353: 6: bad output for k=7: got (65db24e90e6b2f8858f64aaabd8d370bd31ae310b129c8390457, b0a9ffd1de84336f69f5eece60bad99af576737de805a0ce98ddd2e1), want (db2f6be630e246a5cf7d99b85194b123d487e2d466b94b24a03c3e28, f3a30085497f2f611ee2517b163ef8c53b715d18bb4e4808d02b963) --- FAIL: TestP256BaseMult (0.01s) elliptic_test.go:378: #1: got (7cf27b188d034f7e8a52380304b51ac3c08969e277f21b35a60b48fc47669978, 7775510db8ed040293d9ac69f7430dbba7dade63ce982299e04b79d227873d1), want (c25847947e60cbefa0153824c9b24e9fcc2f07209f83d954486ae45cdd0238a4, 1f029fb463c5c053800996ab1b8e06840f7c7e9e0226abf763d6e9a04770b864) elliptic_test.go:378: #2: got (5ecbe4d1a6330a44c8f7ef951d4bf165e6c6b721efada985fb41661bc6e7fd6c, 8734640c4998ff7e374b06ce1a64a2ecd82ab036384fb83d9a79b127a27d5032), want (df3cad201b6eb9ba99ecbdf81772f7363d74b1cc543ff02eab4c5855240c35f7, 6d7c5afea3ec7285ef2224379898b209f1125963a675380f2d0b1d695cfee4b5) elliptic_test.go:378: #3: got (e2534a3532d08fbba02dde659ee62bd0031fe2db785596ef509302446b030852, e0f1575a4c633cc719dfee5fda862d764efc96c3f30ee0055c42c23f184ed8c6), want (256e2a8fe6af28313187a6149cd0a04bd94f924d9984946c470f18e359a7932b, 71de8385fa90d04cc9d08811306ed2680d810373530997af97a6538f792aee76) elliptic_test.go:378: #4: got (51590b7a515140d2d784c85608668fdfef8c82fd1f5be52421554a0dc3d033ed, e0c17da8904a727d8ae1bf36bf8a79260d012f00d4d80888d1d0bb44fda16da4), want (8796cba94f88f620eb76a04e83595199e2a4a00f4b6a00f73a10ed557e281a3e, 6866ebb28fbe165eb21165281382dc661d5651b0e3ad43374f0e5d5a93f8217a) elliptic_test.go:378: #5: got (b01a172a76a4602c92d3242cb897dde3024c740debb215b4c6b0aae93c2291a9, e85c10743237dad56fec0e2dfba703791c00f7701c7e16bdfd7c48538fc77fe2), want (706a5563e010189ec19e78ded20f09d7c9e4dd9db7942e65642a098055c2429e, b40fb72e7adeaa4cf7a73f814429b595fbb2b63c4f05928bf1ceaaa5267ef856) elliptic_test.go:378: #6: got (8e533b6fa0bf7b4625bb30667c01fb
[Bug bootstrap/86739] [9 Regression] Bootstrap broken with host GCC 4.1.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86739 --- Comment #9 from Jakub Jelinek --- Created attachment 45000 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45000&action=edit gcc9-pr86739.patch This works for me (well, make in gcc/ with recent gcc still builds and the preprocessed source from this PR with those tweaks compiles with GCC 4.1).
[Bug bootstrap/86739] [9 Regression] Bootstrap broken with host GCC 4.1.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86739 --- Comment #10 from Jakub Jelinek --- Created attachment 45001 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45001&action=edit gcc9-pr86739-2.patch Variant patch if the conversion operator would not be acceptable.
[Bug c/81824] Warn for missing attributes with function aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81824 --- Comment #15 from Martin Sebor --- Author: msebor Date: Tue Nov 13 19:57:51 2018 New Revision: 266084 URL: https://gcc.gnu.org/viewcvs?rev=266084&root=gcc&view=rev Log: PR middle-end/81824 - Warn for missing attributes with function aliases gcc/c-family/ChangeLog: * c-attribs.c (handle_copy_attribute): Exclude inlining attributes. (handle_tls_model_attribute): Improve diagnostics. gcc/testsuite/ChangeLog: * gcc.dg/attr-copy-5.c: New test. * gcc.dg/tls/diag-6.c: Adjust expected diagnostics. Added: trunk/gcc/testsuite/gcc.dg/attr-copy-5.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-attribs.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tls/diag-6.c
[Bug debug/48886] VTA issues with > word size integers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48886 --- Comment #4 from Alexandre Oliva --- I'm afraid I didn't investigate to tell whether problems were fixed or latent, I just observed that the test passed.
[Bug tree-optimization/87011] [9 Regression] partially dead memset before strcpy not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87011
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||jakub at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #2 from Jakub Jelinek ---
That seems to be intentional and the right thing to me, what GCC 7 did means
unaligned stores.
movq$0, 4(%rdi)
movl$0, 12(%rdi)
movl$3355185, (%rdi)
vs.
pxor%xmm0, %xmm0
movups %xmm0, (%rdi)
movl$3355185, (%rdi)
where the latter, while using unaligned store, is actually at least 64-bit
aligned 128-store. With -O2 -mno-sse it is
movq$0, (%rdi)
movq$0, 8(%rdi)
movl$3355185, (%rdi)
which also looks to be better. With -m32 where &p->a[4] is word-aligned we
still do that, or if you change the testcase to:
struct S { char a[8]; void (*pf)(void); };
void f (struct S *p)
{
__builtin_memset (p, 0, sizeof *p);
__builtin_strcpy (p->a, "1234567");
}
then it is also adjusted.
[Bug debug/68836] GCC can't properly emit debug info for function arguments in a back-trace when using -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68836 --- Comment #7 from Alexandre Oliva --- Thanks. Hmm, tricky. There's no inlining, and debug info is as complete as one could get. The problem is that the registers holding the variables are call-clobbered, and the variables are dead after the call. We emit debug binds right after the call for the variables to the entry values, but the entry values were not saved at the callers either. There's an argument to be made that, at the entry point of foo, the values are still available in the same registers: they haven't been modified yet, and the variables in the enclosing frames were in the same registers up to the point of the call, so one could infer they're still there, but maybe that's asking too much of a debugger. It would have to somehow know that none of the prologue insns changed the registers in a meaningful way to conclude that they still hold the variables that were passed in, to then conclude that the variables in the enclosing frames, that lived in the same registers up to the point of the call, held those values too. And that's the analysis for bar, because, for main, it would again have to somehow know that the value did not change between entry and the call, which is not given by debug info (all we know is that the *location* didn't change), to infer that the registers that held the value up to calling bar still hold the same values, that were held by the corresponding variables. Perhaps if we emitted locations indicating that the variable is unchanged, by naming the entry value as a location for the entire range, a debugger could more easily make that sort of reasoning and find suitable values. It still feels like pushing it a bit, though.
[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 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-13 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- $ cat t.C && gcc -S -Wall -Wextra t.C char array[__SIZE_MAX__]; t.C:1:24: error: size of array ‘array’ is negative 1 | char array[__SIZE_MAX__]; |^ The change was introduced in r258604: r258604 | jason | 2018-03-16 14:56:01 -0400 (Fri, 16 Mar 2018) | 4 lines PR c++/80227 - SFINAE and negative array size. * decl.c (compute_array_index_type): Use build_converted_constant_expr and valid_constant_size_p.
[Bug d/87824] x86_64-linux multilib issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87824 --- Comment #9 from Johannes Pfau --- Fix for the loadDR failure: https://github.com/D-Programming-GDC/GDC/pull/767
[Bug tree-optimization/81454] missing strcmp optimization and warning on duplicate call with an unknown string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81454 Eric Gallager changed: What|Removed |Added Severity|normal |enhancement --- Comment #2 from Eric Gallager --- (In reply to Eric Gallager from comment #1) > Confirmed. (...that I get the same results as you, that is; I wasn't necessarily confirming the merits of doing this. Reprioritizing as an enhancement)
[Bug c++/88012] New: Expected -Wnarrowing not given inside template class method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88012
Bug ID: 88012
Summary: Expected -Wnarrowing not given inside template class
method
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Using Debian 8.2.0-9 the following code compiles without any errors or
warnings:
% cat -n narrowing.cpp
1 using Number = unsigned int;
2
3 template
4 struct S {
5 S() {
6 const Number x = {-1}; (void)x;
7 }
8 };
9
10 int main() {
11 S<1> s;
12 // const Number y = {-1}; (void)y;
13 }
% g++-8 -Wall -c narrowing.cpp
% # i.e. no diagnostic output
Uncommenting the line 12 results in the expected error:
% g++-8 -Wall -c narrowing.cpp
narrowing.cpp: In function ‘int main()’:
narrowing.cpp:12:25: error: narrowing conversion of ‘-1’ from ‘int’ to ‘Number’
{aka ‘unsigned int’} inside { } [-Wnarrowing]
const Number y = {-1}; (void)y;
^
AFAICS the same error should be given for the same code inside S ctor but
somehow the narrowing conversion is not detected there.
Sorry in advance if I'm missing something, but I couldn't find any reason for
this code to be accepted, so reporting it here because it looks like a bug to
me.
FWIW both clang 7 and MSVS 15.7 do report the expected error (and the former
even does it twice for some reason...).
[Bug c++/88012] Expected -Wnarrowing not given inside template class method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88012 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Marek Polacek --- Most likely a dup. I'll add your testcase. *** This bug has been marked as a duplicate of bug 78244 ***
[Bug c++/78244] Narrowing conversion is accepted in a function template, but it should be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78244 Marek Polacek changed: What|Removed |Added CC||vz-gcc at zeitlins dot org --- Comment #7 from Marek Polacek --- *** Bug 88012 has been marked as a duplicate of this bug. ***
[Bug c++/78244] Narrowing conversion is accepted in a function template, but it should be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78244
--- Comment #8 from Marek Polacek ---
Testcase from 88012:
using Number = unsigned int;
template
struct S {
S() {
const Number x = {-1};
(void)x;
}
};
int main()
{
S<1> s;
}
[Bug middle-end/87899] [9 regression]r264897 cause mis-compiled native arm-linux-gnueabihf toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87899 --- Comment #8 from Peter Bergner --- Author: bergner Date: Tue Nov 13 22:14:11 2018 New Revision: 266086 URL: https://gcc.gnu.org/viewcvs?rev=266086&root=gcc&view=rev Log: gcc/ PR rtl-optimization/87899 * lra-lives.c (start_living): Update white space in comment. (enum point_type): New. (sparseset_contains_pseudos_p): New function. (update_pseudo_point): Likewise. (make_hard_regno_live): Use HARD_REGISTER_NUM_P macro. (make_hard_regno_dead): Likewise. Remove ignore_reg_for_conflicts handling. Move early exit after adding conflicts. (mark_pseudo_live): Use HARD_REGISTER_NUM_P macro. Add early exit if regno is already live. Remove all handling of program points. (mark_pseudo_dead): Use HARD_REGISTER_NUM_P macro. Add early exit after adding conflicts. Remove all handling of program points and ignore_reg_for_conflicts. (mark_regno_live): Use HARD_REGISTER_NUM_P macro. Remove return value and do not guard call to mark_pseudo_live. (mark_regno_dead): Use HARD_REGISTER_NUM_P macro. Remove return value and do not guard call to mark_pseudo_dead. (check_pseudos_live_through_calls): Use HARD_REGISTER_NUM_P macro. (process_bb_lives): Use HARD_REGISTER_NUM_P and HARD_REGISTER_P macros. Use new function update_pseudo_point. Handle register copies by removing the source register from the live set. Handle INOUT operands. Update to the next program point using the unused_set, dead_set and start_dying sets. (lra_create_live_ranges_1): Use HARD_REGISTER_NUM_P macro. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-lives.c
[Bug middle-end/87899] [9 regression]r264897 cause mis-compiled native arm-linux-gnueabihf toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87899 Peter Bergner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Peter Bergner --- Fixed.
[Bug tree-optimization/68561] An improvement for VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68561 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|mpolacek at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug c++/86594] Crash on trying to capture 'this' in instantiation of generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86594 --- Comment #2 from Marek Polacek --- For some weird reason this got fixed by my r265734.
[Bug other/88007] [9 Regression] ICE in gt_ggc_m_S, at ggc-page.c:1474
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88007 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- This is because parse_optimize_options has: r = q = (char *) ggc_alloc_atomic (len2 + 3); and constructs in there the whole option, like "-falign-functions=16" , and then options processing comes and points arg into that string (so "16"). As gcc_options is marked GTY, the const char * fields in there thus need to be either not GC memory at all, or they need to point at the start of a GC chunk, or into the middle of STRING_CST, everything else is disallowed. So, either we need to pass down to the option processing info that the options are GC allocated and if we'd have arg pointing into the middle of such a string, ggc_strdup it, or maybe c-common.c should use XOBNEWVEC (&opts_obstack, char, len2 + 3); instead of (char *) ggc_alloc_atomic (len2 + 3) ?
[Bug d/87824] x86_64-linux multilib issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87824 --- Comment #10 from Iain Buclaw --- (In reply to Johannes Pfau from comment #9) > Fix for the loadDR failure: https://github.com/D-Programming-GDC/GDC/pull/767 Could you post that to gcc-patches? Should probably get write after approval for you as well.
