[Bug target/93270] [8/9/10 Regression] DSE removes store incorrectly

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Keywords||wrong-code
   Last reconfirmed||2020-01-15
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|[10 Regression] DSE removes |[8/9/10 Regression] DSE
   |store incorrectly   |removes store incorrectly
   Target Milestone|--- |8.4

--- Comment #1 from Richard Biener  ---
You can probably massage it to make it a very old issue by using

typedef int v4si __attribute__((vector_size(16)));
typedef union { long double value; v4si vec; } data;
void bar(data *);
void foo(long double x)
{
  data m;
  m.vec = (v4si) { 0,0,0,0 };
  m.value = x;
  bar ();
}

even GCC 4.8 produces

foo:
.LFB0:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
fldt32(%rsp)
movq%rsp, %rdi
fstpt   (%rsp)
callbar
addq$24, %rsp
.cfi_def_cfa_offset 8
ret

which looks wrong.  3.4.6 doesn't DSE here, nor does 4.0.4.  But if you
use recent GCC even RTL DSE removes the store if you use -fno-tree-dse.

So the regression is much older.

Possibly other targets are affected as well.

[Bug ipa/92240] [10 regression] ICE in duplicate, at ipa-prop.c:3883

[dimhen at gmail dot com]

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

--- Comment #9 from Dmitry G. Dyachenko  ---
Created attachment 47654
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47654=edit
pre-processed isl_fold.c

gcc_r277495
./contrib/download_prerequisites
~/src/gcc_r277485/configure --enable-checking=yes --enable-languages=c,c++
--disable-multilib --with-isl

make

[...]

libtool: compile:  /home/dimhen/build/./prev-gcc/xgcc
-B/home/dimhen/build/./prev-gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/
-isystem /usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include -fno-checking -DHAVE_CONFIG_H -I.
-I/home/dimhen/src/gcc_r277485/isl -I/home/dimhen/src/gcc_r277485/isl/include
-Iinclude/ -I/home/dimhen/src/gcc_r277485/gmp -I/home/dimhen/build/./gmp -g -O2
-fno-checking -gtoggle -MT isl_fold.lo -MD -MP -MF .deps/isl_fold.Tpo -c
/home/dimhen/src/gcc_r277485/isl/isl_fold.c -o isl_fold.o
during IPA pass: inline
/home/dimhen/src/gcc_r277485/isl/isl_fold.c:1777:1: internal compiler error: in
duplicate, at ipa-prop.c:3883
 1777 | }
  | ^
0xe820f8 ipa_edge_args_sum_t::duplicate(cgraph_edge*, cgraph_edge*,
ipa_edge_args*, ipa_edge_args*)
/home/dimhen/src/gcc_r277485/gcc/ipa-prop.c:3883
0xe8a7df call_summary::symtab_duplication(cgraph_edge*,
cgraph_edge*, void*)
/home/dimhen/src/gcc_r277485/gcc/symbol-summary.h:771
0xae6b11 symbol_table::call_edge_duplication_hooks(cgraph_edge*, cgraph_edge*)
/home/dimhen/src/gcc_r277485/gcc/cgraph.c:453
0xb04f3f cgraph_edge::clone(cgraph_node*, gcall*, unsigned int, profile_count,
profile_count, bool)
/home/dimhen/src/gcc_r277485/gcc/cgraphclones.c:141
0xb05f80 cgraph_node::create_clone(tree_node*, profile_count, bool,
vec, bool, cgraph_node*, ipa_param_adjustments*,
char const*)
/home/dimhen/src/gcc_r277485/gcc/cgraphclones.c:390
0x2060f11 clone_inlined_nodes(cgraph_edge*, bool, bool, int*)
/home/dimhen/src/gcc_r277485/gcc/ipa-inline-transform.c:217
0x2060fc6 clone_inlined_nodes(cgraph_edge*, bool, bool, int*)
/home/dimhen/src/gcc_r277485/gcc/ipa-inline-transform.c:236
0x2060fc6 clone_inlined_nodes(cgraph_edge*, bool, bool, int*)
/home/dimhen/src/gcc_r277485/gcc/ipa-inline-transform.c:236
0x2061c4b inline_call(cgraph_edge*, bool, vec*,
int*, bool, bool*)
/home/dimhen/src/gcc_r277485/gcc/ipa-inline-transform.c:479
0x2052e40 inline_small_functions
/home/dimhen/src/gcc_r277485/gcc/ipa-inline.c:2151
0x20548e9 ipa_inline
/home/dimhen/src/gcc_r277485/gcc/ipa-inline.c:2615
0x205578e execute
/home/dimhen/src/gcc_r277485/gcc/ipa-inline.c:3023
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.


/home/dimhen/build/./prev-gcc/xgcc -B/home/dimhen/build/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/bin/
-B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include -fno-checking -DHAVE_CONFIG_H -I.
-I/home/dimhen/src/gcc_r277485/isl -I/home/dimhen/src/gcc_r277485/isl/include
-Iinclude/ -I/home/dimhen/src/gcc_r277485/gmp -I/home/dimhen/build/./gmp -g -O2
-fno-checking -gtoggle -MT isl_fold.lo -MD -MP -MF .deps/isl_fold.Tpo -c
/home/dimhen/src/gcc_r277485/isl/isl_fold.c -o isl_fold.i -E

/home/dimhen/build/./prev-gcc/xgcc -fpreprocessed
-B/home/dimhen/build/./prev-gcc/ -fno-checking -g -O2 -fno-checking -gtoggle -c
isl_fold.i

[Bug ipa/92240] [10 regression] ICE in duplicate, at ipa-prop.c:3883

[dimhen at gmail dot com]

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

--- Comment #10 from Dmitry G. Dyachenko  ---
(In reply to Martin Liška from comment #6)
> @Dmitry: Can you please attach a pre-processed source file (-E option)?

done

[Bug c/93072] [8/9/10 Regression] ICE: gimplifier segfault with undefined nested function

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Joseph Myers :

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

commit r10-5972-ge2346a33b05871fc065815d4cfd531dfa0195507
Author: Joseph Myers 
Date:   Wed Jan 15 02:54:27 2020 +

Fix setting of DECL_CONTEXT in pushdecl (PR c/93072).

Bug 93072 is a case where the C front end (a) wrongly interprets an
inline declaration at block scope as indicating that DECL_CONTEXT
should be set for an inline function and (b) this results in an ICE.
This is a regression resulting from a previous fix of mine for other
bugs involving such declarations being wrongly interpreted elsewhere
as nested function declarations.  The fix is similar to the previous
fix: use TREE_PUBLIC instead of DECL_EXTERNAL in another place as the
relevant test to determine whether to set DECL_CONTEXT.  (When a
variable reaches the code in question in pushdecl, the two are
equivalent.)

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

PR c/93072
gcc/c:
* c-decl.c (pushdecl): Use TREE_PUBLIC, not DECL_EXTERNAL, to
determine whether to set DECL_CONTEXT.

gcc/testsuite:
* gcc.dg/inline-42.c, gcc.dg/inline-43.c: New tests.

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

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm  ---
Should now be closed on master.

[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 #4 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:32077b693df8e3ed0424031a322df23822bf2f7e

commit r10-5970-g32077b693df8e3ed0424031a322df23822bf2f7e
Author: David Malcolm 
Date:   Thu Jan 9 10:12:59 2020 -0500

analyzer: fix ICE on METHOD_TYPE (PR 93212)

PR analyzer/93212 reports an ICE when attempting to use -fanalyzer
on a C++ source file.  That isn't supported yet, but the fix is
trivial (handling METHOD_TYPE as well as FUNCTION_TYPE).

gcc/analyzer/ChangeLog:
PR analyzer/93212
* region-model.cc (make_region_for_type): Use
FUNC_OR_METHOD_TYPE_P rather than comparing against FUNCTION_TYPE.
* region-model.h (function_region::function_region): Likewise.

[Bug analyzer/58237] gcc fails to detect obvious resource leaks

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:8397af8ed0db685312e44117fd52316b57c2c129

commit r10-5965-g8397af8ed0db685312e44117fd52316b57c2c129
Author: David Malcolm 
Date:   Fri Dec 20 10:56:28 2019 -0500

analyzer: fix tests for UNKNOWN_LOCATION

In the reproducer for PR analyzer/58237 I noticed that some events were
missing locations (and text); for example event 3 here:

|   15 |   while (fgets(buf, 10, fp) != NULL)
|  | ~
|  | |
|  | (2) following 'false' branch...
|
  'f1': event 3
|
|cc1:
|
  'f1': event 4
|
|:19:1:
|   19 | }
|  | ^
|  | |
|  | (4) 'fp' leaks here; was opened at (1)
|

The root cause is that various places in the analyzer compare locations
against UNKNOWN_LOCATION, which fails to detect an unknown location for
the case where an unknown_location has been wrapped into an ad-hoc
location to record a block.

This patch fixes the issue by using get_pure_location whenever testing
against UNKNOWN_LOCATION to look through ad-hoc wrappers.

For the case above, it thus picks a better location in
supernode::get_start_location for event (3) above, improving it to:

|   15 |   while (fgets(buf, 10, fp) != NULL)
|  | ~
|  | |
|  | (2) following 'false' branch...
|..
|   19 | }
|  | ~
|  | |
|  | (3) ...to here
|  | (4) 'fp' leaks here; was opened at (1)
|

gcc/analyzer/ChangeLog:
PR analyzer/58237
* engine.cc (leak_stmt_finder::find_stmt): Use get_pure_location
when comparing against UNKNOWN_LOCATION.
(stmt_requires_new_enode_p): Likewise.
(exploded_graph::dump_exploded_nodes): Likewise.
* supergraph.cc (supernode::get_start_location): Likewise.
(supernode::get_end_location): Likewise.

gcc/testsuite/ChangeLog:
PR analyzer/58237
* gcc.dg/analyzer/file-paths-1.c: New test.

[Bug analyzer/58237] gcc fails to detect obvious resource leaks

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:03dc3f26231cbf570028e14706f8ad77fd5a

commit r10-5964-g03dc3f26231cbf570028e14706f8ad77fd5a
Author: David Malcolm 
Date:   Fri Dec 20 11:20:44 2019 -0500

tree-diagnostic-path.cc: properly handle ad-hoc wrappers of
UNKNOWN_LOCATION

In the reproducer for PR analyzer/58237 I noticed that some events that
were missing locations were also missing text; for example event 3 here:

|   15 |   while (fgets(buf, 10, fp) != NULL)
|  | ~
|  | |
|  | (2) following 'false' branch...
|
  'f1': event 3
|
|cc1:
|

The root cause is that the path_summary-printing code doesn't consider
ad-hoc locations when looking for reserved locations, and so fails to
detect an unknown location for the case where an unknown location has
been wrapped into an ad-hoc location to record a block.

This patch fixes the issue by using get_pure_location, thus looking
through ad-hoc wrappers, improving the result to:

|   15 |   while (fgets(buf, 10, fp) != NULL)
|  | ~
|  | |
|  | (2) following 'false' branch...
|
  'f1': event 3
|
|cc1:
| (3): ...to here
|

gcc/ChangeLog:
* tree-diagnostic-path.cc (path_summary::event_range::print):
When testing for UNKNOWN_LOCATION, look through ad-hoc wrappers
using get_pure_location.

[Bug analyzer/58237] gcc fails to detect obvious resource leaks

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:697251b7a1bb7c14d3805de22248e83a23b90d1a

commit r10-5963-g697251b7a1bb7c14d3805de22248e83a23b90d1a
Author: David Malcolm 
Date:   Thu Dec 19 15:59:04 2019 -0500

analyzer: add known stdio functions to sm-file.cc (PR analyzer/58237)

The analyzer ought to report various file leaks for the reproducer in
PR analyzer/58237, such as:

  void f1(const char *str)
  {
FILE * fp = fopen(str, "r");
char buf[10];
while (fgets(buf, 10, fp) != NULL)
{
  /* Do something with buf */
}
/* Missing call to fclose. Need warning here for resource leak */
  }

but fails to do so, due to not recognizing fgets, and thus
conservatively assuming that it could close "fp".

This patch adds a function_set to sm-file.cc of numerous stdio.h
functions that are known to not close the file (and which require a
valid FILE *, but that's a matter for a followup), fixing the issue.

gcc/analyzer/ChangeLog:
PR analyzer/58237
* analyzer-selftests.cc (selftest::run_analyzer_selftests): Call
selftest::analyzer_sm_file_cc_tests.
* analyzer-selftests.h (selftest::analyzer_sm_file_cc_tests): New
decl.
* sm-file.cc: Include "analyzer/function-set.h" and
"analyzer/analyzer-selftests.h".
(get_file_using_fns): New function.
(is_file_using_fn_p): New function.
(fileptr_state_machine::on_stmt): Return true for known functions.
(selftest::analyzer_sm_file_cc_tests): New function.

gcc/testsuite/ChangeLog:
PR analyzer/58237
* gcc.dg/analyzer/file-1.c (test_4): New.
* gcc.dg/analyzer/file-pr58237.c: New test.

[Bug c/93072] [8/9/10 Regression] ICE: gimplifier segfault with undefined nested function

[jsm28 at gcc dot gnu.org]

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

--- Comment #3 from Joseph S. Myers  ---
This is not actually a nested function; it's another case of a non-nested
function (a valid declaration at block scope) wrongly being interpreted as
nested. Working on a patch.

[Bug c++/93257] consteval functions returning 'void' are rejected when called

[alisdairm at me dot com]

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

--- Comment #2 from Alisdair Meredith  ---
I am trying to use these extensively as ways to collect related static
assertions in my test suite for  and .  By using
consteval rather then constexpr, I get notified if any code is unexpectedly
deferred to runtime, and can fix my own bugs.

[Bug c++/93257] consteval functions returning 'void' are rejected when called

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #1 from Jason Merrill  ---
Hmm, I suppose a constant expression can have void type, but what use is it?

[Bug target/93009] [9 Regression] AVX512 FMA - wrong code generation since r265288

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10 Regression] AVX512|[9 Regression] AVX512 FMA -
   |FMA - wrong code generation |wrong code generation since
   |since r265288   |r265288

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

[Bug tree-optimization/93262] [10 Regression] DSE memstar call trimming affecting -D_FORTIFY_SOURCE since r10-1985

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/93249] [10 Regression] wrong code with __builtin_strncpy() copying empty string

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/93262] [10 Regression] DSE memstar call trimming affecting -D_FORTIFY_SOURCE since r10-1985

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:81a68b9e3774401a99719ea29640d13125745b41

commit r10-5962-g81a68b9e3774401a99719ea29640d13125745b41
Author: Jakub Jelinek 
Date:   Wed Jan 15 01:31:20 2020 +0100

tree-optimization: Fix tree dse of __*_chk PR93262

The following testcase shows that GCC trunk mishandles DSE of __*_chk
calls.  Tail trimming of the calls is fine, we want to just decrease the
third argument and keep the first two and last arguments unmodified.
But for head trimming, we currently increment the two by head_trim and
decrease the third by head_trim, so
  __builtin___memcpy_chk (, b_2(D), 48, 32);
  __builtin_memset (, 32, 16);
into:
  _5 = b_2(D) + 16;
  __builtin___memcpy_chk (  [(void *) + 16B], _5, 32, 32);
  __builtin_memset (, 32, 16);
This is wrong, because the 32 was the determined (maximum) size of the
destination (char a[32]), but [16] has maximum size of 16, not 32.
The __builtin___memcpy_chk (  [(void *) + 16B], _5, 32, 32);
call is just folded later into
__builtin_memcpy (  [(void *) + 16B], _5, 32);
because it says that it copies as many bytes into destination as the
destination has.  We need:
  __builtin___memcpy_chk (  [(void *) + 16B], _5, 32, 16);
instead, which will terminate the program instead of letting it silently
overflow the buffer.
The patch just punts if we'd need to decrease the last argument below 0.

Fortunately, release branches are unaffected.
P.S. it was quite hard to make the runtime test working, in builtins.exp
neither dg-options nor dg-additional-options work and builtins.exp adds
-fno-tree-dse among several other -fno-* options.  Fortunately optimize
attribute works.

2020-01-15  Jakub Jelinek  

PR tree-optimization/93262
* tree-ssa-dse.c (maybe_trim_memstar_call): For *_chk builtins,
perform head trimming only if the last argument is constant,
either all ones, or larger or equal to head trim, in the latter
case decrease the last argument by head_trim.

* gcc.c-torture/execute/builtins/pr93262-chk.c: New test.
* gcc.c-torture/execute/builtins/pr93262-chk-lib.c: New file.
* gcc.c-torture/execute/builtins/pr93262-chk.x: New file.

[Bug tree-optimization/93249] [10 Regression] wrong code with __builtin_strncpy() copying empty string

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:623c6fddd605f8f225142d714440320e4ef54d84

commit r10-5961-g623c6fddd605f8f225142d714440320e4ef54d84
Author: Jakub Jelinek 
Date:   Wed Jan 15 01:28:43 2020 +0100

tree-optimization: Fix tree dse of strncpy PR93249

As the testcase shows, tail trimming of strncpy in tree-ssa-dse.c is fine,
we just copy or clear fewer bytes in the destination, but unlike
memcpy/memset etc., head trimming is problematic in certain cases.
If we can prove that there are no zero bytes among initial head_trim bytes,
it is ok to trim it, if we can prove there is at least one zero byte among
initial head_trim bytes, we could (not implemented in the patch) turn
the strncpy into memset 0, but otherwise we need to avoid the head
trimming,
because the presence or absence of NUL byte there changes the behavior for
subsequent bytes, whether further bytes from src are copied or if further
bytes are cleared.

2020-01-15  Jakub Jelinek  

PR tree-optimization/93249
* tree-ssa-dse.c: Include builtins.h and gimple-fold.h.
(maybe_trim_memstar_call): Move head_trim and tail_trim vars to
function body scope, reindent.  For BUILTIN_IN_STRNCPY*, don't
perform head trim unless we can prove there are no '\0' chars
from the source among the first head_trim chars.

* gcc.c-torture/execute/pr93249.c: New test.

[Bug lto/91576] [10 Regression] error: invalid conversion in gimple call since r272749

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:000c7a93bdf4040d7d0672fbb9b064eae3d78f5d

commit r10-5955-g000c7a93bdf4040d7d0672fbb9b064eae3d78f5d
Author: Jakub Jelinek 
Date:   Wed Jan 15 00:35:58 2020 +0100

Remove bogus initial lines from test.

2020-01-15  Jakub Jelinek  

PR lto/91576
* g++.dg/lto/odr-8_1.C: Remove bogus initial lines.

[Bug target/93009] [9/10 Regression] AVX512 FMA - wrong code generation since r265288

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-5954-gfbbc4c24fd7ba87e0c47cd965ae624afba6fa375
Author: Jakub Jelinek 
Date:   Wed Jan 15 00:30:10 2020 +0100

i386: Fix wrong-code x86 issue with avx512{f,vl} fma PR93009

As mentioned in the PR, the following testcase is miscompiled with
avx512vl.
The reason is that the fma *_bcst_1 define_insns have two alternatives:
"=v,v" "0,v" "v,0" "m,m" and use the same
vfmadd213* %3, %2, %0
pattern.  If the first alternative is chosen, everything is ok, but if the
second alternative is chosen, %2 and %0 are the same register, so instead
of doing dest=dest*another+membcst we do dest=dest*dest+membcst.
Now, to fix this, either we'd need separate:
  "vfmadd213\t{%3, %2,
%0|%0, %2, %3}
   vfmadd213\t{%3, %1,
%0|%0, %1, %3}"
where for the second alternative, we'd just use %1 instead of %2, but
what I think is actually cleaner is just use a single alternative and
make the two multiplication operands commutative, which they really are.

2020-01-15  Jakub Jelinek  

PR target/93009
* config/i386/sse.md
(*fma_fmadd__bcst_1,
*fma_fmsub__bcst_1,
*fma_fnmadd__bcst_1,
*fma_fnmsub__bcst_1): Use
just a single alternative instead of two, make operands 1 and 2
commutative.

* gcc.target/i386/avx512vl-pr93009.c: New test.

[Bug c/92935] typeof() on an atomic type doesn't always return the corresponding unqualified type

[pskocik at gmail dot com]

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

--- Comment #3 from pskocik at gmail dot com ---
jos...@codesourcery.com, that's interesting, but it seems like an unnecessary,
weird special case, considering that gcc already has a qualifier-dropping
mechanism that doesn't necessitate special-casing __typeof for
_Atomic-qualified types.

Casting an expression to its own type (which on gcc works for aggregates too)
doe it.

Compilable example:

#if __clang__
#define DROP_Q(X) ((void)0,X) //clang rejects the casts for aggregate
types
#else
#define DROP_Q(X) (__extension__({ (__typeof(X))(X) ; }))
//__extension__ so aggregates are accepted
//even under -pedantic
#endif
int main(void)
{
#define TEST_RVAL_CONV(Tp) \
do{ \
_Atomic const volatile  Tp abar; \
const volatile  Tp bar; \
__typeof(DROP_Q(bar)) noqualif_bar; \
__typeof(DROP_Q(abar)) noqualif_abar; \
_Generic(_bar, Tp*: (void)0); \
_Generic(_abar, Tp*: (void)0); \
}while(0)

TEST_RVAL_CONV(int);
TEST_RVAL_CONV(__typeof(int*));
typedef struct s_tp { int x; } s_tp;
TEST_RVAL_CONV(s_tp);
}

https://gcc.godbolt.org/z/UtMyxM

I think all lvalue-ness-dropping expressions (e.g., the comma operator or ?: )
ought to drop top-level qualifs too (and they do on clang), and such a
qualif-dropping operation wouldn't then be dependent on the gcc extension of
allowing casts to non-scalar types, but unfortunately, gcc does not drop
top-level qualifs in rvalue-conversions, which means the clang implementation
of the qualifier-dropping macro doesn't work on gcc.

[Bug tree-optimization/93247] [10 Regression] ICE in get_load_store_type, at tree-vect-stmts.c:2462 since g:ac190fcea1bebf87

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
The testcase from the other PR is shorter.

[Bug tree-optimization/93247] [10 Regression] ICE in get_load_store_type, at tree-vect-stmts.c:2462 since g:ac190fcea1bebf87

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Testing a patch.

[Bug tree-optimization/93268] ICE with gcc-10 when compiling hypre library with -O3 since r10-5877

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #7 from rsandifo at gcc dot gnu.org  
---
Dup of PR93247.

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

[Bug tree-optimization/93247] [10 Regression] ICE in get_load_store_type, at tree-vect-stmts.c:2462 since g:ac190fcea1bebf87

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||kristopher.kuhlman at gmail 
dot co
   ||m

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
*** Bug 93268 has been marked as a duplicate of this bug. ***

[Bug c/92935] typeof() on an atomic type doesn't always return the corresponding unqualified type

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
The need to drop qualifiers in typeof in some cases with _Atomic results 
from the stdatomic.h implementation, where it is necessary to define 
temporaries with the corresponding non-atomic, non-volatile type to a 
macro argument.

[Bug tree-optimization/93249] [10 Regression] wrong code with __builtin_strncpy() copying empty string

[law at redhat dot com]

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

--- Comment #7 from Jeffrey A. Law  ---
I think the expedient thing to do here is fix DSE in isolation.  Note that I
think the code in question is new, so if we have to xfail some tests, that
wouldn't IMHO represent a regression.

Integrating DSE & strlen would likely be painful and I don't think capturing
the case envisioned in c#5 would likely be worth the effort involved.  I
wouldn't object to opening a missed-optimization bug, but I don't think we'd
likely be prioritizing it anytime soon.

[Bug c/93241] [8/9/10 Regression] _Bool casts in dead branches of integer constant expressions cause undesirable warnings under -pedantic iff the dead branch contains overflow

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #8 from Joseph S. Myers  ---
Fixed for GCC 8.4, GCC 9.3, GCC 10.

[Bug tree-optimization/93270] New: [10 Regression] DSE removes store incorrectly

[law at redhat dot com]

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

Bug ID: 93270
   Summary: [10 Regression] DSE removes store incorrectly
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: law at redhat dot com
  Target Milestone: ---

Given this code:

> typedef union { long double value; unsigned int word[4]; } memory_long_double;
> static unsigned int ored_words[4];
> static void add_to_ored_words (long double x)
> {
>   memory_long_double m;
>   size_t i;
>   memset (, 0, sizeof (m));
>   m.value = x;
>   for (i = 0; i < 4; i++)
> {
>   ored_words[i] |= m.word[i];
> }
> }
> 

DSE is removing the memset as it thinks the assignment to m.value is
going to set the entire union.

But when we translate that into RTL we use XFmode:

> ;; m.value ={v} x_6(D);
> 
> (insn 7 6 0 (set (mem/v/j/c:XF (plus:DI (reg/f:DI 77 virtual-stack-vars)
> (const_int -16 [0xfff0])) [2 m.value+0 S16 A128])
> (reg/v:XF 86 [ x ])) "j.c":13:11 -1
>  (nil))
> 

That (of course) only writes 80 bits of data because of XFmode, leaving
48 bits uninitialized.  We then read those bits, or-ing the
uninitialized data into ored_words and all hell breaks loose later.

I *think* this is a regression, but I haven't explicitly checked.  This popped
up when comparing autoconf config.h file differences for Fedora between gcc-9
and gcc-10 builds.

[Bug c++/90916] [10 Regression] ICE in retrieve_specialization, at cp/pt.c:1258

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Nathan Sidwell :

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

commit r10-5952-gddd792fa53345180c782494aa597e438a73b6248
Author: Nathan Sidwell 
Date:   Tue Jan 14 13:08:14 2020 -0800

[PR90916]  Use TI accessor.

PR c++/90916
* pt.c (retrieve_specialization): Use get_template_info, not open
coding access.

[Bug lto/91576] [10 Regression] error: invalid conversion in gimple call since r272749

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #21 from Jan Hubicka  ---
The type checking ICE is fixed. I hope the other problems mentioned are now
fixed, too (they do not reproduce for me). If not, lets open new PR.

[Bug lto/91576] [10 Regression] error: invalid conversion in gimple call since r272749

[cvs-commit at gcc dot gnu.org]

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

--- Comment #20 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

https://gcc.gnu.org/g:288c5324bf6e418dd94d718d1619464a4f68ff8e

commit r10-5951-g288c5324bf6e418dd94d718d1619464a4f68ff8e
Author: Jan Hubicka 
Date:   Tue Jan 14 21:45:03 2020 +0100

Compare TREE_ADDRESSABLE and TYPE_MODE when ODR checking types.

PR lto/91576
* ipa-devirt.c (odr_types_equivalent_p): Compare TREE_ADDRESSABLE and
TYPE_MODE.

* testsuite/g++.dg/lto/odr-8_0.C: New testcase.
* testsuite/g++.dg/lto/odr-8_1.C: New testcase.

[Bug ipa/92240] [10 regression] ICE in duplicate, at ipa-prop.c:3883

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #8 from Martin Jambor  ---
(In reply to Dmitry G. Dyachenko from comment #7)
> (In reply to Martin Liška from comment #6)
> > @Dmitry: Can you please attach a pre-processed source file (-E option)?
> 
> @Martin: FAIL start for me during gcc bootstrap somewhere between r277460
> and r277485. bootstrap was restored for me at r277486.
> 

Well, that looks like you have bumped into
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01920.html which was
fixed by exactly that commit.

[Bug target/92692] [9/10 Regression] Saving off the callee saved register between ldxr/stxr (caused by shrink wrapping improvements)

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Any -march= or similar?  Can't reproduce with current trunk, nor
with even Oct 10 GCC snapshot (crosses in both cases).
grep -B1 stxr pr92692.s
doesn't show any stores before stxr.

[Bug ipa/93223] [9/10 Regression] ICE in devirtualization_time_bonus at gcc/ipa-cp.c:3161 since r261744

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Jambor  ---
Fixed with https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00736.html

[Bug ipa/93223] [9/10 Regression] ICE in devirtualization_time_bonus at gcc/ipa-cp.c:3161 since r261744

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Martin Jambor
:

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

commit r9-8133-gb849001991c41b68407e7b0bcabf88e4ef414fff
Author: Martin Jambor 
Date:   Tue Jan 14 19:05:56 2020 +0100

IPA: Avoid segfault in devirtualization_time_bonus (PR 93223)

2020-01-14  Martin Jambor  

PR ipa/93223
* ipa-cp.c (devirtualization_time_bonus): Check whether isummary is
NULL.

testsuite/
* g++.dg/ipa/pr93223.C: New test.

[Bug tree-optimization/92893] [10 Regression] Unhelpful -Wstringop-overflow warning for a trailing one-element array

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
  Component|c++ |tree-optimization

--- Comment #5 from Jason Merrill  ---
This doesn't seem like a front-end issue.

[Bug c++/92590] [10 Regression] Cannot expose protected default constructor with "using" keyword in gcc 10

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed.

[Bug c++/91930] [10 Regression] internal compiler error: in lazily_declare_fn, at cp/method.c:2423 with -fconcepts

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #9 from Jason Merrill  ---
Fixed

[Bug c++/92594] [10 Regression] internal compiler error: in build_value_init_noctor, at cp/init.c:400 using std::tuple

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:08c8c973c082457a7d6192673e87475f1fdfdbef

commit r10-5949-g08c8c973c082457a7d6192673e87475f1fdfdbef
Author: Jason Merrill 
Date:   Tue Jan 14 13:59:54 2020 -0500

PR c++/92590 - wrong handling of inherited default ctor.

I thought my earlier fix for 91930 was an obvious bug fix, but apparently
an
inherited constructor does not count as user-declared.  So this patch
reverts that change and the other follow-on patches, and fixes 91930
differently, by not letting the inherited default constructor hide the
implicitly-declared default constructor.

* class.c (add_method): A constrained inherited ctor doesn't hide an
implicit derived ctor.

Revert:
PR c++/91930 - ICE with constrained inherited default ctor.
* name-lookup.c (do_class_using_decl): Set TYPE_HAS_USER_CONSTRUCTOR
for inherited constructor.
PR c++/92552 - ICE with inherited constrained default ctor.
* pt.c (instantiate_class_template_1): Copy
TYPE_HAS_USER_CONSTRUCTOR.
PR c++/92594 - ICE with inherited trivial default ctor.
* method.c (trivial_fn_p): Treat an inherited default constructor
like a normal default constructor.

[Bug c++/92552] [10 Regression] internal compiler error: in lazily_declare_fn, at cp/method.c:3045 with -fconcepts

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:08c8c973c082457a7d6192673e87475f1fdfdbef

commit r10-5949-g08c8c973c082457a7d6192673e87475f1fdfdbef
Author: Jason Merrill 
Date:   Tue Jan 14 13:59:54 2020 -0500

PR c++/92590 - wrong handling of inherited default ctor.

I thought my earlier fix for 91930 was an obvious bug fix, but apparently
an
inherited constructor does not count as user-declared.  So this patch
reverts that change and the other follow-on patches, and fixes 91930
differently, by not letting the inherited default constructor hide the
implicitly-declared default constructor.

* class.c (add_method): A constrained inherited ctor doesn't hide an
implicit derived ctor.

Revert:
PR c++/91930 - ICE with constrained inherited default ctor.
* name-lookup.c (do_class_using_decl): Set TYPE_HAS_USER_CONSTRUCTOR
for inherited constructor.
PR c++/92552 - ICE with inherited constrained default ctor.
* pt.c (instantiate_class_template_1): Copy
TYPE_HAS_USER_CONSTRUCTOR.
PR c++/92594 - ICE with inherited trivial default ctor.
* method.c (trivial_fn_p): Treat an inherited default constructor
like a normal default constructor.

[Bug c++/92590] [10 Regression] Cannot expose protected default constructor with "using" keyword in gcc 10

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:08c8c973c082457a7d6192673e87475f1fdfdbef

commit r10-5949-g08c8c973c082457a7d6192673e87475f1fdfdbef
Author: Jason Merrill 
Date:   Tue Jan 14 13:59:54 2020 -0500

PR c++/92590 - wrong handling of inherited default ctor.

I thought my earlier fix for 91930 was an obvious bug fix, but apparently
an
inherited constructor does not count as user-declared.  So this patch
reverts that change and the other follow-on patches, and fixes 91930
differently, by not letting the inherited default constructor hide the
implicitly-declared default constructor.

* class.c (add_method): A constrained inherited ctor doesn't hide an
implicit derived ctor.

Revert:
PR c++/91930 - ICE with constrained inherited default ctor.
* name-lookup.c (do_class_using_decl): Set TYPE_HAS_USER_CONSTRUCTOR
for inherited constructor.
PR c++/92552 - ICE with inherited constrained default ctor.
* pt.c (instantiate_class_template_1): Copy
TYPE_HAS_USER_CONSTRUCTOR.
PR c++/92594 - ICE with inherited trivial default ctor.
* method.c (trivial_fn_p): Treat an inherited default constructor
like a normal default constructor.

[Bug c++/91930] [10 Regression] internal compiler error: in lazily_declare_fn, at cp/method.c:2423 with -fconcepts

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:08c8c973c082457a7d6192673e87475f1fdfdbef

commit r10-5949-g08c8c973c082457a7d6192673e87475f1fdfdbef
Author: Jason Merrill 
Date:   Tue Jan 14 13:59:54 2020 -0500

PR c++/92590 - wrong handling of inherited default ctor.

I thought my earlier fix for 91930 was an obvious bug fix, but apparently
an
inherited constructor does not count as user-declared.  So this patch
reverts that change and the other follow-on patches, and fixes 91930
differently, by not letting the inherited default constructor hide the
implicitly-declared default constructor.

* class.c (add_method): A constrained inherited ctor doesn't hide an
implicit derived ctor.

Revert:
PR c++/91930 - ICE with constrained inherited default ctor.
* name-lookup.c (do_class_using_decl): Set TYPE_HAS_USER_CONSTRUCTOR
for inherited constructor.
PR c++/92552 - ICE with inherited constrained default ctor.
* pt.c (instantiate_class_template_1): Copy
TYPE_HAS_USER_CONSTRUCTOR.
PR c++/92594 - ICE with inherited trivial default ctor.
* method.c (trivial_fn_p): Treat an inherited default constructor
like a normal default constructor.

[Bug c++/91073] [9/10 Regression] if constexpr no longer works directly with Concepts

[paolo.carlini at oracle dot com]

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

--- Comment #10 from Paolo Carlini  ---
I have been making progress on this (I'm in contact with Jason about that) but
unfortunately the issue requires additional analysis for the simple reason that
if I remove/amend my r260482 changes then in C++17 mode the testcases are
accepted again, but in C++2a they are rejected anyway with a different error:
"expected ‘auto’ or ‘decltype(auto)’ after ‘HasInit’" for
the first testcase, for example. Likewise for the second testcase.

[Bug c++/90916] [10 Regression] ICE in retrieve_specialization, at cp/pt.c:1258

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #5 from Nathan Sidwell  ---
fixed a5a3c2dcf73aa245b0eb6f6cf56c4d03ab6056da

[Bug c++/90916] [10 Regression] ICE in retrieve_specialization, at cp/pt.c:1258

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Nathan Sidwell :

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

commit r10-5948-ga5a3c2dcf73aa245b0eb6f6cf56c4d03ab6056da
Author: Nathan Sidwell 
Date:   Tue Jan 14 11:12:40 2020 -0800

[PR90916] ICE in retrieve specialization

https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00809.html
PR c++/90916
* pt.c (retrieve_specialization): Get the TI from the decl or the
classtype as appropriate.

[Bug libgcc/93053] [10 Regression] libgcc build failure with old binutils on aarch64

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Either we should document newer binutils requirement for aarch64 (and figure
out which exactly), or e.g. if it is possible fall back to using .byte or
similar to encode instructions if configure determines as doesn't handle those.

[Bug c++/92871] [10 Regression] new test case g++.dg/ext/temp-extend1.C fails starting with its introduction in r279069

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/93269] 32bit-pointer to uint64_t cast sign-extends

[jan.kratochvil at redhat dot com]

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

--- Comment #4 from Jan Kratochvil  ---
Thanks.

[Bug target/93269] 32bit-pointer to uint64_t cast sign-extends

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
.

[Bug target/93269] 32bit-pointer to uint64_t cast sign-extends

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
This is implementation defined area.  And is documented.  Neither is clang or
gcc is wrong.  Now I dont know where clang it is documented but I posted where
gcc behavior is documented. So closing as invalid.

[Bug target/93269] 32bit-pointer to uint64_t cast sign-extends

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Arrays-and-pointers-implementation.html#Arrays-and-pointers-implementation

[Bug target/93269] New: 32bit-pointer to uint64_t cast sign-extends

[jan.kratochvil at redhat dot com]

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

Bug ID: 93269
   Summary: 32bit-pointer to uint64_t cast sign-extends
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.kratochvil at redhat dot com
  Target Milestone: ---

#include 
#include 
#include 
int main() {
void *p=(void *)0x8000;
printf(  "%p""\n",   p );// 0x8000
printf("0x%" PRIxPTR "\n",(uintptr_t)p );// 0x8000
printf("0x%" PRIx64  "\n",reinterpret_cast(p));// 0x8000
printf("0x%" PRIx64  "\n",(uint64_t) p );// 0x8000
printf("0x%" PRIx64  "\n",  (uint64_t)(uintptr_t)p );// 0x8000
}


gcc-9.2.1-1.fc30.x86_64
g++ -o addr_t2 addr_t2.cpp -Wall -g -m32
0x8000
0x8000
0x8000
0x8000
0x8000

clang-8.0.0-3.fc30.x86_64
clang++ -o addr_t2 addr_t2.cpp -Wall -g -m32 ;./addr_t2
0x8000
0x8000
0x8000
0x8000
0x8000

It may be in some standard but it looks suspicious to me.

[Bug c++/91930] [10 Regression] internal compiler error: in lazily_declare_fn, at cp/method.c:2423 with -fconcepts

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
OK, let's try this again.

[Bug tree-optimization/93179] [10 Regression] ICE (segfault) in loop_depth on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Jakub Jelinek  ---
Indeed, fixed by r10-5887-g640b23d7ff5f3fad005dcbfb04a36e27000fc150

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

[Bug c++/93173] [10 Regression] "error: incorrect sharing of tree nodes" and "internal compiler error: verify_gimple failed"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||doko at debian dot org

--- Comment #4 from Jakub Jelinek  ---
*** Bug 93179 has been marked as a duplicate of this bug. ***

[Bug c++/93248] [8/9/10 Regression] ICE in decltype of template constructor with default argument within a class template since r8-2712

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-14
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
Summary|[8/9/10 Regression] ICE in  |[8/9/10 Regression] ICE in
   |decltype of template|decltype of template
   |constructor with default|constructor with default
   |argument within a class |argument within a class
   |template|template since r8-2712
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r8-2712-g4cc20315a7e67b6ebbdbfbb736122476bf28f041
Reduced testcase for -std=c++17:
template  struct S { template  S (T, V, long = 0); };
using U = decltype(S{0, 4u});

[Bug c++/92590] [10 Regression] Cannot expose protected default constructor with "using" keyword in gcc 10

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
This is a consequence of the change Jonathan cites, to treat the inherited
constructor as a user-declared constructor that prevents the implicit
declaration of a default constructor in Derived.

The difference in access behavior follows from this; the standard says,

"A synonym created by a using-declaration has the usual accessibility for a
member-declaration. A using-declarator that names a constructor does not create
a synonym; instead, the additional constructors are accessible if they would be
accessible when used to construct an object of the corresponding base class,
and the accessibility of the using-declaration is ignored."

So if constructing 'd' calls the inherited constructor, it's ill-formed; if it
calls the implicitly-declared default constructor, it's well-formed.

I thought my change was an obvious bug fix, but it seems that other compilers
have the old semantics, so I should probably undo it.

[Bug target/93254] g++ -m32 -mfpmath=sse -msse generates sse2 instructions

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:6bd65ad89c202aba3929b9a03ef7e84de873380a

commit r10-5947-g6bd65ad89c202aba3929b9a03ef7e84de873380a
Author: Uros Bizjak 
Date:   Tue Jan 14 19:07:47 2020 +0100

PR target/93254 - -msse generates sse2 instructions

* config/i386/i386.md (*movsf_internal): Require SSE2 ISA for
alternatives 9 and 10.

[Bug tree-optimization/93258] [10 regression] Missed constant folding from constructor

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Can't reproduce on x86_64-linux:
$ rm pr93258.C.*; /opt/notnfs/gcc-bisect/obj/gcc/cc1plus.272123 -quiet -w -O3
pr93258.C -fdump-tree-fre3; cat pr93258.C.* | tail -n 9
   [local count: 1073741824]:
  p = ck;
  D.2585 = bw::ci::cj (0B, 6); [return slot optimization]
  D.2585 ={v} {CLOBBER};
  __builtin_unreachable ();

}


$ rm pr93258.C.*; /opt/notnfs/gcc-bisect/obj/gcc/cc1plus.272125 -quiet -w -O3
pr93258.C -fdump-tree-fre3; cat pr93258.C.* | tail -n 9
   [local count: 1073741824]:
  p = ck;
  D.2585 = bw::ci::cj (0B, 6); [return slot optimization]
  D.2585 ={v} {CLOBBER};
  __builtin_unreachable ();

}


$ rm pr93258.C.*; /opt/notnfs/gcc-bisect/obj/gcc/cc1plus.280156 -quiet -w -O3
pr93258.C -fdump-tree-fre3; cat pr93258.C.* | tail -n 9
   [local count: 1073741824]:
  p = ck;
  D.2606 = bw::ci::cj (0B, 6); [return slot optimization]
  D.2606 ={v} {CLOBBER};
  __builtin_unreachable ();

}

[Bug tree-optimization/90917] Propagate constants into loads if dominated by str(n)cmp/memcmp

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
The solution for pr83431 doesn't handle the case in comment #2 but hopefully a
future improvement (in GCC 11) will.

[Bug tree-optimization/93266] strlen pass could optimize strncpy with known strlen (src) == 0 into memset

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
The strlen pass sets the range for non-constant strlen results so it can handle
(and make use of) this sort of thing by querying the range of the strlen lhs. 
For example, it detects the buffer overflow in the test case below, but not if
the size and length are changed to 1, because of the strlen() == 0 folding. 
(This is in the early stages so it doesn't work as well as it should.)  

char b[2];

void f (char *a)
{
  if (__builtin_strlen (a) < 2)
return;

  __builtin_strcpy (b, a);
}

[Bug tree-optimization/93262] [10 Regression] DSE memstar call trimming affecting -D_FORTIFY_SOURCE since r10-1985

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|8.4 |10.0
Summary|[8/9/10 Regression] DSE |[10 Regression] DSE memstar
   |memstar call trimming   |call trimming affecting
   |affecting -D_FORTIFY_SOURCE |-D_FORTIFY_SOURCE since
   |since r24   |r10-1985

--- Comment #4 from Jakub Jelinek  ---
Actually sorry, it really started with
r10-1985-g192ece9e15d25fd9b6534b2a8bd271684bf76d38 (while that commit looks
like only changing strncpy, it actually changed the num_args > 3 case too.

[Bug tree-optimization/93268] ICE with gcc-10 when compiling hypre library with -O3 since r10-5877

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||rsandifo at gcc dot gnu.org
  Component|c   |tree-optimization
   Target Milestone|--- |10.0
Summary|ICE with gcc-10 when|ICE with gcc-10 when
   |compiling hypre library |compiling hypre library
   |with -O3|with -O3 since r10-5877

--- Comment #6 from Jakub Jelinek  ---
Started with r10-5877-gac190fcea1bebf87a2c8c3963548a0e5272c42ec

[Bug target/92424] [aarch64] Broken code with -fpatchable-function-entry and BTI

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Marking as confirmed

[Bug libstdc++/93267] std::ranges::begin|end do not work for iota_view when the element and bound type are the same

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
The problem happens when the first template argument is an integer with no
larger integer type available. I try to use __int128 but that's not usable with
-std=c++2a.

#include 

int main()
{
  std::ranges::iota_view i(0, 3);
  std::ranges::begin(i);
}

[Bug c/93268] ICE with gcc-10 when compiling hypre library with -O3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Reduced testcase for -O3 -march=skylake-avx512:
int
foo (int *a, double *b, int *c)
{
  int f, g = 0;
  for (f = 0; f < 100; f++)
if (b[f] && c[a[f]])
  g++;
  return g;
}

[Bug libstdc++/93267] std::ranges::begin|end do not work for iota_view when the element and bound type are the same

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #6 from Jonathan Wakely  ---
(In reply to Pilar Latiesa from comment #5)
> It compiles with -std=gnu++2a but not with -std=c++2a. Hope this helps.

This is why you're supposed to provide the command, and 'gcc -v' info etc.

[Bug c/93268] ICE with gcc-10 when compiling hypre library with -O3

[kristopher.kuhlman at gmail dot com]

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

--- Comment #4 from Kris  ---
Created attachment 47653
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47653=edit
preprocessed source file

gzipped preprocessed source file attached

[Bug tree-optimization/93266] strlen pass could optimize strncpy with known strlen (src) == 0 into memset

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
If the strlen pass would handle if (__builtin_strlen (a)) return; if we
disabled the early folding, then it should be taught to handle whatever it is
folded to.
Though, I'm not sure it can, there is no code to handle sizes only for certain
parts of cfg and others for different ones.

[Bug c++/92590] [10 Regression] Cannot expose protected default constructor with "using" keyword in gcc 10

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/93101] [10 Regression] ICE - aggregate initialization of base

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Jason Merrill  ---
Yep, seems to have been fixed by the patch for bug 93173.

[Bug c++/92594] [10 Regression] internal compiler error: in build_value_init_noctor, at cp/init.c:400 using std::tuple

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Fixed.

[Bug c/93268] ICE with gcc-10 when compiling hypre library with -O3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Yes, the preprocessed file is something that is essential for us, see
https://gcc.gnu.org/bugs/ for details.

[Bug c++/92009] [10 Regression] ICE: Segmentation fault (in is_really_empty_class)

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed.

[Bug c++/92009] [10 Regression] ICE: Segmentation fault (in is_really_empty_class)

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:80de0002429c74626198cefa168c3081c9d90566

commit r10-5944-g80de0002429c74626198cefa168c3081c9d90566
Author: Jason Merrill 
Date:   Tue Jan 14 00:05:47 2020 -0500

PR c++/92009 - ICE with punning of typeid.

There were two issues in this PR:

1) We were crashing in is_really_empty_class because we say that the
internal RTTI types are classes, but never gave them TYPE_BINFO.

2) We were allowing the cast to a different pointer type because STRIP_NOPS
in cxx_fold_indirect_ref ignored REINTERPRET_CAST_P.

* rtti.c (get_tinfo_desc): Call xref_basetypes.
* constexpr.c (cxx_fold_indirect_ref): Don't strip
REINTERPRET_CAST_P.

[Bug c++/92594] [10 Regression] internal compiler error: in build_value_init_noctor, at cp/init.c:400 using std::tuple

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:8982b5535c2762f566fd15e5862acf4702a78690

commit r10-5945-g8982b5535c2762f566fd15e5862acf4702a78690
Author: Jason Merrill 
Date:   Tue Jan 14 01:00:48 2020 -0500

PR c++/92594 - ICE with inherited trivial default ctor.

Here we were getting confused about whether or not pod_tuple has a trivial
default constructor.  bar inherits the trivial e default constructor; the
effect of calling that inherited constructor is equivalent to calling a
defaulted default constructor in bar, so let's treat it as such.

* method.c (trivial_fn_p): Treat an inherited default constructor
like a normal default constructor.

[Bug fortran/93253] Regression on non-standard hex constant syntax

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl  ---
On Tue, Jan 14, 2020 at 10:48:30AM +, fx at gnu dot org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93253
> 
> --- Comment #4 from Dave Love  ---
> Apologies, I was misled by something else; that option does affect the result.
> 
> However, this change in behaviour isn't mentioned in release notes, the error
> message doesn't point to that option, and documentation suggests the code is
> supported and that option is for something else.
> 

We're in luck.  10.1 has not been released, yet; and, trunk 10.0.0
has entered stage 4 (regression and documentation fixes only).  It
seems like a good time for a new contributor to step up and fix what
s/he does not like with documentation.

And, as our good fortunate will have, the move to git means that
I'll not longer be committing changes to gfortran.  We won't have
to deal with a 1000 or so bug fixes, a few 1000 code reviews,
and design decisions based on the Fortran standard.

[Bug c/93241] [8/9/10 Regression] _Bool casts in dead branches of integer constant expressions cause undesirable warnings under -pedantic iff the dead branch contains overflow

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Joseph Myers :

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

commit r8-9933-ga2a2a06cafff858f3211a53a6ecc215f5b296565
Author: Joseph Myers 
Date:   Tue Jan 14 16:53:26 2020 +

Fix handling of overflow in C casts in integer constant expressions (PR
c/93241).

Bug 93241 reports a case where certain C expressions involving casts,
that would not be valid in an evaluated part of an integer constant
expression (because of e.g. involving integer overflow), are wrongly
rejected in an unevaluated part of an integer constant expression even
though all the operands and operations are ones that are valid in that
context.  This is a rejects-valid regression in GCC 4.5 and later
relative to 4.4 (for some testcases; the one in the bug uses
_Static_assert which isn't supported in those older releases).

The rule in the C front end is that an expression with those
properties (valid in an unevaluated part of an integer constant
expression but not an evaluated part) must be represented either as an
INTEGER_CST with TREE_OVERFLOW set or as a C_MAYBE_CONST_EXPR with
C_MAYBE_CONST_EXPR_INT_OPERANDS set.  This patch fixes build_c_cast to
check for that case and call note_integer_operands as needed.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

PR c/93241
gcc/c:
* c-typeck.c (build_c_cast): Check for expressions with integer
operands that can occur in an unevaluated part of an integer
constant expression and call note_integer_operands as needed.

gcc/testsuite:
* gcc.dg/c11-static-assert-10.c, gcc.dg/c99-const-expr-15.c: New
tests.

(cherry picked from commit 3d77686d2eddf76d3498169d0ca5653db45a8662)

[Bug target/92055] [avr] Support 64-bit double

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Georg-Johann Lay :

https://gcc.gnu.org/g:780e19f87c8a69e425b6f98703e6931f49518a80

commit r10-5942-g780e19f87c8a69e425b6f98703e6931f49518a80
Author: Georg-Johann Lay 
Date:   Tue Jan 14 17:45:40 2020 +0100

The mentioned auto-generated file is no more part of the

GCC sources, it's auto-generated in $(builddir) during build.

PR target/92055
* contrib/gcc_update (files_and_dependencies): Remove
entry for gcc/config/avr/t-multilib.

[Bug libstdc++/93267] std::ranges::begin|end do not work for iota_view when the element and bound type are the same

[pilarlatiesa at gmail dot com]

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

--- Comment #5 from Pilar Latiesa  ---
It compiles with -std=gnu++2a but not with -std=c++2a. Hope this helps.

[Bug fortran/93253] Regression on non-standard hex constant syntax

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl  ---
On Tue, Jan 14, 2020 at 11:18:45AM +, pinskia at gcc dot gnu.org wrote:
>  CUT 
> So using an undocumented extension 

The 'X' extension was documented, but I doubt anyone reads
documentation.  Prior to my patch, the docs read

6.1.10 BOZ literal constants
...
   As an extension, GNU Fortran allows hexadecimal BOZ literal constants
to be specified using the 'X' prefix, in addition to the standard 'Z'
prefix.  The BOZ literal can also be specified by adding a suffix to the
string, for example, 'Z'ABC'' and ''ABC'Z' are equivalent.
...

The docs now read

...
   As a deprecated extension, GNU Fortran allows hexadecimal BOZ literal
constants to be specified using the 'X' prefix.  The BOZ literal
constant can also be specified by adding a suffix to the string, for
example, 'Z'ABC'' and ''ABC'X' are equivalent.
...

> Basically BOZ is finally standardized in Fortran2018 and the NAS benchmark
> could be re-written in a standard format instead ...

The first part is indeed true.  User fixing invalid Fortran code
to use standard conforming syntax is encouraged.

[Bug ipa/92240] [10 regression] ICE in duplicate, at ipa-prop.c:3883

[dimhen at gmail dot com]

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

--- Comment #7 from Dmitry G. Dyachenko  ---
(In reply to Martin Liška from comment #6)
> @Dmitry: Can you please attach a pre-processed source file (-E option)?

@Martin: FAIL start for me during gcc bootstrap somewhere between r277460 and
r277485. bootstrap was restored for me at r277486.

Fedora 31, x86_64

For reproduce you can try download gcc sources, run
contrib/download_prerequesites, run configure as c#1 and make.

I"ll download preprocessed file tomorrow.

[Bug libstdc++/93267] std::ranges::begin|end do not work for iota_view when the element and bound type are the same

[pilarlatiesa at gmail dot com]

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

--- Comment #4 from Pilar Latiesa  ---
(In reply to Jonathan Wakely from comment #1)
> Please provide the output of 'gcc -v' as requested by
> https://gcc.gnu.org/bugs/

Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-linux-gnu
Configured with: ../gcc-trunk-20200114/configure --prefix=/usr
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--disable-bootstrap --with-abi=m64 --enable-clocale=gnu
--enable-languages=c,c++,fortran --enable-ld=yes --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto
--enable-plugins --enable-threads=posix --enable-libatomic --enable-libcilkrts
--enable-libgomp 
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20200111 (experimental)

(In reply to Jonathan Wakely from comment #2)
> Your testcase is invalid:
> 
> iota.cc: In function 'int main()':
> iota.cc:22:6: error: conflicting declaration 'auto beginTest4'
>22 | auto beginTest4 = std::ranges::begin(Test5); // OK
>   |  ^~
> iota.cc:19:6: note: previous declaration as 'std::ranges::iota_view unsigned int, long unsigned int>::_Iterator beginTest4'
>19 | auto beginTest4 = std::ranges::begin(Test4); // Error
>   |  ^~

Sorry. I composed the testcase from several pieces but didn't test the whole.

> It compiles for me if I fix that.

Strange. I see the same errors on Compiler Explorer:
https://godbolt.org/z/pcq7fS

[Bug libstdc++/93267] std::ranges::begin|end do not work for iota_view when the element and bound type are the same

[pilarlatiesa at gmail dot com]

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

--- Comment #3 from Pilar Latiesa  ---
(In reply to Jonathan Wakely from comment #1)
> Please provide the output of 'gcc -v' as requested by
> https://gcc.gnu.org/bugs/

Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-linux-gnu
Configured with: ../gcc-trunk-20200114/configure --prefix=/usr
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--disable-bootstrap --with-abi=m64 --enable-clocale=gnu
--enable-languages=c,c++,fortran --enable-ld=yes --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto
--enable-plugins --enable-threads=posix --enable-libatomic --enable-libcilkrts
--enable-libgomp 
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20200111 (experimental)

[Bug tree-optimization/90576] [10 regression] SPEC CPU2006 450.soplex miscompiled with -Os -flto after r271413

[mkuvyrkov at gcc dot gnu.org]

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

Maxim Kuvyrkov  changed:

   What|Removed |Added

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

--- Comment #9 from Maxim Kuvyrkov  ---
Confirmed fixed on both aarch64-linux-gnu and arm-linux-gnueabihf for -Os
-flto.  Thanks!

[Bug c/93268] ICE with gcc-10 when compiling hypre library with -O3

[kristopher.kuhlman at gmail dot com]

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

--- Comment #2 from Kris  ---
It builds with -O2, fails with -O3.

[Bug libstdc++/93267] std::ranges::begin|end do not work for iota_view when the element and bound type are the same

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Your testcase is invalid:

iota.cc: In function 'int main()':
iota.cc:22:6: error: conflicting declaration 'auto beginTest4'
   22 | auto beginTest4 = std::ranges::begin(Test5); // OK
  |  ^~
iota.cc:19:6: note: previous declaration as 'std::ranges::iota_view::_Iterator beginTest4'
   19 | auto beginTest4 = std::ranges::begin(Test4); // Error
  |  ^~


It compiles for me if I fix that.

[Bug libstdc++/93267] std::ranges::begin|end do not work for iota_view when the element and bound type are the same

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Please provide the output of 'gcc -v' as requested by https://gcc.gnu.org/bugs/

[Bug c/93268] ICE with gcc-10 when compiling hypre library with -O3

[kristopher.kuhlman at gmail dot com]

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

--- Comment #1 from Kris  ---
sorry. I guess I should add this version of gcc is built from the git version
pulled this morning.

gcc (GCC) 10.0.0 20200114 (experimental)

[Bug tree-optimization/93266] strlen pass could optimize strncpy with known strlen (src) == 0 into memset

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization
   Last reconfirmed||2020-01-14
 CC||msebor at gcc dot gnu.org
 Blocks||83819
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81433,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81704
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Martin Sebor  ---
Into memset (b, 0, N) sounds right, for any empty source string, as in: 

void f (char *b, const char *a, unsigned n)
{
  if (__builtin_strlen (a))
return;

  __builtin_strncpy (b, a, n);
}

Unfortunately, determining that a is empty in the strncpy call above is
defeated by the super-early strlen() != 0 folding, so the strlen pass has no
idea of a's length.


Referenced Bugs:

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

[Bug tree-optimization/90576] [10 regression] SPEC CPU2006 450.soplex miscompiled with -Os -flto after r271413

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
(In reply to Maxim Kuvyrkov from comment #7)
> Apologies for delay.  Kicked off SPEC2k6 builds, and will report results
> tomorrow.

PING

[Bug c/93268] New: ICE with gcc-10 when compiling hypre library with -O3

[kristopher.kuhlman at gmail dot com]

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

Bug ID: 93268
   Summary: ICE with gcc-10 when compiling hypre library with -O3
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kristopher.kuhlman at gmail dot com
  Target Milestone: ---

I am building petsc, and the hypre library being built as part of that triggers
this ICE when using optimization. When building the same library with -Og there
is no ICE.

This library didn't trigger this ICE with a gcc version from a month or two
ago, so this is maybe due to a recent change?

I created a pre-processed version of the relevant source file, but it is
enormous (12k lines). I can attach it if desired.

Kris

--

/home/klkuhlm/src/petsc/tgcc-c-perf/bin/mpicc -fstack-protector -O3
-march=native  -DHAVE_CONFIG_H -I.. -I. -I./.. -I./../blas -I./../lapack
-I./../utilities -I./../seq_mv  -I/home/klkuhlm/src/petsc/tgcc-c-perf/include
-c par_csr_matop_marked.c 
../config/Makefile.config:49: recipe for target 'par_csr_matop.o' failed
make[1]: Leaving directory
'/home/klkuhlm/src/petsc/tgcc-c-perf/externalpackages/hypre-2.15.1/src/parcsr_mv'
Makefile:90: recipe for target 'all' failedduring GIMPLE pass: vect
par_csr_matop.c: In function ‘hypre_ParCSRMatrixExtractBExt_Arrays_Overlap’:
par_csr_matop.c:1063:6: internal compiler error: in get_load_store_type, at
tree-vect-stmts.c:2462
 1063 | void hypre_ParCSRMatrixExtractBExt_Arrays_Overlap(
  |  ^~~~
0x6f7de9 get_load_store_type
../../gcc-trunk/gcc/tree-vect-stmts.c:2462
0xfb254b vectorizable_load
../../gcc-trunk/gcc/tree-vect-stmts.c:8708
0xfc8f0e vect_transform_stmt(_stmt_vec_info*, gimple_stmt_iterator*,
_slp_tree*, _slp_instance*)
../../gcc-trunk/gcc/tree-vect-stmts.c:10989
0xfcac1e vect_transform_loop_stmt
../../gcc-trunk/gcc/tree-vect-loop.c:8299
0xfe1c6c vect_transform_loop(_loop_vec_info*)
../../gcc-trunk/gcc/tree-vect-loop.c:8690
0xffd6f9 try_vectorize_loop_1
../../gcc-trunk/gcc/tree-vectorizer.c:989
0xffd8f7 try_vectorize_loop_1
../../gcc-trunk/gcc/tree-vectorizer.c:1026
0xffe3f9 vectorize_loops()
../../gcc-trunk/gcc/tree-vectorizer.c:1125
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[1]: *** [par_csr_matop.o] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [all] Error 1

[Bug libstdc++/93267] New: std::ranges::begin|end do not work for iota_view when the element and bound type are the same

[pilarlatiesa at gmail dot com]

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

Bug ID: 93267
   Summary: std::ranges::begin|end do not work for iota_view when
the element and bound type are the same
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pilarlatiesa at gmail dot com
  Target Milestone: ---

The following testcase emits errors at the specified locations:

#include 
#include 

int main()
{
std::size_t const Zero = 0u;
std::size_t const Size = 10u;

auto const Test1 = std::ranges::views::iota(0, Size);
auto beginTest1 = std::ranges::begin(Test1); // OK

auto const Test2 = std::ranges::views::iota(Zero, Size);
auto beginTest2 = std::ranges::begin(Test2); // Error

std::ranges::iota_view const Test3(Zero, Size);
auto beginTest3 = std::ranges::begin(Test3); // Error

std::ranges::iota_view const Test4(0, Size);
auto beginTest4 = std::ranges::begin(Test4); // Error

std::ranges::iota_view const Test5(0, Size);
auto beginTest4 = std::ranges::begin(Test5); // OK
}

The error reads:

error: no match for call to '(const std::ranges::__cust_access::_Begin) (const
std::ranges::iota_view&)'


/home/pililatiesa/gcc-trunk-20200114/include/c++/10.0.0/bits/range_access.h:420:2:
note: candidate: 'constexpr auto
std::ranges::__cust_access::_Begin::operator()(_Tp&&) const [with _Tp = const
std::ranges::iota_view&]'

  420 |  operator()(_Tp&& __t) const noexcept(_S_noexcept<_Tp>())

  |  ^~~~

/home/pililatiesa/gcc-trunk-20200114/include/c++/10.0.0/bits/range_access.h:420:2:
note: constraints not satisfied

: In instantiation of 'constexpr auto
std::ranges::__cust_access::_Begin::operator()(_Tp&&) const [with _Tp = const
std::ranges::iota_view&]':

:10:34:   required from here

/home/pililatiesa/gcc-trunk-20200114/include/c++/10.0.0/bits/range_access.h:420:2:
  required by the constraints of 'template  requires
(__maybe_safe_range<_Tp>) && ((is_array_v::remove_reference_t>) || (__member_begin<_Tp>) ||
(__adl_begin<_Tp>)) constexpr auto
std::ranges::__cust_access::_Begin::operator()(_Tp&&) const'

/home/pililatiesa/gcc-trunk-20200114/include/c++/10.0.0/bits/range_access.h:418:4:
note: neither operand of the disjunction is satisfied

  418 ||| __adl_begin<_Tp>

[Bug ipa/92240] [10 regression] ICE in duplicate, at ipa-prop.c:3883

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
@Dmitry: Can you please attach a pre-processed source file (-E option)?

[Bug lto/91576] [10 Regression] error: invalid conversion in gimple call since r272749

[marxin at gcc dot gnu.org]

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

--- Comment #19 from Martin Liška  ---
> 
> Martin, did you try to get some testsuite scale version of the last testcase?

Sorry, but no. So please apply the patch and we can close it.

[Bug lto/92600] [9/10 Regression] ICE: symtab_node::verify failed, building 523.xalancbmk_r with -flto -fno-inline since r267359

[hubicka at gcc dot gnu.org]

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

--- Comment #6 from Jan Hubicka  ---
Well, because the source files differs, the comdat group differs and the
loosing one has fewer symbols in it.  So we end up keeping some symbols from
the other comdat group that happens to have same name.  The compilation is
bound to fail, so I guess question is how best to silence the ICE.  I suppose
we may get around by dissoling comdat groups of all UNDEF symbols

[Bug c/92935] typeof() on an atomic type doesn't always return the corresponding unqualified type

[pskocik at gmail dot com]

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

pskocik at gmail dot com changed:

   What|Removed |Added

 CC||pskocik at gmail dot com

--- Comment #1 from pskocik at gmail dot com ---
I don't think typeof is supposed to lose qualifiers. _Generic(Expr,...) loses
them for Expr in an rvalue conversion (also decays arrays to pointer), but
__typeof is supposed to preserve everything--it does preserve qualifiers in
other compilers (clang/tinycc) and in gcc:

_Atomic const int aci=0;
_Generic(, _Atomic const int*: (void)0); //ok
_Atomic typeof(const int) aci2=0;
_Generic(, _Atomic const int*: (void)0); //ok

but there does seem to be a bug in gcc in how typeof combines with pointer
symbols (*) and other qualifiers where gcc appears to be curiously dropping all
qualifiers if (and only if) one of the original qualifiers was _Atomic

_Generic((typeof(aci)*)0, _Atomic const int*: (void)0); //gcc error (int*),
ok on clang
_Generic((typeof(aci2)*)0, _Atomic const int*: (void)0); //gcc error
(int*), ok on clang
 _Generic((typeof(aci2) volatile*)0, _Atomic const volatile int*: (void)0);
//gcc error (int volatile*), ok on clang


Clang doesn't do this, and neither gcc or clang typeof drops any qualifiers if
there's no _Atomic among them:

 //no qualifs dropped if no _Atomic was involved
 const int ci=0;
_Generic(,  const int*: (void)0); //ok
 typeof(const int) ci2=0;
_Generic(,  const int*: (void)0); //ok


_Generic((typeof(ci)*)0,  const int*: (void)0); //ok
_Generic((typeof(ci2)*)0,  const int*: (void)0);  //ok
 _Generic((typeof(ci2) volatile*)0,  const volatile int*: (void)0); //ok

https://gcc.godbolt.org/z/TwtEGP

[Bug lto/89358] [8 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings

[hubicka at gcc dot gnu.org]

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

--- Comment #19 from Jan Hubicka  ---
I think backporting would be a good idea :) If you beat me on it even better.
Now I need to set up my trees in git...

[Bug ipa/93144] [10 Regression] 459.GemsFDTD debug info size increase by 50% since r279563

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  ---
Well, the problem was debug info getting bigger due to more inlining? I guss in
that case we could close it. That patch is expected to allow more inlines.

[Bug tree-optimization/93265] memcmp comparisons of structs wrapping a primitive type not as compact/efficient as direct comparisons of the underlying primitive type under -Os

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
So I see it already resolved to a direct compare during GENERIC folding
which is probably confused by the COMPOUND_LITERAL_EXPR:

  return memcmp ((const void *) , (const void *) &<<< Unknown tree:
compound_literal_expr
const struct a_tp D.2112 = {.x=42}; >>>, 4) == 0;

I think tree-ssa-strlen.c has code to change memcmp to memcmp_eq which can
be more optimally expanded.  It also has code to directly emit more optimal
GIMPLE.

Not sure why that doesn't fire here.  Confirmed.