[Bug c++/93377] New: [10 Regression] ICE in tsubst_pack_expansion, at cp/pt.c:12852

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

Bug ID: 93377
   Summary: [10 Regression] ICE in tsubst_pack_expansion, at
cp/pt.c:12852
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
  Target Milestone: ---

The following code worked in gcc9 and below, but fails with a recent snapshot
of gcc

```c++
struct empty
{};

template 
c value;

template 
auto func(value);

template 
struct alignment_algorithm;

template 
struct select
{
  template 
  decltype(algorithm_t()(func<_args_t>...)) choose();

  template 
  static empty choose();

  using type = decltype(choose, args_t...>());
};

template 
struct select_algorithm : select
{};

template  struct maybe_value { int value; };

template 
struct maybe_value;

struct function
{
  template >::value)>
  function(algorithm_t);
};

template 
struct alignment_configuration_traits
{
  static constexpr bool is_vectorised = 0;
};

template 
struct alignment_algorithm
{
  using traits_t = alignment_configuration_traits;
  template 
  void operator()(indexed_sequence_pairs_t) requires traits_t::is_vectorised;
};

int main()
{
function{alignment_algorithm{}};
}
```

(I couldn't reduce it any more, maybe someone else can help with it)

produces the following ICE (https://godbolt.org/z/6uK11R):

```
> g++-git -std=c++17 -fconcepts -c ice.cpp // or g++-git -std=c++2a -c ice.cp

ice.cpp: In instantiation of ‘void alignment_algorithm<
, 
>::operator()(indexed_sequence_pairs_t) requires  traits_t...>::is_vectorised [with indexed_sequence_pairs_t =
int; config_t = int;  = {}]’:
ice.cpp:17:25:   required by substitution of ‘template decltype (algorithm_t()(func<_args_t>...))
select::choose() [with algorithm_t =
alignment_algorithm; _args_t = {int}]’
ice.cpp:22:68:   required from ‘struct select’
ice.cpp:37:13:   recursively required by substitution of ‘template
struct maybe_value [with cn =
select_algorithm, int>]’
ice.cpp:37:13:   required by substitution of ‘template function::function(algorithm_t) [with algorithm_t =
alignment_algorithm;  = ]’
ice.cpp:58:40:   required from here
ice.cpp:17:25: internal compiler error: in tsubst_pack_expansion, at
cp/pt.c:12852
   17 |   decltype(algorithm_t()(func<_args_t>...)) choose();
  |~^~
0x601131 tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:12852
0x770121 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:13111
0x775368 tsubst_argument_pack(tree_node*, tree_node*, int, tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:13073
0x7700f4 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:13123
0x76c46a tsubst(tree_node*, tree_node*, int, tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:14985
0x777997 tsubst_qualified_id
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:16002
0x76742f tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:19259
0x760e34 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:18932
0x760e34 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:18590
0x681222 satisfy_constraint_r
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2499
0x681998 satisfy_constraint
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2575
0x682c14 satisfy_declaration_constraints
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2593
0x682ed8 constraint_satisfaction_value
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2708
0x682ed8 constraints_satisfied_p(tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2729
0x64f2c1 add_function_candidate
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:2281
0x65175c add_template_candidate_real
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:3440
0x651ce6 add_template_candidate
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:3481
0x651ce6 add_candidates
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:5827
0x656d14 add_candidates
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:5742
0x656d14 build_op_call_1
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:4777
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
```


```
> g++

[Bug c++/92541] ICE when concept requires contextual conversion to bool

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

gcc-bugs at marehr dot dialup.fu-berlin.de changed:

   What|Removed |Added

 CC||gcc-bugs at marehr dot 
dialup.fu-b
   ||erlin.de

--- Comment #1 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Is this a variant of the same ICE?

```
template  bool a = true;
template  concept b = a;
template  struct f { template  friend auto g(c, f); };
auto d = f<1>{};
auto e = f<0>{};
```

https://godbolt.org/z/A5xXyR

[Bug analyzer/93378] New: ICE in as_a, at is-a.h:197

[asolokha at gmx dot com]

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

Bug ID: 93378
   Summary: ICE in as_a, at is-a.h:197
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-10.0.0-alpha20200119 snapshot (g:3684bbb022cd75da55e1457673f269980aa12cdf)
ICEs when compiling the following testcase, reduced from
gcc/testsuite/gcc.dg/torture/pr48542.c, w/ -O1 -fanalyzer -g:

typedef long int jmp_buf[1];
jmp_buf x4;

int
_setjmp (jmp_buf);

void
longjmp (jmp_buf, int);

int
la (void)
{
  if (_setjmp (x4) != 0)
return 0;

  longjmp (x4, 1);
}

% gcc-10.0.0-alpha20200119 -O1 -fanalyzer -g -c ysvegkml.c
during IPA pass: analyzer
ysvegkml.c: In function 'la':
ysvegkml.c:16:3: internal compiler error: in as_a, at is-a.h:197
   16 |   longjmp (x4, 1);
  |   ^~~
0x718f5d gcall const* as_a(gimple const*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/is-a.h:197
0x7194ca gcall const* as_a(gimple const*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:1187
0x7194ca rewind_info_t::get_setjmp_call() const
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/exploded-graph.h:337
0x7194ca exploded_node::on_longjmp(exploded_graph&, gcall const*,
program_state*, region_model_context*) const
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:1175
0x10e1ebc exploded_node::on_stmt(exploded_graph&, supernode const*, gimple
const*, program_state*, state_change*) const
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:1002
0x10e24d1 exploded_graph::process_node(exploded_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:2433
0x10e29b2 exploded_graph::process_worklist()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:2253
0x10e3039 impl_run_checkers(logger*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:3570
0x10e3ad3 run_checkers()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:3624
0x10d9558 execute
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/analyzer-pass.cc:84

[Bug analyzer/93379] New: ICE in set_value, at analyzer/region-model.cc:5149

[asolokha at gmx dot com]

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

Bug ID: 93379
   Summary: ICE in set_value, at analyzer/region-model.cc:5149
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-10.0.0-alpha20200119 snapshot (g:3684bbb022cd75da55e1457673f269980aa12cdf)
ICEs when compiling gcc/testsuite/gcc.dg/torture/pr57330.c w/ -O1 -fanalyzer:

% gcc-10.0.0-alpha20200119 -O1 -fanalyzer -c
gcc/testsuite/gcc.dg/torture/pr57330.c
during IPA pass: analyzer
gcc/testsuite/gcc.dg/torture/pr57330.c: In function 'foo':
gcc/testsuite/gcc.dg/torture/pr57330.c:4:1: internal compiler error: in
set_value, at analyzer/region-model.cc:5149
4 | {}
  | ^
0x71a53c region_model::set_value(region_id, svalue_id, region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/region-model.cc:5149
0x11021c0 region_model::update_for_return_superedge(return_superedge const&,
region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/region-model.cc:5672
0x11071c7 region_model::maybe_update_for_edge(superedge const&, gimple const*,
region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/region-model.cc:5599
0x10ee36f program_state::on_edge(exploded_graph&, exploded_node const&,
superedge const*, state_change*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/program-state.cc:727
0x10db1e9 exploded_node::on_edge(exploded_graph&, superedge const*,
program_point*, program_state*, state_change*) const
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:1075
0x10e238e exploded_graph::process_node(exploded_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:2500
0x10e29b2 exploded_graph::process_worklist()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:2253
0x10e3039 impl_run_checkers(logger*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:3570
0x10e3ad3 run_checkers()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:3624
0x10d9558 execute
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/analyzer-pass.cc:84

[Bug lto/93361] FAIL: g++-dg-lto-devirt-19-01.exe 1 blank line(s) in output

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-01-22
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
There will probably a broken job number deduction for -flto=auto. Can you
please attach output of --save-temps --verbose of the test?

[Bug lto/93362] FAIL: g++.dg/lto/pr70929 cp_lto_pr70929_0.o-cp_lto_pr70929_1.o execute -O3 -flto

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-01-22
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Can you please run it manually a test how the program ends?
I bet you'll see Abort call.

[Bug analyzer/93379] ICE in set_value, at analyzer/region-model.cc:5149

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-22
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed.

[Bug analyzer/93378] ICE in as_a, at is-a.h:197

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-22
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed.

[Bug analyzer/93375] ICE in gimple_call_arg, at gimple.h:3258

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-22
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

[Bug analyzer/93373] ICE: Segmentation fault (in tree_class_check)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-22
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

[Bug analyzer/93374] ICE in validate, at analyzer/region-model.cc:182

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-22
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

[Bug analyzer/93288] ICE in supergraph.cc:180

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to David Malcolm from comment #3)
> Marking status as SUSPENDED for now and setting Target Milestone to 11 (in
> the hope of adding c++ support to the analyzer in gcc 11).

Can't we call a sorry function in C++ situation so that we don't ICE?

[Bug c++/93380] New: Variable Length Array Evaluation will be wrong or cause GDB to crash due to GCC

[robert.dumitru at cyberthorstudios dot com]

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

Bug ID: 93380
   Summary: Variable Length Array Evaluation will be wrong or
cause GDB to crash due to GCC
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: robert.dumitru at cyberthorstudios dot com
  Target Milestone: ---

We have the following code that runs on a cortex a9 of a Renesas RZ A1 board
and involves the declaration of a variable length array. I will present here
the code, the debug info for the variable and the disassembly code.  

The sample code:

int main(void)
{
volatile int n;
int a = 1000;

int id_size = sizeof(cTaskList) / sizeof(V4_T_CTSK);
ID id[id_size];


for(;;){
  for(n=0; n<9e2>: Abbrev Number: 38 (DW_TAG_variable)
<9e3>   DW_AT_name: id  
<9e6>   DW_AT_decl_file   : 1   
<9e7>   DW_AT_decl_line   : 85  
<9e8>   DW_AT_type: <0x9f1> 
<9ec>   DW_AT_location: 3 byte block: 91 68 6   (DW_OP_fbreg: -24;
DW_OP_deref)

The disassembly code:

  main():
20021230:   push{r11, lr}
20021234:   add r11, sp, #4
20021238:   sub sp, sp, #24
82  int a = 1000;
2002123c:   mov r3, #1000   ; 0x3e8
20021240:   str r3, [r11, #-8]
84  int id_size = sizeof(cTaskList) / sizeof(V4_T_CTSK);
20021244:   mov r3, #13
20021248:   str r3, [r11, #-12]
85ID id[id_size];/* <-- debug session terminates with this
declaration */
2002124c:   ldr r3, [r11, #-12]
20021250:   sub r12, r3, #1
20021254:   str r12, [r11, #-16]
20021258:   mov r3, r12
2002125c:   add r3, r3, #1
20021260:   mov r0, r3
20021264:   mov r1, #0
20021268:   mov r2, #0
2002126c:   mov r3, #0
20021270:   lsl r3, r1, #5
20021274:   orr r3, r3, r0, lsr #27
20021278:   lsl r2, r0, #5
2002127c:   mov r3, r12
20021280:   add r3, r3, #1
20021284:   mov r0, r3
20021288:   mov r1, #0
2002128c:   mov r2, #0
20021290:   mov r3, #0
20021294:   lsl r3, r1, #5
20021298:   orr r3, r3, r0, lsr #27
2002129c:   lsl r2, r0, #5
200212a0:   mov r3, r12
200212a4:   add r3, r3, #1
200212a8:   lsl r3, r3, #2
200212ac:   add r3, r3, #3
200212b0:   add r3, r3, #7
200212b4:   lsr r3, r3, #3
200212b8:   lsl r3, r3, #3
200212bc:   sub sp, sp, r3
200212c0:   mov r3, sp
200212c4:   add r3, r3, #3
200212c8:   lsr r3, r3, #2
200212cc:   lsl r3, r3, #2
200212d0:   str r3, [r11, #-20]
89  for(n=0; n

[Bug c++/93377] [10 Regression] ICE in tsubst_pack_expansion, at cp/pt.c:12852

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-22
 CC||jason at gcc dot gnu.org
  Known to work||9.2.0
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r10-3735-gcb57504a550158913258e5be8ddb991376475efb.

[Bug target/93376] [10 Regression] ICE: in immed_wide_int_const_1, at emit-rtl.c:660 with -Og -finline-functions-called-once

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-22
 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r10-5741-gc57b4c2208960c3b57abe148a5e9767f8f27747c.

[Bug analyzer/93367] FAIL: gcc.dg/analyzer/abort.c (test for warnings, line 71)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-01-22
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug analyzer/93368] FAIL: gcc.dg/analyzer/data-model-1.c (test for excess errors)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-22
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug fortran/93363] [10 Regression] ICE in gfc_get_class_from_expr, at fortran/trans-expr.c:484

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-22
 CC||marxin at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
  Known to work||9.2.0
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0

--- Comment #2 from Martin Liška  ---
Confirmed, started with r10-3456-g56b070e3bbc4364f86357d6651fe1391464db6d6.

[Bug tree-optimization/93381] New: points-to wrong for integer offsetting and field-sensitive analysis

[rguenth at gcc dot gnu.org]

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

Bug ID: 93381
   Summary: points-to wrong for integer offsetting and
field-sensitive analysis
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

The following aborts at -O2

static struct S { int *p1; int *p2; } s;
typedef __UINTPTR_TYPE__ uintptr_t;
int foo()
{
  int i = 1, j = 2;
  struct S s;
  int **p;
  s.p1 = &i;
  s.p2 = &j;
  p = &s.p1;
  uintptr_t pi = (uintptr_t)p;
  pi = pi + sizeof (int *);
  p = (int **)pi;
  **p = 3;
  return j;
}

int main()
{
  if (foo () != 3)
__builtin_abort ();
  return 0;
}

[Bug fortran/93329] ICE in omp_code_to_statement, at fortran/openmp.c:5902

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r10-6135-ga38979d9d7a4ab08336436052704028c56187618
Author: Jakub Jelinek 
Date:   Wed Jan 22 09:50:53 2020 +0100

openmp: Teach omp_code_to_statement about rest of OpenMP statements

The omp_code_to_statement function added with the initial OpenACC support
only handled small subset of the OpenMP statements, leading to ICE if
any other OpenMP directive appeared inside of OpenACC directive.

2020-01-22  Jakub Jelinek  

PR fortran/93329
* openmp.c (omp_code_to_statement): Handle remaining EXEC_OMP_*
cases.

* gfortran.dg/goacc/pr93329.f90: New test.

[Bug tree-optimization/93381] points-to wrong for integer offsetting and field-sensitive analysis

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||alias, wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-22
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

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

[Bug fortran/93364] [9/10 Regression] ICE in gfc_set_array_spec, at fortran/array.c:879

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-22
 CC||marxin at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
  Known to work||8.3.0
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0, 9.2.0

--- Comment #1 from Martin Liška  ---
Started to ICE with r10-3447-g4c59710186081ed4b2d34ccda1190d43454543db.

[Bug analyzer/93382] New: ICE in validate, at analyzer/program-state.cc:512

[asolokha at gmx dot com]

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

Bug ID: 93382
   Summary: ICE in validate, at analyzer/program-state.cc:512
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-10.0.0-alpha20200119 snapshot (g:3684bbb022cd75da55e1457673f269980aa12cdf)
ICEs when compiling the following testcase w/ -fanalyzer:

typedef unsigned int size_t;

int ya;
void *lv;

size_t
fread (void *, size_t, size_t, void *);

void
ql (void)
{
  int n1[1];

  fread (n1, sizeof (n1[0]), 1, lv);
  ya = n1[0];
}

void
pl (void)
{
  ql ();
}

% gcc-10.0.0-alpha20200119 -fanalyzer -c gjg8xfgd.c
during IPA pass: analyzer
gjg8xfgd.c: In function 'pl':
gjg8xfgd.c:16:1: internal compiler error: in validate, at
analyzer/program-state.cc:512
   16 | }
  | ^
0x7199ad sm_state_map::validate(state_machine const&, int) const
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/program-state.cc:512
0x10ee461 program_state::validate(extrinsic_state const&) const
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/program-state.cc:987
0x10df241 exploded_graph::get_or_create_node(program_point const&,
program_state const&, state_change*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:1833
0x10e2636 exploded_graph::process_node(exploded_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:2508
0x10e29b2 exploded_graph::process_worklist()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:2253
0x10e3039 impl_run_checkers(logger*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:3570
0x10e3ad3 run_checkers()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:3624
0x10d9558 execute
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/analyzer-pass.cc:84

[Bug tree-optimization/93381] points-to wrong for integer offsetting and field-sensitive analysis

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
The reason this breaks is we treat literal integer constants as pointing to
nonlocal memory, not considering pointing to automatic objects (s in this
case).
And a plain PLUS_EXPR is handled as merge operator (compared to
POINTER_PLUS_EXPR which does offsetting with pointer semantic constraints).

A conservative fix is to treat literal integer constants as pointing to
anything.  A more elaborate fix would try to do offsetting without
pointer constraints [when it's clear which operand is the pointer and which
the offset].

Note when tracking points-to sets of integers we basically treat them as
pointers so i + j would offset a pointer with a pointer which doesn't make
too much sense so a merge is most sensible (we treat all "unhandled" operators
that way, assuming you can never create pointers to objects not originally
referenced out of thin air).  PVNI side-steps this completely by not
tracking provenance of non-pointers IIRC.

[Bug ipa/93351] [10 Regression] ICE in ipa_update_overall_fn_summary at gcc/ipa-fnsummary.c:4014

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug analyzer/93382] ICE in validate, at analyzer/program-state.cc:512

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-22
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

[Bug c/93357] Misleading diagnostic for complex type

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug lto/93358] [10 Regression] 447.dealII regresses by 15% after r10-6025-gf5b25e15165adde1356af42e9066ab75c5b37a19

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |10.0

[Bug c++/93360] FAIL: g++.dg/cpp0x/std-layout1.C -std=c++2a (test for excess errors)

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
ISTR there's a duplicate of this report.

[Bug ipa/93369] [10 regression] g++.dg/lto/pr64076 fails

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-22
 CC||marxin at gcc dot gnu.org
  Component|other   |ipa
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

[Bug target/93376] [10 Regression] ICE: in immed_wide_int_const_1, at emit-rtl.c:660 with -Og -finline-functions-called-once

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/91298] $ at the beginging causing Error: junk `(%rip)' after expression

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r10-6137-gc892d8f58f6fed46c343bdb6dd4d365f08f801b8
Author: Jakub Jelinek 
Date:   Wed Jan 22 10:22:16 2020 +0100

i386: Fix up -fdollars-in-identifiers with identifiers starting with $ in
-masm=att [PR91298]

In AT&T syntax leading $ is special, so if we have identifiers that start
with dollar, we usually fail to assemble it (or assemble incorrectly).
As mentioned in the PR, what works is wrapping the identifiers inside of
parens, like:
movl$($a), %eax
leaq($a)(,%rdi,4), %rax
movl($a)(%rip), %eax
movl($a)+16(%rip), %eax
.globl  $a
.type   $a, @object
.size   $a, 72
$a:
.string "$a"
.quad   ($a)
(this is x86_64 -fno-pic -O2).  In some places ($a) is not accepted,
like as .globl operand, in .type, .size, so the patch overrides
ASM_OUTPUT_SYMBOL_REF rather than e.g. ASM_OUTPUT_LABELREF.
I didn't want to duplicate what assemble_name is doing (following
transparent aliases), so split assemble_name into two parts; just
mere looking at the first character of a name before calling assemble_name
wouldn't be good enough, a transparent alias could lead from a name
not starting with $ to one starting with it and vice versa.

2020-01-22  Jakub Jelinek  

PR target/91298
* output.h (assemble_name_resolve): Declare.
* varasm.c (assemble_name_resolve): New function.
(assemble_name): Use it.
* config/i386/i386.h (ASM_OUTPUT_SYMBOL_REF): Define.

* gcc.target/i386/pr91298-1.c: New test.
* gcc.target/i386/pr91298-2.c: New test.

[Bug c++/93377] [10 Regression] ICE in tsubst_pack_expansion, at cp/pt.c:12852

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P1

[Bug fortran/93329] ICE in omp_code_to_statement, at fortran/openmp.c:5902

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed.

[Bug target/93376] [10 Regression] ICE: in immed_wide_int_const_1, at emit-rtl.c:660 with -Og -finline-functions-called-once

[jakub at gcc dot gnu.org]

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

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  ---
Looking...

[Bug ipa/93369] [10 regression] g++.dg/lto/pr64076 fails

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
(In reply to seurer from comment #0)
> THIS STARTED WITH COMMIT 28307164dfed294855bf3d55bed357de560f083b

Please prefix commit hash with g: . It will provide a http link.

[Bug c++/40752] -Wconversion generates false warnings for operands not larger than target type

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #34 from Christophe Lyon  ---
(In reply to Jason Merrill from comment #33)
> Fixed for GCC 10.

Hi,

I've noticed that the new tests fail:
c-c++-common/Wconversion-pr40752.c  -Wc++-compat   (test for warnings, line 34)
c-c++-common/Wconversion-pr40752.c  -Wc++-compat   (test for warnings, line 38)
c-c++-common/Wconversion-pr40752.c  -Wc++-compat   (test for warnings, line 40)
c-c++-common/Wconversion-pr40752.c  -Wc++-compat   (test for warnings, line 42)
c-c++-common/Wconversion-pr40752.c  -Wc++-compat  (test for excess errors)
c-c++-common/Wconversion-pr40752a.c  -Wc++-compat   (test for warnings, line
17)
c-c++-common/Wconversion-pr40752a.c  -Wc++-compat   (test for warnings, line
19)
c-c++-common/Wconversion-pr40752a.c  -Wc++-compat   (test for warnings, line
40)
c-c++-common/Wconversion-pr40752a.c  -Wc++-compat   (test for warnings, line
42)


As a side note, the commit r10-6126-gc77074d05691053ee7347d9e44ab89b3adb23fb1
lacks ChangeLog entries for doc and testsuite, and the commit message does not
mention the doc and testsuite changes either.

[Bug c++/92721] ICE: canonical types differ for identical types 'int(void*, void*)' and 'int(void*, void*)'

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
On second thought, either decl_attributes() (or maybe even
handle_access_attribute()) could arrange to add the internal, condensed form of
the attributes to the function type without modifying the "expanded"
(human-readable) attributes.  That would preserve the "optimization" (although
I'm not sure how much using the condensed form gains over the expanded form).

[Bug ipa/93369] [10 regression] g++.dg/lto/pr64076 fails

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Like g:28307164dfed294855bf3d55bed357de560f083b

[Bug ipa/93369] [10 regression] g++.dg/lto/pr64076 fails

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Known to work||9.2.0
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
  Known to fail||10.0

[Bug c++/92541] ICE when concept requires contextual conversion to bool

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code

--- Comment #2 from Jonathan Wakely  ---
No, there's no conversion to bool in the concept, and it crashes in a
completely different place.

92541-c1.cc: In instantiation of 'struct f<0>':
92541-c1.cc:5:15:   required from here
92541-c1.cc:3:54: internal compiler error: in tsubst, at cp/pt.c:15142
3 | template  struct f { template  friend auto g(c, f); };
  |  ^
0x6714e6 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:15142
0xa867eb tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:13125
0xa792a4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:18999
0xa6d5d7 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:18590
0x93fc56 tsubst_constraint(tree_node*, tree_node*, int, tree_node*)
/home/jwakely/src/gcc/gcc/gcc/cp/constraint.cc:2349
0xa97e94 tsubst_friend_function
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:10846
0xa97e94 instantiate_class_template_1
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:11975
0xa97e94 instantiate_class_template(tree_node*)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:12040
0xae172d complete_type(tree_node*)
/home/jwakely/src/gcc/gcc/gcc/cp/typeck.c:137
0xab168e finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
/home/jwakely/src/gcc/gcc/gcc/cp/semantics.c:2926
0xa1751f cp_parser_functional_cast
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:29391
0xa31834 cp_parser_postfix_expression
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:7134
0xa3a21f cp_parser_unary_expression
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:8514
0xa11b9f cp_parser_cast_expression
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:9405
0xa123d9 cp_parser_binary_expression
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:9508
0xa13dfe cp_parser_assignment_expression
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:9813
0xa12e0d cp_parser_constant_expression
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:10107
0xa133d1 cp_parser_initializer_clause
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:23104
0xa175f7 cp_parser_initializer
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:23042
0xa40871 cp_parser_init_declarator
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:20750
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/92541] ICE when concept requires contextual conversion to bool

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
However, the original segfault seems to have been fixed by r278768 aka
g:1906392b2c9a02da82d1739386219ec0f13bcc33 now anyway.

[Bug target/91298] $ at the beginging causing Error: junk `(%rip)' after expression

[pskocik at gmail dot com]

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

--- Comment #7 from pskocik at gmail dot com ---
(In reply to CVS Commits from comment #6)
> The master branch has been updated by Jakub Jelinek :

Thank you for the fix!

[Bug tree-optimization/81437] missing -Wstringop-overflow reading past the end of a string

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2017-08-30 00:00:00 |2020-1-22
  Known to fail|9.0 |10.0, 9.2.0

--- Comment #4 from Martin Sebor  ---
Calls to all built-in functions that expect a pointer into an object (not a
past-the-end pointer) should be diagnosed when passed an invalid pointer (such
as one past the end).  This bug is only about strings but ideally, pointers to
other types would be detected as well, although they should probably be
reported under a separate warning.  

Here are some other examples:

char a[4];

int f (void)
{
  return __builtin_strcmp (a, &a[4]);   // missing warning
}

int g (void)
{
  return __builtin_puts (&a[4]);   // missing warning
}

int h (int x, int y)
{
  int z;
  return __builtin_add_overflow (x, y, &z + 1) ? 0 : z;   // missing warning
}

[Bug c++/93360] FAIL: g++.dg/cpp0x/std-layout1.C -std=c++2a (test for excess errors)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Yes and it's already fixed.

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

[Bug testsuite/93227] [10 regression] g++.dg/cpp0x/std-layout1.C fails starting with r280065

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #4 from Jonathan Wakely  ---
*** Bug 93360 has been marked as a duplicate of this bug. ***

[Bug c++/92804] [10 Regression] ICE trying to use concept as a nested-name-specifier

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #3 from Paolo Carlini  ---
Seems doable.

[Bug target/91298] $ at the beginging causing Error: junk `(%rip)' after expression

[daffra.claudio at gmail dot com]

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

--- Comment #8 from claudio daffra  ---
it may not work with the double dollar ,
XSTR (x, 0) [0] == '$'
I can't verify '$$ id', "$$$ ... id" ad so on , at the moment




Il giorno mer 22 gen 2020 alle ore 11:24 pskocik at gmail dot com <
gcc-bugzi...@gcc.gnu.org> ha scritto:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91298
>
> --- Comment #7 from pskocik at gmail dot com ---
> (In reply to CVS Commits from comment #6)
> > The master branch has been updated by Jakub Jelinek :
>
> Thank you for the fix!
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug target/91298] $ at the beginging causing Error: junk `(%rip)' after expression

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
(In reply to claudio daffra from comment #8)
> it may not work with the double dollar ,
> XSTR (x, 0) [0] == '$'
> I can't verify '$$ id', "$$$ ... id" ad so on , at the moment

??? The only problem was with leading $, $ in other positions were ok in the
past already. $$var should be treated like $var, in instructions wrapped in
()s, so ($$var) instead of $$var.

[Bug target/91298] $ at the beginging causing Error: junk `(%rip)' after expression

[daffra.claudio at gmail dot com]

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

--- Comment #10 from claudio daffra  ---
Thanks, I'll check it out.

Il giorno mer 22 gen 2020 alle ore 11:47 jakub at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> ha scritto:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91298
>
> --- Comment #9 from Jakub Jelinek  ---
> (In reply to claudio daffra from comment #8)
> > it may not work with the double dollar ,
> > XSTR (x, 0) [0] == '$'
> > I can't verify '$$ id', "$$$ ... id" ad so on , at the moment
>
> ??? The only problem was with leading $, $ in other positions were ok in
> the
> past already. $$var should be treated like $var, in instructions wrapped in
> ()s, so ($$var) instead of $$var.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug target/33989] Extra load/store for float with union

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||powerpc*-*
  Component|middle-end  |target

--- Comment #16 from Andrew Pinski  ---
(In reply to Scott Mansell from comment #15)
> Weirdly, it works fine with doubles.

At least at the time I wrote up this bug report, can_change_mode target hook on
rs6000 would reject SImode and SFmode IIRC which forces a reload (spill when
moving between those two).  Now I have not looked at the rs6000 back-end for
almost 10 years so I cannot say if this still applies or not.

Moving to a target bug.

[Bug target/93376] [10 Regression] ICE: in immed_wide_int_const_1, at emit-rtl.c:660 with -Og -finline-functions-called-once

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
The problem seems to be during try_combine:
(gdb) p debug_rtx (i3)
(insn 18 17 19 2 (parallel [
(set (reg:CCO 17 flags)
(eq:CCO (plus:OI (sign_extend:OI (reg:TI 96))
(const_int 1 [0x1]))
(sign_extend:OI (plus:TI (reg:TI 96)
(const_int 1 [0x1])
(set (reg:TI 98)
(plus:TI (reg:TI 96)
(const_int 1 [0x1])))
]) "pr93376.c":8:10 223 {*addvti4_doubleword_1}
 (expr_list:REG_UNUSED (reg:TI 98)
(expr_list:REG_DEAD (reg:TI 96)
(nil
(gdb) p debug_rtx (i2)
(insn 17 37 18 2 (set (reg:TI 96)
(const_wide_int 0x7fff)) "pr93376.c":8:10
65 {*movti_internal}
 (nil))
The eq in there gets simplified into:
(eq:CCO (const_wide_int 0x08000)
(const_wide_int 0x8000))
(correct), where the first CONST_WIDE_INT has 3 elts (as it is the TImode MS
bit zero extended into OImode) and the second one has 2 elts (the same
sign-extended into OImode).
The problem is that i386.md has
/* Keep the OI and XI modes from confusing the compiler into thinking
   that these modes could actually be used for computation.  They are
   only holders for vectors during data movement.  */
#define MAX_BITSIZE_MODE_ANY_INT (128)
which means WIDE_INT_MAX_ELTS is 3, which is big enough to handle all that the
patterns need, they only need one hwi above the TImode bits to detect overflow
in either way (maybe even just 1-2 bits).
I'm afraid we don't want to bump MAX_BITSIZE_MODE_ANY_INT, because it would
have consequences anywhere.

Anyway, what happens when simplify-rtx.c calls:
4443case MINUS:
  result = wi::sub (pop0, pop1);
4445  break;
(gdb) p pop0
$44 = {> = {},
(const_wide_int 0x08000)first = , second =
E_OImode}
(gdb) p pop1
$45 = {> = {},
(const_wide_int 0x8000)first = , second = E_OImode}
again, len 3 and len 2.
That results in wi::sub creating result of:
$47 = { = {val = {8589917872, 140737127633408,
140737488338464}, len = 13162290, precision = 256}, 
  static is_sign_extended = true}
where the val array has 3 elts, but then:
2539result.set_len (sub_large (val, xi.val, xi.len,
2540   yi.val, yi.len, precision,
2541   UNSIGNED, 0));
and that one unnecessarily uses yet another HWI, overwriting precision in the
wide_int_storage.

The following fixes the ICE, Richard S., would this be acceptable to you?
Only the second hunk is strictly necessary.

--- gcc/wide-int.cc.jj  2020-01-12 11:54:38.535381394 +0100
+++ gcc/wide-int.cc 2020-01-22 12:05:06.739486117 +0100
@@ -1155,8 +1155,14 @@ wi::add_large (HOST_WIDE_INT *val, const

   if (len * HOST_BITS_PER_WIDE_INT < prec)
 {
-  val[len] = mask0 + mask1 + carry;
-  len++;
+  HOST_WIDE_INT val_top = mask0 + mask1 + carry;
+  /* Don't extend len unnecessarily when canonize would shrink it
+again immediately.  */
+  if (SIGN_MASK (val[len - 1]) != val_top)
+   {
+ val[len] = val_top;
+ len++;
+   }
   if (overflow)
*overflow
  = (sgn == UNSIGNED && carry) ? wi::OVF_OVERFLOW : wi::OVF_NONE;
@@ -1566,8 +1572,14 @@ wi::sub_large (HOST_WIDE_INT *val, const

   if (len * HOST_BITS_PER_WIDE_INT < prec)
 {
-  val[len] = mask0 - mask1 - borrow;
-  len++;
+  HOST_WIDE_INT val_top = mask0 - mask1 - borrow;
+  /* Don't extend len unnecessarily when canonize would shrink it
+again immediately.  */
+  if (SIGN_MASK (val[len - 1]) != val_top)
+   {
+ val[len] = val_top;
+ len++;
+   }
   if (overflow)
*overflow = (sgn == UNSIGNED && borrow) ? OVF_UNDERFLOW : OVF_NONE;
 }

[Bug tree-optimization/92924] [10 regression] reproducible indirect call profile merging causes 80% slowdown in Firefox pref-reftest-singletons id-getter microbenchmarks

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:5f32f9cf13f99f6295591927950aaf98aa8dba91

commit r10-6139-g5f32f9cf13f99f6295591927950aaf98aa8dba91
Author: Martin Liska 
Date:   Wed Jan 22 12:08:11 2020 +0100

Smart relaxation of TOP N counter.

PR tree-optimization/92924
* profile.c (compute_value_histograms): Divide
all counter values.
PR tree-optimization/92924
* libgcov-driver.c (prune_topn_counter): New.
(prune_counters): Likewise.
(dump_one_gcov): Prune a run-time counter.
* libgcov-profiler.c (__gcov_topn_values_profiler_body):
For a known value, add GCOV_TOPN_VALUES to value.
Otherwise, decrement all counters by one.

[Bug target/93376] [10 Regression] ICE: in immed_wide_int_const_1, at emit-rtl.c:660 with -Og -finline-functions-called-once

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 47692
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47692&action=edit
gcc10-pr93376.patch

Full untested patch.

[Bug tree-optimization/92924] [10 regression] reproducible indirect call profile merging causes 80% slowdown in Firefox pref-reftest-singletons id-getter microbenchmarks

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #8 from Martin Liška  ---
The issue is still present, I'm leaving that.

[Bug debug/93380] Variable Length Array Evaluation will be wrong or cause GDB to crash due to GCC

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-debug
 Target|cortex a9 - Renesas RZ A1   |arm
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-01-22
  Component|c++ |debug
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Four things:
1) the GDB internal error is a GDB bug and should be reported there.  It might
be already fixed in a newer version of gdb.
2) GCC 7.x is no longer supported, can you try out a newer version of GCC like
say GCC 9.2.0?
3) Since you recieved the toolchain from ARM, please report the issue back to
them.
4) GCC 7.2.1 is a pre-release version of GCC 7.3.0.

[Bug tree-optimization/35629] gcc.dg/tree-ssa/loop-25.c scan-tree-dump-times profile fails

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #21 from Andrew Pinski  ---
No longer working on this one.  My patch does not always work in the end.

[Bug target/93335] [9/10 Regression] ICE: in extract_insn, at recog.c:2310 with __builtin_sub_overflow_p() on aarch64

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r10-6140-gd80f0a8dc9c2e5886bb79bddee2674e1d3f9d105
Author: Jakub Jelinek 
Date:   Wed Jan 22 12:28:16 2020 +0100

aarch64: Fix aarch64_expand_subvti constant handling [PR93335]

The two patterns that call aarch64_expand_subvti ensure that {low,high}_in1
is a register, while {low,high}_in2 can be a register or immediate.
subdi3_compare1_imm uses the aarch64_plus_immediate predicate for its last
two operands (the value and negated value), but aarch64_expand_subvti calls
it whenever low_in2 is a CONST_INT, which leads to ICEs during vregs pass,
as the emitted insn is not recognized as valid subdi3_compare1_imm.
The following patch fixes that by only using subdi3_compare1_imm if it is
ok
to do so, and otherwise force the constant into register and use the
non-immediate version - subdi3_compare1.
Furthermore, previously the code was calling force_reg on high_in2 only if
low_in2 is CONST_INT, on the (reasonable) assumption is that only if
low_in2
is a CONST_INT, high_in2 can be non-REG, but with the above changes even in
the else we might have CONST_INT and force_reg doesn't do anything if the
operand is already a REG, so this patch calls it unconditionally.

2020-01-22  Jakub Jelinek  

PR target/93335
* config/aarch64/aarch64.c (aarch64_expand_subvti): Only use
gen_subdi3_compare1_imm if low_in2 satisfies aarch64_plus_immediate
predicate, not whenever it is CONST_INT.  Otherwise, force_reg it.
Call force_reg on high_in2 unconditionally.

* gcc.c-torture/compile/pr93335.c: New test.

[Bug target/93335] [9 Regression] ICE: in extract_insn, at recog.c:2310 with __builtin_sub_overflow_p() on aarch64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10 Regression] ICE: in   |[9 Regression] ICE: in
   |extract_insn, at|extract_insn, at
   |recog.c:2310 with   |recog.c:2310 with
   |__builtin_sub_overflow_p()  |__builtin_sub_overflow_p()
   |on aarch64  |on aarch64

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/93383] New: ICE on accessing field of a structure which is non-type template parameter, -std=c++2a

[nikita.provotorov.main at gmail dot com]

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

Bug ID: 93383
   Summary: ICE on accessing field of a structure which is
non-type template parameter, -std=c++2a
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nikita.provotorov.main at gmail dot com
  Target Milestone: ---

Snippet of code which causes GCC crash:

template 
struct fixed_string {
char content[N] = {};

constexpr fixed_string(const char (&)[N]) noexcept {}
};

template  fixed_string(const char (&)[N]) -> fixed_string;


template
struct bar
{};

template
struct foo
{
using type = bar;
};


Exact compiler version: 10.0.0 20200111
Used compiler flags: -Wall -Wextra -std=c++2a
Godbolt reference: https://godbolt.org/z/tAnFxP


Compiler output:

internal compiler error: Segmentation fault
   18 | using type = bar;
  | ^
0xc12a5f crash_signal
../../source/gcc/toplev.c:328
0x5fed33 resolve_args(vec*, int)
../../source/gcc/cp/call.c:4429
0x70e69f do_class_deduction
../../source/gcc/cp/pt.c:28566
0x70e69f do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../source/gcc/cp/pt.c:28699
0x70faf2 convert_template_argument
../../source/gcc/cp/pt.c:8325
0x72261f convert_template_argument
../../source/gcc/cp/pt.c:8098
0x72261f coerce_template_parms
../../source/gcc/cp/pt.c:8829
0x72640a lookup_template_class_1
../../source/gcc/cp/pt.c:9666
0x72768c lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../source/gcc/cp/pt.c:10038
0x74291d finish_template_type(tree_node*, tree_node*, int)
../../source/gcc/cp/semantics.c:3405
0x6eb83d cp_parser_template_id
../../source/gcc/cp/parser.c:16659
0x6ebaaa cp_parser_class_name
../../source/gcc/cp/parser.c:23564
0x6e89c1 cp_parser_qualifying_entity
../../source/gcc/cp/parser.c:6727
0x6e89c1 cp_parser_nested_name_specifier_opt
../../source/gcc/cp/parser.c:6410
0x6efc2f cp_parser_simple_type_specifier
../../source/gcc/cp/parser.c:18054
0x6d6bfd cp_parser_type_specifier
../../source/gcc/cp/parser.c:17712
0x6ea094 cp_parser_type_specifier_seq
../../source/gcc/cp/parser.c:22271
0x6e cp_parser_type_id_1
../../source/gcc/cp/parser.c:22100
0x6e5608 cp_parser_type_id
../../source/gcc/cp/parser.c:22179
0x6e5608 cp_parser_alias_declaration
../../source/gcc/cp/parser.c:19927

[Bug c/93384] New: Python 3.9.0a3 fails to build on ppc64le with GCC 10.0.1: redefined symbol cannot be used on reloc

[vstinner at redhat dot com]

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

Bug ID: 93384
   Summary: Python 3.9.0a3 fails to build on ppc64le with GCC
10.0.1: redefined symbol cannot be used on reloc
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vstinner at redhat dot com
  Target Milestone: ---

Hi,

We are working on upgrading Python 3.8 to 3.9 in Fedora Rawhide. Two builds
ago, the build was fine on the 3 archs (x86-64, aarch64, ppc64), but when GCC
has been upgraded from GCC 9.2.1 to GCC 10.0.1, we started the get the
following error on ppc64le (and only on this arch, the two others are building
successfully):

/tmp/cc7LZ1xH.s: Assembler messages:
/tmp/cc7LZ1xH.s:91549: Error: redefined symbol cannot be used on reloc
/tmp/cc7LZ1xH.s:275099: Error: redefined symbol cannot be used on reloc
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

Full build logs:
https://kojipkgs.fedoraproject.org//work/tasks/606/40790606/build.log

We build Python using LTO and PGO.

The first step of PGO (-fprofile-generate) went fine, but the second step
(-fprofile-use) is the one which failed.

GCC error message is unclear :-( I'm not sure if the error comes from the build
of a single .c file, or on the linking command creating libpython3.9.so from
all .o files.

A Python .c file is built with a command like (that's the second PGO step,
using -fprofile-use -fprofile-correction):
---
gcc
 -pthread
 -c
 -Wno-unused-result
 -Wsign-compare
 -DDYNAMIC_ANNOTATIONS_ENABLED=1
 -DNDEBUG 
 -O2
 -g
 -pipe
 -Wall
 -Werror=format-security
 -Wp,-D_FORTIFY_SOURCE=2
 -Wp,-D_GLIBCXX_ASSERTIONS
 -fexceptions
 -fstack-protector-strong
 -grecord-gcc-switches  
 -m64
 -mcpu=power8
 -mtune=power8
 -fasynchronous-unwind-tables
 -fstack-clash-protection
 -D_GNU_SOURCE
 -fPIC
 -fwrapv
 -O2
 -g
 -pipe
 -Wall
 -Werror=format-security
 -Wp,-D_FORTIFY_SOURCE=2
 -Wp,-D_GLIBCXX_ASSERTIONS
 -fexceptions
 -fstack-protector-strong
 -grecord-gcc-switches  
 -m64
 -mcpu=power8
 -mtune=power8
 -fasynchronous-unwind-tables
 -fstack-clash-protection
 -D_GNU_SOURCE
 -fPIC
 -fwrapv  
 -O2
 -g
 -pipe
 -Wall
 -Werror=format-security
 -Wp,-D_FORTIFY_SOURCE=2
 -Wp,-D_GLIBCXX_ASSERTIONS
 -fexceptions
 -fstack-protector-strong
 -grecord-gcc-switches  
 -m64
 -mcpu=power8
 -mtune=power8
 -fasynchronous-unwind-tables
 -fstack-clash-protection
 -D_GNU_SOURCE
 -fPIC
 -fwrapv  
 -O2
 -g
 -pipe
 -Wall
 -Werror=format-security
 -Wp,-D_FORTIFY_SOURCE=2
 -Wp,-D_GLIBCXX_ASSERTIONS
 -fexceptions
 -fstack-protector-strong
 -grecord-gcc-switches
 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
 -m64
 -mcpu=power8
 -mtune=power8
 -fasynchronous-unwind-tables
 -fstack-clash-protection
 -D_GNU_SOURCE
 -fPIC
 -fwrapv
 -fno-semantic-interposition
 -flto
 -fuse-linker-plugin
 -ffat-lto-objects
 -flto-partition=none
 -g
 -std=c99
 -Wextra
 -Wno-unused-result
 -Wno-unused-parameter
 -Wno-missing-field-initializers
 -Werror=implicit-function-declaration
 -fvisibility=hidden
 -O2
 -g
 -pipe
 -Wall
 -Werror=format-security
 -Wp,-D_FORTIFY_SOURCE=2
 -Wp,-D_GLIBCXX_ASSERTIONS
 -fexceptions
 -fstack-protector-strong
 -grecord-gcc-switches
 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
 -m64
 -mcpu=power8
 -mtune=power8
 -fasynchronous-unwind-tables
 -fstack-clash-protection
 -D_GNU_SOURCE
 -fPIC
 -fwrapv
 -fno-semantic-interposition 
 -fprofile-use
 -fprofile-correction
 -I/builddir/build/BUILD/Python-3.9.0a2/Include/internal
 -IObjects
 -IInclude
 -IPython
 -I.
 -I/builddir/build/BUILD/Python-3.9.0a2/Include  
 -fPIC
 -DPy_BUILD_CORE
 -o Python/Python-ast.o
/builddir/build/BUILD/Python-3.9.0a2/Python/Python-ast.c
---

Link libpython3.9.so:
---
gcc
 -pthread
 -shared
 -Wl,-z,relro
 -Wl,--as-needed
 -Wl,-z,now
 -g
 -Wl,-z,relro
 -Wl,--as-needed
 -Wl,-z,now
 -g
 -Wl,-z,relro
 -Wl,--as-needed
 -Wl,-z,now
 -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
 -fno-semantic-interposition
 -g
 -flto
 -fuse-linker-plugin
 -ffat-lto-objects
 -flto-partition=none
 -g
 -Wl,-z,relro
 -Wl,--as-needed
 -Wl,-z,now
 -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
 -fno-semantic-interposition
 -g
 -o libpython3.9.so

 -lcrypt
 -lpthread
 -ldl
 -lutil
 -lm
 -lm

 Modules/getbuildinfo.o
 Parser/acceler.o
 Parser/grammar1.o
 Parser/listnode.o
 Parser/node.o
 Parser/parser.o
 Parser/token.o
 Parser/myreadline.o
 Parser/parsetok.o
 Parser/tokenizer.o
 Objects/abstract.o
 Objects/accu.o
 Objects/boolobject.o
 Objects/bytes_methods.o
 Objects/bytearrayobject.o
 Objects/bytesobject.o
 Objects/call.o
 Objects/capsule.o
 Objects/cellobject.o
 Objects/classobject.o
 Objects/codeobject.o
 Objects/complexobject.o
 Objects/descrobject.o
 Obje

[Bug tree-optimization/30187] accessing an element via a "pointer" on a vector does not cause vec_extract to be used (non constant index)

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Here is the interesting thing:
#define vector __attribute__((vector_size(16)))
float f(vector float t, int i)
{
  vector int tt = {i, i, i, i};
  vector float r = __builtin_shuffle(t, tt);
  return r[0];
}

 CUT ---
produces:
  _7 = i_2(D) & 3;
  vectmp.4 = t_4(D);
  _8 = VIEW_CONVERT_EXPR(vectmp.4)[_7];
  return _8;

[Bug fortran/93309] Wrong error about duplicate implicit none

[ripero84 at gmail dot com]

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

--- Comment #4 from ripero84 at gmail dot com ---
Thank you!  Would it be possible to backport this fix to the other active
branches?

[Bug tree-optimization/30187] accessing an element via a "pointer" on a vector does not cause vec_extract to be used (non constant index)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #4 from Andrew Pinski  ---
I don't know which one is actually better though.

[Bug lto/93384] Python 3.9.0a3 fails to build on ppc64le with GCC 10.0.1: redefined symbol cannot be used on reloc

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||assemble-failure

--- Comment #1 from Andrew Pinski  ---
>GCC error message is unclear

Well not is not a GCC error message but rather the assembler is producing the
error message.

[Bug tree-optimization/93381] points-to wrong for integer offsetting and field-sensitive analysis

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.0

--- Comment #3 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/93381] points-to wrong for integer offsetting and field-sensitive analysis

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Guenther :

https://gcc.gnu.org/g:2b85c0882205c31987ac26ffc49351a3af3b537c

commit r10-6141-g2b85c0882205c31987ac26ffc49351a3af3b537c
Author: Richard Biener 
Date:   Wed Jan 22 12:38:12 2020 +0100

tree-optimization/93381 fix integer offsetting in points-to analysis

We were incorrectly assuming a merge operation is conservative enough
for not explicitely handled operations but we also need to consider
offsetting within fields when field-sensitive analysis applies.

2020-01-22  Richard Biener  

PR tree-optimization/93381
* tree-ssa-structalias.c (find_func_aliases): Assume offsetting
throughout, handle all conversions the same.

* gcc.dg/torture/pr93381.c: New testcase.

[Bug lto/93384] Python 3.9.0a3 fails to build on ppc64le with GCC 10.0.1: redefined symbol cannot be used on reloc

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Can you use -save-temps and look at the generated assembler file in around
those two lines?  This could be some inline-asm that causes the error too.

[Bug target/93385] New: [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce

[zsojka at seznam dot cz]

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

Bug ID: 93385
   Summary: [10 Regression] wrong code with u128 modulo at -O2
-fno-dce -fno-ipa-cp -fno-tree-dce
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 47693
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47693&action=edit
reduced testcase

Output:
$ x86_64-pc-linux-gnu-gcc -O2 -fno-dce -fno-ipa-cp -fno-tree-dce testcase.c
$ ./a.out 
Floating point exception

(gdb) bt
#0  0x004011c4 in __udivmodti4 (rp=, d=0, n=0) at
/repo/gcc-trunk/libgcc/libgcc2.c:1046
#1  __umodti3 (u=, v=) at
/repo/gcc-trunk/libgcc/libgcc2.c:1310
#2  0x00401056 in c (d=) at testcase.c:7
#3  main () at testcase.c:16

The code seems to compute 0 % 0 (all rsi:rdi rcx:rdx are == 0)

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-20200122013655-10502831581-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-20200122013655-10502831581-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.1 20200122 (experimental) (GCC)

[Bug tree-optimization/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-22
  Component|target  |tree-optimization
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
The inliner is broken .076i.inline:
  e = 0;
  _4 = (unsigned int) d_3(D);
  _5 = d_3(D) & 4294967295;
  d_6 = d_3(D) % _5;
  __builtin_strncpy (&a, &e, 1);
  b.2_7 = b;
  _8 = (int) b.2_7;
  e ={v} {CLOBBER};


The assignment to d is gone.

[Bug tree-optimization/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug tree-optimization/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
If we force d to be used after the mod.  Then we get working code.
I suspect the inlininer is doing some kind of dce detection.

[Bug tree-optimization/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #3 from Andrew Pinski  ---
In fact if we add -Wuninitialized, we get the warning:
t2.c: In function ‘main’:
t2.c:7:8: warning: ‘d’ is used uninitialized in this function [-Wuninitialized]
7 |   d %= (unsigned) d;
  |^~~~
t2.c:4:1: note: ‘d’ was declared here
4 | c (unsigned __int128 d)
  | ^

--- CUT ---
Here is a testcase without __int128 so other targets:
char a, b;

static inline int
c (unsigned int d)
{
  char e = 0;
  d %= (unsigned short) d;
  e -= 0;
  __builtin_strncpy (&a, &e, 1);
  return e + b ;
}

int
main (void)
{
  c (~0);
  return 0;
}

[Bug tree-optimization/92924] [10 regression] reproducible indirect call profile merging causes 80% slowdown in Firefox pref-reftest-singletons id-getter microbenchmarks

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:7491c17fe01d8cf116f645532d46120029b26408

commit r10-6145-g7491c17fe01d8cf116f645532d46120029b26408
Author: Martin Liska 
Date:   Wed Jan 22 13:40:12 2020 +0100

Fix TOP N counter update.

PR tree-optimization/92924
* libgcov-profiler.c (__gcov_topn_values_profiler_body): First
try to find an existing value, then find an empty slot
if not found.

[Bug c++/93386] New: Missing a const qualifier in the type denoted by decltype((r))

[kyle.show910 at gmail dot com]

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

Bug ID: 93386
   Summary: Missing a const qualifier in the type denoted by
decltype((r))
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kyle.show910 at gmail dot com
  Target Milestone: ---

According to the standard
timsong-cpp.github.io/cppwp/n4659/expr.prim.lambda.capture#14, we should have
the following:
void f3() {
  float x, &r = x;
  [=] { 
decltype(x) y1; // y1 has type float
decltype((x)) y2 = y1;  // y2 has type float const& because this lambda is
not mutable and x is an lvalue
decltype(r) r1 = y1;// r1 has type float& (transformation not
considered)
decltype((r)) r2 = y2;  // r2 has type float const&
  };
}
but we have this:
void f3() {
  float x, &r = x;
  [=] { 
decltype(x) y1; // y1 has type float
decltype((x)) y2 = y1;  // y2 has type float const&
decltype(r) r1 = y1;// r1 has type float&
decltype((r)) r2 = y2;  // r2 has type float&
  };
}
https://godbolt.org/z/sYXzzn
https://godbolt.org/z/unpxwV

The type denoted by decltype((r)) where r is a reference and decltype occurs
inside a const member function doesn’t contain a const qualifier.

[Bug target/93346] gcc does not generate BZHI

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Created attachment 47694
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47694&action=edit
gcc10-pr93346.patch

While the complicated pattern is needed to properly model the semantics of the
instruction for all values of the last operand (something needed e.g. for the
intrinsic), the patterns in the testcase have undefined behavior unless the
shift count is valid (0 to prec-1) and there is no reason to match them as bzhi
that way.

[Bug analyzer/93367] FAIL: gcc.dg/analyzer/abort.c (test for warnings, line 71)

[dave.anglin at bell dot net]

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

--- Comment #2 from dave.anglin at bell dot net ---
On 2020-01-21 9:55 p.m., dmalcolm at gcc dot gnu.org wrote:
> What's the definition of assert for this system?
   extern void __assert(char *, char *, int);

#  if defined(__cplusplus) && !defined(__STDCPP__)
#    define assert(_EX) \
    ((_EX) ? (void)0 : __assert("_EX", __FILE__, __LINE__))
#  else
#    define assert(_EX) \
    ((_EX) ? (void)0 : __assert(#_EX, __FILE__, __LINE__))
#  endif

I suppose an include hack could be done to add __attribute__((__noreturn__)).

[Bug target/93376] [10 Regression] ICE: in immed_wide_int_const_1, at emit-rtl.c:660 with -Og -finline-functions-called-once

[rsandifo at gcc dot gnu.org]

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Personally I'd prefer it if we skipped arithmetic on modes wider
than MAX_BITSIZE_MODE_ANY_INT.  wide-int routines should always
be able to write HWIs up to the full precision of the integer.

[Bug libstdc++/55394] Using call_once without -lpthread compiles without warning

[kloczko.tomasz at gmail dot com]

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

Tomasz Kłoczko  changed:

   What|Removed |Added

 CC||kloczko.tomasz at gmail dot com

--- Comment #8 from Tomasz Kłoczko  ---
Any progress on that issue?
Looks like I've hit this issu in protobuf
https://github.com/protocolbuffers/protobuf/issues/7092

[Bug target/93376] [10 Regression] ICE: in immed_wide_int_const_1, at emit-rtl.c:660 with -Og -finline-functions-called-once

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 47695
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47695&action=edit
gcc10-pr93376-2.patch

This is a variant patch that uses POImode with 192 bit precision instead of
OImode for these signed overflow patterns from TImode, so that it doesn't
overflow wide_int_storage reserved bits.
I'm afraid it is much more expensive because e.g. reload has arrays sized by
number_of_modes^2.
Yet another way around would be give up on the pattern macroization and instead
of those (eq:CCO (plus:OI (sign_extend:OI (reg:TI)) (sign_extend:OI (reg:TI)))
(sign_extend:OI (plus:TI (reg:TI) (reg:TI and similar replace those
(sign_extend:OI (whatever:TI)) with (sign_extract:TI (whatever:TI) (const_int
32) (const_int 32)) or so.  Except that sign_extract is not valid for
non-single-byte MEM.  Or replace sign_extend with ashiftrt by (const_int 1)?

[Bug c++/93387] New: Invalid read of size 4 in linemap_lookup with pch and -std=gnu++2a

[marxin at gcc dot gnu.org]

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

Bug ID: 93387
   Summary: Invalid read of size 4 in linemap_lookup with pch and
-std=gnu++2a
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Hello.

I see a failure when building telegram-desktop package which utilizes a
pre-compiled header:

$ g++ export_output_html.ii -fmax-errors=1 -Winvalid-pch -O3 -DNDEBUG
-fno-strict-aliasing -Wall -W -fPIC -Wno-unused-variable -Wno-unused-parameter
-Wno-unused-function -Wno-switch -Wno-comment -Wno-unused-but-set-variable
-Wno-missing-field-initializers -Wno-sign-compare -Wno-attributes
-Wno-parentheses -Wno-stringop-overflow -Wno-maybe-uninitialized
-Wno-error=class-memaccess -std=gnu++2a
In file included from
/home/abuild/rpmbuild/BUILD/Libraries/range-v3/include/range/v3/range_fwd.hpp:22,
 from
/home/abuild/rpmbuild/BUILD/Libraries/range-v3/include/range/v3/action/action.hpp:21,
 from
/home/abuild/rpmbuild/BUILD/Libraries/range-v3/include/range/v3/action.hpp:17,
 from
/home/abuild/rpmbuild/BUILD/Libraries/range-v3/include/range/v3/all.hpp:17,
 from
/home/abuild/rpmbuild/BUILD/tdesktop-1.9.6-full/Telegram/SourceFiles/export/export_pch.h:29,
 from
/home/abuild/rpmbuild/BUILD/tdesktop-1.9.6-full/build/Telegram/CMakeFiles/lib_export.dir/cmake_pch.hxx:5,
 from :
/home/abuild/rpmbuild/BUILD/Libraries/range-v3/include/range/v3/utility/semiregular_box.hpp:
In instantiation of ‘struct
ranges::semiregular_box)::
> >’:
/home/abuild/rpmbuild/BUILD/Libraries/range-v3/include/range/v3/view/transform.hpp:106:57:
  required from ‘struct
ranges::iter_transform_view >,
ranges::indirected):: >
>’
/home/abuild/rpmbuild/BUILD/Libraries/range-v3/include/range/v3/view/transform.hpp:190:12:
  required from ‘struct
ranges::transform_view >,
SerializeString(std::vector):: >’
/home/abuild/rpmbuild/BUILD/Libraries/range-v3/include/range/v3/functional/invoke.hpp:133:40:
  required from ‘constexpr decltype
((F&&)(f)((Args&(ranges::invoke_fn::operator()::args))...))
ranges::invoke_fn::operator()(F&&, Args&& ...) const [with F = const
ranges::views::transform_base_fn&; Args = {std::vector >&, const
SerializeString(std::vector)::&}; decltype
((F&&)(f)((Args&(ranges::invoke_fn::operator()::args))...)) =
ranges::transform_view >,
SerializeString(std::vector):: >]’
/home/abuild/rpmbuild/BUILD/Libraries/range-v3/include/range/v3/functional/invoke.hpp:169:24:
  required by substitution of ‘template using
invoke_result_t = decltype (ranges::invoke(declval(),
(declval)()...)) [with Fun = const ranges::views::transform_base_fn&;
Args = {std::vector >&, const
SerializeString(std::vector)::&}]’
/home/abuild/rpmbuild/BUILD/Libraries/range-v3/include/range/v3/functional/bind_back.hpp:112:28:
  required by substitution of ‘template constexpr
ranges::invoke_result_t)::&>
ranges::detail::bind_back_fn_)::
>::operator()(CallArgs&& ...) const & [with CallArgs =
{std::vector >&}]’
/home/abuild/rpmbuild/BUILD/Libraries/range-v3/include/range/v3/functional/invoke.hpp:134:34:
  [ skipping 7 instantiation contexts, use -ftemplate-backtrace-limit=0 to
disable ]
/home/abuild/rpmbuild/BUILD/Libraries/range-v3/include/concepts/concepts.hpp:743:24:
  required from ‘static constexpr bool concepts::detail::and_::impl(std::true_type) [with T =
concepts::detail::boolean_< >; U =
concepts::detail::boolean_< >; std::true_type =
std::integral_constant]’
/home/abuild/rpmbuild/BUILD/Libraries/range-v3/include/concepts/concepts.hpp:747:34:
  required from ‘constexpr concepts::detail::and_::operator bool() const
[with T = concepts::detail::boolean_< >; U =
concepts::detail::boolean_< >]’
/home/abuild/rpmbuild/BUILD/Libraries/range-v3/include/concepts/concepts.hpp:747:41:
  required by substitution of ‘template using bool_ =
std::integral_constant [with bool B =
concepts::detail::and_ >,
concepts::detail::boolean_< >
>{}.concepts::detail::and_ >,
concepts::detail::boolean_< > >::operator bool()]’
/home/abuild/rpmbuild/BUILD/Libraries/range-v3/include/concepts/concepts.hpp:747:34:
  required from ‘constexpr concepts::detail::and_::operator bool() const
[with T = concepts::detail::and_
>, concepts::detail::boolean_< > >; U =
std::integral_constant]’
/home/abuild/rpmbuild/BUILD/Libraries/range-v3/include/range/v3/view/view.hpp:112:13:
  required by substitution of ‘template &&
invocable_view_closure) && CPP_true_{}), int>::type  >
constexpr auto ranges::views::view_closure_base_ns::operator|(Rng&&,
ranges::views::view_closure) [with Rng = std::vector&; ViewFn
= ranges::detail::bind_back_fn_):: >; CPP_true_ =
std::integral_constant; typename
std::enable_if<((viewable_range && invocable_view_c

[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
(In reply to sandra from comment #1)
[...]
> Also observed on nios2-elf:
> 
> FAIL: gcc.dg/analyzer/pattern-test-2.c  == 0 (test for warnings,
> line 21)
> FAIL: gcc.dg/analyzer/pattern-test-2.c  != 0 (test for warnings,
> line 21)
> FAIL: gcc.dg/analyzer/pattern-test-2.c (test for excess errors)
> Excess errors:
> /path/to/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c:21:6: warning:
> pattern match on 'p == 0'
> /path/to/gcc/testsuite/gcc.dg/analyzer/pattern-test-2.c:21:17: warning:
> pattern match on 'q == 0'

Thanks; these pattern-test-2.c ones sound like a dup of PR 93291.

[Bug ipa/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jamborm at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
  Component|tree-optimization   |ipa

--- Comment #4 from Richard Biener  ---
-fno-ipa-sra fixes it.  I suspect it falls foul of needing wide-ints for the
constant, punting at transform time only half-way.

[Bug ipa/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Hmm, no, IPA SRA thinks the parameter is unused (huh).  Possibly -fno-ipa-cp
isn't implemented "fully".

[Bug analyzer/93388] New: ensure -fanalyzer works with our C code

[toon at moene dot org]

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

Bug ID: 93388
   Summary: ensure -fanalyzer works with our C code
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: toon at moene dot org
  Target Milestone: ---

Trying to bootstrap with a new config/bootstrap-analyzer.mk:

STAGE2_CFLAGS += -fanalyzer
STAGE3_CFLAGS += -fanalyzer

fails while building libbacktrace/dwarf.c:448:12: warning: use of uninitialized
value 'unit_buf.buf' [CWE-457] [-Wanalyzer-use-of-uninitialized-value]

[Bug analyzer/93388] ensure -fanalyzer works with our C code

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-22
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
...and as noted on IRC, probably numerous other diagnostics; the last 900 lines
are here:
  https://gcc.gnu.org/ml/gcc-testresults/2020-01/msg01033.html

We should gracefully handle our own C code.

Also, note the 110-event diagnostic_path.  It's not reasonable to expect an
end-user to read through that (and I suspect it's a false positive).

[Bug target/93376] [10 Regression] ICE: in immed_wide_int_const_1, at emit-rtl.c:660 with -Og -finline-functions-called-once

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 47695 [details]
> gcc10-pr93376-2.patch
> 
> This is a variant patch that uses POImode with 192 bit precision instead of
> OImode for these signed overflow patterns from TImode, so that it doesn't
> overflow wide_int_storage reserved bits.
> I'm afraid it is much more expensive because e.g. reload has arrays sized by
> number_of_modes^2.
> Yet another way around would be give up on the pattern macroization and
> instead of those (eq:CCO (plus:OI (sign_extend:OI (reg:TI)) (sign_extend:OI
> (reg:TI)))
> (sign_extend:OI (plus:TI (reg:TI) (reg:TI and similar replace those
> (sign_extend:OI (whatever:TI)) with (sign_extract:TI (whatever:TI)
> (const_int 32) (const_int 32)) or so.  Except that sign_extract is not valid
> for non-single-byte MEM.  Or replace sign_extend with ashiftrt by (const_int
> 1)?

Actually no, neither sign_extract nor ashiftrt would work correctly.

[Bug ipa/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Started with r10-3542-g0b92cf305dcf34387a8e2564e55ca8948df3b47a

[Bug c/84919] [8/9/10 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords|deferred|patch

--- Comment #18 from Martin Sebor  ---
GCC 10 patch: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01471.html

[Bug ipa/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
And with additiona -fno-early-inlining started with
r10-3311-gff6686d2e5f797d6c6a36ad14a7084bc1dc350e4

[Bug ipa/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org

--- Comment #8 from Martin Jambor  ---
Yes, IPA-SRA removes the parameter because we do bunch of computations
on them but never store the result anywhere nor pass it to another
function.  The problem is that the modulo operation survives the
compilation even though its result is not stored anywhere (which
somewhat surprises me, I must say).

I'll figure out why tree-ssa-dce refuses to remove it and see if I can
employ a similar logic in IPA-SRA.

[Bug ipa/93369] [10 regression] g++.dg/lto/pr64076 fails

[seurer at gcc dot gnu.org]

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

--- Comment #3 from seurer at gcc dot gnu.org ---
Will do in the future re: using g:

Should it also go in the Summary line?  The hashes would make it quite long.

[Bug ipa/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
The options include -fno-tree-dce.

[Bug middle-end/26724] __builtin_constant_p fails to recognise function with constant return

[pskocik at gmail dot com]

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

pskocik at gmail dot com changed:

   What|Removed |Added

 CC||pskocik at gmail dot com

--- Comment #3 from pskocik at gmail dot com ---
I don't know if this is related, but what's been bugging me is that gcc's
__builtin_constant_p (clang's also, but in different situations) fails to
recognize the constness/non-constness of a `memcmp` call when it's used for
equality comparisons.

In such situations, I would like to use
__builtin_constant_p(!memcmp(...))?!memcmp(...):!my_memcmp(...) to call a
custom backend function (one not named `memcmp`) if real `memcmp` would be
called, but inline a constant otherwise.

Unfortunately there seem to be edge cases where this doesn't work and while the
assembly for a !memcmp(...) expression shows it's been folded to a constant, a
__builtin_constant_p around such an expression doesn't reflect that.

E.g., in functions eq_eh{2,3}_cexprEh in 
https://gcc.godbolt.org/z/6oefRX (on clang the correspondence breaks in
eq_eh1_cexprEh).

[Bug c++/93386] Missing a const qualifier in the type denoted by decltype((r))

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Dup

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

[Bug c++/79620] decltype() inside a lambda capturing-by-value

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||kyle.show910 at gmail dot com

--- Comment #1 from Jonathan Wakely  ---
*** Bug 93386 has been marked as a duplicate of this bug. ***

[Bug ipa/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce

[jamborm at gcc dot gnu.org]

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

--- Comment #10 from Martin Jambor  ---
Ah, -fno-tree-dce is specfied on the command line...

[Bug c++/93389] New: Failure to detect UB in constexpr context

[klaus.doldinger64 at googlemail dot com]

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

Bug ID: 93389
   Summary: Failure to detect UB in constexpr context
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: klaus.doldinger64 at googlemail dot com
  Target Milestone: ---

The following test as IIFE should be detected as UB, but it isn't:

constexpr auto test3 = []{
int* p{};
{   
int x{};
p = &x;
}
return *p; // should be UB, but isn't detected
}(); // IIFE


int main() {}

[Bug c++/93389] Failure to detect UB in constexpr context

[yankel.scialom-ext at natixis dot com]

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

YSC  changed:

   What|Removed |Added

 CC||yankel.scialom-ext@natixis.
   ||com

--- Comment #1 from YSC  ---
Please note that:
- clang successfully reject this code ;
- this bug is being discussed on Stack Overflow
.

[Bug tree-optimization/92152] [10 Regression] Wrong code (Resurrection of PR53663)

[hubicka at gcc dot gnu.org]

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

--- Comment #10 from Jan Hubicka  ---
Concerning:
> Honza, the type_has_components_p check in
>
>  if (compare_type_sizes (TREE_TYPE (ref2), type1) >= 0
>  && (!end_struct_ref1
>  || compare_type_sizes (TREE_TYPE (ref2),
> TREE_TYPE (end_struct_ref1)) >= 0)
>  && type_has_components_p (TREE_TYPE (ref2))
>  && (base1_alias_set == ref2_alias_set
>  || alias_set_subset_of (base1_alias_set, ref2_alias_set)))
>
> is a compile-time optimization?  Because the alias subset check of course
> would trigger here since ref2_alias_set is not the alias-set of
> TREE_TYPE (ref2) but of one of its bases.

It was not meant as optimization, but to avoid false positives when the base
and ref alias sets intersects but the path can not continue this way.

I see that here we continue path ending with "long" by path starting by
"union". I guess it is only way to continue from "long", so what about simply
testing 
"&& TREE_CODE (TREE_TYPE (base1)) != UNION_TYPE" 
(or more carefully we can check if first non-union type after base1 is same as
TREE_TYPE (ref2)

I do not think we need to cut the access path after unions like in your fix.
If that union is wrapped inside struct, one can not continue from type with no
components.

Honza