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

[pmatos at gcc dot gnu.org]

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

--- Comment #11 from pmatos at gcc dot gnu.org ---
(In reply to David Malcolm from comment #10)
> Should be fixed by the above commit.

David, does this mean the analyzer has C++ support now or just that this
specific bug is fixed in-tree?

[Bug middle-end/64242] Longjmp expansion incorrect

[pinskia at gcc dot gnu.org]

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

--- Comment #38 from Andrew Pinski  ---
(In reply to Wilco from comment #37)
> (In reply to Andrew Pinski from comment #36)
> > MIPS is still broken.  I might look into MIPS brokenness next week.
> 
> Yes it seems builtin_longjmp has the exact same fp corruption issue:
> 
>   move$fp,$17
>   lw  $sp,8($fp)
>   jr  $16
>   lw  $28,12($fp)

Yes the same issue.  I will be testing a patch soon.

[Bug tree-optimization/93697] New: pr93661.c does not warn on (32-bit) powerpc-linux

[segher at gcc dot gnu.org]

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

Bug ID: 93697
   Summary: pr93661.c does not warn on (32-bit) powerpc-linux
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

The new testcase pr93661.c does not warn.

int f ()
{
  unsigned x = 0x;
  __builtin_memset (1+(char *) , 0, -1); /* { dg-warning "maximum object
size" } */
  return (x != 0xf000);
}

(-O2).  It *does* warn at -O0.

[Bug target/93696] New: AVX512VPOPCNTDQ writemask intrinsics produce incorrect results

[crazylht at gmail dot com]

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

Bug ID: 93696
   Summary: AVX512VPOPCNTDQ writemask intrinsics produce incorrect
results
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---
Target: i386, x86-64

The writemask (mask) forms of the AVX512VPOPCNTDQ intrinsics generate incorrect
results. When the mask bit is not set, it appears the GCC implementation is
copying from the third parameter, whereas it should be copying from the first
parameter.

testcase:
cat test.c

#include
__m128i foo (__m128i dst, __mmask8 m, __m128i src)
{
  return _mm_mask_popcnt_epi64 (dst, m, src);
}

gcc10_trunk -O2 -mavx512vpopcntdq -mavx512vl -S

foo(long long __vector(2), unsigned char, long long __vector(2)):
kmovw   %edi, %k1
vpopcntq%xmm0, %xmm1{%k1}
vmovdqa64   %xmm1, %xmm0
ret

which is incorrect, it should be 

foo(__m128i, unsigned char, __m128i):
kmovw %edi, %k1 #4.10
vpopcntq  %xmm1, %xmm0{%k1} #4.10
ret #4.10

Refer to https://godbolt.org/z/EK12b0

Affected intrinsics

_mm256_mask_popcnt_epi64
_mm_mask_popcnt_epi64
_mm256_mask_popcnt_epi32
_mm_mask_popcnt_epi32
_mm512_mask_popcnt_epi32
_mm512_mask_popcnt_epi64
_mm512_mask_popcnt_epi16
_mm256_mask_popcnt_epi16
_mm_mask_popcnt_epi16
_mm512_mask_popcnt_epi8
_mm256_mask_popcnt_epi8
_mm_mask_popcnt_epi8

[Bug tree-optimization/93661] [10 Regression] ICE in tree_to_poly_int64, at tree.c:2976

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
The testcase FAILs on i686-linux (bet other ilp32 targets too), there is no
warning emitted.

[Bug analyzer/93695] New: Allocation and freeing memory for array members in loops is not handled properly by the analyzer

[asolokha at gmx dot com]

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

Bug ID: 93695
   Summary: Allocation and freeing memory for array members in
loops is not handled properly by the analyzer
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-10.0.1-alpha20200209 snapshot (g:8686c4d84517b54cf3dfe98fca3a814b7d606502)
fails to notice that in the following testcase memory in fact gets allocated
(and then freed) for different array members, so there are neither leaks nor
double-'free's there.

It can be easily spotted when using the analyzer on various real-world
codebases, but I fail to see the corresponding item in the Limitations section,
hence the report. Control flow in real-world code is more complex, of course,
but a testcase can be reduced to something as trivial as the one posted above.

#define NELEMS 2
#define ARRAY_SIZE(a) (sizeof (a) / sizeof (a[0]))

void
f (void)
{
  int *p[NELEMS];
  int i;

  for (i = 0; i < ARRAY_SIZE (p); ++i)
p[i] = __builtin_malloc (sizeof (i));

  for (i = 0; i < ARRAY_SIZE (p); ++i)
__builtin_free (p [i]);
}

% gcc-10.0.1 -O1 -fanalyzer -c n0hgjbog.c
n0hgjbog.c: In function 'f':
n0hgjbog.c:10:17: warning: leak of '' [CWE-401]
[-Wanalyzer-malloc-leak]
   10 |   for (i = 0; i < ARRAY_SIZE (p); ++i)
  | ^
  'f': events 1-9
|
|   10 |   for (i = 0; i < ARRAY_SIZE (p); ++i)
|  |   ^~~
|  |   |
|  |   (1) following 'true' branch...
|  |   (4) following 'true' branch...
|  |   (6) following 'true' branch...
|  |   (9) following 'false' branch...
|   11 | p[i] = __builtin_malloc (sizeof (i));
|  |~
|  ||
|  |(2) ...to here
|  |(3) allocated here
|  |(5) ...to here
|  |(7) ...to here
|  |(8) allocated here
|
  'f': event 10
|
|cc1:
| (10): ...to here
|
  'f': events 11-14
|
|   13 |   for (i = 0; i < ARRAY_SIZE (p); ++i)
|  |   ^~~
|  |   |
|  |   (11) following 'true' branch...
|  |   (13) following 'false' branch...
|   14 | __builtin_free (p [i]);
|  | ~
|  |   |
|  |   (12) ...to here
|   15 | }
|  | ~  
|  | |
|  | (14) ...to here
|
  'f': event 15
|
|   10 |   for (i = 0; i < ARRAY_SIZE (p); ++i)
|  | ^
|  | |
|  | (15) '' leaks here; was allocated at (8)
|
n0hgjbog.c:14:5: warning: double-'free' of '' [CWE-415]
[-Wanalyzer-double-free]
   14 | __builtin_free (p [i]);
  | ^~
  'f': events 1-3
|
|   10 |   for (i = 0; i < ARRAY_SIZE (p); ++i)
|  |   ^~~
|  |   |
|  |   (1) following 'true' branch...
|  |   (3) following 'false' branch...
|   11 | p[i] = __builtin_malloc (sizeof (i));
|  |~
|  ||
|  |(2) ...to here
|
  'f': event 4
|
|cc1:
| (4): ...to here
|
  'f': events 5-13
|
|   13 |   for (i = 0; i < ARRAY_SIZE (p); ++i)
|  |   ^~~
|  |   |
|  |   (5) following 'true' branch...
|  |   (8) following 'true' branch...
|  |   (11) following 'true' branch...
|   14 | __builtin_free (p [i]);
|  | ~~
|  | | |
|  | | (6) ...to here
|  | | (7) first 'free' here
|  | | (9) ...to here
|  | | (10) first 'free' here
|  | | (12) ...to here
|  | (13) second 'free' here; first 'free' was at (10)
|
n0hgjbog.c:14:5: note: 1 duplicate
   14 | __builtin_free (p [i]);

[Bug target/91052] [10 Regression] ICE in fix_reg_equiv_init, at ira.c:2705

[linkw at gcc dot gnu.org]

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #17 from Kewen Lin  ---
Should be fixed with r10-6591.

[Bug target/91052] [10 Regression] ICE in fix_reg_equiv_init, at ira.c:2705

[cvs-commit at gcc dot gnu.org]

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

--- Comment #16 from CVS Commits  ---
The master branch has been updated by Kewen Lin :

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

commit r10-6591-g4d2248bec5d22061ab252724bd59d45c8a47e009
Author: Kewen Lin 
Date:   Tue Feb 11 23:22:02 2020 -0600

[IRA] Fix PR91052 by skipping multiple_sets insn in combine_and_move_insns

As PR91052's comments show, commit r272731 exposed one issue in function
combine_and_move_insns.  Function combine_and_move_insns perform the
unexpected movement which alter live interval of some register, leading
incorrect value to be used.  See PR91052 for details.

2020-02-12  Kewen Lin  
PR target/91052
* ira.c (combine_and_move_insns): Skip multiple_sets def_insn.

[Bug c++/93675] Starship operator on a hidden friend operator does not work

[mateusz.pusz at gmail dot com]

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

--- Comment #2 from Mateusz Pusz  ---
Thanks!

Mat

śr., 12 lut 2020, 01:09 użytkownik cvs-commit at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> napisał:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93675
>
> --- Comment #1 from CVS Commits  ---
> The master branch has been updated by Jason Merrill :
>
> https://gcc.gnu.org/g:d6ef77e023cfe0bb3b12b88ae46b77da356d7f85
>
> commit r10-6586-gd6ef77e023cfe0bb3b12b88ae46b77da356d7f85
> Author: Jason Merrill 
> Date:   Tue Feb 11 12:04:37 2020 +0100
>
> c++: Fix implicit friend operator==.
>
> It seems that in writing testcases for the operator<=> proposal I
> didn't
> include any tests for implicitly declared friend operator==, and
> consequently it didn't work.
>
> 2020-02-11  Jason Merrill  
>
> PR c++/93675
> * class.c (add_implicitly_declared_members): Use do_friend.
> * method.c (implicitly_declare_fn): Fix friend handling.
> (decl_remember_implicit_trigger_p): New.
> (synthesize_method): Use it.
> * decl2.c (mark_used): Use it.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug target/93694] Inconsistent grammar in darwin.opt

[roland.illig at gmx dot de]

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

--- Comment #1 from Roland Illig  ---
double space:
> architecture  \"name\"


unnecessarily verbose:
> Specify that the output file should be generated for architecture  "name"

Why not simply: Generate output file for the named architecture.


anachronism:
> MacOS X

Should that be macOS nowadays?


off-by-one:
> must record a greater

I think this should rather be "greater or equal".

[Bug target/93694] New: Inconsistent grammar in darwin.opt

[roland.illig at gmx dot de]

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

Bug ID: 93694
   Summary: Inconsistent grammar in darwin.opt
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From darwin.opt:
> Loads all members of archive libraries
> The version of ld64 in use for this toolchain.
> Produce an output file that will bind symbols on load, rather than lazily.
> Produce a Mach-O bundle (file type MH_BUNDLE)
> This will allow relocs

And a typo:
> exectuable

Unnecessarily unspecific wording:
> Allows setting the page 0 size to 4kb for certain special cases
What exactly are "certain special cases"?

The grammar in this file should be cleaned up and made consistent, as far as
possible.

[Bug analyzer/93692] Possible typo: supergraph vs. callgraph

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
The documentation does describe more what super means :).

[Bug gcov-profile/93626] [GCOV] incorrect coverage when compiled with option '-fsanitize=undefined' for typedef struct

[yangyibiao at hust dot edu.cn]

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

--- Comment #2 from Yibiao Yang  ---
(In reply to Martin Liška from comment #1)
> I would not recommend combining --coverage and a sanitizer.

Thanks for the suggestion. Yes, this is an abnormal combination.

[Bug analyzer/93692] Possible typo: supergraph vs. callgraph

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Note there is a -fdump-analyzer-supergraph so it looks like there is a copy and
paste issue.

[Bug gcov-profile/93693] New: [GCOV] incorrect coverage when compiled with option '-fsanitize=undefined' for function defined inside other function

[yangyibiao at hust dot edu.cn]

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

Bug ID: 93693
   Summary: [GCOV] incorrect coverage when compiled with option
'-fsanitize=undefined' for function defined inside
other function
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at hust dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gdb -v
GNU gdb (GDB) 9.0.50.20191210-git
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-shared
--enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
gcc version 9.2.0 (GCC)


$ cat small.c
int N1 = 0;

int foo(char a[2][++N1])
{
  N1 += 4; return sizeof(a[0]);
}

int bar(int N2)
{
  int foo1(char a[2][++N2])
  {
N2 += 4; return sizeof(a[0]);
  }

  foo1(0);
}

int main()
{
  foo(0); bar(0);
}

$ gcc -O0 --coverage -fsanitize=undefined small.c; ./a.out; gcov small.c; cat
small.c.gcov
File 'small.c'
Lines executed:100.00% of 9
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:1:int N1 = 0;
-:2:
1:3:int foo(char a[2][++N1])
-:4:{
1:5:  N1 += 4; return sizeof(a[0]);
-:6:}
-:7:
1:8:int bar(int N2)
-:9:{
2:   10:  int foo1(char a[2][++N2])
-:   11:  {
1:   12:N2 += 4; return sizeof(a[0]);
-:   13:  }
-:   14:
1:   15:  foo1(0);
1:   16:}
-:   17:
1:   18:int main()
-:   19:{
1:   20:  foo(0); bar(0);
-:   21:}


### We can find that: Line #3 is executed 1 times. foo is executed one time. 
### When function foo is defined inside other function, the coverage is
incorrect with compilation option "-fsanitize=undefined". (Line #10 is executed
2 times.) 
### While removing compilation option "-fsanitize=undefined", the coverage will
be correct. 

[Bug analyzer/93692] Possible typo: supergraph vs. callgraph

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-12
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-fdump-analyzer-callgraph

It does look like it should be call graph.  The documentation in invoke.texi is
correct.

[Bug analyzer/93692] New: Possible typo: supergraph vs. callgraph

[roland.illig at gmx dot de]

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

Bug ID: 93692
   Summary: Possible typo: supergraph vs. callgraph
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From analyzer.opts:
> fdump-analyzer-callgraph
> Common RejectNegative Var(flag_dump_analyzer_callgraph)
> Dump the analyzer supergraph to a SRCFILE.callgraph.dot file.

Should the "supergraph" be "callgraph" as well? As a user I would not know what
you mean by "supergraph". Is it "super" as in super hero, or in super set or
super class?

[Bug c/85957] i686: Integers appear to be different, but compare as equal

[bugdal at aerifal dot cx]

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

--- Comment #25 from Rich Felker  ---
I think standards-conforming excess precision should be forced on, and added to
C++; there are just too many dangerous ways things can break as it is now. If
you really think this is a platform of dwindling relevance (though I question
that; due to the way patent lifetimes work, the first viable open-hardware x86
clones will almost surely lack sse, no?) then we should not have dangerous
hacks for the sake of marginal performance gains, with too few people spending
the time to deal with their fallout.

I'd be fine with an option to change the behavior of constants, and have it set
by default for -std=gnu* as long as the unsafe behavior is removed from
-std=gnu*.

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

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from David Malcolm  ---
Should be fixed by the above commit.

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:91f993b7e31ce85676148dca180bc0d827d4245e

commit r10-6590-g91f993b7e31ce85676148dca180bc0d827d4245e
Author: David Malcolm 
Date:   Wed Feb 5 21:29:04 2020 -0500

analyzer: use ultimate alias target at calls (PR 93288)

PR analyzer/93288 reports an ICE in a C++ testcase when calling a
constructor.

The issue is that when building the supergraph, we encounter the
cgraph edge to "__ct_comp ", the DECL_COMPLETE_CONSTRUCTOR_P, and
this node's DECL_STRUCT_FUNCTION has a NULL CFG, which the analyzer
reads through, leading to the ICE.

This patch reworks function and fndecl lookup at calls throughout the
analyzer so that it looks for the ultimate_alias_target of the callee.
In the case above, this means using the "__ct_base " for the ctor,
which has a CFG, fixing the ICE.

Getting this right allows for some simple C++ cases involving ctors to
work, so the patch also adds some test coverage for that.

gcc/analyzer/ChangeLog:
PR analyzer/93288
* analysis-plan.cc (analysis_plan::use_summary_p): Look through
the ultimate_alias_target when getting the called function.
* engine.cc (exploded_node::on_stmt): Rename second "ctxt" to
"sm_ctxt".  Use the region_model's get_fndecl_for_call rather than
gimple_call_fndecl.
* region-model.cc (region_model::get_fndecl_for_call): Use
ultimate_alias_target on fndecl.
* supergraph.cc (get_ultimate_function_for_cgraph_edge): New
function.
(supergraph_call_edge): Use it when rejecting edges without
functions.
(supergraph::supergraph): Use it to get the function for the
cgraph_edge when building interprocedural superedges.
(callgraph_superedge::get_callee_function):  Use it.
* supergraph.h (supergraph::get_num_snodes): Make param const.
(supergraph::function_to_num_snodes_t): Make first type param
const.

gcc/testsuite/ChangeLog:
PR analyzer/93288
* g++.dg/analyzer/malloc.C: Add test coverage for a double-free
called in a constructor.
* g++.dg/analyzer/pr93288.C: New test.

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:35e24106fc1b782e70f8339e0a1321a2bc7a7f15

commit r10-6588-g35e24106fc1b782e70f8339e0a1321a2bc7a7f15
Author: David Malcolm 
Date:   Thu Nov 21 12:30:45 2019 -0500

analyzer: g++ testsuite support

PR analyzer/93288 reports a C++-specific ICE with -fanalyzer.

This patch creates the beginnings of a C++ test suite for the analyzer,
so that there's a place to put test coverage for the fix.
It adds a regression test for PR analyzer/93212, an ICE fixed
in r10-5970-g32077b693df8e3ed0424031a322df23822bf2f7e.

gcc/testsuite/ChangeLog:
PR analyzer/93212
* g++.dg/analyzer/analyzer.exp: New subdirectory and .exp suite.
* g++.dg/analyzer/malloc.C: New test.
* g++.dg/analyzer/pr93212.C: New test.

[Bug analyzer/93212] internal compiler error: in make_region_for_type, at analyzer/region-model.cc:5961

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:35e24106fc1b782e70f8339e0a1321a2bc7a7f15

commit r10-6588-g35e24106fc1b782e70f8339e0a1321a2bc7a7f15
Author: David Malcolm 
Date:   Thu Nov 21 12:30:45 2019 -0500

analyzer: g++ testsuite support

PR analyzer/93288 reports a C++-specific ICE with -fanalyzer.

This patch creates the beginnings of a C++ test suite for the analyzer,
so that there's a place to put test coverage for the fix.
It adds a regression test for PR analyzer/93212, an ICE fixed
in r10-5970-g32077b693df8e3ed0424031a322df23822bf2f7e.

gcc/testsuite/ChangeLog:
PR analyzer/93212
* g++.dg/analyzer/analyzer.exp: New subdirectory and .exp suite.
* g++.dg/analyzer/malloc.C: New test.
* g++.dg/analyzer/pr93212.C: New test.

[Bug tree-optimization/93682] Wrong optimization: on x87 -fexcess-precision=standard is incompatible with -mpc64

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
On Tue, 11 Feb 2020, bugdal at aerifal dot cx wrote:

> I think the underlying issue here is just that -mpc64 (along with -mpc32) is
> just hopelessly broken and should be documented as such. It could probably be
> made to work, but there are all sorts of issues like float.h being wrong, math
> library code breaking, etc.

Correct.  It's a link-only option that breaks fundamental compile-time 
assumptions about how the processor behaves.

> On a more fundamental level (but seemingly unrelated to the mechanism of
> breakage here), the underlying x87 precision control modes are also hopelessly
> broken. They're not actually single/double precision modes, but single/double
> mantissa with ld80 exponent. So I don't think it's possible to make the
> optimizer aware of them without making it aware of two new floating point
> formats that it doesn't presently know about. If you just pretended they were

Actually GCC does know about one of those formats (see 
ieee_extended_intel_96_round_53_format in real.c - apparently this is used 
by 32-bit FreeBSD).

[Bug c/85957] i686: Integers appear to be different, but compare as equal

[joseph at codesourcery dot com]

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

--- Comment #24 from joseph at codesourcery dot com  ---
On Tue, 11 Feb 2020, ch3root at openwall dot com wrote:

> So, yeah, it seems integers have to be stable. OTOH, now that there is sse and
> there is -fexcess-precision=standard floating-point values are mostly stable
> too. Perhaps various optimizations done for integers could be enabled for FPs
> too? Or the situation is more complicated?

Well, 0.0 == -0.0 but it's not valid to substitute one for the other (and 
similarly with decimal quantum exponents), for example, so floating-point 
certainly has different rules for what's valid in this area.

I think fewer and fewer people care about x87 floating point nowadays; 
32-bit libraries are primarily for running old binaries, not new code.  
So x87 excess precision issues other than maybe the ABI ones for excess 
precision returns from standard library functions will become irrelevant 
in practice as people build 32-bit libraries with SSE (cf. 
),
 
and even the ABI ones will disappear in the context of builds with SSE as 
the remaining float and double not-bound-to-IEEE754-operations glibc libm 
functions with .S implementations move to C implementations once there are 
suitably optimized C implementations that prove faster in benchmarking.  
I'd encourage people who care about reliability with floating point on 
32-bit x86 to do that benchmarking work to justify such removals of 
x86-specific assembly.

However, if you want to fix such issues in GCC, it might be plausible to 
force the standard-conforming excess precision handling to always-on for 
x87 floating point (maybe except for the part relating to constants, since 
that seems to confuse users more).  There would still be the question of 
what to do with -mfpmath=sse+387.

[Bug fortran/93690] Type Bound Generic Assignment Bug Using Intrinsic Assignments

[floschiffmann at gmail dot com]

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

Florian Schiffmann  changed:

   What|Removed |Added

 CC||floschiffmann at gmail dot com

--- Comment #3 from Florian Schiffmann  ---
Hi Steve,

the complication here is that it is not the type with the assignment that is a
vector but the Outer type. The type with assignment is a scalar member of the
vector type. Hence the first question should be how the intrinsic assignment of
the vector of Type(outer) is handled.

Thanks to FortranFan on the comp.lang.fortran group:

cite 
[Note 18-007r1 document toward Fortran 2018 states in Section 10.2.1.3
Interpretation of intrinsic assignments, page 161, paragraph 6:

"If the variable is an array, the assignment is performed element-by-element on
corresponding array elements of the variable and expr"

and on page 163, paragraph 13:

"An intrinsic assignment where the variable is of derived type is performed as
if each component of the variable were assigned from the corresponding
component of expr using .. defined assignment for each nonpointer 
nonallocatable component of a type that has a type-bound defined assignment
consistent with the component, intrinsic assignment for each other nonpointer
nonallocatable component .." ]

According to me, this means that the intrinsic assignment working on outer
should work element wise. Then for each element the scalar assignment should be
called (not the vector version).

I can't say I am sure about it either as reading the standard gives me a
headache :). However, to me it makes sense as 

with my interpretation:
You have to inspect the Types containing the one with TBA
vs your interpretation:
You have to inspect the Types containing the one with TBA plus all direct and
indirect uses of the types (if vectors or not)

to decide whether the assignment has to be an elemental subroutine. 
Not sure whether I made perfect sense there but I hope you can decipher my
idea.

Flo

[Bug rtl-optimization/93565] [9/10 regression] Combine duplicates instructions

[segher at gcc dot gnu.org]

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

--- Comment #13 from Segher Boessenkool  ---
nonzero_bits is not reliable.  We also cannot really do what you propose
here, all of this is done for *every* combination.

We currently generate

(set (reg/v:SI 96 [ a ])
(and:SI (reg:SI 104)
(const_int 14 [0xe])))
(set (reg:DI 99 [ a ])
(and:DI (subreg:DI (reg:SI 104) 0)
(const_int 14 [0xe])))

If we can somehow see the first one is just the lowpart subreg of the second,
we can handle it the same as the first case.

[Bug fortran/93690] Type Bound Generic Assignment Bug Using Intrinsic Assignments

[floschiffmann at gmail dot com]

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

--- Comment #2 from Florian Schiffmann  ---
Hi Steve,

the complication here is that it is not the type with the assignment that is a
vector but the Outer type. The type with assignment is a scalar member of the
vector type. Hence the first question should be how the intrinsic assignment of
the vector of Type(outer) is handled.

Thanks to FortranFan on the comp.lang.fortran group:

cite 
[Note 18-007r1 document toward Fortran 2018 states in Section 10.2.1.3
Interpretation of intrinsic assignments, page 161, paragraph 6:

"If the variable is an array, the assignment is performed element-by-element on
corresponding array elements of the variable and expr"

and on page 163, paragraph 13:

"An intrinsic assignment where the variable is of derived type is performed as
if each component of the variable were assigned from the corresponding
component of expr using .. defined assignment for each nonpointer 
nonallocatable component of a type that has a type-bound defined assignment
consistent with the component, intrinsic assignment for each other nonpointer
nonallocatable component .." ]

According to me, this means that the intrinsic assignment working on outer
should work element wise. Then for each element the scalar assignment should be
called (not the vector version).

I can't say I am sure about it either as reading the standard gives me a
headache :). However, to me it makes sense as 

with my interpretation:
You have to inspect the Types containing the one with TBA
vs your interpretation:
You have to inspect the Types containing the one with TBA plus all direct and
indirect uses of the types (if vectors or not)

to decide whether the assignment has to be an elemental subroutine. 
Not sure whether I made perfect sense there but I hope you can decipher my
idea.

Flo

[Bug c++/93675] Starship operator on a hidden friend operator does not work

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

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

commit r10-6586-gd6ef77e023cfe0bb3b12b88ae46b77da356d7f85
Author: Jason Merrill 
Date:   Tue Feb 11 12:04:37 2020 +0100

c++: Fix implicit friend operator==.

It seems that in writing testcases for the operator<=> proposal I didn't
include any tests for implicitly declared friend operator==, and
consequently it didn't work.

2020-02-11  Jason Merrill  

PR c++/93675
* class.c (add_implicitly_declared_members): Use do_friend.
* method.c (implicitly_declare_fn): Fix friend handling.
(decl_remember_implicit_trigger_p): New.
(synthesize_method): Use it.
* decl2.c (mark_used): Use it.

[Bug tree-optimization/93683] [10 Regression] ICE in ao_ref_init_from_ptr_and_size, at tree-ssa-alias.c:714

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Committed in r10-6585.

[Bug tree-optimization/93683] [10 Regression] ICE in ao_ref_init_from_ptr_and_size, at tree-ssa-alias.c:714

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:9a5338e57db1cda13fa788b0e0debbcf99a475d6

commit r10-6585-g9a5338e57db1cda13fa788b0e0debbcf99a475d6
Author: Martin Sebor 
Date:   Tue Feb 11 16:53:13 2020 -0700

PR tree-optimization/93683 - ICE on calloc with unused return value in
ao_ref_init_from_ptr_and_size

gcc/testsuite/ChangeLog:

PR tree-optimization/93683
* gcc.dg/tree-ssa/ssa-dse-39.c: New test.

gcc/ChangeLog:

PR tree-optimization/93683
* tree-ssa-alias.c (stmt_kills_ref_p): Avoid using LHS when not set.

[Bug fortran/93691] New: Type bound assignment causes too many finalization of derived type when part of other type

[floschiffmann at gmail dot com]

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

Bug ID: 93691
   Summary: Type bound assignment causes too many finalization of
derived type when part of other type
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: floschiffmann at gmail dot com
  Target Milestone: ---

Good morning,

when writing a reference counting scheme, I cam across this slightly intricate
bug. I suspect this is related to a problem in the type bound assignment but I
could not pin it down.

The problem:
Type(Inner) has type bound assignment and Final.
   -assignment associates output reference counter to input reference counter
and incrments
   -final decrements reference counter and deallocates reference count pointer
when 0

Type(outer) has type(inner) as member.

If Type(inner) is used by itself everything works correctly
However, if assignment of type(outer) to type(outer) is made, an additional
finalization is invoked (the third with an unassociated reference counter).

Here is the simplest test code I could produce:

! ==  BEGIN TEST CODE 

MODULE Classes
IMPLICIT NONE

TYPE   :: Inner
   INTEGER, POINTER  :: icount
   CONTAINS
   PROCEDURE :: init
   PROCEDURE :: assignMe
   GENERIC   :: assignment(=) => assignMe
   FINAL :: deleteIt
END TYPE

   TYPE Outer
  TYPE(Inner):: ext
   END TYPE
CONTAINS
   SUBROUTINE init(self)
  CLASS(Inner), INTENT(INOUT)  ::  self

  ALLOCATE(self%icount)
  self%icount=1
   END SUBROUTINE 

! Destrutor, if data is assigned decrement counter and delete once we reach 0
   SUBROUTINE deleteIt(self)
  TYPE(Inner)  ::  self

WRITE(*,*)"FINAL CALLED with icount =", self%icount, "LOC =",LOC(self%icount)
 self%icount=self%icount-1
 IF(self%icount<=0)THEN ! usually == 0 but <=0 better shows the problem
self%icount=-100
WRITE(*,*)"  DEALLOCATING ICOUNT at LOC=", LOC(self%icount)
DEALLOCATE(self%icount)
 END IF
   END SUBROUTINE

! The basic assigment routine, set pointer to input data pointer and increment
counter 
   SUBROUTINE assignMe(self, input)
  CLASS(Inner), INTENT(INOUT)  ::  self
  CLASS(Inner), INTENT(IN)  ::  input
 self%icount => input%icount
 self%icount=self%icount+1
   END SUBROUTINE


END MODULE

PROGRAM test

   USE Classes

IMPLICIT NONE

WRITE(*,*)"Direct Call on inner performs only 2 FINALIZATIONS"
   BLOCK
  TYPE(Inner)  :: inner1, inner2
  CALL inner1%init()
  inner2=inner1
   END BLOCK
WRITE(*,*)
WRITE(*,*)"Indirect Call, 3 FINALIZATIONS, last with dangling pointer on
TYPE(inner)%icount"
   BLOCK
  TYPE(Outer)  :: Outer1, Outer2
  CALL Outer1%ext%init()
  Outer2=Outer1
   END BLOCK 
END 

!= END TEST CODE 


 Note: in Final comparison is for <= 0 to cause double free

best regards
Flo

[Bug tree-optimization/93681] Wrong optimization: instability of x87 floating-point results leads to nonsense

[ch3root at openwall dot com]

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

Alexander Cherepanov  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=323,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=85957,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=93682

--- Comment #3 from Alexander Cherepanov  ---
Bug 85957 is definitely similar. I've added it and a couple of others to "See
Also".

Some differences:
- testcases here use comparisons to jump from FPs to integers while bug 85957
uses casts;
- the exploited discrepancy here is between in-register and in-memory
(run-time) results of type `double` while in bug 85957 it's between
compile-time and run-time results;
- it's probably possible to fix bug 85957 by enhancing the dom2 pass while it
will probably not help here.
Whether it warrants a separate bug report it's hard for me to say.

[Bug fortran/93690] Type Bound Generic Assignment Bug Using Intrinsic Assignments

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Florian Schiffmann from comment #0)
> Good morning,
> 
> I ran across a problem when using a Type bound assignment (TBA). I have two
> type, the type with TBA type(Inner), and type (Outer) which has inner as a
> member. If now Type(outer) is assigned to another type(outer), the Inner
> assignment is only called if it is done elementwise. The vector assignment
> does not call the type(Inner) assignment. As I understand the standard, the
> vector assignment should call the TBA element by element.
> 
> As a side note, the assignment is called if assignMe is made ELEMENTAL
> IMPURE. While nice as a work around, I can't see an obvious reason why this
> would be the correct behavior.
> 

Thanks for reporting the possible bug.

I think the standard requires the ELEMENTAL IMPURE.  In the
following x1 and x2 are the left and right hand sides of the
assignment.  d1 and d2 are the dummy arguments of the subroutine.


10.2.1.4 Defined assignment statement

A subroutine defines the defined assignment x1 = x2 if

  (1) ok
  (2) ok
  (3) ok
  (4) ok

  (5) either

 (a) the ranks of x1 and x2 match those of d1 and d2 or
 (b) the subroutine is elemental, x2 is scalar or has the same
 rank as x1, and there is no other subroutine that defines
 the assignment.

The dummy arguments are scalars, which is rank 0.  The ranks of
x1 and x2 are 1.  5a clear fails, so we fall through to 5b, which
suggests that ELEMENTAL is needed.  IMPURE is needed as you're
doing IO from assignMe.

Note, I could be wrong.

[Bug c++/93689] ICE with default argument in lambda used as non type template argument

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Actually the issue might be just one, even the gimplifier ICE seems to be
caused by a CAST_EXPR leaking where it should not.  Maybe we fail to substitute
default arguments in lambdas in a template parameter list.

[Bug tree-optimization/93683] [10 Regression] ICE in ao_ref_init_from_ptr_and_size, at tree-ssa-alias.c:714

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00680.html

[Bug c++/93689] ICE with default argument in lambda used as non type template argument

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
That's hard to say without really understanding what the issue is, but I'm
afraid this might not be the best first issue -- it involves some pretty
convoluted features, plus it seems there are two issues (that
maybe_constant_value gets a template code and the gimplifier ICE).  "Luckily"
we have over 3000 C++ issues and some of them should be more straightforward:

https://gcc.gnu.org/bugzilla/buglist.cgi?component=c%2B%2B=0_id=240106=gcc_format=advanced=---=bug_id%20DESC_based_on=

Note that we're in stage 4 now, meaning that we only fix regressions.  Good
luck.

[Bug fortran/93690] New: Type Bound Generic Assignment Bug Using Intrinsic Assignments

[floschiffmann at gmail dot com]

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

Bug ID: 93690
   Summary: Type Bound Generic Assignment Bug Using Intrinsic
Assignments
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: floschiffmann at gmail dot com
  Target Milestone: ---

Good morning,

I ran across a problem when using a Type bound assignment (TBA). I have two
type, the type with TBA type(Inner), and type (Outer) which has inner as a
member. If now Type(outer) is assigned to another type(outer), the Inner
assignment is only called if it is done elementwise. The vector assignment does
not call the type(Inner) assignment. As I understand the standard, the vector
assignment should call the TBA element by element.

As a side note, the assignment is called if assignMe is made ELEMENTAL IMPURE.
While nice as a work around, I can't see an obvious reason why this would be
the correct behavior.

Here is the test code, which shows this behavior 

! Example start =
MODULE Classes
IMPLICIT NONE

TYPE Inner
   CONTAINS
   PROCEDURE :: assignMe
   GENERIC   :: assignment(=) => assignMe 
END TYPE

TYPE Outer
   TYPE(Inner):: mInner
END TYPE
CONTAINS

   SUBROUTINE assignMe(self, input)
  CLASS(Inner), INTENT(OUT)  ::  self
  CLASS(Inner), INTENT(IN)  ::  input

  WRITE(*,*)"ASSIGNMENT CALLED"   
   END SUBROUTINE

END MODULE

PROGRAM test
   USE Classes
   IMPLICIT NONE
   TYPE(Outer)  :: mOuter(1), reassigned(1)

WRITE(*,*)"Intrinsic assignment works when called element wise"
   reassigned(1)=mOuter(1)
WRITE(*,*)"Does not work when called as vector assignment"
   reassigned=mOuter

END PROGRAM
! Example end =

best regards

Flo

[Bug c++/93689] ICE with default argument in lambda used as non type template argument

[malle at umich dot edu]

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

--- Comment #3 from malle at umich dot edu ---
@Marek Polacek do you (or anyone) think this is a good first issue?  I am
curious to try contributing.

[Bug rtl-optimization/93565] [9/10 regression] Combine duplicates instructions

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
(In reply to Segher Boessenkool from comment #11)
> (The original problem I have an idea for -- don't generate a parallel of
> two SETs with equal SET_SRC -- but that doesn't handle the new case).

For the new case, nonzero_bits should find out that the sign_extension is the
same thing as zero_extension and it would be best to just do a single and e.g.
on a paradoxical subreg of the source and a pseudo copy.

[Bug c++/93689] ICE with default argument in lambda used as non type template argument

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
The test was rejected with various errors, then with
r9-4045-g0c1e0d63fe0ceabbd04384070f3b59f8bf50de09 we got this ICE:

93689.C: In function ‘int f() [with auto Z = main()::{}]’:
93689.C:5:13: internal compiler error: in gimplify_expr, at gimplify.c:12491
5 | return Z();
  |~^~
0x6dbdf3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/mpolacek/src/gcc9/gcc/gimplify.c:12491
0xceaa9d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/mpolacek/src/gcc9/gcc/gimplify.c:13226
0xcf3ce4 gimplify_expr
/home/mpolacek/src/gcc9/gcc/gimplify.c:13512
0xcf5965 gimplify_call_expr
/home/mpolacek/src/gcc9/gcc/gimplify.c:3405
...

and since r10-6527-gaaa26bf496a646778ac861aed124d960b5bf549f the ICE in Comment
1.

[Bug rtl-optimization/93565] [9/10 regression] Combine duplicates instructions

[segher at gcc dot gnu.org]

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

--- Comment #11 from Segher Boessenkool  ---
(The original problem I have an idea for -- don't generate a parallel of
two SETs with equal SET_SRC -- but that doesn't handle the new case).

[Bug rtl-optimization/93565] [9/10 regression] Combine duplicates instructions

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool  ---
One of the first things combine tries is

Trying 7 -> 8:
7: r96:SI=r104:SI&0xe
  REG_DEAD r104:SI
8: r99:DI=sign_extend(r96:SI)
...
Successfully matched this instruction:
(set (reg/v:SI 96 [ a ])
(and:SI (reg:SI 104)
(const_int 14 [0xe])))
Successfully matched this instruction:
(set (reg:DI 99 [ a ])
(and:DI (subreg:DI (reg:SI 104) 0)
(const_int 14 [0xe])))
allowing combination of insns 7 and 8
original costs 4 + 4 = 8
replacement costs 4 + 4 = 8
modifying insn i2 7: r96:SI=r104:SI&0xe
deferring rescan insn with uid = 7.
modifying insn i3 8: r99:DI=r104:SI#0&0xe
  REG_DEAD r104:SI
deferring rescan insn with uid = 8.

Since combine is a greedy optimisation, what it ends up with depends on the
order it tries things in.  Any local minimum it finds can prevent it from
finding a more global minimum.  In that sense, this is not a regression.

How do you propose we could generate better code for this case?  Without
regressing everything else.

[Bug rtl-optimization/93565] [9/10 regression] Combine duplicates instructions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-11
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |9.3
 Ever confirmed|0   |1

--- Comment #9 from Jakub Jelinek  ---
The #c8 testcase on x86_64-linux -O2 regressed with
r9-2064-gc4c5ad1d6d1e1e1fe7a1c2b3bb097cc269dc7306

[Bug c++/93689] ICE with default argument in lambda used as non type template argument

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

$ ./cc1plus -quiet  93689.C -std=c++2a 
93689.C: In instantiation of ‘int f() [with auto Z = main()::{}]’:
93689.C:9:14:   required from here
93689.C:5:14: internal compiler error: unexpected expression ‘(int)(0)’ of kind
cast_expr
5 | return Z();
  |  ^
0x9a013c cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:6203
0x98cafa cxx_bind_parameters_in_call
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:1522
0x99018a cxx_eval_call_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:2291
0x99ce51 cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:5395
0x9a14a5 cxx_eval_outermost_constant_expr
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:6404
0x9a2641 maybe_constant_value(tree_node*, tree_node*, bool, bool)
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:6692
0xa94da4 fold_for_warn(tree_node*)
/home/mpolacek/src/gcc/gcc/cp/expr.c:401
0xcb3a85 maybe_warn_about_returning_address_of_local
/home/mpolacek/src/gcc/gcc/cp/typeck.c:9472
0xcb6c2f check_return_expr(tree_node*, bool*)
/home/mpolacek/src/gcc/gcc/cp/typeck.c:10081
0xc358a5 finish_return_stmt(tree_node*)
/home/mpolacek/src/gcc/gcc/cp/semantics.c:955
0xbe0b11 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:17691
0xbe3622 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:17999
0xc07109 instantiate_decl(tree_node*, bool, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:25523
0xc07ac6 instantiate_pending_templates(int)
/home/mpolacek/src/gcc/gcc/cp/pt.c:25639
0xa6c433 c_parse_final_cleanups()
/home/mpolacek/src/gcc/gcc/cp/decl2.c:4875
0xd4adb6 c_common_parse_file()
/home/mpolacek/src/gcc/gcc/c-family/c-opts.c:1208

[Bug c++/93191] Conversions to arrays of unknown bound P0388 Fails for variadic args

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-02-11
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Not quite sure if this is valid: clang++ (trunk) accepts (with -std=c++2a)

void cat(const auto(&...s)[6]) { }
using punk = char(*)[];

int
main ()
{
  cat("Hello","world");
}

but not

void cat(const auto(&...s)[]) { }
using punk = char(*)[];

int
main ()
{
  cat("Hello","world");
}

[Bug c++/93689] New: ICE with default argument in lambda used as non type template argument

[malle at umich dot edu]

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

Bug ID: 93689
   Summary: ICE with default argument in lambda used as non type
template argument
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: malle at umich dot edu
  Target Milestone: ---

This code

```
template <
auto Z = [](int l = int(0)) -> int { return l; }
>
int f() {
return Z();
}

int main() {
return f();
}
```

causes this error

```
: In function 'int f() [with auto Z = main()::{}]':
:5:13: internal compiler error: in gimplify_expr, at gimplify.c:12489
5 | return Z();
  |~^~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
ASM generation compiler returned: 1
```

from `g++ (Compiler-Explorer-Build) 9.2.0` compiled with these options

```
-g -o /tmp/compiler-explorer-compiler120111-1689-nlrcj.y9iua/output.s
-fdiagnostics-color=always -Wl,-rpath,/opt/compiler-explorer/gcc-9.2.0/lib
-Wl,-rpath,/opt/compiler-explorer/gcc-9.2.0/lib32
-Wl,-rpath,/opt/compiler-explorer/gcc-9.2.0/lib64 -std=c++2a
/tmp/compiler-explorer-compiler120111-1689-nlrcj.y9iua/example.cpp
```

See it on the compiler explorer: https://godbolt.org/z/TD8aHC



The reason I want to do this is to get source_location::current from an
operator+'s call site.  Since the operator cannot take an extra argument, I
tried template arguments and then a template argument lambda that returns a
source location.

[Bug fortran/93678] ICE in 9.2/9.2.1 not happening in previous gfortran versions

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
  Known to fail||10.0, 8.3.1, 9.2.1

[Bug fortran/93678] ICE in 9.2/9.2.1 not happening in previous gfortran versions

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Reduced testcase.

Have no idea if original code and/or this testcase is valid Fortran.
My suspicion is that the original code is invalid.

module mo_a

   implicit none

   type t_b
  integer n
  contains
 procedure :: unpackint => b_unpackint
 procedure :: unpackbytes => b_unpackbytes  
   end type t_b

   contains

  function b_unpackbytes(me, s) result(res)
 class(t_b), intent(inout) :: me
 character, intent(in) :: s(:)
 character, pointer :: res(:)
 res => null()
 if (len(s) == 1) me%n = 42
  end function b_unpackbytes

  subroutine b_unpackint(me, val)
 class(t_b), intent(inout) :: me
 integer, intent(out) :: val
 character :: c(1)
 c = transfer(val, c)
 val = transfer(me%unpackbytes(c),  val)
  end subroutine b_unpackint
end module mo_a

[Bug c++/93688] Add mcf thread model to GCC on windows for supporting C++11 std::thread?

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
.

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

[Bug c++/93687] Add mcf thread model to GCC on windows for supporting C++11 std::thread?

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
*** Bug 93688 has been marked as a duplicate of this bug. ***

[Bug c++/93688] New: Add mcf thread model to GCC on windows for supporting C++11 std::thread?

[euloanty at live dot com]

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

Bug ID: 93688
   Summary: Add mcf thread model to GCC on windows for supporting
C++11 std::thread?
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

MCF gthread is an NT syscall level of std::thread on windows to support POSIX
semantics. 

https://github.com/lhmouse/mcfgthread/wiki

https://github.com/lhmouse/MINGW-packages/commit/e9d259d606ff9e6e5353ea8834d2689e752bb67e

https://bitbucket.org/ejsvifq_mabmip/mingw-gcc-mcf-gthread/src/master/9000-master-Added-mcf-thread-model-support-from-mcfgthread.patch

https://gcc-mcf.lhmouse.com/

I think this patch should be merged into GCC trunk to support mcf thread model
on windows. Or GCC won't magically compile on windows because lack of
std::thread support

[Bug c++/93687] New: Add mcf thread model to GCC on windows for supporting C++11 std::thread?

[euloanty at live dot com]

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

Bug ID: 93687
   Summary: Add mcf thread model to GCC on windows for supporting
C++11 std::thread?
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

Created attachment 47819
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47819=edit
Officially support std::thread on windows

MCF gthread is an NT syscall level of std::thread on windows to support POSIX
semantics. 

https://github.com/lhmouse/mcfgthread/wiki

https://github.com/lhmouse/MINGW-packages/commit/e9d259d606ff9e6e5353ea8834d2689e752bb67e

https://bitbucket.org/ejsvifq_mabmip/mingw-gcc-mcf-gthread/src/master/9000-master-Added-mcf-thread-model-support-from-mcfgthread.patch

https://gcc-mcf.lhmouse.com/

I think this patch should be merged into GCC trunk to support mcf thread model
on windows. Or GCC won't magically compile on windows because lack of
std::thread support

[Bug c++/93684] [8/9/10 Regression] ICE in cp_lexer_consume_token, at cp/parser.c:1120

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug tree-optimization/93681] Wrong optimization: instability of x87 floating-point results leads to nonsense

[tavianator at gmail dot com]

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

Tavian Barnes  changed:

   What|Removed |Added

 CC||tavianator at gmail dot com

--- Comment #2 from Tavian Barnes  ---
Similar to (dupe of?) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957

[Bug c++/93684] [8/9/10 Regression] ICE in cp_lexer_consume_token, at cp/parser.c:1120

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Goes back to r0-119371-ge28d52cffbb2abc7a5764ed4c97a25c376913fee

[Bug c++/90938] [9/10 Regression] Initializing array with {1} works, but not {0}

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #12 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00676.html

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

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
(In reply to David Binderman from comment #4)
> I tried out -fanalyzer with all the C code under gcc/testsuite.
> 
> There are 35368 C source code files. 234 crashes so far.
> 
> Here are the first ten:

Thanks.

These look like duplicates: I tried to repeat this with current master by
adding -fanalyzer to gcc.dg/dg.exp's DEFAULT_CFLAGS, and I didn't see any
crashes with:
  make check-gcc RUNTESTFLAGS="-v -v --target_board=unix\{-m32,-m64\} dg.exp=*"

=== gcc Summary ===

# of expected passes54990
# of unexpected failures9
# of expected failures  654
# of unsupported tests  328

The unexpected failures were warnings from the analyzer, which appear valid:

gcc.dg/2111-1.c (test for excess errors)
  gcc.dg/2111-1.c:9:10: warning: use of uninitialized value 'p' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
(warning looks valid)

gcc.dg/2906-1.c (test for excess errors)
   gcc.dg/2906-1.c:11:25: warning: use of uninitialized value 'lp.v'
[CWE-457] [-Wanalyzer-use-of-uninitialized-value]
 (not sure about this one)

gcc.dg/loop-1.c (test for excess errors)
   gcc.dg/loop-1.c:17:17: warning: use of uninitialized value 'prod' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
(warning looks valid)

gcc.dg/pr71558.c (test for excess errors)
   gcc.dg/pr71558.c:16:10: warning: use of possibly-NULL 'c' where non-null
expected [CWE-690] [-Wanalyzer-possible-null-argument]
(warning looks valid)

gcc.dg/pr93661.c  (test for warnings, line 7)
  looks like a pre-existing 32-bit vs 64-bit issue with the test

[Bug tree-optimization/93683] [10 Regression] ICE in ao_ref_init_from_ptr_and_size, at tree-ssa-alias.c:714

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
It looks like the new code simply assumes the LHS is non-zero when it need not
be.

[Bug tree-optimization/93683] [10 Regression] ICE in ao_ref_init_from_ptr_and_size, at tree-ssa-alias.c:714

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-11
 CC||msebor at gcc dot gnu.org
  Component|c   |tree-optimization
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Bisection points to r272717:

commit 3fe0ddc88334f9afd622458653a6d103948994bd
Author: Jeff Law 
Date:   Wed Jun 26 15:36:27 2019 -0600

re PR tree-optimization/90883 (Generated code is worse if returned struct
is unnamed)

PR tree-optimization/90883
* tree-ssa-alias.c (stmt_kills_ref_p): Handle BUILT_IN_CALLOC.
* tree-ssa-dse.c: Update various comments to distinguish between
dead and redundant stores.
(initialize_ao_ref_for_dse): Handle BUILT_IN_CALLOC.
(dse_optimize_redundant_stores): New function.
(delete_dead_or_redundant_call): Renamed from delete_dead_call.
Distinguish between dead and redundant calls in dump output.  All
callers updated.
(delete_dead_or_redundant_assignment): Similarly for assignments.
(dse_optimize_stmt): Handle _CHK variants.  For statements which
store 0 into multiple memory locations, try to prove a subsequent
store is redundant.

PR tree-optimization/90883
* g++.dg/tree-ssa/pr90883.C: New test.
* gcc.dg/tree-ssa/ssa-dse-36.c: New test.

From-SVN: r272717

[Bug c++/93668] constexpr delete[]

[euloanty at live dot com]

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

--- Comment #7 from fdlbxtqi  ---
I mean it is a bug.

constexpr int f()
{
auto p(new int[1]);
delete p;
return 4;
}

int main()
{
constexpr auto w(f());
}

I mean this is UB so it should not compile. However, it compiles on the latest
GCC.

Not detecting this is a series of security vulnerabilities if people using it
at runtime.

[Bug fortran/93686] [9/10 Regression] ICE in gfc_match_data, at fortran/decl.c:702

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

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #1 from G. Steinmetz  ---

Additional test cases :


$ cat z2.f90
program p
   type t
  integer :: a = 1
   end type
   type(t), pointer :: x
   data x /t(2)/
end


$ cat z3.f90
program p
   type t
   end type
   type(t), pointer :: x
   data x /t()/
end


$ cat z4.f90
type t
end type
type(t), pointer :: x
data x /
end

[Bug fortran/93686] New: [9/10 Regression] ICE in gfc_match_data, at fortran/decl.c:702

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

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

Bug ID: 93686
   Summary: [9/10 Regression] ICE in gfc_match_data, at
fortran/decl.c:702
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

This changed between 20190106 and 20190113 :


$ cat z1.f90
program p
   type t
  integer :: a
   end type
   type(t), pointer :: x
   data x /t(2)/
end


$ gfortran-9-20190106 -c z1.f90 -O2
$
$ gfortran-10-20200209 -c z1.f90
f951: internal compiler error: Segmentation fault
0xbae4bf crash_signal
../../gcc/toplev.c:328
0x635f2c gfc_match_data()
../../gcc/fortran/decl.c:702
0x69ed71 match_word
../../gcc/fortran/parse.c:65
0x6a2dce decode_statement
../../gcc/fortran/parse.c:469
0x6a3b3a next_free
../../gcc/fortran/parse.c:1279
0x6a3b3a next_statement
../../gcc/fortran/parse.c:1511
0x6a518b parse_spec
../../gcc/fortran/parse.c:3922
0x6a7f5c parse_progunit
../../gcc/fortran/parse.c:5851
0x6a9639 gfc_parse_file()
../../gcc/fortran/parse.c:6392
0x6f42bf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug fortran/93685] New: [9/10 Regression] ICE in gfc_constructor_append_expr, at fortran/constructor.c:135

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

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

Bug ID: 93685
   Summary: [9/10 Regression] ICE in gfc_constructor_append_expr,
at fortran/constructor.c:135
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20180513 and 20180527 :


$ cat z1.f90
program p
   type t
  character :: a
   end type
   type(t) :: x
   character, target :: c = 'c'
   data x%a /c/
end


$ gfortran-9-20180513 -c z1.f90
z1.f90:7:14:

data x%a /c/
  1
Error: Symbol 'c' must be a PARAMETER in DATA statement at (1)


$ gfortran-10-20200209 -c z1.f90
f951: internal compiler error: Segmentation fault
0xbae4bf crash_signal
../../gcc/toplev.c:328
0x62f28b gfc_constructor_append_expr(splay_tree_s**, gfc_expr*, locus*)
../../gcc/fortran/constructor.c:135
0x63102c formalize_structure_cons
../../gcc/fortran/data.c:645
0x63102c formalize_init_expr
../../gcc/fortran/data.c:682
0x6df832 do_traverse_symtree
../../gcc/fortran/symbol.c:4146
0x6b77a3 resolve_types
../../gcc/fortran/resolve.c:17150
0x6bb34c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17237
0x6a96bc resolve_all_program_units
../../gcc/fortran/parse.c:6245
0x6a96bc gfc_parse_file()
../../gcc/fortran/parse.c:6492
0x6f42bf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug c++/93684] New: [8/9/10 Regression] ICE in cp_lexer_consume_token, at cp/parser.c:1120

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

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

Bug ID: 93684
   Summary: [8/9/10 Regression] ICE in cp_lexer_consume_token, at
cp/parser.c:1120
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to r6 (no shorter example found) :

$ cat z1.cc
[[a::


$ g++-5 -c z1.cc
z1.cc:1:1: error: expected unqualified-id before '[' token
 [[a::
 ^
$
$ g++-10-20200209 -c z1.cc
z1.cc:1:4: internal compiler error: in cp_lexer_consume_token, at
cp/parser.c:1120
1 | [[a::
  |^~
0x6e6097 cp_lexer_consume_token
../../gcc/cp/parser.c:1120
0x70ae60 cp_parser_std_attribute
../../gcc/cp/parser.c:26726
0x70ae60 cp_parser_std_attribute_list
../../gcc/cp/parser.c:26883
0x70ae60 cp_parser_std_attribute_spec
../../gcc/cp/parser.c:26969
0x70ae60 cp_parser_std_attribute_spec_seq
../../gcc/cp/parser.c:27062
0x6fe577 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14061
0x6fed11 cp_parser_simple_declaration
../../gcc/cp/parser.c:13557
0x721ff9 cp_parser_declaration
../../gcc/cp/parser.c:13377
0x722771 cp_parser_translation_unit
../../gcc/cp/parser.c:4731
0x722771 c_parse_file()
../../gcc/cp/parser.c:43711
0x7e52d0 c_common_parse_file()
../../gcc/c-family/c-opts.c:1186

[Bug c/93683] New: [10 Regression] ICE in ao_ref_init_from_ptr_and_size, at tree-ssa-alias.c:714

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

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

Bug ID: 93683
   Summary: [10 Regression] ICE in ao_ref_init_from_ptr_and_size,
at tree-ssa-alias.c:714
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20190623 and 20190630 :


$ cat z1.c
void f (int *a)
{
  *a = 0;
  __builtin_calloc(1, 1);
}


$ gcc-10-20200209 -c z1.c -O2
z1.c: In function 'f':
z1.c:4:3: warning: ignoring return value of '__builtin_calloc' declared with
attribute 'warn_unused_result' [-Wunused-result]
4 |   __builtin_calloc(1, 1);
  |   ^~
during GIMPLE pass: dse
z1.c:5:1: internal compiler error: Segmentation fault
5 | }
  | ^
0xb0531f crash_signal
../../gcc/toplev.c:328
0xbd1f5a ao_ref_init_from_ptr_and_size(ao_ref*, tree_node*, tree_node*)
../../gcc/tree-ssa-alias.c:714
0xbd6d91 stmt_kills_ref_p(gimple*, ao_ref*)
../../gcc/tree-ssa-alias.c:3280
0xbf50ca dse_classify_store(ao_ref*, gimple*, bool, simple_bitmap_def*, bool*,
tree_node*)
../../gcc/tree-ssa-dse.c:857
0xbf6685 dse_dom_walker::dse_optimize_stmt(gimple_stmt_iterator*)
../../gcc/tree-ssa-dse.c:1102
0xbf6ce8 dse_dom_walker::before_dom_children(basic_block_def*)
../../gcc/tree-ssa-dse.c:1134
0x12c7bd4 dom_walker::walk(basic_block_def*)
../../gcc/domwalk.c:309
0xbf4643 execute
../../gcc/tree-ssa-dse.c:1188

[Bug c++/93676] [8/9/10 Regression] crash in build_value_init

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug rtl-optimization/93658] [9/10 Regression] infinite loop building ghostscript and icu with -O3 on powerpc64le-linux-gnu

[bergner at gcc dot gnu.org]

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

--- Comment #7 from Peter Bergner  ---
Here's the minimal test case using options -O3 -mcpu=power8
-fstack-protector-strong:

void bar();
char b;
void
foo (void)
{
  char a;
  int d = b;
  char *e = 
  while (d)
*e++ = --d;
  bar ();
}

[Bug c++/93676] [8/9/10 Regression] crash in build_value_init

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
We might get away with just avoiding value-init in a template:

--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -4520,7 +4520,7 @@ build_vec_init (tree base, tree maxindex, tree init,

  We do need to keep going if we're copying an array.  */

-  if (try_const && !init)
+  if (try_const && !init && !processing_template_decl)
 /* With a constexpr default constructor, which we checked for when
setting try_const above, default-initialization is equivalent to
value-initialization, and build_value_init gives us something more

testing more...

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

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #2 from David Malcolm  ---
Should be fixed by the above commit.

[Bug analyzer/93669] ICE in dump_exploded_nodes, at analyzer/engine.cc:3239

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Should be fixed by the above commit.

[Bug analyzer/93649] ICE in get_representative, at analyzer/constraint-manager.cc:297

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Should be fixed by the above commit.

[Bug analyzer/93657] Ambiguous wording "is doing to"

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm  ---
Should be fixed by the above commit.

[Bug c++/93676] [8/9/10 Regression] crash in build_value_init

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P2

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r10-6582-ga60d98890bba58649c26c2fc0c6f28cd6073aaaf
Author: David Malcolm 
Date:   Tue Feb 11 10:52:40 2020 -0500

analyzer: fix ICE due to missing state_change purging (PR 93374)

PR analyzer/93374 reports an ICE within state_change::validate due to an
m_new_sid in a recorded state-change being out of range of the svalues
of the region_model of the new state.

During get_or_create_node we attempt to merge the new state with the
state of each of the existing enodes at the program point (in the
absence of sm-state differences), simplifying the state at each
attempt, and potentially reusing a node if we get a match.

This state-merging invalidates any svalue_ids within any state_change
object.

The root cause is that, although the code was purging any such
svalue_ids for the case where no match was found during merging, it was
failing to purge them for the case where a matching enode *was* found
for the merged state, leading to an invalid state_change along the
exploded_edge to the reused enode.

This patch moves the invalidation code to cover both cases, fixing the
ICE.  It also extends state_change validation so that states are also
checked.

gcc/analyzer/ChangeLog:
PR analyzer/93374
* engine.cc (exploded_edge::exploded_edge): Add ext_state param
and pass it to change.validate.
(exploded_graph::get_or_create_node): Move purging of change
svalues to also cover the case of reusing an existing enode.
(exploded_graph::add_edge): Pass m_ext_state to exploded_edge's
ctor.
* exploded-graph.h (exploded_edge::exploded_edge): Add ext_state
param.
* program-state.cc (state_change::sm_change::validate): Likewise.
Assert that m_sm_idx is sane.  Use ext_state to validate
m_old_state and m_new_state.
(state_change::validate): Add ext_state param and pass it to
the sm_change validate calls.
* program-state.h (state_change::sm_change::validate): Add
ext_state param.
(state_change::validate): Likewise.

gcc/testsuite/ChangeLog:
PR analyzer/93374
* gcc.dg/analyzer/torture/pr93374.c: New test.

[Bug analyzer/93669] ICE in dump_exploded_nodes, at analyzer/engine.cc:3239

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r10-6581-ga0e4929b0461226722d6d08b1fdc2852b9100b75
Author: David Malcolm 
Date:   Tue Feb 11 09:45:48 2020 -0500

analyzer: fix ICE in "__analyzer_dump_exploded_nodes" on non-empty worklist
(PR 93669)

gcc/analyzer/ChangeLog:
PR analyzer/93669
* engine.cc (exploded_graph::dump_exploded_nodes): Handle missing
case of STATUS_WORKLIST in implementation of
"__analyzer_dump_exploded_nodes".

gcc/testsuite/ChangeLog:
PR analyzer/93669
* gcc.dg/analyzer/pr93669.c: New test.

[Bug analyzer/93649] ICE in get_representative, at analyzer/constraint-manager.cc:297

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r10-6580-gcd28b75921354c64fd4c8a1c238991e522abc38e
Author: David Malcolm 
Date:   Mon Feb 10 16:47:21 2020 -0500

analyzer: fix ICE with equiv_class constant (PR 93649)

gcc/analyzer/ChangeLog:
PR analyzer/93649
* constraint-manager.cc (constraint_manager::add_constraint): When
merging equivalence classes and updating m_constant, also update
m_cst_sid.
(constraint_manager::validate): If m_constant is non-NULL assert
that m_cst_sid is non-null and is valid.

gcc/testsuite/ChangeLog:
PR analyzer/93649
* gcc.dg/analyzer/torture/pr93649.c: New test.

[Bug analyzer/93657] Ambiguous wording "is doing to"

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r10-6579-g5e17c1bdadbbd5606d869b1178ed3e653f931cda
Author: David Malcolm 
Date:   Mon Feb 10 16:00:42 2020 -0500

analyzer.opt: reword descriptions of two dump options (PR 93657)

gcc/analyzer/ChangeLog:
PR analyzer/93657
* analyzer.opt (fdump-analyzer): Reword description.
(fdump-analyzer-stderr): Likewise.

[Bug rtl-optimization/93565] [9/10 regression] Combine duplicates instructions

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||segher at kernel dot 
crashing.org
Summary|Combine duplicates count|[9/10 regression] Combine
   |trailing zero instructions  |duplicates instructions

--- Comment #8 from Wilco  ---
Here is a much simpler example:

void f (int *p, int y)
{
  int a = y & 14;
  *p = a | p[a];
}

Trunk and GCC9.1 for x64:
mov eax, esi
and esi, 14
and eax, 14
or  eax, DWORD PTR [rdi+rsi*4]
mov DWORD PTR [rdi], eax
ret

and AArch64:
and x2, x1, 14
and w1, w1, 14
ldr w2, [x0, x2, lsl 2]
orr w1, w2, w1
str w1, [x0]
ret

However GCC8.2 does:
and w1, w1, 14
ldr w2, [x0, w1, sxtw 2]
orr w2, w2, w1
str w2, [x0]
ret

So it is a 9 regression...

[Bug c++/93676] [8/9/10 Regression] crash in build_value_init

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
A bit shorter test:

struct P {
  int x = 0;
};

template
struct S {
  S() { new P[2][2]; }
};

[Bug rtl-optimization/88879] [9 Regression] ICE in sel_target_adjust_priority, at sel-sched.c:3332

[arnd at linaro dot org]

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

--- Comment #16 from Arnd Bergmann  ---
Right, I was on the releases/gcc-9 branch, not HEAD. Sorry about the confusion.
I applied your fix and have a working 9.2 build that can build the kernel now.
Thanks!

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

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

--- Comment #159 from Peter Bisroev  ---
(In reply to dave.anglin from comment #157)
> On 2020-02-11 12:27 p.m., peter.bisroev at groundlabs dot com wrote:
> > Just to confirm though, using gcc 4.7.4 that I have previously compiled with
> > aCC that adequately passed 'make check' tests, bootstrap gcc 4.7.4 with 
> > default
> > build flags for STAGE1. Observe PCREL21B errors and manually recompile 
> > affected
> > .c with "-save-temps -da". Is that correct?
> Right, we want to build stage1 with -O0.  You can rebuild 4.7.4 or any other
> gcc version
> that demonstrates the PCREL21B error.  Keep the build log so you can copy
> the compile
> options for the failing object.
> >
> > Do you want to apply any patches to 4.7.4 or compile original code as I have
> > done previously?
> No.  We need to figure out why 4.7.4 generates incorrect PCREL21B
> relocations.  Then,
> maybe we patch it.

Understood, thank you Dave. Will do that tonight.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

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

--- Comment #158 from Peter Bisroev  ---
(In reply to dave.anglin from comment #156)
> On 2020-02-11 11:31 a.m., peter.bisroev at groundlabs dot com wrote:
> > However the above can be compiled with -O0 with the same compiler. So I 
> > changed
> > my build line to use -O0 as well:
> > --
> > gmake \
> >   STAGE1_CFLAGS="-D_XOPEN_SOURCE_EXTENDED -g -O1" \
> >   STAGE1_CXXFLAGS="-D_XOPEN_SOURCE_EXTENDED -g -O1" \
> >   STAGE1_TFLAGS='-g -O0 -D_XOPEN_SOURCE_EXTENDED' \
> >   BOOT_CFLAGS='-g -O0 -D_XOPEN_SOURCE_EXTENDED' \
> >   CFLAGS_FOR_TARGET='-g -O0 -D_XOPEN_SOURCE_EXTENDED' bootstrap
> Regarding the _XOPEN_SOURCE_EXTENDED define, I changed the PA-RISC backend
> to automatically
> enable the XOPEN extensions.  See pa-hpux11.h.  This makes the HP-UX c++
> environment closer to
> Linux.

Will take a look, thanks!

> I doubt you need to define STAGE1_TFLAGS.  Likewise for CFLAGS_FOR_TARGET.
> You may want BOOT_CXXFLAGS.

Actually this is what I tried first. However during configure inside libraries
-O2 was still being used. So I just threw everything in there to see what
happens :)

[Bug middle-end/93634] Improving modular calculations (e.g. divisibility tests).

[cassio.neri at gmail dot com]

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

--- Comment #1 from Cassio Neri  ---
FYI, this is what clang trunk generates:
  imull $-1431655765, %edi, %eax # imm = 0xAAAB
  addl $1431655764, %eax # imm = 0x5554
  rorl %eax
  cmpl $715827882, %eax # imm = 0x2AAA
  setb %al
  retq

[Bug rtl-optimization/93658] [9/10 Regression] infinite loop building ghostscript and icu with -O3 on powerpc64le-linux-gnu

[bergner at gcc dot gnu.org]

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

--- Comment #6 from Peter Bergner  ---
So we are in an infinite loop in process_address() calling process_address_1().
 I've hacked in some code to ICE if we loop for too long and I'm currently
using creduce to minimize the test case.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

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

--- Comment #157 from dave.anglin at bell dot net ---
On 2020-02-11 12:27 p.m., peter.bisroev at groundlabs dot com wrote:
> Just to confirm though, using gcc 4.7.4 that I have previously compiled with
> aCC that adequately passed 'make check' tests, bootstrap gcc 4.7.4 with 
> default
> build flags for STAGE1. Observe PCREL21B errors and manually recompile 
> affected
> .c with "-save-temps -da". Is that correct?
Right, we want to build stage1 with -O0.  You can rebuild 4.7.4 or any other
gcc version
that demonstrates the PCREL21B error.  Keep the build log so you can copy the
compile
options for the failing object.
>
> Do you want to apply any patches to 4.7.4 or compile original code as I have
> done previously?
No.  We need to figure out why 4.7.4 generates incorrect PCREL21B relocations. 
Then,
maybe we patch it.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

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

--- Comment #156 from dave.anglin at bell dot net ---
On 2020-02-11 11:31 a.m., peter.bisroev at groundlabs dot com wrote:
> However the above can be compiled with -O0 with the same compiler. So I 
> changed
> my build line to use -O0 as well:
> --
> gmake \
>   STAGE1_CFLAGS="-D_XOPEN_SOURCE_EXTENDED -g -O1" \
>   STAGE1_CXXFLAGS="-D_XOPEN_SOURCE_EXTENDED -g -O1" \
>   STAGE1_TFLAGS='-g -O0 -D_XOPEN_SOURCE_EXTENDED' \
>   BOOT_CFLAGS='-g -O0 -D_XOPEN_SOURCE_EXTENDED' \
>   CFLAGS_FOR_TARGET='-g -O0 -D_XOPEN_SOURCE_EXTENDED' bootstrap
Regarding the _XOPEN_SOURCE_EXTENDED define, I changed the PA-RISC backend to
automatically
enable the XOPEN extensions.  See pa-hpux11.h.  This makes the HP-UX c++
environment closer to
Linux.

I doubt you need to define STAGE1_TFLAGS.  Likewise for CFLAGS_FOR_TARGET.
You may want BOOT_CXXFLAGS.

[Bug rtl-optimization/88879] [9 Regression] ICE in sel_target_adjust_priority, at sel-sched.c:3332

[amonakov at gcc dot gnu.org]

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

--- Comment #15 from Alexander Monakov  ---
This should not be reproducible with current HEAD because the assert was simply
eliminated. If GCC master definitely fails, can you please provide the exact
diagnostic?

As for 9.2 this is sadly expected because the patch was not backported, I will
backport it soon for the next release from the gcc-9 branch (but if you're
building GCC yourself you can easily do it on your end as the patch simply
removes the offending assert). Sorry about the trouble.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

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

--- Comment #155 from Peter Bisroev  ---
(In reply to dave.anglin from comment #154)
> On 2020-02-11 11:31 a.m., peter.bisroev at groundlabs dot com wrote:
> > We already know that we currently cannot compile stage1 with -O0 as it 
> > causes
> > binaries to become huge and we get PCREL21B errors that were already 
> > described
> > here from HP's linker.
> I believe this issue needs to be fixed in bootstrap compiler.  If I go back
> to the initial report, we had:
> 
> ld: The value 0xfdf68820 does not fit when applying the relocation
> PCREL21B for symbol ".text" at offset 0x102 in section index 74 of
> file libbackend.a[function.o]
> 
> We need to go back and recompile function.c.  Add "-save-temps -da".  This
> will generate .s file and rtl dumps.

Thank you Dave, I think I should be able to do that later on tonight.

Just to confirm though, using gcc 4.7.4 that I have previously compiled with
aCC that adequately passed 'make check' tests, bootstrap gcc 4.7.4 with default
build flags for STAGE1. Observe PCREL21B errors and manually recompile affected
.c with "-save-temps -da". Is that correct?

Do you want to apply any patches to 4.7.4 or compile original code as I have
done previously?

> I suspect the value above needs to be zero extended rather than pointer
> extended.
As soon as I've read that, that error started to make sense :)

Thanks!
--peter

[Bug c++/93667] [10 regression] ICE in esra with nested [[no_unique_address]] field

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Jambor  ---
Mine.

[Bug tree-optimization/93682] Wrong optimization: on x87 -fexcess-precision=standard is incompatible with -mpc64

[bugdal at aerifal dot cx]

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

--- Comment #2 from Rich Felker  ---
I think the underlying issue here is just that -mpc64 (along with -mpc32) is
just hopelessly broken and should be documented as such. It could probably be
made to work, but there are all sorts of issues like float.h being wrong, math
library code breaking, etc.

On a more fundamental level (but seemingly unrelated to the mechanism of
breakage here), the underlying x87 precision control modes are also hopelessly
broken. They're not actually single/double precision modes, but single/double
mantissa with ld80 exponent. So I don't think it's possible to make the
optimizer aware of them without making it aware of two new floating point
formats that it doesn't presently know about. If you just pretended they were
single/double, the same sort of issue would arise again as soon as someone uses
small or large values that should be denormal/underflow/overflow but which
retain their full-precision values by virtue of the excess exponent precision.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

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

--- Comment #154 from dave.anglin at bell dot net ---
On 2020-02-11 11:31 a.m., peter.bisroev at groundlabs dot com wrote:
> We already know that we currently cannot compile stage1 with -O0 as it causes
> binaries to become huge and we get PCREL21B errors that were already described
> here from HP's linker.
I believe this issue needs to be fixed in bootstrap compiler.  If I go back to
the initial report, we had:

ld: The value 0xfdf68820 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x102 in section index 74 of
file libbackend.a[function.o]

We need to go back and recompile function.c.  Add "-save-temps -da".  This will
generate .s file and rtl dumps.

I suspect the value above needs to be zero extended rather than pointer
extended.

[Bug rtl-optimization/88879] [9 Regression] ICE in sel_target_adjust_priority, at sel-sched.c:3332

[arnd at linaro dot org]

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

Arnd Bergmann  changed:

   What|Removed |Added

 CC||arnd at linaro dot org

--- Comment #14 from Arnd Bergmann  ---
I got the same output while building the linux kernel defconfig today, reduced
to this minimal test case:

$ cat test.c
long a, b;
int fn1() {
  char *c = (void *)b;
  while (1) {
const long d = *c = d;
do
  a++;
while (a == 5);
  }
}
$ ia64-linux-gcc -O3 -c test.c
during RTL pass: mach
lz4_decompress.c:10:1: internal compiler error: in sel_target_adjust_priority,
at sel-sched.c:3334
   10 | }

Reproduced both with 9.2 and current HEAD 
$ ia64-linux-gcc --version
ia64-linux-gcc (GCC) 9.2.1 20200211

[Bug other/91085] fixincludes breaks

[sch...@linux-m68k.org]

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

--- Comment #8 from Andreas Schwab  ---
Yes, nothing has changed.

[Bug c++/93676] [8/9/10 Regression] crash in build_value_init

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
We hit this assert in build_value_init:

  /* The AGGR_INIT_EXPR tweaking below breaks in templates.  */
  gcc_assert (!processing_template_decl
  || (SCALAR_TYPE_P (type) || TREE_CODE (type) == ARRAY_TYPE));

because we're trying to value-initialize "struct point" in a template.

[Bug c/85957] i686: Integers appear to be different, but compare as equal

[ch3root at openwall dot com]

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

--- Comment #23 from Alexander Cherepanov  ---
(In reply to Alexander Monakov from comment #10)
> Also note that both the original and the reduced testcase can be tweaked to
> exhibit the surprising transformation even when -fexcess-precision=standard
> is enabled. A "lazy" way is via -mpc64

I think this is another problem. I filed bug 93682 for it.

[Bug c/85957] i686: Integers appear to be different, but compare as equal

[ch3root at openwall dot com]

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

--- Comment #22 from Alexander Cherepanov  ---
(In reply to jos...@codesourcery.com from comment #11)
> Yes, I agree that any particular conversion to integer executed in the 
> abstract machine must produce some definite integer value for each 
> execution.
The idea that floating-point variables could be unstable but integer variables
have to be stable seems like an arbitrary boundary. But I guess this is deeply
ingrained in gcc: the optimizer just assumes that integers are stable (e.g.,
optimizes `if (x != y && y == z) use(x == z);` for integers to `if (x != y && y
== z) use(0);`) but it's ready for instability of FPs (e.g., doesn't do the
same optimization for FPs).

When the stability of integers is violated everything blows up. This bug report
show that instability of floating-point values extends to integers via casts.
Another way is via comparisons -- I've just filed bug 93681 for it. There is
also a testcase there that shows how such an instability can taint surrounding
code.

So, yeah, it seems integers have to be stable. OTOH, now that there is sse and
there is -fexcess-precision=standard floating-point values are mostly stable
too. Perhaps various optimizations done for integers could be enabled for FPs
too? Or the situation is more complicated?

[Bug tree-optimization/93682] Wrong optimization: on x87 -fexcess-precision=standard is incompatible with -mpc64

[ch3root at openwall dot com]

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

--- Comment #1 from Alexander Cherepanov  ---
The instability can also taint surrounding code which leads to nonsense:

--
#include 

__attribute__((noipa)) // imagine it in a separate TU
static long double opaque(long double d) { return d; }

int main()
{
int one = opaque(1);
long double x = opaque(1);
int a = x + 0x1p-60 == 1;

opaque(a);
if (one == a) {
opaque(0);
if (x == 1) {
opaque(0);
if (a == 0) {
opaque(0);
if (one == 0)
printf("one = %d\n", one);
}
}
}
}
--
$ gcc -std=c11 -pedantic -Wall -Wextra -m32 -march=i686 -mpc64 -O3 test.c &&
./a.out
one = 0
--
gcc x86-64 version: gcc (GCC) 10.0.1 20200211 (experimental)
--

[Bug tree-optimization/93682] New: Wrong optimization: on x87 -fexcess-precision=standard is incompatible with -mpc64

[ch3root at openwall dot com]

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

Bug ID: 93682
   Summary: Wrong optimization: on x87 -fexcess-precision=standard
is incompatible with -mpc64
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

Spotted by Alexander Monakov in bug 85957, comment 10...

Not sure if -mpc64 is supposed to be compatible with
-fexcess-precision=standard (and -std=c11 which enables it) but I don't see any
warnings in the description of these options.

-mpc64 changes hardware precision but the optimizer seems to be unaffected
which leads to discrepancies. For example, AIUI -fexcess-precision=standard is
supposed to give predictable results but the results of the following testcase
depend on the optimization level:

--
#include 

int main()
{
int x = 1;

printf("%a\n", 0x1p-60 + x - 1);
}
--
$ gcc -std=c11 -pedantic -Wall -Wextra -m32 -march=i686 -mpc64 test.c &&
./a.out
0x0p+0
$ gcc -std=c11 -pedantic -Wall -Wextra -m32 -march=i686 -mpc64 -O3 test.c &&
./a.out
0x1p-60
--
gcc x86-64 version: gcc (GCC) 10.0.1 20200211 (experimental)
--

[Bug c/85957] i686: Integers appear to be different, but compare as equal

[ch3root at openwall dot com]

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

--- Comment #21 from Alexander Cherepanov  ---
The following variation works with the trunk:

--
#include 

__attribute__((noipa)) // imagine it in a separate TU
static int opaque(int i) { return i; }

int main()
{
static int a = 0;
int d = opaque(1);

if (opaque(0))
puts("ignore");
// need the next `if` to be at the start of a BB

if (d == 1)
a = 1;

int i = d - 0x1p-60;

if (i == 1)
printf("i = %d\n", i);

printf("i = %d\n", i);

opaque(a);
}
--
$ gcc -std=gnu11 -pedantic -Wall -Wextra -m32 -march=i686 -O3 test.c && ./a.out
i = 1
i = 0
--
gcc x86-64 version: gcc (GCC) 10.0.1 20200211 (experimental)
--

All the same but the computation of `i` is hoisted from the `if` in the
133t.pre pass so dom3 doesn't have a chance to fold it.

Another interesting aspect: there are no comparisons of floating-point numbers
in this example, all FP operations are limited to a basic arithmetic and a
conversion.

[Bug c/85957] i686: Integers appear to be different, but compare as equal

[ch3root at openwall dot com]

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

Alexander Cherepanov  changed:

   What|Removed |Added

 CC||ch3root at openwall dot com

--- Comment #20 from Alexander Cherepanov  ---
Minimized testcase that should still be quite close to the original:

--
#include 

__attribute__((noipa)) // imagine it in a separate TU
static double opaque(double d) { return d; }

int main()
{
double d;
do {
d = opaque(1e6);
} while (opaque(0));

if (d == 1e6)
printf("yes\n");

int i = d * 1e-6;
printf("i = %d\n", i);

if (i == 1)
printf("equal to 1\n");
}
--
$ gcc -std=gnu11 -pedantic -Wall -Wextra -m32 -march=i686 -O3 test.c && ./a.out
yes
i = 0
equal to 1
--

According to https://godbolt.org/z/AmkmS5 , this happens for gcc versions
8.1--9.2 but not for trunk (I haven't tried earlier versions).

With gcc 8.3.0 from the stable Debian it works like this:
- (as described in comment 7) 120t.dom2 merges two `if`s, in particular
deducing that `i == 1` is true if `d == 1e6` is true but not substituting `i`
in `printf`;
- 142t.loopinit introduces `# d_4 = PHI ` between the loop and the
first `if`;
- 181t.dom3 would fold computation of `i` in the `d == 1e6` branch but the
introduced `PHI` seems to prevent this.

With gcc from the trunk a new pass 180t.fre4 removes that `PHI` and 182t.dom3
then does its work. (The numeration of passes changed slightly since gcc
8.3.0.)