date:20201101

[Bug analyzer/97668] [11 Regression] ICE in cmp_cst, at analyzer/svalue.cc:283

2020-11-01 Thread rguenth at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97668

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug inline-asm/97667] [11 Regression] a bug in asm_operand_ok() recog.c:1801

2020-11-01 Thread rguenth at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97667

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target||x86_64-*-*
   Target Milestone|--- |11.0
Summary|a bug in asm_operand_ok()   |[11 Regression] a bug in
   |recog.c:1801|asm_operand_ok()
   ||recog.c:1801

[Bug tree-optimization/97666] [11 Regression] bootstrap fail for powerpc-darwin while building libgfortran after r11-4485

2020-11-01 Thread rguenth at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97666

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

--- Comment #1 from Richard Biener  ---
Hmm, in vectorizable_operation () can you try

(gdb) p debug (slp_node)

?

If r11-4485 is the correct bisect point -fdump-tree-slp-details before/after
this rev might also provide a clue ...

[Bug ipa/97660] [11 Regression] ICE: Segmentation fault in function_summary::get(cgraph_node*) since r11-4587

2020-11-01 Thread rguenth at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97660

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Richard Biener  ---
Fixed.

[Bug middle-end/97656] Specify that there is no address arithmetic on a pointer

2020-11-01 Thread rguenth at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97656

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
It's of course not that simple since the GIMPLE IL can require pointer
arithmetic as implementation detail.  I guess we could try modeling this as 'fn
spec'
by making 'direct' even stricter meaning 'direct w/o additional offset' so
we can build an exact ao_ref here.  Maybe use

". WT"

for this?  And the discussed 'a'...'z' for the "upper case" '1'...'9', both
to denote the range is exact?  Note we discussed that we can this way
specify a must-def but here it's a may-def but with known offset.  Guess
must vs. may would rather be another first letter like 'D'? (and only 'direct'
supported there obviously)  And the upper case size specification means
at zero offset?

[Bug tree-optimization/96967] [11 Regression] ICE in decompose, at wide-int.h:984

2020-11-01 Thread clyon at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96967

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #5 from Christophe Lyon  ---
Sorry comment #4 is unrelated to this PR, I made a typo and meant PR96767.

[Bug target/96767] -mpure-code produces indirect loads for thumb-1

2020-11-01 Thread clyon at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96767

Christophe Lyon  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #2 from Christophe Lyon  ---
The master branch has been updated by Christophe Lyon :

https://gcc.gnu.org/g:4d9af90d6a216822fe117337fb9836ba656dc3af

commit r11-4598-g4d9af90d6a216822fe117337fb9836ba656dc3af
Author: Christophe Lyon 
Date:   Mon Nov 2 07:31:22 2020 +

arm: Avoid indirection with -mpure-code on v6m (PR96967)

With -mpure-code on v6m (thumb-1), to avoid a useless indirection when
building the address of a symbol, we want to consider SYMBOL_REF as a
legitimate constant. This way, we build the address using a series of
upper/lower relocations instead of loading the address from memory.

This patch also fixes a missing "clob" conds attribute for
thumb1_movsi_insn, needed because that alternative clobbers the flags.

2020-11-02  Christophe Lyon  

gcc/
PR target/96967
* config/arm/arm.c (thumb_legitimate_constant_p): Add support for
disabled literal pool in thumb-1.
* config/arm/thumb1.md (thumb1_movsi_symbol_ref): Remove.
(*thumb1_movsi_insn): Add support for SYMBOL_REF with -mpure-code.

gcc/testsuite
PR target/96967
* gcc.target/arm/pure-code/pr96767.c: New test.

[Bug tree-optimization/97650] ICE: tree check: expected ssa_name, have addr_expr in vect_get_and_check_slp_defs, at tree-vect-slp.c:533 with "-Os -ftree-slp-vectorize -fallow-store-data-races"

2020-11-01 Thread rguenth at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97650

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
  Component|c   |tree-optimization
   Last reconfirmed||2020-11-02
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #1 from Richard Biener  ---
Mine.

[Bug target/96770] -mpure-code produces suboptimal code for relocations with small offset for thumb-1

2020-11-01 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96770

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Christophe Lyon :

https://gcc.gnu.org/g:c3c3e2c9e88e25a410a2fe089782b094e911bb39

commit r11-4599-gc3c3e2c9e88e25a410a2fe089782b094e911bb39
Author: Christophe Lyon 
Date:   Mon Nov 2 07:34:50 2020 +

arm: Improve handling of relocations with small offsets with -mpure-code on
v6m (PR96770)

With -mpure-code on v6m (thumb-1), we can use small offsets with
upper/lower relocations to avoid the extra addition of the
offset.

This patch accepts expressions symbol+offset as legitimate constants
when the literal pool is disabled, making sure that the offset is
within the range supported by thumb-1 [0..255] as described in the
AAELF32 documentation.

It also makes sure that thumb1_movsi_insn emits an error in case we
try to use it with an unsupported RTL construct.

2020-09-28  Christophe Lyon  

gcc/
PR target/96770
* config/arm/arm.c (thumb_legitimate_constant_p): Accept
(symbol_ref + addend) when literal pool is disabled.
(arm_valid_symbolic_address_p): Add support for thumb-1 without
MOVT/MOVW.
* config/arm/thumb1.md (*thumb1_movsi_insn): Accept (symbol_ref +
addend) in the pure-code alternative.

gcc/testsuite/
PR target/96770
* gcc.target/arm/pure-code/pr96770.c: New test.

[Bug tree-optimization/96967] [11 Regression] ICE in decompose, at wide-int.h:984

2020-11-01 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96967

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Christophe Lyon :

https://gcc.gnu.org/g:4d9af90d6a216822fe117337fb9836ba656dc3af

commit r11-4598-g4d9af90d6a216822fe117337fb9836ba656dc3af
Author: Christophe Lyon 
Date:   Mon Nov 2 07:31:22 2020 +

arm: Avoid indirection with -mpure-code on v6m (PR96967)

With -mpure-code on v6m (thumb-1), to avoid a useless indirection when
building the address of a symbol, we want to consider SYMBOL_REF as a
legitimate constant. This way, we build the address using a series of
upper/lower relocations instead of loading the address from memory.

This patch also fixes a missing "clob" conds attribute for
thumb1_movsi_insn, needed because that alternative clobbers the flags.

2020-11-02  Christophe Lyon  

gcc/
PR target/96967
* config/arm/arm.c (thumb_legitimate_constant_p): Add support for
disabled literal pool in thumb-1.
* config/arm/thumb1.md (thumb1_movsi_symbol_ref): Remove.
(*thumb1_movsi_insn): Add support for SYMBOL_REF with -mpure-code.

gcc/testsuite
PR target/96967
* gcc.target/arm/pure-code/pr96767.c: New test.

[Bug analyzer/97668] New: [11 Regression] ICE in cmp_cst, at analyzer/svalue.cc:283

2020-11-01 Thread asolokha at gmx dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97668

Bug ID: 97668
   Summary: [11 Regression] ICE in cmp_cst, at
analyzer/svalue.cc:283
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

Created attachment 49484
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49484=edit
Testcase

gfortran-11.0.0-alpha20201101 snapshot
(g:590febb5f6624f78b36402a7c9a9c318978f1efa) ICEs when compiling the attached
testcase w/ -O1 -fanalyzer:

% powerpc-e300c3-linux-gnu-gfortran-11.0.0 -std=legacy -O1 -fanalyzer -c
d9xjyayq.f
during IPA pass: analyzer
d9xjyayq.f:6:16:

6 |   DO 136 IG=IS,1
  |^
internal compiler error: in cmp_cst, at analyzer/svalue.cc:283
0x71ef8e cmp_cst
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/analyzer/svalue.cc:283
0x18aca58 cmp1
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/sort.cc:153
0x18acab4 netsort
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/sort.cc:170
0x18acab4 mergesort
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/sort.cc:207
0x18ad0f2 gcc_qsort(void*, unsigned long, unsigned long, int (*)(void const*,
void const*))
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/sort.cc:266
0x183636a ana::constraint_manager::canonicalize()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/analyzer/constraint-manager.cc:1713
0x1211e95 ana::program_state::prune_for_point(ana::exploded_graph&,
ana::program_point const&, ana::exploded_node const*) const
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/analyzer/program-state.cc:1049
0x11fcf02 ana::exploded_graph::get_or_create_node(ana::program_point const&,
ana::program_state const&, ana::exploded_node const*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/analyzer/engine.cc:2045
0x11ffae4 ana::exploded_graph::process_node(ana::exploded_node*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/analyzer/engine.cc:2850
0x1200672 ana::exploded_graph::process_worklist()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/analyzer/engine.cc:2523
0x120282b ana::impl_run_checkers(ana::logger*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/analyzer/engine.cc:4658
0x1203721 ana::run_checkers()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/analyzer/engine.cc:4729
0x11f6748 execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/analyzer/analyzer-pass.cc:84

(While my target here is powerpc, the ICE should not be target-specific.)

[Bug inline-asm/97667] New: a bug in asm_operand_ok() recog.c:1801

2020-11-01 Thread huntazhang at tencent dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97667

Bug ID: 97667
   Summary: a bug in asm_operand_ok() recog.c:1801
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: huntazhang at tencent dot com
  Target Milestone: ---

when i used gcc-11.0 compile linux kernel in
arch/x86/include/asm/checksum_64.h:171 trigger a bug 

here is compile source code argurment 
gcc -Wp,-MMD,net/core/.utils.o.d  -nostdinc -isystem
/usr/lib/gcc/x86_64-linux-gnu/11.0.0/include -I../arch/x86/include
-I./arch/x86/include/generated -I../include -I./include
-I../arch/x86/include/uapi -I./arch/x86/include/generated/uapi
-I../include/uapi -I./include/generated/uapi -include
../include/linux/kconfig.h -include ../include/linux/compiler_types.h
-D__KERNEL__ -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE
-Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type
-Wno-format-security -std=gnu89 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx
-m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387
-mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone
-mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables
-mindirect-branch=thunk-extern -mindirect-branch-register -fno-jump-tables
-fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation
-Wno-format-overflow -Wno-address-of-packed-member -O2
-fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector-strong
-Wno-unused-but-set-variable -Wimplicit-fallthrough -Wno-unused-const-variable
-fomit-frame-pointer -Wdeclaration-after-statement -Wvla -Wno-pointer-sign
-Wno-stringop-truncation -Wno-zero-length-bounds -Wno-array-bounds
-Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized
-fno-strict-overflow -fno-stack-check -fconserve-stack -Werror=date-time
-Werror=incompatible-pointer-types -Werror=designated-init
-fmacro-prefix-map=../= -fcf-protection=none -Wno-packed-not-aligned -I
../net/core -I ./net/core-DKBUILD_MODFILE='"net/core/utils"'
-DKBUILD_BASENAME='"utils"' -DKBUILD_MODNAME='"utils"' -c -o net/core/utils.o
../net/core/utils.c

here is gcc configure:

# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --build=x86_64-linux-gnu --enable-multilib
--enable-pugin --prefix=/usr
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201027 (experimental) (GCC) 

here is trigger  bug source code :
static inline unsigned add32_with_carry(unsigned a, unsigned b)
{
asm("addl %2,%0\n\t"
"adcl $0,%0"
: "=r" (a)
: "0" (a), "rm" (b));
return a;
}

gcc-11.0 combine inline-asm 

(insn 43 84 44 5 (parallel [
(set (reg:SI 126 [ a ])
(asm_operands:SI ("addl %2,%0
adcl $0,%0") ("=r") 0 [
(reg:SI 126 [ a ])
(not:SI (mem/j:SI (plus:DI (reg/v/f:DI 108 [ skb ])
(const_int 136 [0x88])) [169
skb_7(D)->D.41008.csum+0 S4 A64]))
]
 [
(asm_input:SI ("0")
../arch/x86/include/asm/checksum_64.h:171)
(asm_input:SI ("rm")
../arch/x86/include/asm/checksum_64.h:171)
]
 [] ../arch/x86/include/asm/checksum_64.h:171))
(clobber (reg:CC 17 flags))
]) "../arch/x86/include/asm/checksum_64.h":171:2 -1
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))

gcc-10 combine inline-asm 

(insn 43 84 44 5 (parallel [
(set (reg:SI 126 [ a ])
(asm_operands:SI ("addl %2,%0
adcl $0,%0") ("=r") 0 [
(reg:SI 126 [ a ])
(reg:SI 127)
]
 [
(asm_input:SI ("0")
../arch/x86/include/asm/checksum_64.h:171)
(asm_input:SI ("rm")
../arch/x86/include/asm/checksum_64.h:171)
]
 [] ../arch/x86/include/asm/checksum_64.h:171))
(clobber (reg:CC 17 flags))
]) "../arch/x86/include/asm/checksum_64.h":171:2 -1
 (expr_list:REG_DEAD (reg:SI 127)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil


the difference between gcc10 and gcc 11 in asm_operand_ok() recog.c 

gcc-11 is 
case CT_MEMORY:
case CT_SPECIAL_MEMORY:
  /* Every memory operand can be reloaded to fit.  */
  result = result || memory_operand (extract_mem_from_operand (op),

[Bug tree-optimization/97666] [11 Regression] bootstrap fail for powerpc-darwin while building libgfortran after r11-4485

2020-11-01 Thread iains at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97666

Iain Sandoe  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target||powerpc-apple-darwin9
 CC||rguenth at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Host||powerpc-apple-darwin9
   Last reconfirmed||2020-11-01

[Bug tree-optimization/97666] New: [11 Regression] bootstrap fail for powerpc-darwin while building libgfortran after r11-4485

2020-11-01 Thread iains at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97666

Bug ID: 97666
   Summary: [11 Regression] bootstrap fail for powerpc-darwin
while building libgfortran after r11-4485
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
  Target Milestone: ---

Created attachment 49483
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49483=edit
preprocessed generated source example for libgfortran.

unfortunately, although this does fail for a stage#1 on powerpc-darwin, it does
not reproduce on a cross from x86_64.

Program received signal SIGBUS, Bus error.

0x0192cc68 in vect_is_simple_use (vinfo=0x441499e0, stmt=0x4413c8c0,
slp_node=0x2c6c058 , operand=0, op=0xbfffdca8,
slp_def=0xbfffdce8, dt=0xbfffdcb8, vectype=0xbfffdcb4, def_stmt_info_out=0x0)
at /src-local/gcc-master-asi/gcc/tree-vect-stmts.c:11344
11344 *vectype = SLP_TREE_VECTYPE (child);
(gdb) bt
#0  0x0192cc68 in vect_is_simple_use (vinfo=0x441499e0, stmt=0x4413c8c0,
slp_node=0x2c6c058 , operand=0, op=0xbfffdca8,
slp_def=0xbfffdce8, dt=0xbfffdcb8, vectype=0xbfffdcb4, def_stmt_info_out=0x0)
at /src-local/gcc-master-asi/gcc/tree-vect-stmts.c:11344
#1  0x01917cb8 in vectorizable_operation (vinfo=0x441499e0,
stmt_info=0x4413c8c0, gsi=0x0, vec_stmt=0x0, slp_node=0x2c6c058
, cost_vec=0xbfffe1b4) at
/src-local/gcc-master-asi/gcc/tree-vect-stmts.c:5776
#2  0x01929dd0 in vect_analyze_stmt (vinfo=0x441499e0, stmt_info=0x4413c8c0,
need_to_vectorize=0xbfffdf64, node=0x2c6c058 ,
node_instance=0x4413cfd0, cost_vec=0xbfffe1b4)
at /src-local/gcc-master-asi/gcc/tree-vect-stmts.c:10686
#3  0x0197eb00 in vect_slp_analyze_node_operations_1 (vinfo=0x441499e0,
node=0x2c6c058 , node_instance=0x4413cfd0,
cost_vec=0xbfffe1b4) at /src-local/gcc-master-asi/gcc/tree-vect-slp.c:3385
#4  0x0197f194 in vect_slp_analyze_node_operations (vinfo=0x441499e0,
node=0x2c6c058 , node_instance=0x4413cfd0,
visited_set=..., visited_vec=..., cost_vec=0xbfffe1b4)
at /src-local/gcc-master-asi/gcc/tree-vect-slp.c:3532
#5  0x0197f148 in vect_slp_analyze_node_operations (vinfo=0x441499e0,
node=0x2c6c00c , node_instance=0x4413cfd0,
visited_set=..., visited_vec=..., cost_vec=0xbfffe1b4)
at /src-local/gcc-master-asi/gcc/tree-vect-slp.c:3525
#6  0x0197fa30 in vect_slp_analyze_operations (vinfo=0x441499e0) at
/src-local/gcc-master-asi/gcc/tree-vect-slp.c:3722
#7  0x019428a4 in vect_analyze_loop_2 (loop_vinfo=0x441499e0,
fatal=@0xbfffe934: false, n_stmts=0xbfffe90c) at
/src-local/gcc-master-asi/gcc/tree-vect-loop.c:2338
#8  0x01944294 in vect_analyze_loop (loop=0x29be2d8 ,
shared=0xbfffea88) at /src-local/gcc-master-asi/gcc/tree-vect-loop.c:2799
#9  0x01999e10 in try_vectorize_loop_1 (simduid_to_vf_htab=@0xbfffebc8: 0x0,
num_vectorized_loops=0xbfffebc0, loop=0x29be2d8 ,
loop_vectorized_call=0x0, loop_dist_alias_call=0x0)
at /src-local/gcc-master-asi/gcc/tree-vectorizer.c:995
#10 0x0199a5ec in try_vectorize_loop (simduid_to_vf_htab=@0xbfffebc8: 0x0,
num_vectorized_loops=0xbfffebc0, loop=0x29be2d8 ) at
/src-local/gcc-master-asi/gcc/tree-vectorizer.c:1148
#11 0x0199a830 in vectorize_loops () at
/src-local/gcc-master-asi/gcc/tree-vectorizer.c:1230
#12 0x01765f74 in pass_vectorize::execute (this=0x44109b70, fun=0x4473c270) at
/src-local/gcc-master-asi/gcc/tree-ssa-loop.c:414
#13 0x012ad464 in execute_one_pass (pass=0x44109b70) at
/src-local/gcc-master-asi/gcc/passes.c:2517
#14 0x012ad874 in execute_pass_list_1 (pass=0x44109b70) at
/src-local/gcc-master-asi/gcc/passes.c:2606
#15 0x012ad8b4 in execute_pass_list_1 (pass=0x44109630) at
/src-local/gcc-master-asi/gcc/passes.c:2607
#16 0x012ad8b4 in execute_pass_list_1 (pass=0x441089b0) at
/src-local/gcc-master-asi/gcc/passes.c:2607
#17 0x012ad944 in execute_pass_list (fn=0x4473c270, pass=0x44108830) at
/src-local/gcc-master-asi/gcc/passes.c:2617
#18 0x00a1eaa4 in cgraph_node::expand (this=) at
/src-local/gcc-master-asi/gcc/cgraphunit.c:1829
#19 0x00a1f39c in expand_all_functions () at
/src-local/gcc-master-asi/gcc/cgraphunit.c:1997
#20 0x00a2032c in symbol_table::compile (this=) at
/src-local/gcc-master-asi/gcc/cgraphunit.c:2361
#21 0x00a2096c in symbol_table::finalize_compilation_unit (this=) at
/src-local/gcc-master-asi/gcc/cgraphunit.c:2542
#22 0x01488688 in compile_file () at /src-local/gcc-master-asi/gcc/toplev.c:485
#23 0x0148cff0 in do_compile () at /src-local/gcc-master-asi/gcc/toplev.c:2321
#24 0x0148d58c in toplev::main (this=, argc=,
argv=) at /src-local/gcc-master-asi/gcc/toplev.c:2460
#25 0x01c89534 in main (argc=37, argv=0xb1ec) at
/src-local/gcc-master-asi/gcc/main.c:39

  I don't really know what I'm looking at here - so these are somewhat
random prints of values.

gdb) p *vectype
$1 = (tree) 0x0
(gdb) p child
$2 = (slp_tree) 0x0
(gdb) up
#1  0x01913cd4 in

[Bug c++/97665] constexpr union array member incorrectly rejected as non-constexpr

2020-11-01 Thread ldalessandro at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97665

--- Comment #1 from Luke Dalessandro  ---
(In reply to Luke Dalessandro from comment #0)
> GCC currently rejects the following code snippet, where it infers the
> constexpr definition of V as non-constexpr. 

The definition of `v`, not the type `V`. I apologize.

[Bug c++/97665] New: constexpr union array member incorrectly rejected as non-constexpr

2020-11-01 Thread ldalessandro at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97665

Bug ID: 97665
   Summary: constexpr union array member incorrectly rejected as
non-constexpr
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldalessandro at gmail dot com
  Target Milestone: ---

GCC currently rejects the following code snippet, where it infers the constexpr
definition of V as non-constexpr. The monostate member provides a temporary
workaround.

https://godbolt.org/z/Ph1n1P

```
struct Foo {
constexpr Foo() {}
};

union U {
   // struct {} monostate = {};
Foo foo;
constexpr U() {}
};

struct V {
U storage[1];
};

constexpr V v;
```

[Bug ipa/97660] [11 Regression] ICE: Segmentation fault in function_summary::get(cgraph_node*) since r11-4587

2020-11-01 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97660

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:895fdc1f4c9ff1dfb18b80af838aa353363edb40

commit r11-4592-g895fdc1f4c9ff1dfb18b80af838aa353363edb40
Author: Iain Buclaw 
Date:   Sun Nov 1 16:39:10 2020 +0100

ipa: Fix segmentation fault in
function_summary::get(cgraph_node*)

PR 97660 occurs when cgraph_node::get returns NULL, and this NULL
cgraph_node is then passed to clone_info::get.  As the original assert
prior to the regressing change in r11-4587 allowed for the cgraph_node
to be NULL, clone_info::get is now only called when cgraph_node::get
returns a nonnull value.

gcc/ChangeLog:

PR ipa/97660
* cgraph.c (cgraph_edge::redirect_call_stmt_to_callee): Don't call
clone_info::get when cgraph_node::get returns NULL.

[Bug c++/97663] [c++17] Function with return type 'unsigned' in nested namespace misinterpreted as deduction guide

2020-11-01 Thread ville.voutilainen at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97663

Ville Voutilainen  changed:

   What|Removed |Added

 CC||jason at redhat dot com
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-11-01

[Bug ipa/97660] [11 Regression] ICE: Segmentation fault in function_summary::get(cgraph_node*) since r11-4587

2020-11-01 Thread ibuclaw at gdcproject dot org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97660

--- Comment #4 from Iain Buclaw  ---
Suggested fix
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557691.html

[Bug ipa/97660] [11 Regression] ICE: Segmentation fault in function_summary::get(cgraph_node*) since r11-4587

2020-11-01 Thread hjl.tools at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97660

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #2 from H.J. Lu  ---
*** Bug 97662 has been marked as a duplicate of this bug. ***

[Bug ipa/97660] [11 Regression] ICE: Segmentation fault in function_summary::get(cgraph_node*) since r11-4587

2020-11-01 Thread hjl.tools at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97660

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed||2020-11-01
 Ever confirmed|0   |1
 CC||jh at suse dot cz
   Host|x86_64-freebsd12.2  |
   Target Milestone|--- |11.0
  Build|x86_64-freebsd12.2  |
 Target|x86_64-freebsd12.2  |
 Status|UNCONFIRMED |NEW

--- Comment #3 from H.J. Lu  ---
j...@suse.cz

[Bug bootstrap/97662] [11 Regression] r11-4587 breaks non-bootstrap build

2020-11-01 Thread hjl.tools at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97662

H.J. Lu  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from H.J. Lu  ---
Dup.

*** This bug has been marked as a duplicate of bug 97660 ***

[Bug target/97025] In -m32 mode the alignment of pointers returned by malloc or operator new is less than alignof(std::max_align_t)

2020-11-01 Thread redi at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97025

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 Target|i?86-linux-gnu  |i?86-*
   Last reconfirmed||2020-11-01

--- Comment #6 from Jonathan Wakely  ---
This is also an issue on (at least) Solaris, Vxworks 7 and mingw.

See https://sourceforge.net/p/mingw-w64/bugs/778/ and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973495 and Bug 77691 for
problems caused by GCC's incorrect definition of max_align_t.

[Bug c++/97664] New: constexpr evaluation incorrectly accepts non-constant destruction

2020-11-01 Thread ldalessandro at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97664

Bug ID: 97664
   Summary: constexpr evaluation incorrectly accepts non-constant
destruction
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldalessandro at gmail dot com
  Target Milestone: ---

This one involves some language-lawyering, which is not my forte.

While developing a constexpr, array-based vector that supports non-default
constructible types, I have run into the following inconsistency between clang
and gcc. 

https://godbolt.org/z/PYdq5P

```
#include 

struct Foo {
mutable int n = 0;
};

union U {
Foo foo;
constexpr U() {}
};

struct cvector {
U storage[1];
constexpr cvector() {
std::construct_at([0].foo);
}
constexpr ~cvector() {
std::destroy_at([0].foo);
}
};

constexpr cvector v;
```

After some slack discussion that I didn't entirely follow, it seems that
http://eel.is/c++draft/expr.const#7.2 combined with
http://eel.is/c++draft/expr.const#6.2 may exclude the constexpr use of
destroy_at of an instance of a class with mutable members. I am not confident
with this analysis, nor am I confident that this is desirable behavior, but am
reporting it for consideration.

[Bug c++/97663] New: [c++17] Function with return type 'unsigned' in nested namespace misinterpreted as deduction guide

2020-11-01 Thread hans.dembinski at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97663

Bug ID: 97663
   Summary: [c++17] Function with return type 'unsigned' in nested
namespace misinterpreted as deduction guide
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hans.dembinski at gmail dot com
  Target Milestone: ---

g++ with -std=c++17 since version 7.1 up to current trunk misdetects 'bar::foo'
the following code as a deduction guide for 'struct foo':

```
template  struct foo {};

namespace bar {

unsigned foo();

}
```

Code on Godbolt: https://godbolt.org/z/6E4efY

Workarounds:
- Use 'unsigned int foo()'
- Use 'auto foo() -> unsigned'.

Related issue with more context:
https://github.com/boostorg/histogram/issues/290

[Bug c/97578] ice during IPA pass: inline

2020-11-01 Thread hubicka at ucw dot cz via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97578

--- Comment #5 from Jan Hubicka  ---
Hi,
this patch fixes the ICE, though I think we do have a design issue here
while producing debug info across ltrans boundary.

Martin, Jakub: as discussed on IRC it would be nice to add predicate
when the body is really needed and avoid materializing if it is not.
Can you add one?

Something like param_adjustemnts->need_callee_parm_decls_p ()

Honza

diff --git a/gcc/ipa-inline-transform.c b/gcc/ipa-inline-transform.c
index 4df1b7fb9ee..907a95cac5a 100644
--- a/gcc/ipa-inline-transform.c
+++ b/gcc/ipa-inline-transform.c
@@ -51,6 +51,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "ipa-modref-tree.h"
 #include "ipa-modref.h"
 #include "symtab-thunks.h"
+#include "symtab-clones.h"

 int ncalls_inlined;
 int nfunctions_inlined;
@@ -695,6 +696,31 @@ preserve_function_body_p (struct cgraph_node *node)
   return false;
 }

+/* tree-inline can not recurse; materialize all function bodie we will need
+   during inlining.  This includes inlined functions, but also called
functions
+   with param manipulation because IPA param manipulation attaches debug
+   statements to PARM_DECLs of called clone.  Materialize them if needed.
+
+   FIXME: This is somehwat broken by design because it does not play well
+   with partitioning.  */
+
+static void
+maybe_materialize_called_clones (cgraph_node *node)
+{
+  for (cgraph_edge *e = node->callees; e; e = e->next_callee)
+{
+  clone_info *info;
+
+  if (!e->inline_failed)
+   maybe_materialize_called_clones (e->callee);
+
+  cgraph_node *callee = cgraph_node::get (e->callee->decl);
+  if (callee->clone_of
+ && (info = clone_info::get (callee)) && info->param_adjustments)
+   callee->get_untransformed_body ();
+}
+}
+
 /* Apply inline plan to function.  */

 unsigned int
@@ -748,6 +774,7 @@ inline_transform (struct cgraph_node *node)
   ENTRY_BLOCK_PTR_FOR_FN (cfun)->count = node->count;
 }

+  maybe_materialize_called_clones (node);
   for (e = node->callees; e; e = next)
 {
   if (!e->inline_failed)

Re: [Bug c/97578] ice during IPA pass: inline

2020-11-01 Thread Jan Hubicka

Hi,
this patch fixes the ICE, though I think we do have a design issue here
while producing debug info across ltrans boundary.

Martin, Jakub: as discussed on IRC it would be nice to add predicate
when the body is really needed and avoid materializing if it is not.
Can you add one?

Something like param_adjustemnts->need_callee_parm_decls_p ()

Honza

diff --git a/gcc/ipa-inline-transform.c b/gcc/ipa-inline-transform.c
index 4df1b7fb9ee..907a95cac5a 100644
--- a/gcc/ipa-inline-transform.c
+++ b/gcc/ipa-inline-transform.c
@@ -51,6 +51,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "ipa-modref-tree.h"
 #include "ipa-modref.h"
 #include "symtab-thunks.h"
+#include "symtab-clones.h"
 
 int ncalls_inlined;
 int nfunctions_inlined;
@@ -695,6 +696,31 @@ preserve_function_body_p (struct cgraph_node *node)
   return false;
 }
 
+/* tree-inline can not recurse; materialize all function bodie we will need
+   during inlining.  This includes inlined functions, but also called functions
+   with param manipulation because IPA param manipulation attaches debug
+   statements to PARM_DECLs of called clone.  Materialize them if needed.
+
+   FIXME: This is somehwat broken by design because it does not play well
+   with partitioning.  */
+
+static void
+maybe_materialize_called_clones (cgraph_node *node)
+{
+  for (cgraph_edge *e = node->callees; e; e = e->next_callee)
+{
+  clone_info *info;
+
+  if (!e->inline_failed)
+   maybe_materialize_called_clones (e->callee);
+
+  cgraph_node *callee = cgraph_node::get (e->callee->decl);
+  if (callee->clone_of
+ && (info = clone_info::get (callee)) && info->param_adjustments)
+   callee->get_untransformed_body ();
+}
+}
+
 /* Apply inline plan to function.  */
 
 unsigned int
@@ -748,6 +774,7 @@ inline_transform (struct cgraph_node *node)
   ENTRY_BLOCK_PTR_FOR_FN (cfun)->count = node->count;
 }
 
+  maybe_materialize_called_clones (node);
   for (e = node->callees; e; e = next)
 {
   if (!e->inline_failed)

[Bug bootstrap/97662] New: [11 Regression] r11-4587 breaks non-bootstrap build

2020-11-01 Thread hjl.tools at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97662

Bug ID: 97662
   Summary: [11 Regression] r11-4587 breaks non-bootstrap build
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: jh at suse dot cz
  Target Milestone: ---

On Linux/x86-64, r11-4587 caused:

$ ../../gcc/configure
--prefix=/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++ --enable-cet --disable-bootstrap
--with-fpmath=sse --disable-libcc1 --disable-libcilkrts --disable-libsanitizer
...
git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/bin/
-B/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/lib/
-isystem
/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/include
-isystem
/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/sys-include
   -O2 -g -O2  -O2 -g -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include  -fpic
-mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector  -fpic -mlong-double-80 -DUSE_ELF_SYMVER
-fcf-protection -mshstk -I. -I. -I../.././gcc -I../../../../gcc/libgcc
-I../../../../gcc/libgcc/. -I../../../../gcc/libgcc/../gcc
-I../../../../gcc/libgcc/../include -I../../../../gcc/libgcc/config/libbid
-DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS  -DUSE_TLS -Wno-missing-prototypes
-Wno-type-limits -o floatunditf_s.o -MT floatunditf_s.o -MD -MP -MF
floatunditf_s.dep -DSHARED  -c ../../../../gcc/libgcc/soft-fp/floatunditf.c
/export/project/git/gcc-bisect-bootstrap/master/r11-4587/bld/./gcc/xgcc
-B/export/project/git/gcc-bisect-bootstrap/master/r11-4587/bld/./gcc/
-B/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/bin/
-B/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/lib/
-isystem
/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/include
-isystem
/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/sys-include
   -O2 -g -O2  -O2 -g -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include  -fpic
-mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector  -fpic -mlong-double-80 -DUSE_ELF_SYMVER
-fcf-protection -mshstk -I. -I. -I../.././gcc -I../../../../gcc/libgcc
-I../../../../gcc/libgcc/. -I../../../../gcc/libgcc/../gcc
-I../../../../gcc/libgcc/../include -I../../../../gcc/libgcc/config/libbid
-DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS  -DUSE_TLS -Wno-missing-prototypes
-Wno-type-limits -o fixtfti_s.o -MT fixtfti_s.o -MD -MP -MF fixtfti_s.dep
-DSHARED  -c ../../../../gcc/libgcc/soft-fp/fixtfti.c
/export/project/git/gcc-bisect-bootstrap/master/r11-4587/bld/./gcc/xgcc
-B/export/project/git/gcc-bisect-bootstrap/master/r11-4587/bld/./gcc/
-B/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/bin/
-B/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/lib/
-isystem
/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/include
-isystem
/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/sys-include
   -O2 -g -O2  -O2 -g -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include  -fpic
-mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector  -fpic -mlong-double-80 -DUSE_ELF_SYMVER
-fcf-protection -mshstk -I. -I. -I../.././gcc -I../../../../gcc/libgcc
-I../../../../gcc/libgcc/. -I../../../../gcc/libgcc/../gcc
-I../../../../gcc/libgcc/../include -I../../../../gcc/libgcc/config/libbid
-DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS  -DUSE_TLS -Wno-missing-prototypes
-Wno-type-limits -o fixunstfti_s.o -MT fixunstfti_s.o -MD -MP -MF
fixunstfti_s.dep -DSHARED  -c ../../../../gcc/libgcc/soft-fp/fixunstfti.c
/export/project/git/gcc-bisect-bootstrap/master/r11-4587/bld/./gcc/xgcc
-B/export/project/git/gcc-bisect-bootstrap/master/r11-4587/bld/./gcc/
-B/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/bin/
-B/export/project/git/gcc-bisect-bootstrap/master/r11-4587/usr/x86_64-pc-linux-gnu/lib/
-isystem

[Bug c++/97661] New: Bogus error message about initializing a using declaration

2020-11-01 Thread markus.boeck02 at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97661

Bug ID: 97661
   Summary: Bogus error message about initializing a using
declaration
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markus.boeck02 at gmail dot com
  Target Milestone: ---

Following code produces an error message I can't quite decipher. The code to my
knowledge is also correct and compiles with clang and MSVC:

template 
class Base
{

};

class Derived : public Base
{

};

template 
struct DeduceArgs
{
Base* p;

using type = Base;
};

template 
DeduceArgs(Base*) -> DeduceArgs;

template 
constexpr bool always_false = false;

#include 

template ()})::type>
class Deleter
{
static_assert(always_false);
};

template 
class Deleter>
{
public:

void operator()(Derived* pointer) const noexcept
{
delete pointer;
}

};

#include 

template 
using IntrVarPtr = std::unique_ptr>;

int main()
{
IntrVarPtr ptr;
}


The error message I receive is:
: In substitution of 'template using IntrVarPtr =
std::unique_ptr > [with T = Derived]':

:54:23:   required from here

:50:7: error: initializer for 'Base' must be
brace-enclosed

   50 | using IntrVarPtr = std::unique_ptr>;

  |   ^~


Corresponding godbolt link: https://godbolt.org/z/eK8fex

[Bug ipa/97660] [11 Regression] ICE: Segmentation fault in function_summary::get(cgraph_node*) since r11-4587

2020-11-01 Thread ibuclaw at gdcproject dot org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97660

--- Comment #1 from Iain Buclaw  ---
The call statement being looked at by cgraph_edge::redirect_call_stmt_to_callee
is:

   # .MEM = VDEF <.MEM>
   _47 = __sync_val_compare_and_swap_8 (ptr_45, 0, new_node.0_46);

cgraph_node::get returns NULL on the __sync_val_compare_and_swap_8 decl at
cgraph.c:1494


This looks like it is expected to happen, given that the assert on the
following line used to be `gcc_assert (!node ||
!node->clone.param_adjustments);`.

The change that causes the segfault is:

   if (flag_checking && decl)
 {
   cgraph_node *node = cgraph_node::get (decl);
-  gcc_assert (!node || !node->clone.param_adjustments);
+  clone_info *info = clone_info::get (node);
+  gcc_assert (!node || !info || !info->param_adjustments);
 }

[Bug c++/96504] [coroutines] Use after free in std::__n4861::coroutine_handle::done()

2020-11-01 Thread iains at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96504

--- Comment #5 from Iain Sandoe  ---
(In reply to H.J. Lu from comment #4)
> __builtin_coro_resume and __builtin_coro_destroy delete the memory.
> Everything goes downhill after it.

thanks for the analysis - I will hopefully take a look later.

[Bug c++/96504] [coroutines] Use after free in std::__n4861::coroutine_handle::done()

2020-11-01 Thread hjl.tools at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96504

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |10.3

[Bug c++/96504] [coroutines] Use after free in std::__n4861::coroutine_handle::done()

2020-11-01 Thread hjl.tools at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96504

--- Comment #4 from H.J. Lu  ---
__builtin_coro_resume and __builtin_coro_destroy delete the memory.
Everything goes downhill after it.

[Bug ipa/97660] New: [11 Regression] ICE: Segmentation fault in function_summary::get(cgraph_node*) since r11-4587

2020-11-01 Thread ibuclaw at gdcproject dot org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97660

Bug ID: 97660
   Summary: [11 Regression] ICE: Segmentation fault in
function_summary::get(cgraph_node*) since
r11-4587
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ibuclaw at gdcproject dot org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

On FreeBSD 12.2, host compiler gcc 9.3.0.

Segmentation fault occurs during stage1 when compiling libgcc.

git bisect points at r11-4587 being the first bad commit.


Backtrace:
---
during IPA pass: inline
../../../libgcc/libgcov-merge.c: In function '__gcov_merge_topn':
../../../libgcc/libgcov-merge.c:118:11: internal compiler error: Segmentation
fault
  118 |   gcov_topn_add_value (counters + GCOV_TOPN_MEM_COUNTERS * i,
value,
  |  
^~
  119 |count, 0, 0);
  |
0xe7c39f crash_signal
../../gcc/toplev.c:330
0xa3244a function_summary::get(cgraph_node*)
../../gcc/symbol-summary.h:212
0xa3244a clone_info::get(cgraph_node*)
../../gcc/symtab-clones.h:70
0xa3244a cgraph_edge::redirect_call_stmt_to_callee(cgraph_edge*)
../../gcc/cgraph.c:1495
0xeff807 redirect_all_calls(copy_body_data*, basic_block_def*)
../../gcc/tree-inline.c:2963
0xf024da copy_cfg_body
../../gcc/tree-inline.c:3118
0xf024da copy_body
../../gcc/tree-inline.c:3294
0xf04e86 expand_call_inline
../../gcc/tree-inline.c:5084
0xf06489 gimple_expand_calls_inline
../../gcc/tree-inline.c:5274
0xf06489 optimize_inline_calls(tree_node*)
../../gcc/tree-inline.c:5447
0xc5842b inline_transform(cgraph_node*)
../../gcc/ipa-inline-transform.c:763
0xd9a62c execute_one_ipa_transform_pass
../../gcc/passes.c:2240
0xd9a62c execute_all_ipa_transforms(bool)
../../gcc/passes.c:2287
0xa39015 cgraph_node::expand()
../../gcc/cgraphunit.c:1822
0xa3a417 expand_all_functions
../../gcc/cgraphunit.c:1997
0xa3a417 symbol_table::compile()
../../gcc/cgraphunit.c:2361
0xa3d217 symbol_table::compile()
../../gcc/cgraphunit.c:2274
0xa3d217 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2542
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
gmake: *** [Makefile:921: _gcov_merge_topn.o] Error 1

[Bug fortran/97655] gcc/fortran/openmp.c:4133: possible cut'n'paste error ?

2020-11-01 Thread burnus at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97655

--- Comment #3 from Tobias Burnus  ---
(In reply to Jakub Jelinek from comment #2)
> Guess the second condition should be !c->capture.

I concur.


> Now, something I have clearly missed in the review, why is capture not part
> of atomic_op?  capture is atomic-clause like the others.

Because of preparation/anticipation for OpenMP 5.1 (TR9), which has:
* atomic-clause is one of the following:
  read, write, update
* memory-order-clause is one of the following:
  seq_cst, acq_rel, release, acquire, relaxed
* clause is either atomic-clause, memory-order-clause or one of the following:
  capture, compare, hint(hint-expression), fail(seq_cst | acquire | relaxed),
  weak

With:
* If atomic-clause is not present on the construct, the behavior is as if the
update clause is specified.
* If a capture or compare clause appears on the construct then atomic-clause
  must be update.

> And I'd be afraid we'd allow something like !$omp atomic capture update or
> !$omp atomic update capture by making it separate.

Which is intended (for OpenMP 5.1). I did loop at OpenMP 5.0 + 5.1 and OpenACC
2.6 + 3.0, but I admittedly missed that 'capture' could not occur with 'update'
in OpenMP 5.0, also because the previous code was used for OpenACC, which does
permit 'update capture' besides 'capture' (since OpenACC 2.5).

[Bug libstdc++/97659] Invalid pointer subtraction in vector::insert() (reported by pointer-subtract AddressSanitizer)

2020-11-01 Thread redi at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97659

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-11-01
 Ever confirmed|0   |1

--- Comment #6 from Jonathan Wakely  ---
Alternatively, we could reinterpret_cast before doing the
subtractions (and divide the result by sizeof(_Tp)), which would avoid the
overhead of adjusting the ASan tracking.

Either way, if my assumption about the cause is right, it's not a real bug in
std::vector, it's caused by incorrect (or insufficient) ASan instrumentation.

[Bug libstdc++/97659] Invalid pointer subtraction in vector::insert() (reported by pointer-subtract AddressSanitizer)

2020-11-01 Thread redi at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97659

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #3)
> That sanitizer diagnoses
> http://eel.is/c++draft/expr.add#5.3
> which still seems UB.

Not since http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0593r6.html
said that an array of T[n] can be implicitly created in the storage returned by
the allocator.

> Of course there can be bugs on the sanitizer side too; the sanitizer
> generally works by scanning the shadow memory in between the two pointers
> and if it finds an unaccessible byte in there (memory not part of an object,
> e.g. the inter-object redzone), it shall diagnose it.

I think the problem is that the unused capacity at the end of the vector is
marked as inaccessible. We need to flip it to accessible again before doing
that subtraction, then flip it back to inaccessible. Similarly in the
vector::capacity() member function. Maybe it would be simpler to add the
instrumentation in capacity() and then in the _M_range_insert function shown in
comment 0, use (capacity() - size()) >= n

[Bug libstdc++/97659] Invalid pointer subtraction in vector::insert() (reported by pointer-subtract AddressSanitizer)

2020-11-01 Thread chfast at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97659

--- Comment #4 from Paweł Bylica  ---
I'd like to explain some things here (to my best knowledge):

1. The "pointer-subtract" checks is ASan extension, not enabled by default.
When running with this check enabled in my application I have not detected any
issues in std::vector.

2. The "pointer-subtract" checks if you pointer subtraction operands are from
the same memory allocation. Allowed values are all pointers from the memory
region plus the "end" pointer one element outside of the region. Other
subtractions are UB in C to my information.

3. The issue shows up only when "pointer-subtract" is combined with
_GLIBCXX_SANITIZE_VECTOR. Moreover, the report looks like false positive
because the subtraction is between the "end" pointer and a pointer from inside
of a memory region.

[Bug bootstrap/96735] --enable-maintainer-mode broken

2020-11-01 Thread tkoenig at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96735

Thomas Koenig  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #4 from Thomas Koenig  ---
Didn't happen again, so the best bet is that make was indeed run
from the gcc subdirectory.

39 matches

Mail list logo