[Bug debug/87916] [9 Regression] ICE in dwarf2out_abstract_function, at dwarf2out.c:22479 since r264943

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2018-11-7
  Known to work||8.2.0
   Target Milestone|--- |9.0
  Known to fail||9.0

[Bug debug/87916] New: [9 Regression] ICE in dwarf2out_abstract_function, at dwarf2out.c:22479 since r264943

[marxin at gcc dot gnu.org]

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

Bug ID: 87916
   Summary: [9 Regression] ICE in dwarf2out_abstract_function, at
dwarf2out.c:22479 since r264943
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: ebotcazou at gcc dot gnu.org
  Target Milestone: ---

Following causes ICE:

$ cat turbo.ii
struct a {
  virtual ~a();
};
template  class c {
public:
  class d {
  public:
d(c);
b *operator->();
  };
};
int e, f;
class g {
public:
  class h {
  public:
virtual void j(g &, int &, bool) = 0;
  };
  c k();
  int *l();
  int *m();
};
int *g::l() try {
  for (c::d i(k());;)
i->j(*this, e, true);
} catch (int) {
  return 0;
}
int *g::m() try {
  for (c::d i(k());;)
i->j(*this, f, false);
} catch (int) {
  return 0;
}
struct n : a, g::h {
  void o();
  void j(g &, int &, bool) { o(); }
};

$ g++ -O2 -g turbo.ii  -c -m32 -fPIC -Wall
during IPA pass: inline
turbo.ii: In member function ‘int* g::l()’:
turbo.ii:25:9: internal compiler error: in dwarf2out_abstract_function, at
dwarf2out.c:22479
   25 | i->j(*this, e, true);
  | ^~~~
0x731731 dwarf2out_abstract_function
/home/marxin/Programming/gcc/gcc/dwarf2out.c:22479
0x31fa65f expand_call_inline
/home/marxin/Programming/gcc/gcc/tree-inline.c:4855
0x3202412 gimple_expand_calls_inline
/home/marxin/Programming/gcc/gcc/tree-inline.c:4886
0x3202412 optimize_inline_calls(tree_node*)
/home/marxin/Programming/gcc/gcc/tree-inline.c:5026
0x57cbd67 inline_transform(cgraph_node*)
/home/marxin/Programming/gcc/gcc/ipa-inline-transform.c:682
0x29de91a execute_one_ipa_transform_pass
/home/marxin/Programming/gcc/gcc/passes.c:2190
0x29de91a execute_all_ipa_transforms()
/home/marxin/Programming/gcc/gcc/passes.c:2229
0x196c0f5 cgraph_node::expand()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2187
0x1972724 expand_all_functions
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2332
0x1972724 symbol_table::compile()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2683
0x197dc3a symbol_table::finalize_compilation_unit()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2861
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/87793] [8/9 Regression] GCC reports error when compiling with "-fpic -Os -g"

[aoliva at gcc dot gnu.org]

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

--- Comment #4 from Alexandre Oliva  ---
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00411.html

[Bug lto/87905] structures in two different cpp source files with same name get flagged by ODR warning

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
(In reply to Raymond Jennings from comment #4)
> (In reply to Martin Liška from comment #2)
> > > 
> > > Note in the test package that neither struct is exposed to the other
> > > translation unit.
> > 
> > But it's violation of C++ ODR and as LTO compilation unit is entire program,
> > you then introduce violation.
> 
> I respectfully disagree.
> 
> Unless the source code itself changes, toggling LTO shouldn't affect
> generated warnings.

That's not true. Your source code snippet is violating ODR even without LTO,
but compiler can't prove that.

> 
> It may be one /compilation/ unit, but by the standard they still count as
> separate translation units.  LTO is an artifact of the compiler and not the
> standard so it shouldn't have an impact on ODR warnings.

Please take a look at:
https://en.wikipedia.org/wiki/One_Definition_Rule

more particularly at 'Example showing unexpected side effects' where you can
see example where even non-LTO mode produces undefined behavior based on the
violation.

In general, we as compiler developers, are under pressure due to user's
expectation about highly optimized binaries. On the other hand, we need to base
these optimizations on standards that we can leverage.

[Bug rtl-optimization/87874] [8/9 Regression] ICE in simplify_subreg, at simplify-rtx.c:6396

[aoliva at gcc dot gnu.org]

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

--- Comment #5 from Alexandre Oliva  ---
Author: aoliva
Date: Wed Nov  7 06:25:30 2018
New Revision: 265860

URL: https://gcc.gnu.org/viewcvs?rev=265860=gcc=rev
Log:
[PR87874] avoid const-wide-int subreg in LRA

Just like CONST_INT, CONST_WIDE_INT is VOIDmode, so LRA might be
tempted to build a SUBREG to "convert" it to the wanted mode.  That's
no use.  Test for CONST_SCALAR_INT_P instead of CONST_INT_P so that we
skip the subreg creation for both.

for  gcc/ChangeLog

PR rtl-optimization/87874
* lra.c (lra_substitute_pseudo): Do not create a subreg for
const wide ints.

for  gcc/testsuite/ChangeLog

PR rtl-optimization/87874
* gcc.dg/pr87874.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/pr87874.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra.c
trunk/gcc/testsuite/ChangeLog

[Bug target/87793] [8/9 Regression] GCC reports error when compiling with "-fpic -Os -g"

[aoliva at gcc dot gnu.org]

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

--- Comment #3 from Alexandre Oliva  ---
Created attachment 44966
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44966=edit
candidate patch

[Bug libstdc++/87872] debug list::splice should not call _M_transfer_from_if on self-splices

[fdumont at gcc dot gnu.org]

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

François Dumont  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #5 from François Dumont  ---
Patch committed, thanks again.

[Bug tree-optimization/87915] New: emit warning if (explicit) vectorization failed

[hoganmeier at gmail dot com]

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

Bug ID: 87915
   Summary: emit warning if (explicit) vectorization failed
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hoganmeier at gmail dot com
  Target Milestone: ---

When using #pragma omp simd for explicit vectorization shouldn't it warn if
vectorization failed?

clang has -Wpass-failed for that:
http://lists.llvm.org/pipermail/cfe-dev/2015-July/044226.html

[Bug tree-optimization/87914] New: gcc fails to vectorize bitreverse code

[hoganmeier at gmail dot com]

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

Bug ID: 87914
   Summary: gcc fails to vectorize bitreverse code
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hoganmeier at gmail dot com
  Target Milestone: ---

$ gcc -fopenmp-simd -O3 -march=haswell -fopt-info-vec-omp-optimized-missed

template 
T reverseBits(T x)
{
unsigned int s = sizeof(x) * 8;
T mask = ~T(0);
while ((s >>= 1) > 0)
{
mask ^= (mask << s);
x = ((x >> s) & mask) | ((x << s) & ~mask); // unsupported use
in stmt
}
return x;
}

void test_reverseBits(unsigned* x)
{
#pragma omp simd aligned(x:32)
for (int i = 0; i < 16; ++i)
x[i] = reverseBits(x[i]); // couldn't vectorize loop
}

clang and icc vectorize this:
https://godbolt.org/z/ROJZGZ

[Bug lto/87905] structures in two different cpp source files with same name get flagged by ODR warning

[shentino at gmail dot com]

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

--- Comment #4 from Raymond Jennings  ---
(In reply to Martin Liška from comment #2)
> > 
> > Note in the test package that neither struct is exposed to the other
> > translation unit.
> 
> But it's violation of C++ ODR and as LTO compilation unit is entire program,
> you then introduce violation.

I respectfully disagree.

Unless the source code itself changes, toggling LTO shouldn't affect generated
warnings.

It may be one /compilation/ unit, but by the standard they still count as
separate translation units.  LTO is an artifact of the compiler and not the
standard so it shouldn't have an impact on ODR warnings.

[Bug tree-optimization/87913] New: max(n, 1) code generation

[hoganmeier at gmail dot com]

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

Bug ID: 87913
   Summary: max(n, 1) code generation
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hoganmeier at gmail dot com
  Target Milestone: ---

unsigned int f(unsigned int num)
{
return num < 1 ? 1 : num;
}

int f2(int num)
{
return num < 1 ? 1 : num;
}

unsigned int g(unsigned int num)
{
return num + !num;
}

$ gcc -O3

f(unsigned int):
mov eax, edi
testedi, edi
mov edx, 1
cmove   eax, edx
f2(int):
testedi, edi
mov eax, 1
cmovg   eax, edi
g(unsigned int):
xor eax, eax
testedi, edi
seteal
add eax, edi

f and g could be:
f:  testedi, edi
mov eax, 1
cmovne  eax, edi
g:  cmp edi, 1
adc edi, 0
mov eax, edi

https://godbolt.org/z/YJWjsQ

[Bug target/87793] [8/9 Regression] GCC reports error when compiling with "-fpic -Os -g"

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #2 from Alexandre Oliva  ---
Mine

[Bug c++/41958] [c++0x] bogus variadic partial ordering code

[frankhb1989 at gmail dot com]

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

frankhb1989 at gmail dot com changed:

   What|Removed |Added

 CC||frankhb1989 at gmail dot com

--- Comment #10 from frankhb1989 at gmail dot com ---
The example from IS [temp.func.order]/5 (introduced by
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3281.pdf) still fails.

As per https://godbolt.org/z/6wq5Hx (from
https://www.zhihu.com/question/55055208/answer/142424499), 4.6.4 is OK, but
4.7.1 is nonconforming.

Not sure which change cause the behavior divergence; please confirm.

(BTW, the original issue asked in the post is about PR 33807. It seems
innocent. MSVC 15.8.2 does not have the operator== for allocator; not sure
it is correct, but MSVC does reject the example in this issue correctly.
Nevertheless, I wonder the status of LWG 2472 and whether the resolution of LWG
280 have some related effects.)

[Bug other/87909] Undocumented option -f{,no-}tree-cselim

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-06
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.

[Bug c/87911] OpenACC/OpenMP clauses parsing: comma operator vs. separator

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
In OpenMP 5.0 this got clarified, in C/C++ all expressions with just very few
exceptiosn in the grammar in clauses are assignment-expression.  I'll change it
this week.

[Bug c/87912] New: ICE with comma operator in C OpenACC async clause

[tschwinge at gcc dot gnu.org]

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

Bug ID: 87912
   Summary: ICE with comma operator in C OpenACC async clause
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, openacc
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

void f()
{
#pragma acc parallel async (1, 2)
  ;
}

C:

#1  0x00a35cba in gimplify_expr
(expr_p=expr_p@entry=0x767bd078, pre_p=pre_p@entry=0x7fffbde0,
post_p=0x7fffb8e0, post_p@entry=0x0, gimple_test_f=0x9ebda0
, fallback=fallback@entry=1) at [...]/gcc/gimplify.c:12357
#2  0x00a2598b in gimplify_scan_omp_clauses
(list_p=list_p@entry=0x768e0c78, pre_p=pre_p@entry=0x7fffbde0,
region_type=region_type@entry=ORT_ACC_PARALLEL, code=) at
[...]/gcc/gimplify.c:8496
#3  0x00a392f6 in gimplify_omp_workshare
(expr_p=expr_p@entry=0x76907b90, pre_p=pre_p@entry=0x7fffbde0) at
[...]/gcc/gimplify.c:10859
#4  0x00a34648 in gimplify_expr (expr_p=0x76907b90,
pre_p=pre_p@entry=0x7fffbde0, post_p=0x7fffbc80, post_p@entry=0x0,
gimple_test_f=gimple_test_f@entry=0xa1c730 ,
fallback=fallback@entry=0) at [...]/gcc/gimplify.c:12113
#5  0x00a37f47 in gimplify_stmt
(stmt_p=stmt_p@entry=0x76907b90, seq_p=seq_p@entry=0x7fffbde0) at
[...]/gcc/gimplify.c:6614
#6  0x00a3aa26 in gimplify_bind_expr
(expr_p=expr_p@entry=0x768e75c0, pre_p=pre_p@entry=0x7fffbfe8) at
[...]/gcc/gimplify.c:1331
#7  0x00a3518e in gimplify_expr (expr_p=0x768e75c0,
pre_p=pre_p@entry=0x7fffbfe8, post_p=0x7fffbea0, post_p@entry=0x0,
gimple_test_f=gimple_test_f@entry=0xa1c730 ,
fallback=fallback@entry=0) at [...]/gcc/gimplify.c:11805
#8  0x00a37f47 in gimplify_stmt
(stmt_p=stmt_p@entry=0x768e75c0, seq_p=seq_p@entry=0x7fffbfe8) at
[...]/gcc/gimplify.c:6614
#9  0x00a3b748 in gimplify_body
(fndecl=fndecl@entry=0x768e7500, do_parms=do_parms@entry=true) at
[...]/gcc/gimplify.c:12805
#10 0x00a3bc95 in gimplify_function_tree (fndecl=0x768e7500) at
[...]/gcc/gimplify.c:12949
#11 0x00855fe8 in cgraph_node::analyze
(this=this@entry=0x767ab2d0) at [...]/gcc/cgraphunit.c:667
#12 0x008594b0 in analyze_functions
(first_time=first_time@entry=true) at [...]/gcc/cgraphunit.c:1126
#13 0x0085a2f3 in symbol_table::finalize_compilation_unit
(this=0x767ac100) at [...]/gcc/cgraphunit.c:2833
#14 0x00d3430d in compile_file () at [...]/gcc/toplev.c:480
#15 0x006952d5 in do_compile () at [...]/gcc/toplev.c:2172
#16 toplev::main (this=this@entry=0x7fffc250, argc=argc@entry=33,
argv=argv@entry=0x7fffc358) at [...]/gcc/toplev.c:2307
#17 0x00698bf7 in main (argc=33, argv=0x7fffc358) at
[...]/gcc/main.c:39

That's most likely gcc/c/c-parser.c:c_parser_oacc_clause_async not doing the
right thing; compare to how other similar clauses are handled.

C++:

source-gcc/gcc/testsuite/c-c++-common/goacc/asyncwait-1_.c: In function
'void f()':
source-gcc/gcc/testsuite/c-c++-common/goacc/asyncwait-1_.c:3:32: warning:
left operand of comma operator has no effect [-Wunused-value]
3 | #pragma acc parallel async (1, 2)
  |^

(As discussed in PR87911.)

[Bug c/87911] New: OpenACC/OpenMP clauses parsing: comma operator vs. separator

[tschwinge at gcc dot gnu.org]

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

Bug ID: 87911
   Summary: OpenACC/OpenMP clauses parsing: comma operator vs.
separator
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

All over OpenACC/OpenMP clauses parsing we sometimes diagnose "warning: left
operand of comma operator has no effect" (C) or "warning: left-hand operand of
comma expression has no effect" (C++) vs. "error: expected ')' before ','
token".  For example:

void f()
{
#pragma omp parallel num_threads (3, 4)
  ;

#pragma omp target device (5, 6)
  ;
}

C:

../oo.c: In function 'f':
../oo.c:3:36: warning: left-hand operand of comma expression has no effect
[-Wunused-value]
3 | #pragma omp parallel num_threads (3, 4)
  |^
../oo.c:6:29: error: expected ')' before ',' token
6 | #pragma omp target device (5, 6)
  |   ~ ^
  | )

C++:

../oo.c: In function 'void f()':
../oo.c:3:38: warning: left operand of comma operator has no effect
[-Wunused-value]
3 | #pragma omp parallel num_threads (3, 4)
  |  ^
../oo.c:6:31: warning: left operand of comma operator has no effect
[-Wunused-value]
6 | #pragma omp target device (5, 6)
  |   ^

I see how this is happening in the front ends.

Note that at least for OpenACC there are certain clauses that do need the comma
as separator, for they accept several expressions: "wait (1, 2, 3)", for
example.  Is there any good reason that the single-argument clauses should use
the comma operator semantics (consistently)?  I have not verified the
OpenACC/OpenMP standards, but I suppose user expectation would be to diagnose
all these as syntax errors?  (Jakub?)

(Also note how the caret location is different for C and C++, and not quite
right for both.  But that seems to be a general problem, also seen for "return
1, 2;", for example.)

[Bug c++/87910] New: Missing typename/template not diagnosed

[mpolacek at gcc dot gnu.org]

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

Bug ID: 87910
   Summary: Missing typename/template not diagnosed
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

While working on P0634 I noticed that the following testcase is accepted while
it probably shouldn't be:

template struct A {
  template struct B;
  template using C = U;
};

template A::B f1();
template A::C f2();

The dependent names "A::B" should be prefixed by the typename keyword,
and the template keyword should come after ::.

With P0634 that typename will no longer be required[*] but I think it still
requires "::template".

[*] it is a decl-specifier of the decl-specifier-seq of a simple-declaration or
a function-definition in namespace scope

[Bug libstdc++/87872] debug list::splice should not call _M_transfer_from_if on self-splices

[fdumont at gcc dot gnu.org]

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

--- Comment #4 from François Dumont  ---
Author: fdumont
Date: Tue Nov  6 20:20:06 2018
New Revision: 265851

URL: https://gcc.gnu.org/viewcvs?rev=265851=gcc=rev
Log:
2018-11-06  John Bytheway  

PR libstdc++/87872
* include/debug/safe_sequence.tcc
(_Safe_sequence<>::_M_transfer_from_if): Skip transfer to self.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/debug/safe_sequence.tcc

[Bug middle-end/87869] Unrolled loop leads to excessive code bloat with -Os on ARC EM.

[nbowler at draconx dot ca]

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

--- Comment #5 from Nick Bowler  ---
Looking at some of my other code output, it looks that these long encodings are
emitted a lot more frequently than it would seem they are needed.

If shorter store encodings were used more generally then I'd expect to see
significant size improvements not just to the test case under discussion here
but to that other code as well.

[Bug rtl-optimization/87902] [9 Regression] Shrink-wrapping multiple conditions

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
So why does it use r12 there if it could use r2?  That's an RA problem.
This is related to PR87708, in a way.

prepare_shrinkwrap needs a good overhaul.  Moving all copies down also
*degrades* code quality, more often if you don't restrict it to the
first BB.

[Bug bootstrap/61164] GCC 4.9.0 fails to build libitm when fortification enabled

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #7 from Martin Sebor  ---
(In reply to Romain Naour from comment #6)

GCC 4 and 5 (and even 6) branches are no longer being maintained so the changes
cannot be backported to them.

[Bug middle-end/87886] ICE in format_helper, at real.h:227

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
It doesn't avoid the ICE but my latest patch for pr83656 at least diagnoses the
invalid call (see below).  The warning is predicated on the front-end
preserving the built-in property of the function despite the missing prototype.
 If the front-end were to treat the function as ordinary (as it does with sqrtf
because of pr87890), the warning for the call disappears in lieu of one for the
declaration.  In both cases, the undefined call is made at runtime.

For best results I think the front-end needs to preserve the fact that a
function is a built-in, not just so that invalid calls to it can be diagnosed
but also to make it possible for the middle-end to handle them in a safer way
(e.g., by replacing the undefined ones with a trap in response to some option,
as discussed at Cauldron).

$ cat t.c && /ssd/build/gcc-83656/gcc/xgcc -B /ssd/build/gcc-83656/gcc -S t.c
extern double sqrt ();

int f (int x)
{
  return sqrt (x);
}


extern float sqrtf ();

int g (int x)
{
  return sqrtf (x);
}

t.c: In function ‘f’:
t.c:5:16: warning: ‘sqrt’ argument 1 type is ‘int’ where ‘double’ is expected
in a call to built-in function declared without prototype
[-Wbuiltin-declaration-mismatch]
5 |   return sqrt (x);
  |^
t.c:1:15: note: built-in ‘sqrt’ declared here
1 | extern double sqrt ();
  |   ^~~~
t.c: At top level:
t.c:9:14: warning: conflicting types for built-in function ‘sqrtf’; expected
‘float(float)’ [-Wbuiltin-declaration-mismatch]
9 | extern float sqrtf ();
  |  ^
t.c:1:1: note: ‘sqrtf’ is declared in header ‘’
  +++ |+#include 
1 | extern double sqrt ();

[Bug tree-optimization/83648] missing -Wsuggest-attribute=malloc on a trivial malloc-like function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||9.0
 Resolution|--- |FIXED
   Target Milestone|--- |9.0
  Known to fail||8.2.0

--- Comment #5 from Martin Sebor  ---
GCC 9 reports both functions in the test case in comment #0 as candidates for
attribute malloc.  Resolving as fixed.

[Bug other/87909] New: Undocumented option -f{,no-}tree-cselim

[asolokha at gmx dot com]

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

Bug ID: 87909
   Summary: Undocumented option -f{,no-}tree-cselim
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

The -f{,no-}tree-cselim option was introduced ages ago (more than a decade?).
However, it still seems to be undocumented in the user's manual as of the
current top of trunk.

[Bug tree-optimization/87900] malloc + memset to calloc doesn't work for aggregate initialization

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-06
 CC||msebor at gcc dot gnu.org
 Blocks||83819
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  Below is an enhanced test case and the output:

$ cat u.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout u.c
struct S { int a[1024]; };

struct S *foo ()   // not transformed
{
  struct S *p = (struct S *)__builtin_malloc (sizeof (struct S));
  *p = (struct S){};
  return p;
}

struct S *bar ()   // transformed into calloc()
{
  struct S *p = (struct S *)__builtin_malloc (sizeof (struct S));
  __builtin_memset (p, 0, sizeof *p);
  return p;
}


;; Function foo (foo, funcdef_no=0, decl_uid=1907, cgraph_uid=1,
symbol_order=0)

foo ()
{
  struct S * p;

   [local count: 1073741824]:
  p_3 = __builtin_malloc (4096);
  *p_3 = {};
  return p_3;

}



;; Function bar (bar, funcdef_no=1, decl_uid=1911, cgraph_uid=2,
symbol_order=1)

bar ()
{
  struct S * p;

   [local count: 1073741824]:
  p_3 = __builtin_calloc (4096, 1); [tail call]
  return p_3;

}


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
[Bug 83819] [meta-bug] missing strlen optimizations

[Bug tree-optimization/87901] partial DSE of memset doesn't work for other kind of stores

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor  ---
The example is undefined -- it forms a past the-end pointer -- and
-Warray-bounds detects it:

warning: array subscript 2 is outside array bounds of ‘int[1]’ [-Warray-bounds]
6 |   *((short *) + sizeof (int) - sizeof (short)) = 1;

I don't suppose you meant to do that, but presumably meant to access a part of
the object.  But even then the code is undefined.

Can you explain/clarify what you have in mind and why it's important?

[Bug fortran/87908] ICE in check_interface0, at fortran/interface.c:1841

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-06
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
> ICE affects versions 8/9 :

For gcc7 I see

(null):0: confused by earlier errors, bailing out

which is equivalent to an ICE when gcc is configured with
--enable-checking=release

gcc6 gives

pr87908.f90:6:21:

   generic :: read(formatted) => g
 1
Error: Expected '=>' at (1)
pr87908.f90:12:20:

   interface read(formatted)
1
Error: Syntax error: Trailing garbage in INTERFACE statement at (1)
pr87908.f90:13:9:

  procedure g
 1
Error: Unclassifiable statement at (1)
pr87908.f90:14:9:

   end interface
 1
Error: Expecting END SUBROUTINE statement at (1)

Compiling the test with an instrumented compiler gives

=
==69263==ERROR: AddressSanitizer: heap-use-after-free on address 0x61309e14
at pc 0x000100170f91 bp 0x7ffeefbfe5f0 sp 0x7ffeefbfe5e8
READ of size 1 at 0x61309e14 thread T0
#0 0x100170f90 in check_interface0(gfc_interface*, char const*)
interface.c:1836
#1 0x10018e217 in check_sym_interfaces(gfc_symbol*) interface.c:1974
#2 0x1004bb14d in do_traverse_symtree(gfc_symtree*, void (*)(gfc_symtree*),
void (*)(gfc_symbol*)) symbol.c:4151
#3 0x1004d8313 in gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*))
symbol.c:4176
#4 0x10019595f in gfc_check_interfaces(gfc_namespace*) interface.c:2085
#5 0x100438af2 in resolve_types(gfc_namespace*) resolve.c:16643
#6 0x100438903 in resolve_types(gfc_namespace*) resolve.c:16638
#7 0x1003cabe0 in gfc_resolve(gfc_namespace*) resolve.c:16741
#8 0x10034f049 in gfc_parse_file() parse.c:6266
#9 0x100522fbf in gfc_be_parse_file() f95-lang.c:204
#10 0x10611cde8 in compile_file() toplev.c:455
#11 0x1061284a3 in do_compile() toplev.c:2172
#12 0x10915f5d7 in toplev::main(int, char**) toplev.c:2307
#13 0x1095b359c in main main.c:39
#14 0x7fff703f908c in start (libdyld.dylib:x86_64+0x1708c)

0x61309e14 is located 84 bytes inside of 344-byte region
[0x61309dc0,0x61309f18)
freed by thread T0 here:
#0 0x158cb18e0 in wrap_free.part.0 sanitizer_malloc_mac.inc:121
#1 0x1004d7a4a in gfc_free_symbol(gfc_symbol*) symbol.c:3081
#2 0x1004d7d96 in gfc_release_symbol(gfc_symbol*) symbol.c:3108
#3 0x10034 in gfc_fixup_sibling_symbols(gfc_symbol*, gfc_namespace*)
parse.c:5485
#4 0x10034d679 in parse_contained(int) parse.c:5577
#5 0x10034e74e in parse_module() parse.c:5943
#6 0x10034f77e in gfc_parse_file() parse.c:6239
#7 0x100522fbf in gfc_be_parse_file() f95-lang.c:204
#8 0x10611cde8 in compile_file() toplev.c:455
#9 0x1061284a3 in do_compile() toplev.c:2172
#10 0x10915f5d7 in toplev::main(int, char**) toplev.c:2307
#11 0x1095b359c in main main.c:39
#12 0x7fff703f908c in start (libdyld.dylib:x86_64+0x1708c)

previously allocated by thread T0 here:
#0 0x158cb0db3 in wrap_calloc sanitizer_malloc_mac.inc:132
#1 0x10869f9ea in xcalloc xmalloc.c:162
#2 0x1004cf141 in gfc_new_symbol(char const*, gfc_namespace*) symbol.c:3117
#3 0x1004d16cf in gfc_get_sym_tree(char const*, gfc_namespace*,
gfc_symtree**, bool) symbol.c:3369
#4 0x1004d2cfd in gfc_get_symbol(char const*, gfc_namespace*, gfc_symbol**)
symbol.c:3419
#5 0x1000b22c2 in match_procedure_in_interface() decl.c:6912
#6 0x1000ef830 in gfc_match_procedure() decl.c:6952
#7 0x100330018 in match_word(char const*, match (*)(), locus*) parse.c:65
#8 0x10033da46 in decode_statement() parse.c:541
#9 0x10033eef6 in next_free() parse.c:1234
#10 0x10033f8cb in next_statement() parse.c:1466
#11 0x1003473bb in parse_interface() parse.c:3455
#12 0x100345f9f in parse_spec(gfc_statement) parse.c:3810
#13 0x10034cbfa in parse_progunit(gfc_statement) parse.c:5671
#14 0x10034d622 in parse_contained(int) parse.c:5574
#15 0x10034e74e in parse_module() parse.c:5943
#16 0x10034f77e in gfc_parse_file() parse.c:6239
#17 0x100522fbf in gfc_be_parse_file() f95-lang.c:204
#18 0x10611cde8 in compile_file() toplev.c:455
#19 0x1061284a3 in do_compile() toplev.c:2172
#20 0x10915f5d7 in toplev::main(int, char**) toplev.c:2307
#21 0x1095b359c in main main.c:39
#22 0x7fff703f908c in start (libdyld.dylib:x86_64+0x1708c)

SUMMARY: AddressSanitizer: heap-use-after-free interface.c:1836 in
check_interface0(gfc_interface*, char const*)
Shadow bytes around the buggy address:
  0x1c261370: fd fd fd fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c261380: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 

[Bug fortran/87908] New: ICE in check_interface0, at fortran/interface.c:1841

[gs...@t-online.de]

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

Bug ID: 87908
   Summary: ICE in check_interface0, at fortran/interface.c:1841
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

ICE affects versions 8/9 :


$ cat z1.f90
module m
   type t
  character :: c
   contains
  procedure :: g
  generic :: read(formatted) => g
   end type
contains
   subroutine s (unit, x)
  integer, intent(in) :: unit
  integer, intent(in) :: x(:)
  interface read(formatted)
 procedure g
  end interface
   end
   subroutine g (dtv, unit, iotype, v_list, iostat, iomsg)
  class(t), intent(inout) :: dtv
  integer, intent(in) :: unit
  character(*), intent(in) :: iotype
  integer, intent(in) :: v_list(:)
  integer, intent(out) :: iostat
  character(*), intent(inout) :: iomsg
  read (unit, '(a)', iostat=iostat, iomsg=iomsg) dtv%c
   end
end


$ gfortran-9-20181104 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb205df crash_signal
../../gcc/toplev.c:325
0x623c67 check_interface0
../../gcc/fortran/interface.c:1841
0x627694 check_sym_interfaces
../../gcc/fortran/interface.c:1974
0x6a9d12 do_traverse_symtree
../../gcc/fortran/symbol.c:4151
0x62a6c0 gfc_check_interfaces(gfc_namespace*)
../../gcc/fortran/interface.c:2085
0x68133d resolve_types
../../gcc/fortran/resolve.c:16635
0x681310 resolve_types
../../gcc/fortran/resolve.c:16630
0x68613c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16733
0x673d02 gfc_parse_file()
../../gcc/fortran/parse.c:6266
0x6bc03f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug middle-end/28205] Request an option to make -finstrument-functions not apply to inlined function calls

[joev.dubach at nuance dot com]

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

--- Comment #4 from Joev Dubach  ---
clang 7.0.0 now has the option -finstrument-functions-after-inlining (see
https://reviews.llvm.org/D39331 ), which is the same feature I asked for in
this bug. It'd be great if gcc could add this option too!

[Bug fortran/87907] New: ICE in resolve_contained_fntype, at fortran/resolve.c:587

[gs...@t-online.de]

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

Bug ID: 87907
   Summary: ICE in resolve_contained_fntype, at
fortran/resolve.c:587
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With an interface mismatch since version 6 :


$ cat z1.f90
module m
   interface
  module function g(x) result(z)
 integer, intent(in) :: x
 integer, allocatable :: z
  end
   end interface
end
submodule(m) m2
contains
   subroutine g(x)
   end
end
program p
   use m
   integer :: x = 3
   call g(x)
end


$ gfortran-9-20181104 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb205df crash_signal
../../gcc/toplev.c:325
0x67a9fc resolve_contained_fntype
../../gcc/fortran/resolve.c:587
0x681156 resolve_contained_functions
../../gcc/fortran/resolve.c:1134
0x681156 resolve_types
../../gcc/fortran/resolve.c:16608
0x68613c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16733
0x673d02 gfc_parse_file()
../../gcc/fortran/parse.c:6266
0x6bc03f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/70070] ICE on initializing character data beyond min/max bound

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #8 from G. Steinmetz  ---

All the above cases do not seem to cause an ICE anymore,
unfortunately there are a few more cases using other numbers :


$ cat za.f90
program p
   character(23) :: c
   data (c(i:i), i=1,123) /123*'#'/
end


$ gfortran-9-20181104 -c za.f90
*** Error in `../x86_64-pc-linux-gnu/9.0.0/f951': free(): invalid next size
(fast): 0x02450790 ***
during IPA pass: inline
za.f90:4:0:

4 | end
  |
internal compiler error: Aborted
0xb205df crash_signal
../../gcc/toplev.c:325
0x12703df ipa_inline
../../gcc/ipa-inline.c:2508
0x12703df execute
../../gcc/ipa-inline.c:2919


$ gfortran-9-20181104-chk -c za.f90
*** Error in `../x86_64-pc-linux-gnu/9.0.0/f951': free(): invalid next size
(fast): 0x028fb790 ***
during GIMPLE pass: cfg
za.f90:4:0:

4 | end
  |
internal compiler error: Aborted
0xc78e8f crash_signal
../../gcc/toplev.c:325
0x7f2a3c verify_flow_info()
../../gcc/cfghooks.c:259
0xcd0db7 checking_verify_flow_info
../../gcc/cfghooks.h:198
0xcd0db7 cleanup_tree_cfg_noloop
../../gcc/tree-cfgcleanup.c:938
0xcd0db7 cleanup_tree_cfg()
../../gcc/tree-cfgcleanup.c:989
0xccbc2c execute_build_cfg
../../gcc/tree-cfg.c:415
0xccbc2c execute
../../gcc/tree-cfg.c:444

[Bug fortran/87881] gfortran.dg/inquiry_type_ref_(1.f08|3.f90) fail on darwin

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> First, I have tested the patch at
> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44892
> with the test in pr40196 comment 9 without seeing any problem.
> So it seems that the problem has been introduced/uncovered by the subsequent
> changes.

Confirmed for the first test in comment 2 for which the ICE appears with the
patch at
https://gcc.gnu.org/ml/fortran/2018-10/msg00115.html.

The ICE for the second test in comment 2 was already present with the first
patch.

[Bug middle-end/87899] [9 regression]r264897 cause mis-compiled native arm-linux-gnueabihf toolchain

[renlin at gcc dot gnu.org]

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

--- Comment #3 from Renlin Li  ---
(In reply to Renlin Li from comment #1)
> in tree-loop-distribution.c, distribution_loop function, I got the following
> code snippets.
> 
>  30386: 0103cff4 4 OBJECT  LOCAL  DEFAULT   25 _ZL23bb_top_order_index_s
>  30387: 0103cff8 4 OBJECT  LOCAL  DEFAULT   25 _ZL18bb_top_order_index
>  30388: 0103cffc 4 OBJECT  LOCAL  DEFAULT   25 _ZL10ddrs_table
>  30389: 0103d000 4 OBJECT  LOCAL  DEFAULT   25 _ZL9loop_nest
>  30390: 0103d004 4 OBJECT  LOCAL  DEFAULT   25 _ZL12datarefs_vec
> 
> 
> r1 = 0x103cff4, which points to the local anchor area.
> r4 is the dynamically allocated has_table pointer which supposed to be store
> into ddrs_table, i.e. 0103cffc.
> 
>0x61a346 ,
> control_dependences*, int*, bool*)+90>:  strbr7, [r2, #0]
>0x61a348 ,
> control_dependences*, int*, bool*)+92>:  str.w   r7, [r8]
> 1=>0x61a34c ,
> control_dependences*, int*, bool*)+96>:  str.w   r7, [r1, #12]!
>0x61a350 ,
> control_dependences*, int*, bool*)+100>: mov r5, r1
> 2=>0x61a352 ,
> control_dependences*, int*, bool*)+102>: str r4, [r1, #8]
>0x61a354 ,
> control_dependences*, int*, bool*)+104>: str r0, [r4, #0]
>0x61a356 ,
> control_dependences*, int*, bool*)+106>: mov r0, r9
> 
> However, r1 is changed by the previous pre-indexed store at 0x61a34c (marked
> as 1).
> This makes the store later store the pointer in the wrong position.
> Later when accessing ddrs_table, it got a null pointer, eventually resulting
> in the ICE observed here.
> 
> The full assembly is attached.


Before the change:

 0x0061a746 <+26>:bl  0xc86134 
   0x0061a74a <+30>:movwr2, #57316  ; 0xdfe4
   0x0061a74e <+34>:movtr2, #259; 0x103
   0x0061a752 <+38>:str r2, [sp, #28]
   0x0061a754 <+40>:mov r4, r0
   0x0061a756 <+42>:movwr0, #389; 0x185
   0x0061a75a <+46>:str r7, [r4, #8]
   0x0061a75c <+48>:str r7, [r4, #12]
   0x0061a75e <+50>:strdr7, r7, [r4, #16]
   0x0061a762 <+54>:strhr7, [r4, #28]
   0x0061a764 <+56>:bl  0xc2bc50

   0x0061a768 <+60>:movwr3, #8452   ; 0x2104
   0x0061a76c <+64>:movtr3, #242; 0xf2
   0x0061a770 <+68>:lslsr2, r0, #4
   0x0061a772 <+70>:mov r5, r0
   0x0061a774 <+72>:mov r0, r4
   0x0061a776 <+74>:ldr r6, [r3, r2]
   0x0061a778 <+76>:mov r1, r6
   0x0061a77a <+78>:bl  0x61d1b4 ::alloc_entries(unsigned int) const>
   0x0061a77e <+82>:ldr.w   r12, [sp, #28]
   0x0061a782 <+86>:ldr r2, [sp, #296]  ; 0x128
   0x0061a784 <+88>:str r5, [r4, #24]
   0x0061a786 <+90>:mov r1, r12
   0x0061a788 <+92>:str r6, [r4, #4]
   0x0061a78a <+94>:strbr7, [r2, #0]
   0x0061a78c <+96>:mov r5, r12
   0x0061a78e <+98>:str.w   r7, [r8]
   0x0061a792 <+102>:   str.w   r7, [r1, #12]!
   0x0061a796 <+106>:   str.w   r4, [r12, #8]

We can see that, r4 is store in [r12+8], not using the updated r1 above.

[Bug sanitizer/87884] ubsan causes wrong -Wformat-overflow warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=82076,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79265
 Ever confirmed|0   |1

--- Comment #4 from Martin Sebor  ---
The sanitizer inserts a lot of tests some of which then interfere with
subsequent analyses (for some related examples, see pr82076 and pr79265). 
Ideally, it would be possible to use both the sanitizer and late warnings at
the same time, but we're not there yet.  Until then, the guidance has been to
avoid mixing the two.  Let me add something to the manual.

I agree that the null destination pointer warning should be controlled by an
option separate from -Wformat-overflow such as -Wnonnull.  That should make it
easier to avoid the sanitizer problem.  Let me adjust that.

[Bug middle-end/87899] [9 regression]r264897 cause mis-compiled native arm-linux-gnueabihf toolchain

[renlin at gcc dot gnu.org]

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

--- Comment #2 from Renlin Li  ---
Created attachment 44965
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44965=edit
disassembly of distribute_loop

disassembly of wrongly compiled distribute_loop function

[Bug middle-end/87899] [9 regression]r264897 cause mis-compiled native arm-linux-gnueabihf toolchain

[renlin at gcc dot gnu.org]

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

--- Comment #1 from Renlin Li  ---

in tree-loop-distribution.c, distribution_loop function, I got the following
code snippets.

 30386: 0103cff4 4 OBJECT  LOCAL  DEFAULT   25 _ZL23bb_top_order_index_s
 30387: 0103cff8 4 OBJECT  LOCAL  DEFAULT   25 _ZL18bb_top_order_index
 30388: 0103cffc 4 OBJECT  LOCAL  DEFAULT   25 _ZL10ddrs_table
 30389: 0103d000 4 OBJECT  LOCAL  DEFAULT   25 _ZL9loop_nest
 30390: 0103d004 4 OBJECT  LOCAL  DEFAULT   25 _ZL12datarefs_vec


r1 = 0x103cff4, which points to the local anchor area.
r4 is the dynamically allocated has_table pointer which supposed to be store
into ddrs_table, i.e. 0103cffc.

   0x61a346 ,
control_dependences*, int*, bool*)+90>:  strbr7, [r2, #0]
   0x61a348 ,
control_dependences*, int*, bool*)+92>:  str.w   r7, [r8]
1=>0x61a34c ,
control_dependences*, int*, bool*)+96>:  str.w   r7, [r1, #12]!
   0x61a350 ,
control_dependences*, int*, bool*)+100>: mov r5, r1
2=>0x61a352 ,
control_dependences*, int*, bool*)+102>: str r4, [r1, #8]
   0x61a354 ,
control_dependences*, int*, bool*)+104>: str r0, [r4, #0]
   0x61a356 ,
control_dependences*, int*, bool*)+106>: mov r0, r9

However, r1 is changed by the previous pre-indexed store at 0x61a34c (marked as
1).
This makes the store later store the pointer in the wrong position.
Later when accessing ddrs_table, it got a null pointer, eventually resulting in
the ICE observed here.

The full assembly is attached.

[Bug tree-optimization/86850] ubsan: runtime error: member call on null pointer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||9.0
 Resolution|--- |FIXED

--- Comment #10 from Richard Biener  ---
Fixed on trunk.

[Bug tree-optimization/86850] ubsan: runtime error: member call on null pointer

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Tue Nov  6 15:46:42 2018
New Revision: 265848

URL: https://gcc.gnu.org/viewcvs?rev=265848=gcc=rev
Log:
2018-11-06  Richard Biener  

PR tree-optimization/86850
* vec.h (vec::splice): Check src.length ()
instead of src.m_vec.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/vec.h

[Bug c++/87897] [9 Regression] ICE in maybe_constant_value, at cp/constexpr.c:5255 since r265788

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-06
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Confirmed.

[Bug lto/87906] [9 Regression] ICE in tree check: expected block, have function_decl in block_ultimate_origin, at tree.c:12326 since r264734

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Iff we are sure abstract origin and BLOCK are never in the same SCC we can
fixup
during stream-in, but it's still somewhat ugly and it feels that we are losing
some debug info here (which clone we inlined).

diff --git a/gcc/tree-streamer-in.c b/gcc/tree-streamer-in.c
index bd98ed0b128..50433bf925c 100644
--- a/gcc/tree-streamer-in.c
+++ b/gcc/tree-streamer-in.c
@@ -915,6 +915,8 @@ lto_input_ts_block_tree_pointers (struct lto_input_block
*ib,

   BLOCK_SUPERCONTEXT (expr) = stream_read_tree (ib, data_in);
   BLOCK_ABSTRACT_ORIGIN (expr) = stream_read_tree (ib, data_in);
+  if (DECL_P (BLOCK_ORIGIN (expr)))
+BLOCK_ABSTRACT_ORIGIN (expr) = DECL_ORIGIN (BLOCK_ABSTRACT_ORIGIN (expr));
   /* Do not stream BLOCK_NONLOCALIZED_VARS.  We cannot handle debug
information
  for early inlined BLOCKs so drop it on the floor instead of ICEing in
  dwarf2out.c.  */

when we'd stream this reference as DIE we would get away.  But of course
esp. the FUNCTION_DECLs referenced as part of the inline BLOCKs are very
hard to get rid of (BLOCKs as abstract origin not so).  And this isn't
stage1 material anymore I fear.

[Bug c++/87882] -Wredundant-move false positive

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |9.0

[Bug c++/87904] [9 Regression] ICE in lookup_mark, at cp/tree.c:2322 since r265679

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-06
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug lto/87906] [9 Regression] ICE in tree check: expected block, have function_decl in block_ultimate_origin, at tree.c:12326 since r264734

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Ah, so the assert is somewhat bogus if it triggers:

12324 gcc_checking_assert ((DECL_P (origin)
12325   && DECL_ORIGIN (origin) == origin)
12326  || BLOCK_ORIGIN (origin) == origin);

when it's a DECL_P but DECL_ORIGIN is wrecked then we access a DECL as BLOCK.

(gdb) p origin
$3 = 
(gdb) p origin->decl_common.abstract_origin 
$4 = 

what this means is that when we do tree/decl merging we end up merging
sth with DECL_ORIGIN (x) == x to a prevailing node which does not
honor this property.  This makes

  BLOCK_ABSTRACT_ORIGIN (id->block) = DECL_ORIGIN (fn);

as set by the inliner not the ultimate origin and thus we ICE.

Indeed.

(gdb) commands 8
Type commands for breakpoint(s) 8, one per line.
End with a line saying just "end".
>p decl->decl_common.abstract_origin
>p prevailing->decl_common.abstract_origin
>end

Breakpoint 8, lto_symtab_prevail_decl (
prevailing=, 
decl=)
at /space/rguenther/src/gcc-slpcost/gcc/lto/lto-symtab.h:34
34gcc_checking_assert (! DECL_LANG_FLAG_0 (decl));
$3 = 
$4 = 

And that probably happens because of the ODR violation.

[Bug d/87866] gdc fails to compile minimal test

[ibuclaw at gdcproject dot org]

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

--- Comment #3 from Iain Buclaw  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #2)
> > --- Comment #1 from Iain Buclaw  ---
> > I backported a fix from the D sources so it should no longer segfault at 
> > least.
> 
> It doesn't indeed.
> 
> > From what I can see, it should pick up the object.d source correctly.
> >
> > -nostdinc -I /vol/gcc/src/hg/trunk/local/libphobos/libdruntime 
> >
> > Unless it really isn't in the -I path.
> 
> I've found what's going on:
> 
> When d-incpath.dd (add_globalpaths) calls into Filename::canonicalName
> (path), path is set correctly to the d21 -I arg:
> 
> 81const char *target = FileName::canonicalName (path);
> (gdb) p path
> $7 = 0x9f33878 "/vol/gcc/src/hg/trunk/local/libphobos/libdruntime"
> 
> (gdb) s
> 0x0833cea6 in FileName::canonicalName (
> name=0x9f33878 "/vol/gcc/src/hg/trunk/local/libphobos/libdruntime")
> at /vol/gcc/src/hg/trunk/local/gcc/d/dmd/root/filename.c:616
> 616 return realpath(name, NULL);
> (gdb) n
> 83if (target == NULL || !FileName::exists (target))
> (gdb) p target
> $8 = 0x0
> 
> However, canonicalPath returns with NULL.  I traced this to realpath(3C)
> on Solaris 10 behaving differently, as explained in the man page:
> 
>  bolic  links.  The  generated  pathname is stored as a null-
>  terminated string, up  to  a  maximum  of  {PATH_MAX}  bytes
>  (defined  in  limits.h(3HEAD)),  in the buffer pointed to by
>  resolved_name.
> 
> RETURN VALUES
>  On successful completion, realpath() returns  a  pointer  to
>  the  resolved  name.   Otherwise,  realpath() returns a null
>  pointer and sets errno to indicate the error, and  the  con-
>  tents  of the buffer pointed to by resolved_name are left in
>  an indeterminate state.
> 
> Unlike e.g. the Solaris 11.4 version, realpath doesn't allocate a buffer
> on it's own if the second arg is NULL, but given that it couldn't store
> the real path, returned NULL to indicate that failure.
> 
>   Rainer

OK, I guess I should be using libiberty here instead of the front-end's
provided FileName functions here, and probably in other places.

[Bug lto/87906] [9 Regression] ICE in tree check: expected block, have function_decl in block_ultimate_origin, at tree.c:12326 since r264734

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Better test-cases that do not violate ODR:

$ cat 1.ii
namespace com {
namespace sun {
namespace star {}
} // namespace sun
} // namespace com
namespace a = com::sun::star;
namespace com {
namespace sun {
namespace star {
namespace uno {
class a {
public:
  ~a();
};

class b {
public:
  ~b();
  a c;
};
class c {
  b e;
};
class RuntimeException : b {};
} // namespace uno
} // namespace star
} // namespace sun
} // namespace com
template  void d(int) { throw a::uno::RuntimeException(); }
int f;
void g() { d(f); }

$ cat 2.ii
namespace com {
namespace sun {
namespace star {
namespace uno {
class a {
public:
  ~a();
};
class b {
  a c;
};
class RuntimeException : b {};
} // namespace uno
class C : uno::RuntimeException {};
} // namespace star
} // namespace sun
} // namespace com
using com::sun::star::C;
using com::sun::star::uno::RuntimeException;
void d() { throw RuntimeException(); }
void e() { C(); }

[Bug lto/87905] structures in two different cpp source files with same name get flagged by ODR warning

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
As a workaround wrap the offending code in an anonymous namespace.

[Bug rtl-optimization/87902] [9 Regression] Shrink-wrapping multiple conditions

[iii at linux dot ibm.com]

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

--- Comment #1 from Ilya Leoshkevich  ---
Bisect points to r265398: combine: Do not combine moves from hard
registers.

I wonder what would be the best place to fix this?  I was thinking about
making shrink-wrapping try harder by not limiting the processing to the
first basic block.

[Bug d/87866] gdc fails to compile minimal test

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Iain Buclaw  ---
> I backported a fix from the D sources so it should no longer segfault at 
> least.

It doesn't indeed.

> From what I can see, it should pick up the object.d source correctly.
>
> -nostdinc -I /vol/gcc/src/hg/trunk/local/libphobos/libdruntime 
>
> Unless it really isn't in the -I path.

I've found what's going on:

When d-incpath.dd (add_globalpaths) calls into Filename::canonicalName
(path), path is set correctly to the d21 -I arg:

81const char *target = FileName::canonicalName (path);
(gdb) p path
$7 = 0x9f33878 "/vol/gcc/src/hg/trunk/local/libphobos/libdruntime"

(gdb) s
0x0833cea6 in FileName::canonicalName (
name=0x9f33878 "/vol/gcc/src/hg/trunk/local/libphobos/libdruntime")
at /vol/gcc/src/hg/trunk/local/gcc/d/dmd/root/filename.c:616
616 return realpath(name, NULL);
(gdb) n
83if (target == NULL || !FileName::exists (target))
(gdb) p target
$8 = 0x0

However, canonicalPath returns with NULL.  I traced this to realpath(3C)
on Solaris 10 behaving differently, as explained in the man page:

 bolic  links.  The  generated  pathname is stored as a null-
 terminated string, up  to  a  maximum  of  {PATH_MAX}  bytes
 (defined  in  limits.h(3HEAD)),  in the buffer pointed to by
 resolved_name.

RETURN VALUES
 On successful completion, realpath() returns  a  pointer  to
 the  resolved  name.   Otherwise,  realpath() returns a null
 pointer and sets errno to indicate the error, and  the  con-
 tents  of the buffer pointed to by resolved_name are left in
 an indeterminate state.

Unlike e.g. the Solaris 11.4 version, realpath doesn't allocate a buffer
on it's own if the second arg is NULL, but given that it couldn't store
the real path, returned NULL to indicate that failure.

Rainer

[Bug lto/87906] [9 Regression] ICE in tree check: expected block, have function_decl in block_ultimate_origin, at tree.c:12326 since r264734

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2018-11-6
 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Known to work||8.2.0
   Target Milestone|--- |9.0
  Known to fail||9.0

[Bug lto/87906] New: [9 Regression] ICE in tree check: expected block, have function_decl in block_ultimate_origin, at tree.c:12326 since r264734

[marxin at gcc dot gnu.org]

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

Bug ID: 87906
   Summary: [9 Regression] ICE in tree check: expected block, have
function_decl in block_ultimate_origin, at
tree.c:12326 since r264734
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Following 2 files cause an ICE:

$ cat 1.ii
namespace com {
namespace sun {
namespace star {}
} // namespace sun
} // namespace com
namespace a = com::sun::star;
namespace com {
namespace sun {
namespace star {
namespace uno {
class b {
public:
  ~b();
};
class c {
  b e;
};
class RuntimeException : c {};
} // namespace uno
} // namespace star
} // namespace sun
} // namespace com
template  void d(int) { throw a::uno::RuntimeException(); }
int f;
void g() { d(f); }

$ cat 2.ii
namespace com {
namespace sun {
namespace star {
namespace uno {
class a {
public:
  ~a();
};
class b {
  a c;
};
class RuntimeException : b {};
} // namespace uno
class C : uno::RuntimeException {};
} // namespace star
} // namespace sun
} // namespace com
using com::sun::star::C;
using com::sun::star::uno::RuntimeException;
void d() { throw RuntimeException(); }
void e() { C(); }

$ g++ [12].ii -O -shared -fPIC -flto
1.ii:11:7: warning: type ‘struct b’ violates the C++ One Definition Rule
[-Wodr]
   11 | class b {
  |   ^
1.ii:11:7: note: a different type is defined in another translation unit
2.ii:10:5: note: the first difference of corresponding definitions is field ‘c’
   10 |   a c;
  | ^
1.ii:11:7: note: a type with different number of fields is defined in another
translation unit
   11 | class b {
  |   ^
1.ii:18:7: warning: type ‘struct RuntimeException’ violates the C++ One
Definition Rule [-Wodr]
   18 | class RuntimeException : c {};
  |   ^
1.ii:18:7: note: a type with different bases is defined in another translation
unit
during GIMPLE pass: optimized
2.ii: In function ‘e’:
2.ii:21:6: internal compiler error: tree check: expected block, have
function_decl in block_ultimate_origin, at tree.c:12326
   21 | void e() { C(); }
  |  ^
0x7d56a6 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/marxin/Programming/gcc/gcc/tree.c:9544
0x7dca31 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/marxin/Programming/gcc/gcc/tree.h:3118
0x7dca31 block_ultimate_origin(tree_node const*)
/home/marxin/Programming/gcc/gcc/tree.c:12324
0x184709b inlined_polymorphic_ctor_dtor_block_p(tree_node*, bool)
/home/marxin/Programming/gcc/gcc/ipa-polymorphic-call.c:516
0x2a06f91 remove_unused_scope_block_p
/home/marxin/Programming/gcc/gcc/tree-ssa-live.c:420
0x2a074a5 remove_unused_scope_block_p
/home/marxin/Programming/gcc/gcc/tree-ssa-live.c:516
0x2a074a5 remove_unused_scope_block_p
/home/marxin/Programming/gcc/gcc/tree-ssa-live.c:516
0x2a0f17e remove_unused_locals()
/home/marxin/Programming/gcc/gcc/tree-ssa-live.c:896
0x1e65964 execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.c:1920
0x1e6709e execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:1996

[Bug lto/87905] structures in two different cpp source files with same name get flagged by ODR warning

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Martin Liška  ---
> 
> Note in the test package that neither struct is exposed to the other
> translation unit.

But it's violation of C++ ODR and as LTO compilation unit is entire program,
you then introduce violation.

[Bug sanitizer/87892] [9 Regression]: libsanitizer fails to build on CentOS 5.11 (glibc 2.5)

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Hints from Jakub:

 marxin: just look at libgomp sources, I have all kinds of stuff there
 jakub: ok, then let me fix that 
 marxin: sysconf(_SC_NPROCESSORS_ONLN) is a good fallback if the
affinity doesn't work
 note even the version they wrote is of course incorrect
 it will not work on machines where the cpuset is very large
 jakub: due to buffer(4096); ?
 marxin: cpu_set_t is fixed size
 marxin: newer glibcs provide APIs where one specifies the size
 jakub: ok
 marxin: if they don't want to use sysconf because it allocates memory,
then can read /proc/cpuinfo themselves
 jakub: they read /sys/devices/system/cpu instead
 marxin: they do that on android only; /sys is newer than /proc though
 marxin: in any case, CPU_COUNT, if missing, can be easily written using
__builtin_popcountl in a loop, see libgomp/config/linux/proc.c
(gomp_cpuset_popcount)
 but that assumption that sched_getaffinity will succeed is bogus, it
might fail because it isn't implemented, or may fail because the cpu_set_t is
too small
 marxin: then you can of course allocate using their allocators
something bigger and retry
 marxin: see also gomp_init_num_threads in the same file; while you
might avoid the sysconf if they don't want to call it at start, start with
cpu_set_t size
 thanks for hints
 just note that libgomp is GPL and libsanitizer is not, so copy'n'paste
is not allowed

[Bug sanitizer/87880] [9 regression] All macOS asan execution tests FAIL

[iains at gcc dot gnu.org]

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

--- Comment #6 from Iain Sandoe  ---
so I looked a little more at this.

As Rainer points out, the libsupc++ implementation does not provide
cxa_rethrow_primary_exception whereas the libc++-abi.dylib has it.

For the macOS implementations of libstdc.6.dylib and libc++.dylib the symbols
from libc++-abi are forwarded via the presented library.  For the GCC
implementation of libstdc++.dylib, the libsupc++ implementation is statically
linked into the library.

So - it seems that the build for libsanitiser is either resolving those symbols
accidentally from the /usr/lib/libstdc++.dylib (or has been constructed to
permit them to be unresolved at link time)

 - first case seems a build bug
 - second case they should be guarded by a check for presence at runtime (IIRC
there are already an number of symbols that are guarded this way).

Longer term:
1. we could add the cxa_rethrow_primary_exception to libsupc++ (will talk to
Jonathan about the implications of this)

2. We could split libstdc++ from libsupc++ on Darwin and have the option to
build the library on top of libc++abi (forwarding the symbols as the installed
system library does).

 - this is analogous to the need to forward to the unwinder implementation
which must always be provided by the shared /usr/lib/system impl on Darwin.

It's not 100% clear at the moment if there's state in the abi lib that would
mandate that action anyway.

At the Cauldron I talked to Jonathan about potentially doing this split, and he
didn't at that point have any objection.

[Bug sanitizer/87892] [9 Regression]: libsanitizer fails to build on CentOS 5.11 (glibc 2.5)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED

--- Comment #5 from Martin Liška  ---
Ok, sorry for bailing that too early..

[Bug lto/87905] structures in two different cpp source files with same name get flagged by ODR warning

[shentino at gmail dot com]

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

--- Comment #1 from Raymond Jennings  ---
just do g++ -flto *.cpp

[Bug sanitizer/87892] [9 Regression]: libsanitizer fails to build on CentOS 5.11 (glibc 2.5)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |---

--- Comment #4 from Jakub Jelinek  ---
While upstream is careless, we shouldn't be.
You can look e.g. at libgomp/config/linux/affinity.c for how to handle older
glibcs that don't define CPU_COUNT, or CPU_*_S, etc.

[Bug lto/87905] New: structures in two different cpp source files with same name get flagged by ODR warning

[shentino at gmail dot com]

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

Bug ID: 87905
   Summary: structures in two different cpp source files with same
name get flagged by ODR warning
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shentino at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 44964
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44964=edit
demonstrates the problem

This only happens when I enable -flto

Note in the test package that neither struct is exposed to the other
translation unit.

[Bug sanitizer/87884] ubsan causes wrong -Wformat-overflow warning

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #1)
> In general we have issues with warnings when sanitizers are used.
> Martin: What about notifying users that one should not combine sanitizers
> and warnings? It's becoming a very common issue.

We don't have issues with most of the warnings, the problems are mainly with
late warnings, FE warnings are mostly ok.  There are issues e.g. with warnings
that rely on VRP where the extra runtime checks added for sanitization will
cause fewer optimizations.  This case is I guess about thread jumping on the
NULL pointer checks.

[Bug tree-optimization/86850] ubsan: runtime error: member call on null pointer

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
> diff --git a/gcc/vec.h b/gcc/vec.h
> index f8c039754d2..407269c5ad3 100644
> --- a/gcc/vec.h
> +++ b/gcc/vec.h
> @@ -1688,7 +1688,7 @@ template
>  inline void
>  vec::splice (const vec )
>  {
> -  if (src.m_vec)
> +  if (src.length ())
>  m_vec->splice (*(src.m_vec));
>  }

I can confirm that ubsan GCC is not happy and no run-time error is reported.

[Bug sanitizer/87892] [9 Regression]: libsanitizer fails to build on CentOS 5.11 (glibc 2.5)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Martin Liška  ---
So it looks mainline is not interested in fixing support for 10 years old
glibc. I'm also not planning to fix that.

[Bug sanitizer/87884] ubsan causes wrong -Wformat-overflow warning

[stsp at users dot sourceforge.net]

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

--- Comment #2 from Stas Sergeev  ---
(In reply to Martin Liška from comment #1)
> In general we have issues with warnings when sanitizers are used.
More than that.
You also have a compile-time errors now!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87857
Which is completely unacceptable IMHO.

> Martin: What about notifying users that one should not combine sanitizers
> and warnings? It's becoming a very common issue.
Could you please clarify?
Do you mean, -Wall should not have been used
together with -fsanitize?
Also I wonder how do you mean to notify users,
and why not to fix the code instead.

[Bug c++/87904] [9 Regression] ICE in lookup_mark, at cp/tree.c:2322 since r265679

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.2.0
   Target Milestone|--- |9.0
  Known to fail||9.0

[Bug c++/87904] New: [9 Regression] ICE in lookup_mark, at cp/tree.c:2322 since r265679

[marxin at gcc dot gnu.org]

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

Bug ID: 87904
   Summary: [9 Regression] ICE in lookup_mark, at cp/tree.c:2322
since r265679
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
  Target Milestone: ---

Reduced test-case:

$ cat filer.ii
struct a {};
namespace {
void operator<<(a, int) {};
}
struct b {
  friend a <<(a &, const b &);
};
using ::operator<<;
void operator<<(a, b);

a <<(a , const b &) {
  c << 123;
}

[Bug tree-optimization/87896] [9 Regression] ICE in verify_flow_info failed

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to fail|7.3.1   |

--- Comment #4 from Martin Liška  ---
(In reply to Martin Liška from comment #1)
> Apparently also tip of GCC 7 is affected (but neither of GCC 7.x releases).

This is not true, I had wrongly built binary for it.

[Bug rtl-optimization/87902] [9 Regression] Shrink-wrapping multiple conditions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3

[hubicka at ucw dot cz]

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

--- Comment #82 from Jan Hubicka  ---
> > Yep, this is because they used to be arrays indexed by symbol UIDs which
> > Martin converted to hash tables.  Inliner happily calls summary_get each
> > time it needs the summary.  I have some patches to speed this up which I
> > will push out after the type changes (while they add bit of extra
> > functionality by teaching ipa-predicates abou value range I hope they
> > are OK for early stage3).
> 
> Awww.  I guess with no longer re-using UIDs we then get bad hashing
> behavior as well :/  I hope the hash function is _not_ simply the UID?

Yep, UID reuse was there precisely to make the arrays reasonably
compact.  hash is int_hash which IMO returns simply uid.

[Bug target/87762] [9 Regression] extract_constrain_insn, at recog.c:2206 on s390x

[iii at gcc dot gnu.org]

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

--- Comment #3 from iii at gcc dot gnu.org ---
Author: iii
Date: Tue Nov  6 13:20:21 2018
New Revision: 265844

URL: https://gcc.gnu.org/viewcvs?rev=265844=gcc=rev
Log:
S/390: Introduce relative_long attribute

In order to properly fix PR87762, we need to distinguish between
instructions which support relative addressing and instructions which
don't.  We could check whether the existing "type" attribute is equal to
"larl", but there are notable exceptions (lrl, for example), and
changing them makes scheduling worse on z10.  We could also check
whether the existing "op_type" attribute is equal to "RIL-b" or "RIL-c".
However, adding a new attribute provides more flexibility, since we
don't depend idiosyncrasies which might be introduced into PoP in the
future.

gcc/ChangeLog:

2018-11-06  Ilya Leoshkevich  

PR target/87762
* config/s390/s390.md: Add relative_long attribute.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/s390.md

[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3

[rguenther at suse dot de]

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

--- Comment #81 from rguenther at suse dot de  ---
On Tue, 6 Nov 2018, hubicka at ucw dot cz wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
> 
> --- Comment #80 from Jan Hubicka  ---
> > 
> > flat perf profile:
> > 
> > Samples: 510K of event 'instructions:p', Event count (approx.): 
> > 715615147320
> > Overhead   Samples  Command  Shared Object Symbol   
> > 
> >8.08% 95243  f951 f951  [.] bitmap_ior_into
> >7.21% 25966  f951 f951  [.] sreal::operator*
> >5.43% 19353  f951 f951  [.]
> > hash_table >5.20% 23167  f951 f951  [.] 
> > get_ref_base_and_extent
> >4.93% 17947  f951 f951  [.]
> > profile_count::to_sreal_s
> >4.37% 15865  f951 f951  [.] sreal::operator/
> >3.45% 30532  f951 f951  [.] bitmap_set_bit
> >3.41% 12159  f951 f951  [.]
> > hash_table >3.08% 11034  f951 f951  [.] 
> > default_binds_local_p_3
> >3.08% 11146  f951 f951  [.]
> > hash_table >2.21%  7877  f951 f951  [.]
> > want_inline_small_functio
> >1.93%  6874  f951 f951  [.] edge_badness
> >1.87%  6675  f951 f951  [.]
> > compute_inlined_call_time
> > 
> > the ipa_fn_summary hash and edge_growth_cache / call_summary hashes are
> > oddly on top of the profile...
> 
> Yep, this is because they used to be arrays indexed by symbol UIDs which
> Martin converted to hash tables.  Inliner happily calls summary_get each
> time it needs the summary.  I have some patches to speed this up which I
> will push out after the type changes (while they add bit of extra
> functionality by teaching ipa-predicates abou value range I hope they
> are OK for early stage3).

Awww.  I guess with no longer re-using UIDs we then get bad hashing
behavior as well :/  I hope the hash function is _not_ simply the UID?

[Bug tree-optimization/86850] ubsan: runtime error: member call on null pointer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
So the suggested assert is bogus.  But indeed the issue is that
vect_create_new_slp_node eventually uses .create (0) which does nothing
and then splice does

template
inline void
vec::splice (const vec )
{
  if (src.m_vec)
m_vec->splice (*(src.m_vec));
}

which for m_vec == NULL is doing the reported.  I guess replacing
if (src.m_vec) with if (src.length ()) would fix this.

diff --git a/gcc/vec.h b/gcc/vec.h
index f8c039754d2..407269c5ad3 100644
--- a/gcc/vec.h
+++ b/gcc/vec.h
@@ -1688,7 +1688,7 @@ template
 inline void
 vec::splice (const vec )
 {
-  if (src.m_vec)
+  if (src.length ())
 m_vec->splice (*(src.m_vec));
 }

[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3

[hubicka at ucw dot cz]

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

--- Comment #80 from Jan Hubicka  ---
> 
> flat perf profile:
> 
> Samples: 510K of event 'instructions:p', Event count (approx.): 715615147320  
>   
> Overhead   Samples  Command  Shared Object Symbol 
>   
>8.08% 95243  f951 f951  [.] bitmap_ior_into
>7.21% 25966  f951 f951  [.] sreal::operator*
>5.43% 19353  f951 f951  [.]
> hash_table5.20% 23167  f951 f951  [.] get_ref_base_and_extent
>4.93% 17947  f951 f951  [.]
> profile_count::to_sreal_s
>4.37% 15865  f951 f951  [.] sreal::operator/
>3.45% 30532  f951 f951  [.] bitmap_set_bit
>3.41% 12159  f951 f951  [.]
> hash_table3.08% 11034  f951 f951  [.] default_binds_local_p_3
>3.08% 11146  f951 f951  [.]
> hash_table2.21%  7877  f951 f951  [.]
> want_inline_small_functio
>1.93%  6874  f951 f951  [.] edge_badness
>1.87%  6675  f951 f951  [.]
> compute_inlined_call_time
> 
> the ipa_fn_summary hash and edge_growth_cache / call_summary hashes are
> oddly on top of the profile...

Yep, this is because they used to be arrays indexed by symbol UIDs which
Martin converted to hash tables.  Inliner happily calls summary_get each
time it needs the summary.  I have some patches to speed this up which I
will push out after the type changes (while they add bit of extra
functionality by teaching ipa-predicates abou value range I hope they
are OK for early stage3).

[Bug target/87903] Documentation for __builtin_cpu_supports and __builtin_cpu_is is not complete

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-06
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Current values one can see in code:

  const arch_names_table[] =
{
  {"amd", M_AMD},
  {"intel", M_INTEL},
  {"atom", M_INTEL_BONNELL},
  {"slm", M_INTEL_SILVERMONT},
  {"core2", M_INTEL_CORE2},
  {"corei7", M_INTEL_COREI7},
  {"nehalem", M_INTEL_COREI7_NEHALEM},
  {"westmere", M_INTEL_COREI7_WESTMERE},
  {"sandybridge", M_INTEL_COREI7_SANDYBRIDGE},
  {"ivybridge", M_INTEL_COREI7_IVYBRIDGE},
  {"haswell", M_INTEL_COREI7_HASWELL},
  {"broadwell", M_INTEL_COREI7_BROADWELL},
  {"skylake", M_INTEL_COREI7_SKYLAKE},
  {"skylake-avx512", M_INTEL_COREI7_SKYLAKE_AVX512},
  {"cannonlake", M_INTEL_COREI7_CANNONLAKE},
  {"icelake-client", M_INTEL_COREI7_ICELAKE_CLIENT},
  {"icelake-server", M_INTEL_COREI7_ICELAKE_SERVER},
  {"bonnell", M_INTEL_BONNELL},
  {"silvermont", M_INTEL_SILVERMONT},
  {"goldmont", M_INTEL_GOLDMONT},
  {"goldmont-plus", M_INTEL_GOLDMONT_PLUS},
  {"tremont", M_INTEL_TREMONT},
  {"knl", M_INTEL_KNL},
  {"knm", M_INTEL_KNM},
  {"amdfam10h", M_AMDFAM10H},
  {"barcelona", M_AMDFAM10H_BARCELONA},
  {"shanghai", M_AMDFAM10H_SHANGHAI},
  {"istanbul", M_AMDFAM10H_ISTANBUL},
  {"btver1", M_AMD_BTVER1},  
  {"amdfam15h", M_AMDFAM15H},
  {"bdver1", M_AMDFAM15H_BDVER1},
  {"bdver2", M_AMDFAM15H_BDVER2},
  {"bdver3", M_AMDFAM15H_BDVER3},
  {"bdver4", M_AMDFAM15H_BDVER4},
  {"btver2", M_AMD_BTVER2},
  {"amdfam17h", M_AMDFAM17H},
  {"znver1", M_AMDFAM17H_ZNVER1},
  {"znver2", M_AMDFAM17H_ZNVER2},
};

  const isa_names_table[] =
{
  {"cmov",F_CMOV},
  {"mmx", F_MMX},
  {"popcnt",  F_POPCNT},
  {"sse", F_SSE},
  {"sse2",F_SSE2},
  {"sse3",F_SSE3},
  {"ssse3",   F_SSSE3},
  {"sse4a",   F_SSE4_A},
  {"sse4.1",  F_SSE4_1},
  {"sse4.2",  F_SSE4_2},
  {"avx", F_AVX},
  {"fma4",F_FMA4},
  {"xop", F_XOP},
  {"fma", F_FMA},
  {"avx2",F_AVX2},
  {"avx512f", F_AVX512F},
  {"bmi", F_BMI},
  {"bmi2",F_BMI2},
  {"aes", F_AES},
  {"pclmul",  F_PCLMUL},
  {"avx512vl",F_AVX512VL},
  {"avx512bw",F_AVX512BW},
  {"avx512dq",F_AVX512DQ},
  {"avx512cd",F_AVX512CD},
  {"avx512er",F_AVX512ER},
  {"avx512pf",F_AVX512PF},
  {"avx512vbmi",F_AVX512VBMI},
  {"avx512ifma",F_AVX512IFMA},
  {"avx5124vnniw",F_AVX5124VNNIW},
  {"avx5124fmaps",F_AVX5124FMAPS},
  {"avx512vpopcntdq",F_AVX512VPOPCNTDQ},
  {"avx512vbmi2", F_AVX512VBMI2},
  {"gfni", F_GFNI},
  {"vpclmulqdq", F_VPCLMULQDQ},
  {"avx512vnni", F_AVX512VNNI},
  {"avx512bitalg", F_AVX512BITALG}
};

[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #79 from Richard Biener  ---
On the GCC 8 branch with -g -O0 (x86_64-linux) I get

 TOTAL  :   9.59  0.49 10.09   
 551543 kB
10.53user 0.55system 0:11.08elapsed 99%CPU (0avgtext+0avgdata
1230908maxresident)k
0inputs+68384outputs (0major+379474minor)pagefaults 0swaps

On trunk with mem-stats the biggest offender is (as reported)

df_scan mw_reg  alloc-pool.h:487 (df_scan_alloc)   
  1136 0 :  0.0%  483M   38M: 92.4%  32

going up to -Ofast makes compile-time explode again.  For the reduced testcase
it's still inlining and PTA:

 ipa inlining heuristics:  41.55 ( 36%)   0.01 (  1%)  41.60 ( 36%)
   6333 kB (  2%)
 alias stmt walking :  14.73 ( 13%)   0.14 ( 18%)  14.98 ( 13%)
164 kB (  0%)
 tree PTA   :  37.93 ( 33%)   0.23 ( 30%)  38.16 ( 33%)
  31921 kB (  8%)
 TOTAL  : 115.67  0.77116.52   
 411925 kB
115.83user 0.81system 1:56.71elapsed 99%CPU (0avgtext+0avgdata
1034364maxresident)k
1624inputs+12624outputs (1major+308881minor)pagefaults 0swaps

trunk seems to behave similar:

 ipa inlining heuristics:  53.74 ( 41%)   0.02 (  2%)  53.75 ( 40%)
   5428 kB (  1%)
 alias stmt walking :  14.98 ( 11%)   0.19 ( 23%)  15.16 ( 11%)
165 kB (  0%)
 tree PTA   :  39.70 ( 30%)   0.24 ( 29%)  39.92 ( 30%)
  31896 kB (  8%)
 TOTAL  : 132.01  0.83132.85   
 407617 kB
132.01user 0.86system 2:12.88elapsed 99%CPU (0avgtext+0avgdata
1034096maxresident)k
0inputs+8224outputs (0major+301553minor)pagefaults 0swaps

flat perf profile:

Samples: 510K of event 'instructions:p', Event count (approx.): 715615147320
Overhead   Samples  Command  Shared Object Symbol   
   8.08% 95243  f951 f951  [.] bitmap_ior_into
   7.21% 25966  f951 f951  [.] sreal::operator*
   5.43% 19353  f951 f951  [.]
hash_table

[Bug target/87903] New: Documentation for __builtin_cpu_supports and __builtin_cpu_is is not complete

[marxin at gcc dot gnu.org]

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

Bug ID: 87903
   Summary: Documentation for __builtin_cpu_supports and
__builtin_cpu_is is not complete
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

As seen here:
https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/x86-Built-in-Functions.html#x86-Built-in-Functions

there are missing values for both of these options.

[Bug rtl-optimization/87902] New: [9 Regression] Shrink-wrapping multiple conditions

[iii at linux dot ibm.com]

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

Bug ID: 87902
   Summary: [9 Regression] Shrink-wrapping multiple conditions
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iii at linux dot ibm.com
CC: krebbel at gcc dot gnu.org
  Target Milestone: ---
Target: s390x-linux-gnu

I've noticed that r265830 fails to shrink-wrap multiple early returns in
gcc/testsuite/gcc.target/s390/nobp-return-mem-z900.c, while r264877 managed to
do so just fine.

After reload we end up with the following code for those conditions:

;; basic block 2
(note 5 1 3 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 3 5 2 2 NOTE_INSN_FUNCTION_BEG)
(insn 2 3 7 2 (set (reg/v:DI 12 %r12 [orig:63 aD.2191+-4 ] [63])
(reg:DI 2 %r2 [72]))
"gcc/testsuite/gcc.target/s390/nobp-return-mem-z900.c":14:1 1269 {*movdi_64}
 (nil))
(insn 7 2 8 2 (set (reg:CCZ 33 %cc)
(compare:CCZ (reg:SI 12 %r12 [orig:63 aD.2191 ] [63])
(const_int 42 [0x2a])))
"gcc/testsuite/gcc.target/s390/nobp-return-mem-z900.c":17:6 1232 {*cmpsi_cct}
 (nil))
(jump_insn 8 7 9 2 (set (pc)
(if_then_else (eq (reg:CCZ 33 %cc)
(const_int 0 [0]))
(label_ref:DI 33)
(pc))) "gcc/testsuite/gcc.target/s390/nobp-return-mem-z900.c":17:6
1896 {*cjump_64}
 (int_list:REG_BR_PROB 225163668 (nil))
 -> 33)

;; basic block 3
(note 9 8 12 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn 12 9 13 3 (set (reg:CCS 33 %cc)
(compare:CCS (reg:SI 12 %r12 [orig:63 aD.2191 ] [63])
(const_int 0 [0])))
"gcc/testsuite/gcc.target/s390/nobp-return-mem-z900.c":20:3 1222
{*tstsi_cconly2}
 (nil))
(jump_insn 13 12 14 3 (set (pc)
(if_then_else (le (reg:CCS 33 %cc)
(const_int 0 [0]))
(label_ref:DI 33)
(pc))) "gcc/testsuite/gcc.target/s390/nobp-return-mem-z900.c":20:3
1896 {*cjump_64}
 (int_list:REG_BR_PROB 118111604 (nil))
 -> 33)

Note that comparisons use a copy in caller-saved %r12, and not %r2.  Then,
prepare_shrink_wrap () successfully propagates it to basic block 2. Basic block
3 is not affected - this seems to be by design, since prepare_shrink_wrap ()
only concerns itself with the first basic block.

In the past reload used to eliminate the copy and use %r2 directly in both
comparisons, but this seems to be no longer the case.

[Bug tree-optimization/86850] ubsan: runtime error: member call on null pointer

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #6 from Martin Liška  ---
Richi can you please assign that?

[Bug sanitizer/87884] ubsan causes wrong -Wformat-overflow warning

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2018-11-6
 CC||msebor at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
In general we have issues with warnings when sanitizers are used.
Martin: What about notifying users that one should not combine sanitizers and
warnings? It's becoming a very common issue.

[Bug sanitizer/87892] [9 Regression]: libsanitizer fails to build on CentOS 5.11 (glibc 2.5)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   See Also||https://github.com/google/s
   ||anitizers/issues/1019

--- Comment #2 from Martin Liška  ---
Reported upstream.

[Bug sanitizer/87892] [9 Regression]: libsanitizer fails to build on CentOS 5.11 (glibc 2.5)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-06
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, it's mainline bug, I'll report that.

[Bug middle-end/37150] basic-block vectorization misses some unrolled loops

[rguenth at gcc dot gnu.org]

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

--- Comment #29 from Richard Biener  ---
On the original testcase I now get

> ./f951  -quiet -Ofast t.f90 -march=core-avx2 -fopt-info-vec 
t.f90:157:0: optimized: loop vectorized using 32 byte vectors
t.f90:158:0: optimized: basic block part vectorized using 32 byte vectors

the non-reduced testcase still doesn't see any vectorization.

[Bug tree-optimization/36602] memset should be optimized into an empty CONSTRUCTOR

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Attachment #27563|0   |1
is obsolete||

--- Comment #11 from Richard Biener  ---
Created attachment 44963
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44963=edit
updated patch

Updated patch.  There are the expected missing warnings plus the two missed
optimizations noted by the bugs this now depends on.

[Bug tree-optimization/87901] New: partial DSE of memset doesn't work for other kind of stores

[rguenth at gcc dot gnu.org]

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

Bug ID: 87901
   Summary: partial DSE of memset doesn't work for other kind of
stores
   Product: gcc
   Version: 9.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: ---

When transforming the memsets in tree-ssa/ssa-dse-25.c to = {} and = 0 inits
the DSE pass no longer knows how to trim them.

Similarly for

int i;
void foo ()
{
  i = 0;
  *((short *) + sizeof (int) - sizeof (short)) = 1;
}

[Bug tree-optimization/87900] New: malloc + memse to calloc doesn't work for aggregate initialization

[rguenth at gcc dot gnu.org]

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

Bug ID: 87900
   Summary: malloc + memse to calloc doesn't work for aggregate
initialization
   Product: gcc
   Version: 9.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: ---

struct S { int a[1024]; };
struct S *foo ()
{
  struct S *p = (struct S *)__builtin_malloc (sizeof (struct S));
  *p = (struct S){};
  return p;
}

is not transformed to calloc, it only works when doing

  __builtin_memset (p, 0, sizeof (struct S));

the strlen pass is doing this transform (also DSEing zero-inits after calloc).

[Bug tree-optimization/87885] ICE in release_ssa_name_fn with -fprofile-report

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |9.0

--- Comment #4 from Martin Liška  ---
Let me finish that based on what was discussed on IRC:

 dead BBs can have bogus IL,
 for example propagators do not bother to update IL in such blocks but
release SSA names that are otherwise propagated out
 but actual BB removal is left to CFG cleanup because that knows how to
properly do that
 hmm, that is not very pretty but I guess we could just drop the middle
value.
 one can modify the code to account only reachable BBs but that would
give simliar values as doing accounting after cfgcleanup.
 so that would mean moving both calls after TODO?
 just completely dropping the first call and the first accounted number
would be OK I guess
 if it can't be computed safely, that is.
 but the docs say theres two phases - so it isn't really two phases?!
 we can also elide the first call if TODO_cfg_cleanup
 but then there isn't any cleanup and the first call is pointless
 why does it use estimate_num_insns rather than just counting stmts?
 well, the statistics was originally intended to help judging if, say,
re-running fre for third time is useful
 it's about profile after all?
 because you can do FDO build and then you get number of much the code
has similified after every pass
 OK, but then that's the after-TODO value that is interesting
 estimate_num_insns is used to estimate runtime of the program
 it also accounts profile mismatches.  The two runs was really done to
have idea how much the pass itself mangled the profile and how much the profile
was beaten during the cfg cleanups the pass invoked
 having only the second value is OK
 if calculating first meaningfully is a trouble.
 so we can look at the profile only in the first pass and the size/time
in the second?
 yes, that would work, too.
 anyway, I leave the PR to somebody else ;)
 I can look into it next week.
 works for me
 I wanted to discuss a bit the pointers.  So my understanding is that
C++ has rvalue and normal referneces.

[Bug d/87865] gdc doesn't build unless assert is marked noreturn

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #7 from Iain Buclaw  ---
> It required removing all system includes from all dmd frontend sources, but I
> think this OK now.  I have verified that gcc_assert() is being called now
> instead of assert().

I've now been able to build gdc/d21 on sparc-sun-solaris2.10 and
i386-pc-solaris2.10 without issues.

Thanks for fixing this.

Rainer

[Bug debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #23 from Rainer Orth  ---
(In reply to Eric Gallager from comment #22)
> (In reply to Rainer Orth from comment #8)
> > Fixed for 4.8.0.
> 
> Rainer, do you want to remain the assignee for this? It was reopened for a
> different platform than you originally opened it for... Although, then again:
> 
> (In reply to Jason Merrill from comment #18)
> > Author: jason
> > Date: Wed Mar  6 15:34:11 2013
> > New Revision: 196493
> > 
> > URL: http://gcc.gnu.org/viewcvs?root=gcc=rev=196493
> > Log:
> > PR debug/53363
> > * g++.dg/debug/dwarf2/thunk1.C: Skip on darwin.
> > 
> > Modified:
> > trunk/gcc/testsuite/ChangeLog
> > trunk/gcc/testsuite/g++.dg/debug/dwarf2/thunk1.C
> 
> ...did this fix it? If so we can just close it and it won't matter who the
> assignee is.

I don't see any failure of this test on any target, so it can be closed.

Thanks for looking after this.

  Rainer

[Bug middle-end/87899] [9 regression]r264897 cause mis-compiled native arm-linux-gnueabihf toolchain

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|8.0 |9.0
   Target Milestone|--- |9.0

[Bug sanitizer/80953] Support libsanitizer on Solaris

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2018-11/msg00337.ht
   ||ml
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org
   Target Milestone|--- |9.0

--- Comment #10 from Rainer Orth  ---
Fixed for 9.0.

[Bug sanitizer/80953] Support libsanitizer on Solaris

[ro at gcc dot gnu.org]

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

--- Comment #9 from Rainer Orth  ---
Author: ro
Date: Tue Nov  6 10:49:34 2018
New Revision: 265837

URL: https://gcc.gnu.org/viewcvs?rev=265837=gcc=rev
Log:
Enable libsanitizer on Solaris (PR sanitizer/80953)

gcc:
PR sanitizer/80953
* config/sol2.h (ASAN_CC1_SPEC): Define.
(LD_WHOLE_ARCHIVE_OPTION): Define.
(LD_NO_WHOLE_ARCHIVE_OPTION): Define.
(ASAN_REJECT_SPEC): Provide default.
(LIBASAN_EARLY_SPEC): Define.
(LIBTSAN_EARLY_SPEC): Define.
(LIBLSAN_EARLY_SPEC): Define.
* config/i386/sol2.h (CC1_SPEC): Redefine.
(ASAN_REJECT_SPEC): Define.

* config/sparc/sparc.c (sparc_asan_shadow_offset): Declare.
(TARGET_ASAN_SHADOW_OFFSET): Define.
(sparc_asan_shadow_offset): New function.
* config/sparc/sol2.h (CC1_SPEC): Append ASAN_CC1_SPEC.
(ASAN_REJECT_SPEC): Define.

gcc/testsuite:
PR sanitizer/80953
* c-c++-common/asan/alloca_loop_unpoisoning.c: Require alloca
support.
(foo): Use __builtin_alloca.

libsanitizer:
PR sanitizer/80953
* configure.tgt (sparc*-*-solaris2.11*): Enable.
(x86_64-*-solaris2.11* | i?86-*-solaris2.11*): Enable.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sol2.h
trunk/gcc/config/sol2.h
trunk/gcc/config/sparc/sol2.h
trunk/gcc/config/sparc/sparc.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/asan/alloca_loop_unpoisoning.c
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/configure.tgt

[Bug middle-end/87899] New: [9 regression]r264897 cause mis-compiled native arm-linux-gnueabihf toolchain

[renlin at gcc dot gnu.org]

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

Bug ID: 87899
   Summary: [9 regression]r264897 cause mis-compiled native
arm-linux-gnueabihf toolchain
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: renlin at gcc dot gnu.org
  Target Milestone: ---

since r264897, native arm-linux-gnueabihf toolchain has been mis-compiled.
Somehow, it survives boostrap.

It ICEs when compiling a lot of test cases. They fail with similar message.
For example:

./gcc/cc1 ~/gcc/./gcc/testsuite/gcc.c-torture/execute/pr36034-1.c  -O3
 test main
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>   
  Streaming LTO
   
Assembling
functions:
  testduring GIMPLE pass: ldist

gcc/./gcc/testsuite/gcc.c-torture/execute/pr36034-1.c: In function ‘test’:
gcc/./gcc/testsuite/gcc.c-torture/execute/pr36034-1.c:9:1: internal compiler
error: Segmentation fault
9 | test (void)
  | ^~~~
0x5c3a37 crash_signal
../../gcc/gcc/toplev.c:325
0x63ef6b inchash::hash::add(void const*, unsigned int)
../../gcc/gcc/inchash.h:100
0x63ef6b inchash::hash::add_ptr(void const*)
../../gcc/gcc/inchash.h:94
0x63ef6b ddr_hasher::hash(data_dependence_relation const*)
../../gcc/gcc/tree-loop-distribution.c:143
0x63ef6b hash_table::find_slot(data_dependence_relation* const&, insert_option)
../../gcc/gcc/hash-table.h:414
0x63ef6b get_data_dependence
../../gcc/gcc/tree-loop-distribution.c:1184
0x63f2bd data_dep_in_cycle_p
../../gcc/gcc/tree-loop-distribution.c:1210
0x63f2bd update_type_for_merge
../../gcc/gcc/tree-loop-distribution.c:1255
0x64064b build_rdg_partition_for_vertex
../../gcc/gcc/tree-loop-distribution.c:1302
0x64064b rdg_build_partitions
../../gcc/gcc/tree-loop-distribution.c:1754
0x64064b distribute_loop
../../gcc/gcc/tree-loop-distribution.c:2795
0x642299 execute
../../gcc/gcc/tree-loop-distribution.c:3133
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug sanitizer/80953] Support libsanitizer on Solaris

[ro at gcc dot gnu.org]

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

--- Comment #8 from Rainer Orth  ---
Author: ro
Date: Tue Nov  6 10:42:05 2018
New Revision: 265836

URL: https://gcc.gnu.org/viewcvs?rev=265836=gcc=rev
Log:
Cherry-pick Solaris sanitizer fixes (PR sanitizer/80953)

PR sanitizer/80953
* sanitizer_common/sanitizer_internal_defs.h,
sanitizer_common/sanitizer_platform_limits_solaris.h,
sanitizer_common/sanitizer_procmaps_solaris.cc,
sanitizer_common/sanitizer_solaris.cc: Cherry-pick compiler-rt
revision 346153.
* sanitizer_common/sanitizer_stacktrace.h,
sanitizer_common/sanitizer_stacktrace_sparc.cc: Cherry-pick
compiler-rt revision 346155.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/sanitizer_common/sanitizer_internal_defs.h
trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_solaris.h
trunk/libsanitizer/sanitizer_common/sanitizer_procmaps_solaris.cc
trunk/libsanitizer/sanitizer_common/sanitizer_solaris.cc
trunk/libsanitizer/sanitizer_common/sanitizer_stacktrace.h
trunk/libsanitizer/sanitizer_common/sanitizer_stacktrace_sparc.cc

[Bug fortran/87881] gfortran.dg/inquiry_type_ref_(1.f08|3.f90) fail on darwin

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-06
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
First, I have tested the patch at
https://gcc.gnu.org/bugzilla/attachment.cgi?id=44892
with the test in pr40196 comment 9 without seeing any problem.
So it seems that the problem has been introduced/uncovered by the subsequent
changes.

Second, I see the ICE for two quite different reduced tests:

module m
  character (:), allocatable :: str
  type :: mytype
character(6) :: str
  end type
end module

  use m

  type(mytype) :: der

  str = "abcd"

!  if (str%kind .ne. kind (str)) stop 6
  if (der%str%len .ne. len (der%str)) stop 7
end

for which the ICE is also seen for the commented line, and

  complex, parameter :: zc = ( 99.0, 199.0 )
  REAL, parameter :: rc = zc%re
  REAL, parameter :: ic = zc%im

end

for which the two lines 'REAL, parameter' are needed to trigger the ICE.

Compiling these tests with an instrumented compiler gives:

=
==75699==ERROR: AddressSanitizer: heap-use-after-free on address 0x617045d8
at pc 0x00010015620e bp 0x7ffeefbfccf0 sp 0x7ffeefbfcce8
READ of size 8 at 0x617045d8 thread T0
#0 0x10015620d in simplify_ref_chain(gfc_ref*, int, gfc_expr**) expr.c:1943
#1 0x1001528fb in gfc_simplify_expr(gfc_expr*, int) expr.c:2064
#2 0x100369fe7 in gfc_match_varspec(gfc_expr*, int, bool, bool)
primary.c:2287
#3 0x1003765a8 in gfc_match_rvalue(gfc_expr**) primary.c:3429
#4 0x10025a96b in match_primary(gfc_expr**) matchexp.c:157
#5 0x10025abfa in match_level_1(gfc_expr**) matchexp.c:211
#6 0x10025af6b in match_mult_operand(gfc_expr**) matchexp.c:264
#7 0x10025b7ac in match_add_operand(gfc_expr**) matchexp.c:351
#8 0x10025c1ba in match_level_2(gfc_expr**) matchexp.c:480
#9 0x10025c726 in match_level_3(gfc_expr**) matchexp.c:547
#10 0x10025cb9f in match_level_4(gfc_expr**) matchexp.c:593
#11 0x10025d9d5 in match_and_operand(gfc_expr**) matchexp.c:693
#12 0x10025dca8 in match_or_operand(gfc_expr**) matchexp.c:718
#13 0x10025e10d in match_equiv_operand(gfc_expr**) matchexp.c:761
#14 0x10025e57b in match_level_5(gfc_expr**) matchexp.c:806
#15 0x10025a48f in gfc_match_expr(gfc_expr**) matchexp.c:865
#16 0x10015adb1 in gfc_match_init_expr(gfc_expr**) expr.c:2987
#17 0x1000f6516 in variable_decl(int) decl.c:2715
#18 0x1000f77f3 in gfc_match_data_decl() decl.c:5926
#19 0x100330018 in match_word(char const*, match (*)(), locus*) parse.c:65
#20 0x10033c950 in decode_statement() parse.c:376
#21 0x10033eef6 in next_free() parse.c:1234
#22 0x10033f8cb in next_statement() parse.c:1466
#23 0x100345fab in parse_spec(gfc_statement) parse.c:3858
#24 0x10034cbfa in parse_progunit(gfc_statement) parse.c:5671
#25 0x10034f8de in gfc_parse_file() parse.c:6259
#26 0x100522fbf in gfc_be_parse_file() f95-lang.c:204
#27 0x10611cde8 in compile_file() toplev.c:455
#28 0x1061284a3 in do_compile() toplev.c:2172
#29 0x10915f5d7 in toplev::main(int, char**) toplev.c:2307
#30 0x1095b359c in main main.c:39
#31 0x7fff703f908c in start (libdyld.dylib:x86_64+0x1708c)

0x617045d8 is located 728 bytes inside of 736-byte region
[0x61704300,0x617045e0)
freed by thread T0 here:
#0 0x158cb18e0 in wrap_free.part.0 sanitizer_malloc_mac.inc:121
#1 0x10012e5f7 in gfc_free_ref_list(gfc_ref*) expr.c:599
#2 0x10012ecef in free_expr0(gfc_expr*) expr.c:505
#3 0x10012f0d0 in gfc_replace_expr(gfc_expr*, gfc_expr*) expr.c:616
#4 0x10015601c in simplify_ref_chain(gfc_ref*, int, gfc_expr**) expr.c:1970
#5 0x1001528fb in gfc_simplify_expr(gfc_expr*, int) expr.c:2064
#6 0x100369fe7 in gfc_match_varspec(gfc_expr*, int, bool, bool)
primary.c:2287
#7 0x1003765a8 in gfc_match_rvalue(gfc_expr**) primary.c:3429
#8 0x10025a96b in match_primary(gfc_expr**) matchexp.c:157
#9 0x10025abfa in match_level_1(gfc_expr**) matchexp.c:211
#10 0x10025af6b in match_mult_operand(gfc_expr**) matchexp.c:264
#11 0x10025b7ac in match_add_operand(gfc_expr**) matchexp.c:351
#12 0x10025c1ba in match_level_2(gfc_expr**) matchexp.c:480
#13 0x10025c726 in match_level_3(gfc_expr**) matchexp.c:547
#14 0x10025cb9f in match_level_4(gfc_expr**) matchexp.c:593
#15 0x10025d9d5 in match_and_operand(gfc_expr**) matchexp.c:693
#16 0x10025dca8 in match_or_operand(gfc_expr**) matchexp.c:718
#17 0x10025e10d in match_equiv_operand(gfc_expr**) matchexp.c:761
#18 0x10025e57b in match_level_5(gfc_expr**) matchexp.c:806
#19 0x10025a48f in gfc_match_expr(gfc_expr**) matchexp.c:865
#20 

[Bug tree-optimization/87889] [9 Regression] CPU2000 177.mesa failed to build

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue Nov  6 10:23:30 2018
New Revision: 265833

URL: https://gcc.gnu.org/viewcvs?rev=265833=gcc=rev
Log:
2018-11-06  Richard Biener  

PR tree-optimization/87889
* tree-vect-loop-manip.c (slpeel_duplicate_current_defs_from_edges):
Do nothing if old and new arg are the same

* gcc.dg/pr87894.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr87894.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop-manip.c

[Bug tree-optimization/87889] [9 Regression] CPU2000 177.mesa failed to build

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/85787] malloc_candidate_p fails to detect malloc attribute on nested phis

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Martin Liška  ---
Fixed.

[Bug target/87723] [9 Regression] ICE: output_operand: invalid %-code on s390x

[krebbel at gcc dot gnu.org]

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

--- Comment #3 from Andreas Krebbel  ---
Author: krebbel
Date: Tue Nov  6 10:22:05 2018
New Revision: 265832

URL: https://gcc.gnu.org/viewcvs?rev=265832=gcc=rev
Log:
S/390: Fix PR87723

gcc/ChangeLog:

2018-11-06  Andreas Krebbel  

PR target/87723
* config/s390/s390.md ("*rsbg_di_rotl"): Remove mode
attributes for operands 3 and 4.

gcc/testsuite/ChangeLog:

2018-11-06  Andreas Krebbel  

PR target/87723
* gcc.target/s390/pr87723.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/s390/pr87723.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/s390.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/87897] [9 Regression] ICE in maybe_constant_value, at cp/constexpr.c:5255 since r265788

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
One more test-case:

$ cat ice.ii
struct c {
  int b;
};
struct e : c {
  constexpr e() : c{} {}
};
using d = e;
const int ((2, d{}).b);

$ g++ ice.ii -c
ice.ii:8:24: internal compiler error: in build_target_expr_with_type, at
cp/tree.c:793
8 | const int ((2, d{}).b);
  |^
0x67a78d build_target_expr_with_type(tree_node*, tree_node*, int)
../../gcc/cp/tree.c:793
0x887963 cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.c:5110
0x88accc maybe_constant_init_1
../../gcc/cp/constexpr.c:5371
0x859d10 set_up_extended_ref_temp
../../gcc/cp/call.c:11144
0x859d10 extend_ref_init_temps_1
../../gcc/cp/call.c:11304
0xa217f7 store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc/cp/typeck2.c:815
0x8b334d check_initializer
../../gcc/cp/decl.c:6486
0x8cb79c cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:7162
0x96776b cp_parser_init_declarator
../../gcc/cp/parser.c:20033
0x96f203 cp_parser_simple_declaration
../../gcc/cp/parser.c:13219
0x974262 cp_parser_declaration
../../gcc/cp/parser.c:12916
0x974a0c cp_parser_translation_unit
../../gcc/cp/parser.c:4668
0x974a0c c_parse_file()
../../gcc/cp/parser.c:39266
0xa77000 c_common_parse_file()
../../gcc/c-family/c-opts.c:1150

[Bug tree-optimization/87885] ICE in release_ssa_name_fn with -fprofile-report

[hubicka at ucw dot cz]

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

--- Comment #3 from Jan Hubicka  ---
OK, I now recall. The intend was really to have three values 
- profile before pass was run (which you can see from stats of previous
  pass)
- profile after pass was run
- profile after cleanups

This is somewhat useful because, say for CCP one can see how much code
sped up just by removing some calculation and how much it was affected
by subsequent unreacable code removal.  If we can't calculate the middle
value safely, we can just drop it.

Honza

[Bug rtl-optimization/87895] [7/8/9 Regression] ICE in purge_dead_edges, at cfgrtl.c:3246

[asolokha at gmx dot com]

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

--- Comment #2 from Arseny Solokha  ---
And another one, apparently:

#pragma omp declare simd
int
vm (int *ty, int oh)
{
  if ((oh == 0) ? (*ty = 0) : *ty)
return 0;
}

% x86_64-pc-linux-gnu-gcc-9.0.0-alpha20181104 -O1 -fopenmp -c logpnyyb.c
logpnyyb.c: In function 'vm.simdclone.0':
logpnyyb.c:3:1: error: fallthru to exit from bb 10
3 | vm (int *ty, int oh)
  | ^~
during GIMPLE pass: dom
logpnyyb.c:3:1: internal compiler error: verify_flow_info failed
0x8a889a verify_flow_info()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/cfghooks.c:265
0xd1d674 checking_verify_flow_info
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/cfghooks.h:198
0xd1d674 cleanup_tree_cfg_noloop
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/tree-cfgcleanup.c:938
0xd1d674 cleanup_tree_cfg()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/tree-cfgcleanup.c:989
0xbec05c execute_function_todo
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/passes.c:1878
0xbecece execute_todo
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181104/work/gcc-9-20181104/gcc/passes.c:1979

[Bug tree-optimization/87885] ICE in release_ssa_name_fn with -fprofile-report

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  ---
The patch makes sense to me. I am not sure why it was run after pass but before
cleanups originally... Seems like a bug.