[Bug tree-optimization/83963] [8 Regression] [graphite] ICE in merge_sese, at graphite-scop-detection.c:517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83963 --- Comment #6 from Richard Biener --- Author: rguenth Date: Tue Jan 23 08:00:20 2018 New Revision: 256973 URL: https://gcc.gnu.org/viewcvs?rev=256973&root=gcc&view=rev Log: 2018-01-23 Richard Biener PR tree-optimization/83963 * graphite-scop-detection.c (scop_detection::harmful_loop_in_region): Properly terminate dominator walk when crossing the exit edge not when visiting its source block. * gfortran.dg/graphite/pr83963.f: New testcase. * gcc.dg/graphite/pr83963-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/graphite/pr83963-2.c trunk/gcc/testsuite/gfortran.dg/graphite/pr83963.f Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-scop-detection.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/83977] [8 Regression] ICE in simd_clone_clauses_extract, at omp-simd-clone.c:184
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83977 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-23 CC||jakub at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r253395, I'll have a look.
[Bug rtl-optimization/83913] [6/7/8 Regression] Compile time and memory hog w/ selective scheduling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83913
Andrey Belevantsev changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |abel at gcc dot gnu.org
--- Comment #3 from Andrey Belevantsev ---
We've discussed with Alexander about this one. The simpler fix will be never
pipelining anything of priority 0, as this wouldn't give any benefit. The
better fix is to make bookkeeping copies within the pipelined region inherit
sched_times -- the number of times this insn was scheduled. It will not work
for regular scheduling as those new insns have to be scheduled at some point,
but for pipelined regions we're rescheduling blocks with new insns anyways. So
something like below works, but for that kind of patch I will need testing on
ia64 and it takes time.
diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
index 76092f9587a..58f4ca4016f 100644
--- a/gcc/sel-sched.c
+++ b/gcc/sel-sched.c
@@ -4773,7 +4773,16 @@ emit_bookkeeping_insn (insn_t place_to_insert, expr_t
c_expr, int new_seqno)
insn_t new_insn = emit_insn_from_expr_after (c_expr, new_vinsn, new_seqno,
place_to_insert);
- INSN_SCHED_TIMES (new_insn) = 0;
+ if (pipelining_p && !sel_is_loop_preheader_p (BLOCK_FOR_INSN
(place_to_insert)))
+{
+ int sched_times = EXPR_SCHED_TIMES (c_expr);
+ if (sched_times < 0)
+ sched_times = 0;
+ INSN_SCHED_TIMES (new_insn) = sched_times;
+}
+ else
+INSN_SCHED_TIMES (new_insn) = 0;
+
bitmap_set_bit (current_copies, INSN_UID (new_insn));
return new_insn;
[Bug rtl-optimization/83972] ICE in code_motion_process_successors, at sel-sched.c:6398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83972 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Version|unknown |8.0 --- Comment #2 from Richard Biener --- x86 I presume
[Bug lto/83967] LTO removes C functions declared as weak in assembler(depending on files order in linking)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83967 --- Comment #4 from Rafał Mszal --- Created attachment 43210 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43210&action=edit Basic example of main funtion with LTO failure. This is simple example of observed LTO issue. RTC1_IRQHandler is removed despite it is used to change volatile variable. RTC1_IRQHandler is defined weak in the assembler startup file.
[Bug lto/83967] LTO removes C functions declared as weak in assembler(depending on files order in linking)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83967 --- Comment #5 from Rafał Mszal --- Created attachment 43211 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43211&action=edit Makefile that causes failure.
[Bug fortran/83975] [8 Regression] ICE in set_parm_default_def_partition, at tree-ssa-coalesce.c:1919
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83975
--- Comment #4 from Richard Biener ---
Somehow the VAR_DECL for 'y' is in the PARM_DECL chain for the FUNCTION_DECL s:
>
QI
size
unit-size
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76a53e70
attributes
value >>
arg-types
chain
chain
public static QI t.f90:1:0 align:8 warn_if_not_align:0 context
initial
result
ignored VOID t.f90:1:0
align:8 warn_if_not_align:0 context >
(mem:QI (symbol_ref:DI ("s_") [flags 0x3] )
[0 S1 A8])
arguments
unsigned restrict DI
size
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1
structural-equality>
readonly used unsigned DI passed-by-reference t.f90:1:0 size
unit-size
align:64 warn_if_not_align:0 context
arg-type
unsigned restrict DI size unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76a53dc8>
chain
readonly used DI t.f90:1:0 size
unit-size
align:64 warn_if_not_align:0 context arg-type chain >>
[Bug middle-end/83977] [8 Regression] ICE in simd_clone_clauses_extract, at omp-simd-clone.c:184
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83977 Richard Biener changed: What|Removed |Added Keywords||openmp Priority|P3 |P1 Component|fortran |middle-end
[Bug c++/83979] [8 Regression] ICE with pointer comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83979 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |8.0
[Bug lto/83967] LTO removes C functions declared as weak in assembler(depending on files order in linking)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83967 --- Comment #6 from Rafał Mszal --- Created attachment 43212 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43212&action=edit Startup file for the nRF52 microcontroller. This is typical startup for nRF5x microcontrollers. The main thing that is important is the interrupts vector table. All interrupts used in table are declared as weak at the end of file.
[Bug target/83986] [8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2348
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83986 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug middle-end/83977] [8 Regression] ICE in simd_clone_clauses_extract, at omp-simd-clone.c:184
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83977 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 43213 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43213&action=edit gcc8-pr83977.patch Untested fix.
[Bug sanitizer/83987] [6/7/8 Regression] ICE with OpenMP, sanitizer and virtual bases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83987 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-23 CC||dodji at gcc dot gnu.org, ||dvyukov at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||kcc at gcc dot gnu.org Component|lto |sanitizer Target Milestone|--- |6.5 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- We output from fn->local_decls 'i' which has a DECL_VALUE_EXPR of ((struct A *) (struct B *) this + (sizetype) *(long int *) ((UBSAN_VPTR ((struct B *) this, (long unsigned int) ((struct B *) this)->_vptr.B, 18446725456357140888, &_ZTI1B, 9B);, (struct B *) this;)->_vptr.B + 18446744073709551592))->i I think we need to prune sanitizer instrumentation from DECL_VALUE_EXPRs somehow. -> sanitizer issue.
[Bug lto/83967] LTO removes C functions declared as weak in assembler(depending on files order in linking)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83967 --- Comment #7 from Rafał Mszal --- Thanks for response. I've send some basic example of the failure. However, it needs some others file to compile and link, like linker, SystemInit function decalration and so on. I've just send you most important files, now I am working on removing sources that are not important, but this will take me a while, since i need to remove lot of dependencies between those files, makefile and linker. I've checked 'used' attribute, it doesn't solve the problem. Same with the suggested '-fuse-linker-plugin' flag.
[Bug c++/83988] New: Internal compiler error in tsubst_baselink
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83988 Bug ID: 83988 Summary: Internal compiler error in tsubst_baselink Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: csaba_22 at yahoo dot co.uk Target Milestone: --- Created attachment 43214 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43214&action=edit preprocessed source, compressed $ g++-8 -v -Wall -pedantic -Wextra -g -save-temps -I ~/wk/hotblack/third_party/rapidjson/include snafu.cc -o snafu Using built-in specs. COLLECT_GCC=g++-8 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../trunk/configure --program-suffix=-8 --enable-version-specific-runtime-libs --enable-languages=c,c++,lto : (reconfigured) ../trunk/configure --program-suffix=-8 --enable-version-specific-runtime-libs --enable-languages=c,c++,lto : (reconfigured) ../trunk/configure --program-suffix=-8 --enable-version-specific-runtime-libs --enable-languages=c,c++,lto --no-create --no-recursion : (reconfigured) ../trunk/configure --program-suffix=-8 --enable-version-specific-runtime-libs --enable-languages=c,c++,lto --no-create --no-recursion : (reconfigured) ../trunk/configure --program-suffix=-8 --enable-version-specific-runtime-libs --enable-languages=c,c++,lto --no-create --no-recursion : (reconfigured) ../trunk/configure --program-suffix=-8 --enable-version-specific-runtime-libs --enable-languages=c,c++,lto --no-create --no-recursion : (reconfigured) ../trunk/configure --program-suffix=-8 --enable-version-specific-runtime-libs --enable-languages=c,c++,lto --no-create --no-recursion : (reconfigured) ../trunk/configure --program-suffix=-8 --enable-version-specific-runtime-libs --enable-languages=c,c++,lto --no-create --no-recursion : (reconfigured) ../trunk/configure --program-suffix=-8 --enable-version-specific-runtime-libs --enable-languages=c,c++,lto --no-create --no-recursion Thread model: posix gcc version 8.0.1 20180122 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-Wall' '-Wpedantic' '-Wextra' '-g' '-save-temps' '-I' '/home/csabaraduly/wk/hotblack/third_party/rapidjson/include' '-o' 'snafu' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/cc1plus -E -quiet -v -I /home/csabaraduly/wk/hotblack/third_party/rapidjson/include -imultiarch x86_64-linux-gnu -D_GNU_SOURCE snafu.cc -mtune=generic -march=x86-64 -Wall -Wpedantic -Wextra -g -fworking-directory -fpch-preprocess -o snafu.ii ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-pc-linux-gnu/8.0.1/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /home/csabaraduly/wk/hotblack/third_party/rapidjson/include /usr/local/lib/gcc/x86_64-pc-linux-gnu/8.0.1/include/c++ /usr/local/lib/gcc/x86_64-pc-linux-gnu/8.0.1/include/c++/x86_64-pc-linux-gnu /usr/local/lib/gcc/x86_64-pc-linux-gnu/8.0.1/include/c++/backward /usr/local/lib/gcc/x86_64-pc-linux-gnu/8.0.1/include /usr/local/include /usr/local/lib/gcc/x86_64-pc-linux-gnu/8.0.1/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-Wall' '-Wpedantic' '-Wextra' '-g' '-save-temps' '-I' '/home/csabaraduly/wk/hotblack/third_party/rapidjson/include' '-o' 'snafu' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/cc1plus -fpreprocessed snafu.ii -quiet -dumpbase snafu.cc -mtune=generic -march=x86-64 -auxbase snafu -g -Wall -Wpedantic -Wextra -version -o snafu.s GNU C++14 (GCC) version 8.0.1 20180122 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 8.0.1 20180122 (experimental), GMP version 6.1.2, MPFR version 3.1.6, MPC version 1.0.3, isl version none GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C++14 (GCC) version 8.0.1 20180122 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 8.0.1 20180122 (experimental), GMP version 6.1.2, MPFR version 3.1.6, MPC version 1.0.3, isl version none GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 8ee7c7ccea3c2943f7408516591b8840 snafu.cc: In instantiation of ‘boost::optional get_from_json::maybe() const [with AsWhat = long unsigned int]’: snafu.cc:119:64: required from here snafu.cc:102:35: internal compiler error: in tsubst_baselink, at cp/pt.c:14451 this->operator boost::optional(); ~~^~~~ 0x61cde5 tsubst_baselink ../../trunk/gcc/cp/pt.c:14451 0x92746b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../trunk/gcc/cp/pt.c:17996 0x925eaf tsubst_copy_and_build(tree_
[Bug lto/83967] LTO removes C functions declared as weak in assembler(depending on files order in linking)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83967
Richard Biener changed:
What|Removed |Added
Status|WAITING |NEW
CC||hjl.tools at gmail dot com
--- Comment #8 from Richard Biener ---
(In reply to Rafał Mszal from comment #4)
> Created attachment 43210 [details]
> Basic example of main funtion with LTO failure.
>
> This is simple example of observed LTO issue. RTC1_IRQHandler is removed
> despite it is used to change volatile variable. RTC1_IRQHandler is defined
> weak in the assembler startup file.
I don't see it being defined in the startup file. But I take it should be
similar
to
.weak NMI_Handler
.type NMI_Handler, %function
NMI_Handler:
b .
.size NMI_Handler, . - NMI_Handler
and the only use is in the startup file as well:
.section .isr_vector
.align 2
.globl __isr_vector
__isr_vector:
.long __StackTop /* Top of Stack */
.long Reset_Handler
.long NMI_Handler
and you'd define it in a C file as non-weak (what it does doesn't matter)
void RTC1_IRQHandler(void)
{
}
So a testcase is:
t1.c:
-
int i;
void Handler()
{
i = 1;
}
void *Dispatch;
int main(){ ((void (*)(void))Dispatch)(); return i;}
t2.s:
-
.file "t2.s"
.text
.weak Handler
.type Handler, @function
Handler:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size Handler, .-Handler
.globl Dispatch
.data
.align 8
.type Dispatch, @object
.size Dispatch, 8
Dispatch:
.quad Handler
.ident "GCC: (SUSE Linux) 7.2.1 20171020 [gcc-7-branch revision
253932]"
.section.note.GNU-stack,"",@progbits
and then I get
> gcc-7 t2.s t1.c -flto
/tmp/ccGhH7Cp.o:(.data+0x0): undefined reference to `Handler'
collect2: error: ld returned 1 exit status
> gcc-7 t1.c t2.s -flto
in the working case:
1
t1.o 4
190 16b2980a71930688 PREEMPTED_REG Handler
198 16b2980a71930688 PREVAILING_DEF_IRONLY i
194 16b2980a71930688 PREVAILING_DEF main
202 16b2980a71930688 RESOLVED_EXEC Dispatch
in the failing case (GNU ld):
1
t1.o 4
190 801577c96f9ccef3 PREVAILING_DEF_IRONLY Handler
198 801577c96f9ccef3 PREVAILING_DEF_IRONLY i
194 801577c96f9ccef3 PREVAILING_DEF main
202 801577c96f9ccef3 RESOLVED_EXEC Dispatch
which works with gold:
1
t1.o 4
190 680bbd652c7cfe04 PREVAILING_DEF Handler
198 680bbd652c7cfe04 PREVAILING_DEF_IRONLY i
194 680bbd652c7cfe04 PREVAILING_DEF main
202 680bbd652c7cfe04 RESOLVED_EXEC Dispatch
HJ? This is with binutils 2.29.1, thus confirmed but as a GNU ld issue.
[Bug sanitizer/83987] [6/7/8 Regression] ICE with OpenMP, sanitizer and virtual bases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83987 --- Comment #2 from Jakub Jelinek --- Perhaps free_lang_data pass could drop DECL_VALUE_EXPRs from DECL_IGNORED_P variables, because those will not be useful for debug info anyway.
[Bug lto/83967] LTO removes C functions declared as weak in assembler(depending on files order in linking)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83967 --- Comment #9 from Richard Biener --- Still not 100% sure which Handler should prevail in resolving the symbol for Dispatch. Currently it seems the non-weak one prevails which looks correct. I think in both cases the resolution from GNU ld is bogus. Take the working one: 190 16b2980a71930688 PREEMPTED_REG Handler that's clearly wrong -- Handler prevails! 190 801577c96f9ccef3 PREVAILING_DEF_IRONLY Handler that's wrong because in the assembler file Handler is used to resolve the symbol at Dispatch. gold seems to get it correct as PREVAILING_DEF (but not _IRONLY).
[Bug lto/83967] LTO removes C functions declared as weak in assembler(depending on files order in linking)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83967 --- Comment #10 from rguenther at suse dot de --- On Tue, 23 Jan 2018, hurwic8 at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83967 > > --- Comment #7 from Rafał Mszal --- > Thanks for response. > > I've send some basic example of the failure. However, it needs some others > file > to compile and link, like linker, SystemInit function decalration and so on. > > I've just send you most important files, now I am working on removing sources > that are not important, but this will take me a while, since i need to remove > lot of dependencies between those files, makefile and linker. > > I've checked 'used' attribute, it doesn't solve the problem. Same with the > suggested '-fuse-linker-plugin' flag. From my analysis the issue is with GNU ld and you could avoid hitting it by using gold (you can say -fuse-ld=gold to GCC if you have gold installed)
[Bug fortran/83975] [8 Regression] ICE in set_parm_default_def_partition, at tree-ssa-coalesce.c:1919
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83975 Janne Blomqvist changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org --- Comment #5 from Janne Blomqvist --- I have a "fix", I'll post it shortly.
[Bug fortran/83975] [8 Regression] ICE in set_parm_default_def_partition, at tree-ssa-coalesce.c:1919
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83975 Janne Blomqvist changed: What|Removed |Added Status|NEW |WAITING URL||https://gcc.gnu.org/ml/gcc- ||patches/2018-01/msg01917.ht ||ml --- Comment #6 from Janne Blomqvist --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01917.html
[Bug sanitizer/83987] [6/7/8 Regression] ICE with OpenMP, sanitizer and virtual bases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83987 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 43215 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43215&action=edit gcc8-pr83987.patch Untested fix.
[Bug c/83989] New: -Wrestrict false positive with malloc-style functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83989 Bug ID: 83989 Summary: -Wrestrict false positive with malloc-style functions Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: sirl at gcc dot gnu.org Target Milestone: --- Created attachment 43216 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43216&action=edit testcase Compiling the attached file with r256939 of trunk issues 2 warnings. I believe they are false positives and should have been suppressed by __attribute__((__malloc__)). gcc-7.2.1 didn't issue a warning here. # gcc-trunk -c -Wall -Wrestrict -O2 Wrestrict-false-positive.c Wrestrict-false-positive.c: In function 'load1': Wrestrict-false-positive.c:44:4: warning: 'memcpy' accessing between 384 and 25769803764 bytes at offsets 0 and 0 overlaps between 384 and 25769803764 bytes at offset 0 [-Wrestrict] memcpy(recmem, oldrecmem, oldsize * sizeof(record_t)); ^ Wrestrict-false-positive.c: In function 'load2': Wrestrict-false-positive.c:75:4: warning: 'memcpy' accessing between 384 and 25769803764 bytes at offsets 0 and 0 overlaps between 384 and 25769803764 bytes at offset 0 [-Wrestrict] memcpy(recmem, oldrecmem, oldsize * sizeof(record_t)); ^
[Bug testsuite/83983] FAIL: g++.dg/lto/pr83121 (test for LTO warnings, pr83121_0.C line 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83983 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-23 CC||dmalcolm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Similar to this report on aarch64/arm: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01637.html
[Bug c/83989] [8 Regression] -Wrestrict false positive with malloc-style functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83989 Richard Biener changed: What|Removed |Added Keywords||diagnostic CC||msebor at gcc dot gnu.org Target Milestone|--- |8.0 Summary|-Wrestrict false positive |[8 Regression] -Wrestrict |with malloc-style functions |false positive with ||malloc-style functions
[Bug c++/83947] [8 Regression] ICE on invalid C++ code with auto: in tsubst_decl, at cp/pt.c:13046
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83947 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-23 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r253600.
[Bug target/83964] [8 Regression] ICE in extract_insn, at recog.c:2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83964 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- So, should BU_FP_MISC_1 define use as mask RS6000_BTM_HARD_FLOAT | RS6000_BTM_CELL instead of just RS6000_BTM_HARD_FLOAT? Though, the instructions are also guarded with TARGET_DOUBLE_FLOAT resp. TARGET_SINGLE_FLOAT, so on singlefp.h targets it might still ICEs. Do other builtin's masks match the conditions on corresponding instructions?
[Bug tree-optimization/83965] [8 Regression] ICE in vectorize_fold_left_reduction, at tree-vect-loop.c:6154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83965 --- Comment #1 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Tue Jan 23 10:42:10 2018 New Revision: 256976 URL: https://gcc.gnu.org/viewcvs?rev=256976&root=gcc&view=rev Log: Disable some patterns for fold-left reductions (PR 83965) In this PR we recognised a PLUS_EXPR as a fold-left reduction, then applied pattern matching to convert it to a WIDEN_SUM_EXPR. We need to keep the original code in this case since we implement the reduction using scalar rather than vector operations. 2018-01-23 Richard Sandiford gcc/ PR tree-optimization/83965 * tree-vect-patterns.c (vect_reassociating_reduction_p): New function. (vect_recog_dot_prod_pattern, vect_recog_sad_pattern): Use it instead of checking only for a reduction. (vect_recog_widen_sum_pattern): Likewise. gcc/testsuite/ PR tree-optimization/83965 * gcc.dg/vect/pr83965.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr83965.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-patterns.c
[Bug target/83888] [8 regression] new failures after r256639 on armhf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83888 --- Comment #3 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Tue Jan 23 10:42:32 2018 New Revision: 256977 URL: https://gcc.gnu.org/viewcvs?rev=256977&root=gcc&view=rev Log: Fix vect_float markup for a couple of tests (PR 83888) vect_float is true for arm*-*-* targets, but the support is only available when -funsafe-math-optimizations is on. This caused failures in two tests that disable fast-math. The easiest fix seemed to be to add a new target selector for "vect_float without special options". 2018-01-23 Richard Sandiford gcc/ PR testsuite/83888 * doc/sourcebuild.texi (vect_float): Say that the selector only describes the situation when -funsafe-math-optimizations is on. (vect_float_strict): Document. gcc/testsuite/ PR testsuite/83888 * lib/target-supports.exp (check_effective_target_vect_float): Say that the result only holds when -funsafe-math-optimizations is on. (check_effective_target_vect_float_strict): New procedure. * gcc.dg/vect/no-fast-math-vect16.c: Use vect_float_strict instead of vect_float. * gcc.dg/vect/vect-reduc-6.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/sourcebuild.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/no-fast-math-vect16.c trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-6.c trunk/gcc/testsuite/lib/target-supports.exp
[Bug tree-optimization/83965] [8 Regression] ICE in vectorize_fold_left_reduction, at tree-vect-loop.c:6154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83965 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from rsandifo at gcc dot gnu.org --- Patch applied.
[Bug target/83888] [8 regression] new failures after r256639 on armhf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83888 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from rsandifo at gcc dot gnu.org --- Patch applied.
[Bug rtl-optimization/83985] Compile time hog for 32-bit BE powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83985 --- Comment #1 from Jakub Jelinek --- Started with r254602.
[Bug rtl-optimization/83985] [8 Regression] Compile time hog for 32-bit BE powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83985 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-23 CC||jakub at gcc dot gnu.org Target Milestone|--- |8.0 Summary|Compile time hog for 32-bit |[8 Regression] Compile time |BE powerpc targets |hog for 32-bit BE powerpc ||targets Ever confirmed|0 |1
[Bug c++/83988] [8 Regression] Internal compiler error in tsubst_baselink
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83988
David Malcolm changed:
What|Removed |Added
Keywords||ice-on-valid-code
Priority|P3 |P1
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-01-23
CC||dmalcolm at gcc dot gnu.org,
||nathan at gcc dot gnu.org
Summary|Internal compiler error in |[8 Regression] Internal
|tsubst_baselink |compiler error in
||tsubst_baselink
Ever confirmed|0 |1
--- Comment #1 from David Malcolm ---
Works with r255598.
ICEs with r255605.
Looks like r255605 may have introduced this.
Minimal reproducer:
$ cat ../../src/pr83988.C
template struct optional {};
struct get_from_json {
template
explicit operator optional() const {return optional ();}
template
optional maybe() const
{
return this->operator optional();
}
};
void test()
{
get_from_json().maybe();
}
$ ./xg++ -B. ../../src/pr83988.C
../../src/pr83988.C: In instantiation of ‘optional
get_from_json::maybe() const [with AsWhat = int]’:
../../src/pr83988.C:13:30: required from here
../../src/pr83988.C:8:27: internal compiler error: in tsubst_baselink, at
cp/pt.c:14451
return this->operator optional();
~~~^~~~
0x93759c tsubst_baselink
../../src/gcc/cp/pt.c:14451
0x9319ba tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:17996
0x92f82f tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:17604
0x91d25c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:16779
0x91b435 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:15996
0x91a155 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:16263
0x918913 instantiate_decl(tree_node*, bool, bool)
../../src/gcc/cp/pt.c:23329
0x95ebdf instantiate_pending_templates(int)
../../src/gcc/cp/pt.c:23445
0x836612 c_parse_final_cleanups()
../../src/gcc/cp/decl2.c:4705
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/83990] New: Spurious "potential null pointer dereference" warning regression from 7.1 onwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83990
Bug ID: 83990
Summary: Spurious "potential null pointer dereference" warning
regression from 7.1 onwards
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
Created attachment 43217
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43217&action=edit
Pre-processed (-save-temps) on GCC 7.2.0 [Ubuntu 17.10]
Compiling this code:
#include
#include
#include
void a() {
std::vector s;
s.reserve( 5 );
for (const std::string &x : s) {
std::cout << x;
}
}
template void ignore_unused(Ts &&...) {}
void b() {
for (const int &i : { 0, 0, 0, 0 } ) {
ignore_unused( i );
std::vector s;
s.reserve( 5 );
for (const std::string &x : s) {
std::cout << x;
}
}
}
...with...
g++ -std=c++17 -O3 -Werror -Wnull-dereference a.cpp -s -o /tmp/a.o
Gives the following error (upgraded from a warning):
In function ‘void std::vector<_Tp, _Alloc>::reserve(std::vector<_Tp,
_Alloc>::size_type) [with _Tp = std::__cxx11::basic_string; _Alloc =
std::allocator >]’:
cc1plus: error: potential null pointer dereference
[-Werror=null-dereference]
cc1plus: all warnings being treated as errors
I don't think the user code is doing anything to warrant this warning and it's
unhelpful that there is no stack/line information to track the issue.
I'm guessing that the problem here is that, as is hypothesised for bug 83591,
the source location info has been lost so the warning isn't being squelched as
it should for being in a system header.
>From what I can see on GodBolt, this issue was introduced between 6.3 and 7.1
and is still present in trunk (8.0.1 20180122).
In 7.1, the problem goes away if compiling with -std=c++14 or -std=c++11
(rather than -std=c++17) but in trunk (8.0.1 20180122) the problem persists in
all three modes.
[Bug tree-optimization/81082] [8 Regression] Failure to vectorise after reassociating index computation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81082 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #5 from Richard Biener --- So I think the solution will be to remove this transform from early folding and make reassoc do this transform - which it already can do, but only for unsigned arithmetic. I'll give teaching reassoc to operate on signed arithmetic a quick shot...
[Bug c++/83990] Spurious "potential null pointer dereference" warning regression from 7.1 onwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83990 --- Comment #1 from Tony E Lewis --- Created attachment 43218 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43218&action=edit Verbose output from GCC 7.2.0 [Ubuntu 17.10]
[Bug tree-optimization/83510] [8 Regression] Recent changes for -Warray-bounds trigger false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83510 --- Comment #7 from David Malcolm --- Author: dmalcolm Date: Tue Jan 23 11:10:47 2018 New Revision: 256980 URL: https://gcc.gnu.org/viewcvs?rev=256980&root=gcc&view=rev Log: -Warray-bounds: Fix false positive in some "switch" stmts (PR tree-optimization/83510) PR tree-optimization/83510 reports that r255649 (for PR tree-optimization/83312) introduced a false positive for -Warray-bounds for array accesses within certain switch statements: those for which value-ranges allow more than one case to be reachable, but for which one or more of the VR-unreachable cases contain out-of-range array accesses. In the reproducer, after the switch in f is inlined into g, we have 3 cases for the switch (case 9, case 10-19, and default), within a loop that ranges from 0..9. With both the old and new code, vr_values::simplify_switch_using_ranges clears the EDGE_EXECUTABLE flag on the edge to the "case 10-19" block. This happens during the dom walk within the substitute_and_fold_engine. With the old code, the clearing of that EDGE_EXECUTABLE flag led to the /* Skip blocks that were found to be unreachable. */ code in the old implementation of vrp_prop::check_all_array_refs skipping the "case 10-19" block. With the new code, we have a second dom walk, and that dom_walker's ctor sets all edges to be EDGE_EXECUTABLE, losing that information. Then, dom_walker::before_dom_children (here, the subclass' check_array_bounds_dom_walker::before_dom_children) can return one edge, if there's a unique successor edge, and dom_walker::walk filters the dom walk to just that edge. Here we have two VR-valid edges (case 9 and default), and an VR-invalid successor edge (case 10-19). There's no *unique* valid successor edge, and hence taken_edge is NULL, and the filtering in dom_walker::walk doesn't fire. Hence we've lost the filtering of the "case 10-19" BB, hence the false positive. The issue is that we have two dom walks: first within vr_values' substitute_and_fold_dom_walker (which has skip_unreachable_blocks == false), then another within vrp_prop::check_all_array_refs (with skip_unreachable_blocks == true). Each has different "knowledge" about ruling out edges due to value-ranges, but we aren't combining that information. The former "knows" about out-edges at a particular control construct (e.g. at a switch), the latter "knows" about dominance, but only about unique successors (hence the problem when two out of three switch cases are valid). This patch combines the information by preserving the EDGE_EXECUTABLE flags from the first dom walk, and using it in the second dom walk, potentially rejecting additional edges. Doing so fixes the false positive. I attempted an alternative fix, merging the two dom walks into one, but that led to crashes in identify_jump_threads, so I went with this, as a less invasive fix. gcc/ChangeLog: PR tree-optimization/83510 * domwalk.c (set_all_edges_as_executable): New function. (dom_walker::dom_walker): Convert bool param "skip_unreachable_blocks" to enum reachability. Move setup of edge flags to set_all_edges_as_executable and only do it when reachability is REACHABLE_BLOCKS. * domwalk.h (enum dom_walker::reachability): New enum. (dom_walker::dom_walker): Convert bool param "skip_unreachable_blocks" to enum reachability. (set_all_edges_as_executable): New decl. * graphite-scop-detection.c (gather_bbs::gather_bbs): Convert from false for "skip_unreachable_blocks" to ALL_BLOCKS for "reachability". * tree-ssa-dom.c (dom_opt_dom_walker::dom_opt_dom_walker): Likewise, but converting true to REACHABLE_BLOCKS. * tree-ssa-sccvn.c (sccvn_dom_walker::sccvn_dom_walker): Likewise. * tree-vrp.c (check_array_bounds_dom_walker::check_array_bounds_dom_walker): Likewise, but converting it to REACHABLE_BLOCKS_PRESERVING_FLAGS. (vrp_dom_walker::vrp_dom_walker): Likewise, but converting it to REACHABLE_BLOCKS. (vrp_prop::vrp_finalize): Call set_all_edges_as_executable if check_all_array_refs will be called. gcc/testsuite/ChangeLog: PR tree-optimization/83510 * gcc.c-torture/compile/pr83510.c: New test case. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr83510.c Modified: trunk/gcc/ChangeLog trunk/gcc/domwalk.c trunk/gcc/domwalk.h trunk/gcc/graphite-scop-detection.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-dom.c trunk/gcc/tree-ssa-sccvn.c trunk/gcc/tree-vrp.c
[Bug tree-optimization/83312] [8 regression] bogus -Warray-bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83312 --- Comment #11 from David Malcolm --- Author: dmalcolm Date: Tue Jan 23 11:10:47 2018 New Revision: 256980 URL: https://gcc.gnu.org/viewcvs?rev=256980&root=gcc&view=rev Log: -Warray-bounds: Fix false positive in some "switch" stmts (PR tree-optimization/83510) PR tree-optimization/83510 reports that r255649 (for PR tree-optimization/83312) introduced a false positive for -Warray-bounds for array accesses within certain switch statements: those for which value-ranges allow more than one case to be reachable, but for which one or more of the VR-unreachable cases contain out-of-range array accesses. In the reproducer, after the switch in f is inlined into g, we have 3 cases for the switch (case 9, case 10-19, and default), within a loop that ranges from 0..9. With both the old and new code, vr_values::simplify_switch_using_ranges clears the EDGE_EXECUTABLE flag on the edge to the "case 10-19" block. This happens during the dom walk within the substitute_and_fold_engine. With the old code, the clearing of that EDGE_EXECUTABLE flag led to the /* Skip blocks that were found to be unreachable. */ code in the old implementation of vrp_prop::check_all_array_refs skipping the "case 10-19" block. With the new code, we have a second dom walk, and that dom_walker's ctor sets all edges to be EDGE_EXECUTABLE, losing that information. Then, dom_walker::before_dom_children (here, the subclass' check_array_bounds_dom_walker::before_dom_children) can return one edge, if there's a unique successor edge, and dom_walker::walk filters the dom walk to just that edge. Here we have two VR-valid edges (case 9 and default), and an VR-invalid successor edge (case 10-19). There's no *unique* valid successor edge, and hence taken_edge is NULL, and the filtering in dom_walker::walk doesn't fire. Hence we've lost the filtering of the "case 10-19" BB, hence the false positive. The issue is that we have two dom walks: first within vr_values' substitute_and_fold_dom_walker (which has skip_unreachable_blocks == false), then another within vrp_prop::check_all_array_refs (with skip_unreachable_blocks == true). Each has different "knowledge" about ruling out edges due to value-ranges, but we aren't combining that information. The former "knows" about out-edges at a particular control construct (e.g. at a switch), the latter "knows" about dominance, but only about unique successors (hence the problem when two out of three switch cases are valid). This patch combines the information by preserving the EDGE_EXECUTABLE flags from the first dom walk, and using it in the second dom walk, potentially rejecting additional edges. Doing so fixes the false positive. I attempted an alternative fix, merging the two dom walks into one, but that led to crashes in identify_jump_threads, so I went with this, as a less invasive fix. gcc/ChangeLog: PR tree-optimization/83510 * domwalk.c (set_all_edges_as_executable): New function. (dom_walker::dom_walker): Convert bool param "skip_unreachable_blocks" to enum reachability. Move setup of edge flags to set_all_edges_as_executable and only do it when reachability is REACHABLE_BLOCKS. * domwalk.h (enum dom_walker::reachability): New enum. (dom_walker::dom_walker): Convert bool param "skip_unreachable_blocks" to enum reachability. (set_all_edges_as_executable): New decl. * graphite-scop-detection.c (gather_bbs::gather_bbs): Convert from false for "skip_unreachable_blocks" to ALL_BLOCKS for "reachability". * tree-ssa-dom.c (dom_opt_dom_walker::dom_opt_dom_walker): Likewise, but converting true to REACHABLE_BLOCKS. * tree-ssa-sccvn.c (sccvn_dom_walker::sccvn_dom_walker): Likewise. * tree-vrp.c (check_array_bounds_dom_walker::check_array_bounds_dom_walker): Likewise, but converting it to REACHABLE_BLOCKS_PRESERVING_FLAGS. (vrp_dom_walker::vrp_dom_walker): Likewise, but converting it to REACHABLE_BLOCKS. (vrp_prop::vrp_finalize): Call set_all_edges_as_executable if check_all_array_refs will be called. gcc/testsuite/ChangeLog: PR tree-optimization/83510 * gcc.c-torture/compile/pr83510.c: New test case. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr83510.c Modified: trunk/gcc/ChangeLog trunk/gcc/domwalk.c trunk/gcc/domwalk.h trunk/gcc/graphite-scop-detection.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-dom.c trunk/gcc/tree-ssa-sccvn.c trunk/gcc/tree-vrp.c
[Bug tree-optimization/83510] [8 Regression] Recent changes for -Warray-bounds trigger false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83510 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from David Malcolm --- Should be fixed by r256980.
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 83510, which changed state. Bug 83510 Summary: [8 Regression] Recent changes for -Warray-bounds trigger false positive https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83510 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/83962] [8 Regression] ICE: verify_flow_info failed (too many outgoing branch edges from bb 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83962
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-01-23
CC||abel at gcc dot gnu.org,
||amonakov at gcc dot gnu.org,
||jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Bisecting, but the ICE is very old.
Anyway, what I see is we have EDGE_FALLTHRU edge as the single edge out of a bb
not ending with any jump, then in reorder_basic_blocks ->
set_edge_can_fallthru_flag EDGE_CAN_FALLTHRU is ored with it. Then
cfg_layout_finalize -> fixup_reorder_chain -> force_nonfallthru_and_redirect
clears the EDGE_FALLTHRU bit in and adds an unconditional jump to the target
bb.
But then selective scheduling (sched2 pass) creates bogus:
(code_label 51 29 50 8 7 (nil) [0 uses])
(note 50 51 98 8 [bb 8] NOTE_INSN_BASIC_BLOCK)
(insn 98 50 82 8 (set (reg:SI 3 3 [orig:123 iftmp.0_4 ] [123])
(reg:SI 10 10 [orig:140 iftmp.0_4 ] [140])) 487 {*movsi_internal1}
(nil))
;; succ: 10 [always] (CAN_FALLTHRU)
;; lr out 1 [1] 3 [3] 7 [7] 8 [8] 9 [9] 10 [10] 73 [5]
(barrier 82 98 32)
;; basic block 10, loop depth 0, maybe hot
;; prev block 8, next block 1, flags: (REACHABLE, RTL, MODIFIED)
;; pred: 5 (CAN_FALLTHRU)
;; 7 (CAN_FALLTHRU)
;; 8 [always] (CAN_FALLTHRU)
;; 4 (CAN_FALLTHRU)
;; 6 (CAN_FALLTHRU)
;; bb 10 artificial_defs: { }
;; bb 10 artificial_uses: { u-1(1){ }}
;; lr in1 [1] 3 [3] 7 [7] 8 [8] 9 [9] 10 [10] 73 [5]
;; lr use 1 [1] 3 [3]
;; lr def 3 [3] 4 [4] 76 [ca]
(code_label 32 82 33 10 3 (nil) [4 uses])
out of that, if the edge falls through into the next bb, it should be
EDGE_FALLTHRU, and the barrier should be left out, or there should be an
unconditional jump other passes could remove as unneeded later on.
[Bug c++/83950] [8 regression] error: no matching function for call to ‘folly::dynamic::at(size_t&) const’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83950 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-23 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r256866.
[Bug rtl-optimization/83962] [6/7/8 Regression] ICE: verify_flow_info failed (too many outgoing branch edges from bb 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83962 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 CC||segher at gcc dot gnu.org Summary|[8 Regression] ICE: |[6/7/8 Regression] ICE: |verify_flow_info failed |verify_flow_info failed |(too many outgoing branch |(too many outgoing branch |edges from bb 8)|edges from bb 8) --- Comment #2 from Jakub Jelinek --- Started with r228692, likely latent before.
[Bug tree-optimization/81082] [8 Regression] Failure to vectorise after reassociating index computation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81082
--- Comment #6 from Richard Biener ---
So moving the transform to match.pd will only have an effect in late VRP
given we need loop header copying to derive a range for the bNs.
The following is what I've done, remove the problematic foldings from
fold-const.c
and re-instantiate the full transform (but not the factoring of power of twos)
in match.pd. It vectorizes this testcase again and restores Himeno performance
(PR81554), dump differences are too big to see what helps but I can say
the match.pd patterns mostly apply via generic (SCEV/IVOPTs) and there's
two late applies in VRP2 and forwprop4 on GIMPLE. Note that all but one
match the a*b + a cases, the single a*b + a*c case is from forwprop4.
I'm quite sure the patterns are confused by association, say,
a*(b*c) + a*b, where for signed arithmetic reassoc doesn't "fix" this up.
But the fold-const.c implementation has exactly the same issue.
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 256977)
+++ gcc/fold-const.c(working copy)
@@ -7095,24 +7095,7 @@ fold_plusminus_mult_expr (location_t loc
fold_convert_loc (loc, type, alt1)),
fold_convert_loc (loc, type, same));
- /* Same may be zero and thus the operation 'code' may overflow. Likewise
- same may be minus one and thus the multiplication may overflow. Perform
- the operations in an unsigned type. */
- tree utype = unsigned_type_for (type);
- tree tem = fold_build2_loc (loc, code, utype,
- fold_convert_loc (loc, utype, alt0),
- fold_convert_loc (loc, utype, alt1));
- /* If the sum evaluated to a constant that is not -INF the multiplication
- cannot overflow. */
- if (TREE_CODE (tem) == INTEGER_CST
- && (wi::to_wide (tem)
- != wi::min_value (TYPE_PRECISION (utype), SIGNED)))
-return fold_build2_loc (loc, MULT_EXPR, type,
- fold_convert (type, tem), same);
-
- return fold_convert_loc (loc, type,
- fold_build2_loc (loc, MULT_EXPR, utype, tem,
- fold_convert_loc (loc, utype,
same)));
+ return NULL_TREE;
}
/* Subroutine of native_encode_expr. Encode the INTEGER_CST
Index: gcc/match.pd
===
--- gcc/match.pd(revision 256977)
+++ gcc/match.pd(working copy)
@@ -4617,3 +4617,29 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
|| wi::geu_p (wi::to_wide (@rpos),
wi::to_wide (@ipos) + isize))
(BIT_FIELD_REF @0 @rsize @rpos)
+
+(for plusminus (plus minus)
+ (simplify
+ (plusminus (mult @0 @1) (mult:c @0 @2))
+ (if (! INTEGRAL_TYPE_P (type)
+ || TYPE_OVERFLOW_WRAPS (type)
+ || (tree_expr_nonzero_p (@0)
+ && expr_not_equal_to (@0, wi::minus_one (TYPE_PRECISION (type)
+ (mult (plusminus @1 @2) @0)))
+ (simplify
+ (plusminus @0 (mult:c @0 @2))
+ /* We cannot generate constant 1 for fract. */
+ (if (! ALL_FRACT_MODE_P (TYPE_MODE (type))
+ && (! INTEGRAL_TYPE_P (type)
+ || TYPE_OVERFLOW_WRAPS (type)
+ || (tree_expr_nonzero_p (@0)
+ && expr_not_equal_to (@0, wi::minus_one (TYPE_PRECISION
(type))
+ (mult (plusminus { build_one_cst (type); } @2) @0)))
+ (simplify
+ (plusminus (mult:c @0 @2) @0)
+ (if (! ALL_FRACT_MODE_P (TYPE_MODE (type))
+ && (! INTEGRAL_TYPE_P (type)
+ || TYPE_OVERFLOW_WRAPS (type)
+ || (tree_expr_nonzero_p (@0)
+ && expr_not_equal_to (@0, wi::minus_one (TYPE_PRECISION
(type))
+ (mult (plusminus @2 { build_one_cst (type); }) @0
Now testing the patch looking for testsuite fallout.
[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- I've even seen in one recent regtest: FAIL: libstdc++-prettyprinters/80276.cc whatis p4 FAIL: libstdc++-prettyprinters/80276.cc whatis p4 where both normal15 and normal16 directories contained the FAILs. Perhaps the parallelization of libstdc++ tests got out of sync?
[Bug rtl-optimization/81443] [7/8 regression] build/genrecog.o: virtual memory exhausted: Cannot allocate memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81443 Eric Botcazou changed: What|Removed |Added Component|middle-end |rtl-optimization --- Comment #15 from Eric Botcazou --- Recategorizing.
[Bug c++/83988] [8 Regression] Internal compiler error in tsubst_baselink
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83988 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug rtl-optimization/81443] [7/8 regression] build/genrecog.o: virtual memory exhausted: Cannot allocate memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81443 Eric Botcazou changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #16 from Eric Botcazou --- Richard, would you be OK to apply a stopgap fix for the 7.3 release? Index: rtlanal.c === --- rtlanal.c (revision 256841) +++ rtlanal.c (working copy) @@ -4976,7 +4976,7 @@ num_sign_bit_copies1 (const_rtx x, machi if (WORD_REGISTER_OPERATIONS && load_extend_op (inner_mode) == SIGN_EXTEND && paradoxical_subreg_p (x) - && (MEM_P (SUBREG_REG (x)) || REG_P (SUBREG_REG (x + && MEM_P (SUBREG_REG (x))) return cached_num_sign_bit_copies (SUBREG_REG (x), mode, known_x, known_mode, known_ret); break; It's a partial reversion of my change for PR rtl-optimization/59461, hence only a small pessimization for 64-bit WORD_REGISTER_OPERATIONS SIGN_EXTEND targets.
[Bug lto/81440] -Wlto-type-mismatch warning with flexible array in struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81440 --- Comment #6 from Martin Liška --- Patch candidate: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01942.html
[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906 --- Comment #7 from Jakub Jelinek --- Actually, the bug seems to FAIL at random, as shown by: while :; do echo -n .; make check RUNTESTFLAGS=prettyprinters.exp=80276.cc > /dev/null 2>/dev/null; grep -q ^FAIL testsuite/libstdc++.log && break; done Got one FAIL after printing 3 dots, another time after 5 dots, then 1 dot, 1 dot again. With patched 80276.cc with your patch, I get one FAIL after printing 2 dots, then 1 dot, 1 dot, 5 dots. So no, this patch doesn't help. This was i686-linux build, gdb-8.0.1-33.fc27.x86_64.
[Bug target/83986] [6/7/8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2348
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83986 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-23 CC||jakub at gcc dot gnu.org Summary|[8 Regression] ICE in |[6/7/8 Regression] ICE in |maybe_record_trace_start, |maybe_record_trace_start, |at dwarf2cfi.c:2348 |at dwarf2cfi.c:2348 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r217331.
[Bug target/83986] [6/7/8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2348
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83986 Jakub Jelinek changed: What|Removed |Added Target Milestone|8.0 |6.5
[Bug rtl-optimization/83962] [6/7/8 Regression] ICE: verify_flow_info failed (too many outgoing branch edges from bb 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83962 Jakub Jelinek changed: What|Removed |Added Target Milestone|8.0 |6.5
[Bug tree-optimization/83991] New: [8 regression] gcc.dg/vect/pr79347.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83991 Bug ID: 83991 Summary: [8 regression] gcc.dg/vect/pr79347.c fail Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: andrey.y.guskov at intel dot com Target Milestone: --- r256888 triggers this: spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/ /source/gcc/testsuite/gcc.dg/vect/pr79347.c -B/work/x86_64-pc-linux-gnu/./libmpx/ -B/work/x86_64-pc-linux-gnu/./libmpx/mpxrt -L/work/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs -B/work/x86_64-pc-linux-gnu/./libmpx/ -B/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap -L/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs -fno-diagnostics-show-caret -fdiagnostics-color=never -msse2 -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -fdump-tree-vect-all -S -o pr79347.s PASS: gcc.dg/vect/pr79347.c (test for excess errors) FAIL: gcc.dg/vect/pr79347.c scan-tree-dump-not vect "Invalid sum of " Option set: -with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared --enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl --enable-languages=c,c++,fortran,jit,lto -with-arch=silvermont --with-cpu=silvermont
[Bug go/83992] New: wrong debug info: wrong NOTE_INSN_BLOCK_BEG placement causes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83992
Bug ID: 83992
Summary: wrong debug info: wrong NOTE_INSN_BLOCK_BEG placement
causes
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: ubizjak at gmail dot com
CC: cmang at google dot com
Target Milestone: ---
The following problem causes TestCrashDumpsAllThreads gotools testcase failure,
as explained in [1]. The core of the problem is in wrong placement of $LBB
label in the for loop [2].
Following testcase illustrates the problem:
--cut here--
package main
func loop(i int, c chan bool) {
close(c)
for {
for j := 0; j < 0x7fff; j++ {
}
}
}
--cut here--
the testcase can be compiled with a crosscompiler to alpha-linux-gnu:
~/gcc-build-alpha/gcc/go1 -O2 -fkeep-static-functions l.go
to generate assembly, where $LBB2 is placed after "lda" insn.
main.loop:
...
$L2:
lda $1,-1($1)
$LBB2:
$LM6:
bne $1,$L2
br $31,$L3
$LBE2:
...
In ._final rtl dump, we can see that (note 52) is in wrong place. It should
be placed in front of (insn 13).
(code_label 14 6 12 2 (nil) [1 uses])
(note 12 14 13 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn:TI 13 12 52 (set (reg:DI 1 $1 [orig:70 ivtmp_1 ] [70])
(plus:DI (reg:DI 1 $1 [orig:70 ivtmp_1 ] [70])
(const_int -1 [0x]))) 7 {*adddi_internal}
(nil))
(note 52 13 15 0x7f6b5f2791e0 NOTE_INSN_BLOCK_BEG)
(jump_insn:TI 15 52 45 (set (pc)
(if_then_else (ne (reg:DI 1 $1 [orig:70 ivtmp_1 ] [70])
(const_int 0 [0]))
(label_ref:DI 14)
(pc))) "l.go":6 169 {*bcc_normal}
(int_list:REG_BR_PROB 1062895956 (nil))
-> 14)
(note 45 15 46 [bb 5] NOTE_INSN_BASIC_BLOCK)
(jump_insn:TI 46 45 47 (set (pc)
(label_ref 16)) 200 {jump}
(nil)
-> 16)
(barrier 47 46 32)
(note 32 47 54 NOTE_INSN_DELETED)
(note 54 32 0 0x7f6b5f2791e0 NOTE_INSN_BLOCK_END)
The wrong label placement results in invalid debug_ranges, which are essential
for libbacktrace to determine name of inlined funcion.
[1] https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01842.html
[2] https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01932.html
[Bug tree-optimization/82819] [8 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82819
--- Comment #3 from Richard Biener ---
I _think_ that in this particular case (and maybe others) we can avoid the
issue by not telling ISL anything about s4 -- this means treating s4 += xn
(which has
associated PHIs and loop-closed PHIs) as black-boxes. This probably also means
we can't handle the if (s4 != 0) stmt in itself (we'd need to treat the
sub-CFG controlled by it as black-box).
So in the end this requires re-writing what GRAPHITE associates with a
black-box,
aka ISL user stmt, making it not only possibly sub-BB granular but also
possibly
covering more than one BB (and in case there is no dependence the black boxes
might even overlap in the original GIMPLE - but a valid pre-transform would be
to re-schedule GIMPLE stmts to make them non-overlapping).
That said, the issue is the following original AST:
[scheduler] original ast:
for (int c0 = 0; c0 < -P_2; c0 += 1) {
S_4(c0);
for (int c1 = 0; c1 <= 2; c1 += 1)
S_5(c0, c1);
S_16(c0);
if (P_19 + 6 * c0 == 18446744073709551610)
S_9((-P_19 + 18446744073709551610) / 6);
S_10(c0);
}
where the if in the AST is from
[local count: 39370534]:
# ns.1_30 = PHI
# s4_29 = PHI
# b2_31 = PHI <&ns(3), b2_13(12)>
...
[local count: 39370534]:
s4_22 = s4_29 + 6;
if (s4_22 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
and the scalar evolution of s4_22 in the region is {s4_19(D) + 6, +, 6}_1.
Looks like the zero test is obfuscated a bit ... the pw_aff for s4_22 is
[P_2, P_19] -> { S_9[i1] -> [(6 + P_19 + 6i1 - 18446744073709551616*floor((6 +
P_19 + 6i1)/18446744073709551616))] }
where the obfuscation is from the chrec initial value s4_19(D) + 6 which
is computed in unsigned arithmetic and thus has to properly support
wrapping.
One thing would be to do more clever pattern matching during code-generation
handling for no-ops. In this particular case
Index: gcc/graphite-isl-ast-to-gimple.c
===
--- gcc/graphite-isl-ast-to-gimple.c(revision 256977)
+++ gcc/graphite-isl-ast-to-gimple.c(working copy)
@@ -326,7 +326,8 @@ binary_op_to_tree (tree type, __isl_take
/* From our constraint generation we may get modulo operations that
we cannot represent explicitely but that are no-ops for TYPE.
Elide those. */
- if (expr_type == isl_ast_op_pdiv_r
+ if ((expr_type == isl_ast_op_pdiv_r
+ || expr_type == isl_ast_op_add)
&& isl_ast_expr_get_type (arg_expr) == isl_ast_expr_int
&& (wi::exact_log2 (widest_int_from_isl_expr_int (arg_expr))
>= TYPE_PRECISION (type)))
is a fix.
[Bug rtl-optimization/81443] [7/8 regression] build/genrecog.o: virtual memory exhausted: Cannot allocate memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81443 --- Comment #17 from rguenther at suse dot de --- On Tue, 23 Jan 2018, ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81443 > > Eric Botcazou changed: > >What|Removed |Added > > CC||rguenth at gcc dot gnu.org > > --- Comment #16 from Eric Botcazou --- > Richard, would you be OK to apply a stopgap fix for the 7.3 release? > > Index: rtlanal.c > === > --- rtlanal.c (revision 256841) > +++ rtlanal.c (working copy) > @@ -4976,7 +4976,7 @@ num_sign_bit_copies1 (const_rtx x, machi >if (WORD_REGISTER_OPERATIONS > && load_extend_op (inner_mode) == SIGN_EXTEND > && paradoxical_subreg_p (x) > - && (MEM_P (SUBREG_REG (x)) || REG_P (SUBREG_REG (x > + && MEM_P (SUBREG_REG (x))) > return cached_num_sign_bit_copies (SUBREG_REG (x), mode, >known_x, known_mode, known_ret); >break; > > It's a partial reversion of my change for PR rtl-optimization/59461, hence > only > a small pessimization for 64-bit WORD_REGISTER_OPERATIONS SIGN_EXTEND targets. Yes, that works for me. It looks like after the above change this part of the code is exactly the same as on the GCC 6 branch (after hookizing LOAD_EXTEND_OP)
[Bug tree-optimization/83991] [8 regression] gcc.dg/vect/pr79347.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83991 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-23 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Let me take a look.
[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #8 from Jonathan Wakely --- The bug is here: if self.type_obj == type_obj: return strip_inline_namespaces(self.name) This assumes the two types resolve to the same gdb.Type but that isn't guaranteed.
[Bug target/82851] [8 regression] g++.dg/vect/slp-pr56812.cc, i386/avx2-vpaddq-3.c, i386/avx2-vpsubq-3.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82851 Andrey Guskov changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #3 from Andrey Guskov --- Honza, I`m very sorry, but the issue persists. I was wrong telling you it`s gone. All three tests continue failing.
[Bug c++/83958] [7/8 Regression] ICE: Segmentation fault (in find_decomp_class_base)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83958 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Tue Jan 23 13:52:23 2018 New Revision: 256984 URL: https://gcc.gnu.org/viewcvs?rev=256984&root=gcc&view=rev Log: PR c++/83958 * decl.c (cp_finish_decomp): Diagnose if reference structure binding refers to incomplete type. * g++.dg/cpp1z/decomp35.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1z/decomp35.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c++/83958] [7 Regression] ICE: Segmentation fault (in find_decomp_class_base)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83958 Jakub Jelinek changed: What|Removed |Added Summary|[7/8 Regression] ICE: |[7 Regression] ICE: |Segmentation fault (in |Segmentation fault (in |find_decomp_class_base) |find_decomp_class_base) --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c++/83978] [8 Regression] ICE in determine_visibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83978 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Tue Jan 23 14:04:18 2018 New Revision: 256985 URL: https://gcc.gnu.org/viewcvs?rev=256985&root=gcc&view=rev Log: PR c++/82882 PR c++/83978 * g++.dg/cpp0x/pr82882.C: New test. * g++.dg/cpp0x/pr83978.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr82882.C trunk/gcc/testsuite/g++.dg/cpp0x/pr83978.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/82882] [8 regression] ICE Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82882 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Tue Jan 23 14:04:18 2018 New Revision: 256985 URL: https://gcc.gnu.org/viewcvs?rev=256985&root=gcc&view=rev Log: PR c++/82882 PR c++/83978 * g++.dg/cpp0x/pr82882.C: New test. * g++.dg/cpp0x/pr83978.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr82882.C trunk/gcc/testsuite/g++.dg/cpp0x/pr83978.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/82882] [8 regression] ICE Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82882 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed with r256964 aka PR83720 fix.
[Bug lto/83720] [8 Regression] ICE: in mangle_decl, at cp/mangle.c:3847
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83720 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed, thanks.
[Bug c++/83988] [8 Regression] Internal compiler error in tsubst_baselink
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83988 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Nathan Sidwell --- Fixed r256986.
[Bug c++/83988] [8 Regression] Internal compiler error in tsubst_baselink
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83988 --- Comment #3 from Nathan Sidwell --- Author: nathan Date: Tue Jan 23 14:08:11 2018 New Revision: 256986 URL: https://gcc.gnu.org/viewcvs?rev=256986&root=gcc&view=rev Log: [PR c++/839888] Baselink tsubst ICE https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01954.html PR c++/83988 * pt.c (tsubst_baselink): Remove optype assert. * ptree.c (cxx_print_xnode): Print BASELINK_OPTYPE. PR c++/83988 * g++.dg/template/pr83988.C: New. Added: trunk/gcc/testsuite/g++.dg/template/pr83988.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/cp/ptree.c trunk/gcc/testsuite/ChangeLog
[Bug c++/83993] New: error: constant not recomputed when ADDR_EXPR changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83993
Bug ID: 83993
Summary: error: constant not recomputed when ADDR_EXPR changed
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: falk at debian dot org
Target Milestone: ---
/tmp% g++ --version
g++ (GCC) 8.0.1 20180119 (experimental)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
/tmp% g++ -c test.cc
test.cc: In function ‘int f()’:
test.cc:3:5: error: constant not recomputed when ADDR_EXPR changed
int f() { return ptable[0]; }
^
&table[0]
test.cc:3:26: note: in statement
int f() { return ptable[0]; }
^
ptable.0_1 = &table[0];
during GIMPLE pass: cfg
test.cc:3:5: internal compiler error: verify_gimple failed
int f() { return ptable[0]; }
^
0xebe341 verify_gimple_in_cfg(function*, bool)
../../gcc/tree-cfg.c:5574
0xda714f execute_function_todo
../../gcc/passes.c:1994
0xda7bae execute_todo
../../gcc/passes.c:2048
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/83993] error: constant not recomputed when ADDR_EXPR changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83993
--- Comment #1 from Falk Hueffner ---
/tmp% cat test.cc
extern const int table[];
const int* const ptable = &table[0];
int f() { return ptable[0]; }
[Bug c++/83974] [8 Regression] ICE in cxx_eval_constant_expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83974 --- Comment #3 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01955.html
[Bug tree-optimization/81082] [8 Regression] Failure to vectorise after reassociating index computation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81082 --- Comment #7 from Richard Biener --- FAIL: gcc.dg/tree-ssa/loop-15.c scan-tree-dump-times optimized " + " 0 (found 2 times) the loop is gone but we end up with unfolded _1 = (unsigned int) n_5; _10 = _1 + 4294967295; _6 = (int) _10; _13 = n_5 * _6; j_2 = n_5 + _13; which is when you decipher, just (n * (n - 1)) + n == n * n FAIL: gcc.dg/tree-ssa/pr23294.c scan-tree-dump-not optimized "* 6" FAIL: gcc.dg/tree-ssa/pr23294.c scan-tree-dump-times optimized " * 2" 3 (found 4 times) FAIL: gcc.dg/tree-ssa/pr23294.c scan-tree-dump-times optimized "a_..D. * 5" 3 (found 0 times) my patterns are incomplete and don't for example handle _1 = a_2(D) * 6; _3 = _1 - a_2(D); where it isn't important whether a_2 is zero or -1. Leaving these cases to fold-const.c might be best at this point(?). FAIL: gcc.dg/tree-ssa/pr63586-2.c scan-tree-dump-times reassoc1 "* 6" 1 (found 0 times) Similar. FAIL: gcc.dg/tree-ssa/slsr-3.c scan-tree-dump-times optimized "* 4" 1 (found 4 times) FAIL: gcc.dg/tree-ssa/slsr-3.c scan-tree-dump-times optimized "+ 12|, 12>" 1 (found 0 times) FAIL: gcc.dg/tree-ssa/slsr-3.c scan-tree-dump-times optimized "+ 4|, 4>" 2 (found 1 times) FAIL: gcc.dg/tree-ssa/slsr-3.c scan-tree-dump-times optimized "+ 8|, 8>" 1 (found 0 times) FAIL: gcc.dg/tree-ssa/slsr-4.c scan-tree-dump-times optimized "* 40" 1 (found 2 times) FAIL: gcc.dg/tree-ssa/slsr-4.c scan-tree-dump-times optimized "+ 40" 1 (found 0 times) FAIL: gfortran.dg/reassoc_4.f -O scan-tree-dump-times reassoc1 "[0-9] * " 22 (found 23 times) Leaves us with those FAILs. Thus adjusted fold-const.c hunk would be Index: gcc/fold-const.c === --- gcc/fold-const.c(revision 256977) +++ gcc/fold-const.c(working copy) @@ -7097,7 +7097,7 @@ fold_plusminus_mult_expr (location_t loc /* Same may be zero and thus the operation 'code' may overflow. Likewise same may be minus one and thus the multiplication may overflow. Perform - the operations in an unsigned type. */ + the sum operation in an unsigned type. */ tree utype = unsigned_type_for (type); tree tem = fold_build2_loc (loc, code, utype, fold_convert_loc (loc, utype, alt0), @@ -7110,9 +7110,9 @@ fold_plusminus_mult_expr (location_t loc return fold_build2_loc (loc, MULT_EXPR, type, fold_convert (type, tem), same); - return fold_convert_loc (loc, type, - fold_build2_loc (loc, MULT_EXPR, utype, tem, - fold_convert_loc (loc, utype, same))); + /* Do not resort to unsigned multiplication because + we lose the no-overflow property of the expression. */ + return NULL_TREE; } /* Subroutine of native_encode_expr. Encode the INTEGER_CST
[Bug fortran/82258] [8 regression] allocate_zerosize_3.f fails since r251949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82258 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #13 from rsandifo at gcc dot gnu.org --- I think this is almost certainly a back-end bug, and the same one that caused PR83851
[Bug target/83851] [8 regression] gcc.dg/vect/pr53185-2.c fails on armeb after r256634
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83851 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|rsandifo at gcc dot gnu.org|unassigned at gcc dot gnu.org --- Comment #2 from rsandifo at gcc dot gnu.org --- I think this is a backend bug. Many other vect.exp tests already fail with armeb hf, and similar LD3 uses have been shown to be broken before, see e.g. PR82258. r256634 deliberately introduced the use of LD3 in tests like this, and that in itself isn't wrong.
[Bug c++/83993] [8 Regression] ICE: constant not recomputed when ADDR_EXPR changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83993 David Malcolm changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-23 CC||dmalcolm at gcc dot gnu.org, ||jakub at gcc dot gnu.org Summary|error: constant not |[8 Regression] ICE: |recomputed when ADDR_EXPR |constant not recomputed |changed |when ADDR_EXPR changed Ever confirmed|0 |1 --- Comment #2 from David Malcolm --- Confirmed; seems to have started with r243873.
[Bug target/83851] [8 regression] gcc.dg/vect/pr53185-2.c fails on armeb after r256634
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83851
--- Comment #3 from rsandifo at gcc dot gnu.org
---
To give a few more details, the loop in question is:
.L3:
mov ip, r3
add r3, r3, #48
cmp r3, r4
vld3.32 {d16, d18, d20}, [ip]!
vld3.32 {d17, d19, d21}, [ip]
vstmia sp, {d16-d21}
vld1.64 {d16-d17}, [sp:64]
vst1.64 {d16-d17}, [lr:64]!
bne .L3
which apart from being awful code, has the effect of switching the elements.
[Bug target/83994] New: %ebx is clobbered by stack-clash probing for regparm-3 function in PIC mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83994 Bug ID: 83994 Summary: %ebx is clobbered by stack-clash probing for regparm-3 function in PIC mode Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- Target: i686 Created attachment 43219 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43219&action=edit regparm-3-pic-probe.c The attached reproducer, when compiled with -O2 -m32 -march=i686 -fpic -fstack-clash-protection, clobbers %ebx in PIC mode due to the probing at the start of the function. (Seen on trunk@25693.) The comment on get_scratch_register_on_entry says: /* Return a short-lived scratch register for use on function entry. In 32-bit mode, it is valid only after the registers are saved in the prologue. This register must be released by means of release_scratch_register_on_entry once it is dead. */ This is called from ix86_adjust_stack_and_probe_stack_clash, but in the reproducer, this happens when int_registers_saved is still false in ix86_expand_prologue. It seems that in this case, ix86_save_reg cannot be used to select a register which is save to clobber.
[Bug target/83995] New: ICE: cross compiling for cr16-elf on msys2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83995 Bug ID: 83995 Summary: ICE: cross compiling for cr16-elf on msys2 Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gcc at wijen dot net Target Milestone: --- Created attachment 43220 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43220&action=edit libgcc2.i While cross compiling for cr16-elf in an msys2 environment I came across an ICE. Please note that following exaclty the same procedure does work on arch. During 'make all-target-libgcc': /home/Ben/devel/cr16-elf/gcc-build/./gcc/xgcc -v -save-temps -B/home/Ben/devel/cr16-elf/gcc-build/./gcc/ -B/opt/cr16-elf/cr16-elf/bin/ -B/opt/cr16-elf/cr16-elf/lib/ -isystem /opt/cr16-elf/cr16-elf/include -isystem /opt/cr16-elf/cr16-elf/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../.././gcc -I../../../gcc-7.2.0/libgcc -I../../../gcc-7.2.0/libgcc/. -I../../../gcc-7.2.0/libgcc/../gcc -I../../../gcc-7.2.0/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _mulvdi3.o -MT _mulvdi3.o -MD -MP -MF _mulvdi3.dep -DL_mulvdi3 -c ../../../gcc-7.2.0/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS Reading specs from C:/msys64/home/Ben/devel/cr16-elf/gcc-build/gcc/specs COLLECT_GCC=C:\msys64\home\Ben\devel\cr16-elf\gcc-build\gcc\xgcc.exe Target: cr16-elf Configured with: ../gcc-7.2.0/configure --disable-nls --disable-multilib --disable-shared --disable-threads --prefix=/opt/cr16-elf --target=cr16-elf --with-newlib --enable-languages=c Thread model: single gcc version 7.2.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-B' 'C:/msys64/home/Ben/devel/cr16-elf/gcc-build/gcc/' '-B' 'C:/msys64/opt/cr16-elf/cr16-elf/bin/' '-B' 'C:/msys64/opt/cr16-elf/cr16-elf/lib/' '-isystem' 'C:/msys64/opt/cr16-elf/cr16-elf/include' '-isystem' 'C:/msys64/opt/cr16-elf/cr16-elf/sys-include' '-g' '-O2' '-O2' '-g' '-O2' '-D' 'IN_GCC' '-D' 'CROSS_DIRECTORY_STRUCTURE' '-Wextra' '-Wall' '-Wno-narrowing' '-Wwrite-strings' '-Wcast-qual' '-Wstrict-prototypes' '-Wmissing-prototypes' '-Wold-style-definition' '-isystem' './include' '-g' '-D' 'IN_LIBGCC2' '-fbuilding-libgcc' '-fno-stack-protector' '-D' 'inhibit_libc' '-I' '.' '-I' '.' '-I' '../.././gcc' '-I' '../../../gcc-7.2.0/libgcc' '-I' '../../../gcc-7.2.0/libgcc/.' '-I' '../../../gcc-7.2.0/libgcc/../gcc' '-I' '../../../gcc-7.2.0/libgcc/../include' '-D' 'HAVE_CC_TLS' '-D' 'USE_EMUTLS' '-o' '_mulvdi3.o' '-MT' '_mulvdi3.o' '-MD' '-MP' '-MF' '_mulvdi3.dep' '-D' 'L_mulvdi3' '-c' '-fvisibility=hidden' '-D' 'HIDE_EXPORTS' C:/msys64/home/Ben/devel/cr16-elf/gcc-build/gcc/cc1.exe -E -quiet -v -I . -I . -I ../.././gcc -I ../../../gcc-7.2.0/libgcc -I ../../../gcc-7.2.0/libgcc/. -I ../../../gcc-7.2.0/libgcc/../gcc -I ../../../gcc-7.2.0/libgcc/../include -iprefix c:\msys64\home\ben\devel\cr16-elf\gcc-build\gcc\../lib/gcc/cr16-elf/7.2.0/ -isystem C:/msys64/home/Ben/devel/cr16-elf/gcc-build/gcc/include -isystem C:/msys64/home/Ben/devel/cr16-elf/gcc-build/gcc/include-fixed -MD _mulvdi3.d -MF _mulvdi3.dep -MP -MT _mulvdi3.o -D IN_GCC -D CROSS_DIRECTORY_STRUCTURE -D IN_LIBGCC2 -D inhibit_libc -D HAVE_CC_TLS -D USE_EMUTLS -D L_mulvdi3 -D HIDE_EXPORTS -isystem C:/msys64/opt/cr16-elf/cr16-elf/include -isystem C:/msys64/opt/cr16-elf/cr16-elf/sys-include -isystem ./include ../../../gcc-7.2.0/libgcc/libgcc2.c -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -fbuilding-libgcc -fno-stack-protector -fvisibility=hidden -g -g -g -fworking-directory -O2 -O2 -O2 -fpch-preprocess -o libgcc2.i ignoring nonexistent directory "C:/msys64/opt/cr16-elf/cr16-elf/include" ignoring nonexistent directory "C:/msys64/opt/cr16-elf/cr16-elf/sys-include" ignoring nonexistent directory "./include" ignoring nonexistent directory "c:\msys64\home\ben\devel\cr16-elf\gcc-build\gcc\../lib/gcc/cr16-elf/7.2.0/include" ignoring nonexistent directory "c:\msys64\home\ben\devel\cr16-elf\gcc-build\gcc\../lib/gcc/cr16-elf/7.2.0/include-fixed" ignoring nonexistent directory "c:\msys64\home\ben\devel\cr16-elf\gcc-build\gcc\../lib/gcc/cr16-elf/7.2.0/../../../../cr16-elf/sys-include" ignoring nonexistent directory "c:\msys64\home\ben\devel\cr16-elf\gcc-build\gcc\../lib/gcc/cr16-elf/7.2.0/../../../../cr16-elf/include" ignoring nonexistent directory "c:/msys64/home/ben/devel/cr16-elf/gcc-build/lib/gcc/cr16-elf/7.2.0/include" ignoring nonexistent directory "c:/msys64/home/ben/devel/cr16-elf/gcc-build/lib/gcc/cr16-elf/7.2.0/include-fixed" ignoring nonexistent directory "c:/msys64/home/ben/devel/cr16-elf/gcc-build/cr16-elf/sys-include" ignoring nonexistent
[Bug target/83986] [6/7/8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2348
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83986
Jakub Jelinek changed:
What|Removed |Added
CC||segher at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
So, the problem seems to be aggressive scheduling of the
(insn/f 72 71 73 7 (set (reg:SI 0 0)
(reg:SI 65 lr)) "pr83986.c":5 483 {*movsi_internal1}
(expr_list:REG_DEAD (reg:SI 65 lr)
(nil)))
frame related instruction across a branch, from the basic block containing the
shrink-wrapped prologue to the predecessor, which only conditionally branches
to the prologue.
Shall we disallow moving of frame related instructions across branches in the
scheduler?
[Bug tree-optimization/81082] [8 Regression] Failure to vectorise after reassociating index computation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81082 --- Comment #8 from rsandifo at gcc dot gnu.org --- (In reply to Richard Biener from comment #6) > So moving the transform to match.pd will only have an effect in late VRP > given we need loop header copying to derive a range for the bNs. > > The following is what I've done, remove the problematic foldings from > fold-const.c > and re-instantiate the full transform (but not the factoring of power of > twos) > in match.pd. It vectorizes this testcase again and restores Himeno > performance > (PR81554) Thanks for looking at this. Himeno was (as you probably guessed) the original benchmark from which the testcase was reduced. The impact for us was much higher than the one in PR81554.
[Bug c++/83947] [8 Regression] ICE on invalid C++ code with auto: in tsubst_decl, at cp/pt.c:13046
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83947 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/83994] %ebx is clobbered by stack-clash probing for regparm-3 function in PIC mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83994 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #1 from Jeffrey A. Law --- I haven't looked at this yet (but will shortly). But it is worth noting that %ebx is no longer fixed, even with -fPIC on i686.
[Bug target/83862] powerpc: ICE in signbit testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83862 --- Comment #3 from Michael Meissner --- Author: meissner Date: Tue Jan 23 15:07:00 2018 New Revision: 256987 URL: https://gcc.gnu.org/viewcvs?rev=256987&root=gcc&view=rev Log: [gcc] 2018-01-23 Michael Meissner Back port from trunk 2018-01-22 Michael Meissner PR target/83862 * config/rs6000/rs6000-protos.h (rs6000_split_signbit): Delete, no longer used. * config/rs6000/rs6000.c (rs6000_split_signbit): Likewise. * config/rs6000/rs6000.md (signbit2): Change code for IEEE 128-bit to produce an UNSPEC move to get the double word with the signbit and then a shift directly to do signbit. (signbit2_dm): Replace old IEEE 128-bit signbit implementation with a new version that just does either a direct move or a regular move. Move memory interface to separate insns. Move insns so they are next to the expander. (signbit2_dm_mem_be): New combiner insns to combine load with signbit move. Split big and little endian case. (signbit2_dm_mem_le): Likewise. (signbit2_dm_ext): Delete, no longer used. (signbit2_dm2): Likewise. [gcc/testsuite] 2018-01-23 Michael Meissner Back port from trunk 2018-01-22 Michael Meissner PR target/83862 * gcc.target/powerpc/pr83862.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr83862.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/rs6000/rs6000-protos.h branches/gcc-6-branch/gcc/config/rs6000/rs6000.c branches/gcc-6-branch/gcc/config/rs6000/rs6000.md branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug target/83862] powerpc: ICE in signbit testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83862 --- Comment #4 from Michael Meissner --- GCC 6 backport applied, GCC 7 backport waiting for GCC 7.3 to ship, before applying the patch.
[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906 Jakub Jelinek changed: What|Removed |Added CC||palves at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- If I retry this while :; do echo -n .; make check RUNTESTFLAGS=prettyprinters.exp=80276.cc > /dev/null 2>/dev/null; grep -q ^FAIL testsuite/libstdc++.log && break; done under setarch x86_64 -R /bin/sh shell, I see no random failures, 20 PASSes in a row, then I've Ctrl-Ced it. The question is if this is because of ASLR of the gdb process, or ASLR of the debugger process.
[Bug lto/83967] LTO removes C functions declared as weak in assembler(depending on files order in linking)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83967 Bernd K changed: What|Removed |Added CC||prof7bit at gmail dot com --- Comment #11 from Bernd K --- Created attachment 43221 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43221&action=edit self contained demo I have made a minimal self contained project that demonstrates the bug with arm-none-eabi-gcc compiling for a Cortex M0+ target (Kinetis MKL05), it is self contained and does not require anything but the installed toolchain itself. Extract the attached archive KL05_demo_gcc_weak_strong_bug.tar.gz. You will find a minimal makefile project, versioned in a git repository with only two commits on two branches, one shows the bug and the other doesn't. $ git checkout bad $ make clean $ make all look at the generated .lst file in the build folder and note that the Systick handler looks like this, it is the weak default implementation from the startup assembly: 04f4 : 4f4: e7feb.n 4f4 now checkout the good version $ git checkout good $ make clean $ make all The systick handler will look like this which is the strong C implementation: 044c : 44c: 4a02ldr r2, [pc, #8] ; (458 ) 44e: 6813ldr r3, [r2, #0] 450: 3301adds r3, #1 452: 6013str r3, [r2, #0] 454: 4770bx lr 456: 46c0nop ; (mov r8, r8) 458: 1c00 .word 0x1c00 and the only difference between these two sources is one line in the makefile moved to a different position: $ git diff bad good diff --git a/Makefile b/Makefile index 35ff9c6..82e6d47 100644 --- a/Makefile +++ b/Makefile @@ -4,9 +4,9 @@ NAME= example -SRCS += $(wildcard *.c) SRCS += $(wildcard cmsis/MKL05Z4/*.s) SRCS += $(wildcard cmsis/MKL05Z4/*.c) +SRCS += $(wildcard *.c) INCDIRS = cmsis/ INCDIRS+= cmsis/MKL05Z4/
[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906 Pedro Alves changed: What|Removed |Added CC||palves at redhat dot com --- Comment #10 from Pedro Alves --- GDB starts inferiors with ASLR disabled by default: (gdb) show disable-randomization Disabling randomization of debuggee's virtual address space is on. so if this is ASLR, it's going to be ASLR of the gdb process. Which sounds consistent with Jonathan's finding.
[Bug target/83994] %ebx is clobbered by stack-clash probing for regparm-3 function in PIC mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83994 --- Comment #2 from Florian Weimer --- It's still callee-saved, so it is picked by get_scratch_register_on_entry if it is saved by the function, under the assumption that it is used only after the prologue has saved it and there is no need to save and restore it separately. (At least that's my understanding of the issue.)
[Bug lto/81440] -Wlto-type-mismatch warning with flexible array in struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81440 --- Comment #7 from Martin Liška --- Author: marxin Date: Tue Jan 23 15:46:02 2018 New Revision: 256989 URL: https://gcc.gnu.org/viewcvs?rev=256989&root=gcc&view=rev Log: Handle trailing arrays in ODR warning (PR lto/81440). 2018-01-23 Martin Liska PR lto/81440 * lto-symtab.c (lto_symtab_merge): Handle and do not warn about trailing arrays at the end of a struct. 2018-01-23 Martin Liska PR lto/81440 * gcc.dg/lto/pr81440.h: New test. * gcc.dg/lto/pr81440_0.c: New test. * gcc.dg/lto/pr81440_1.c: New test. Added: trunk/gcc/testsuite/gcc.dg/lto/pr81440.h trunk/gcc/testsuite/gcc.dg/lto/pr81440_0.c trunk/gcc/testsuite/gcc.dg/lto/pr81440_1.c Modified: trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto-symtab.c trunk/gcc/testsuite/ChangeLog
[Bug go/83992] wrong debug info: wrong NOTE_INSN_BLOCK_BEG placement causes TestCrashDumpsAllThreads gotools testcase failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83992 --- Comment #1 from Ian Lance Taylor --- In the 147t.cddce2 dump (as dumped with -fdump-tree-all-lineno) I see this: [local count: 1063004407]: # j_8 = PHI <[foo.go:6:7] 0(3), [foo.go:6:31] j_5(6)> # DEBUG j => j_8 [foo.go:6:31] j_5 = j_8 + 1; [foo.go:6:31] # DEBUG j => j_5 # DEBUG j => j_5 [foo.go:6:17] if (j_5 != 2147483647) goto ; [98.99%] else goto ; [1.01%] In the subsequent 148t.ivcanon dump I see this: [local count: 1063004407]: # j_8 = PHI <[foo.go:6:7] 0(3), [foo.go:6:31] j_5(6)> # ivtmp_7 = PHI <2147483647(3), ivtmp_1(6)> # DEBUG j => j_8 [foo.go:6:31] j_5 = j_8 + 1; [foo.go:6:31] # DEBUG j => j_5 # DEBUG j => j_5 ivtmp_1 = ivtmp_7 - 1; [foo.go:6:17] if (ivtmp_1 != 0) goto ; [98.99%] else goto ; [1.01%] Note that the new insn `ivtmp_1 = ivtmp_7 - 1;` has no location info. I think that is the point that leads to the incorrect placement of the NOTE_INSN_BLOCK_BEG note.
[Bug lto/81440] -Wlto-type-mismatch warning with flexible array in struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81440 Martin Liška changed: What|Removed |Added Known to work||8.0 Known to fail||6.4.0, 7.2.0 --- Comment #8 from Martin Liška --- Fixed on trunk, queued for backport.
[Bug c++/83993] [7/8 Regression] ICE: constant not recomputed when ADDR_EXPR changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83993
Jakub Jelinek changed:
What|Removed |Added
Priority|P1 |P2
CC||jason at gcc dot gnu.org
Target Milestone|--- |8.0
Summary|[8 Regression] ICE: |[7/8 Regression] ICE:
|constant not recomputed |constant not recomputed
|when ADDR_EXPR changed |when ADDR_EXPR changed
--- Comment #3 from Jakub Jelinek ---
Because the array has no TYPE_DOMAIN, in cxx_eval_array_reference
if (TREE_CODE (TREE_TYPE (ary)) == ARRAY_TYPE)
nelts = array_type_nelts_top (TREE_TYPE (ary));
sets nelts to error_mark_node + 1, and so the cxx_eval_constant_expression
calls sets *non_constant_p. Then later on the caller of this,
cxx_eval_outermost_constant_expr, does:
4818 else if (non_constant_p && TREE_CONSTANT (r))
4819{
4820 /* This isn't actually constant, so unset TREE_CONSTANT. */
4821 if (EXPR_P (r))
4822r = copy_node (r);
4823 else if (TREE_CODE (r) == CONSTRUCTOR)
4824r = build1 (VIEW_CONVERT_EXPR, TREE_TYPE (r), r);
4825 else
4826r = build_nop (TREE_TYPE (r), r);
4827 TREE_CONSTANT (r) = false;
4828}
on the ADDR_EXPR surrounding the ARRAY_REF.
So, the questions are:
1) if we have such [] arrays, does any access to any element in the array imply
a non-constant expression, or should we ignore the in-bounds check?
E.g. on
extern const int a[];
const int b[5] = { 1, 2, 3, 4, 5 };
extern const int c[5];
constexpr const int *d = &a[0];
constexpr const int *e = &a[10];
constexpr const int *f = &b[0];
constexpr const int *g = &b[5];
constexpr const int *h = &b[6];
constexpr const int *i = &b[0];
constexpr const int *j = &b[5];
constexpr const int *k = &b[6];
g++ errors on h and k definitions, while clang++ errors on e, h, k, somehow it
considers &a[0] to be always ok no matter how large the array is (that is
actually a reasonable assumption for lval case, even if the array has zero
size, it is still valid to form a pointer past it), but considers &a[10]
invalid, even when the other TU could have const int a[100].
2) does cxx_eval_outermost_constant_expr really need to clear TREE_CONSTANT
even on ADDR_EXPRs, or could we special case those? If we need to clear those,
supposedly during genericization we should try to recompute the ADDR_EXPR flags
and if that would change them, copy node and restore there what the middle-end
expects.
Jason, do you have answers to these questions, please?
[Bug target/83994] %ebx is clobbered by stack-clash probing for regparm-3 function in PIC mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83994 --- Comment #3 from Jeffrey A. Law --- I think the problem here is that we don't force the register saves to happen prior to probing.
[Bug target/83994] %ebx is clobbered by stack-clash probing for regparm-3 function in PIC mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83994 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-23 Ever confirmed|0 |1
[Bug c++/83993] [7/8 Regression] ICE: constant not recomputed when ADDR_EXPR changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83993 --- Comment #4 from Jakub Jelinek --- The clang++ error on e is: pr83993-2.C:5:22: error: constexpr variable 'e' must be initialized by a constant expression constexpr const int *e = &a[10]; ^ ~~ pr83993-2.C:5:27: note: indexing of array without known bound is not allowed in a constant expression constexpr const int *e = &a[10]; ^ Note, diag_array_subscript is called in constexpr.c multiple times, if we go for allowing lval ary[0] for array of unknown bounds, but disallow ary[N] for N != 0 for lval or any N for !lval, we'd need 2 other diagnostic messages in diag_array_subscript and handle these cases in the callers. Another case that needs testing is const int array[0]; and [] arrays with initializers from which the size is determined.
[Bug tree-optimization/83991] [8 regression] gcc.dg/vect/pr79347.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83991 Martin Liška changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #2 from Martin Liška --- Can't reproduce on my Haswell CPU. What're your -march and -mtune options?
[Bug tree-optimization/83992] wrong debug info: wrong NOTE_INSN_BLOCK_BEG placement causes TestCrashDumpsAllThreads gotools testcase failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83992 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Is that really a bug? The ivtmp decrement is an artificial statement, so why should it have a location and what exactly? I really think the test should build with -O0 or -Og or something similar if it expects the trivial loop not to be optimized significantly.
[Bug middle-end/70895] OpenACC: loop reduction does not work. Output is zero.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70895 Tom de Vries changed: What|Removed |Added CC||vries at gcc dot gnu.org --- Comment #9 from Tom de Vries --- Chung-Lin, is there something that remains to be done here, or can this be closed?
[Bug tree-optimization/82604] [8 Regression] SPEC CPU2006 410.bwaves ~50% performance regression with trunk@253679 when ftree-parallelize-loops is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82604 --- Comment #18 from amker at gcc dot gnu.org --- Author: amker Date: Tue Jan 23 16:47:03 2018 New Revision: 256990 URL: https://gcc.gnu.org/viewcvs?rev=256990&root=gcc&view=rev Log: PR tree-optimization/82604 * tree-loop-distribution.c (enum partition_kind): New enum item PKIND_PARTIAL_MEMSET. (partition_builtin_p): Support above new enum item. (generate_code_for_partition): Ditto. (compute_access_range): Differentiate cases that equality can be proven at all loops, the innermost loops or no loops. (classify_builtin_st, classify_builtin_ldst): Adjust call to above function. Set PKIND_PARTIAL_MEMSET for partition appropriately. (finalize_partitions, distribute_loop): Don't fuse partition of PKIND_PARTIAL_MEMSET kind when distributing 3-level loop nest. (prepare_perfect_loop_nest): Distribute 3-level loop nest only if parloop is enabled. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-loop-distribution.c
