[Bug fortran/92533] [F2018] Permit module names in access-stmt (public::/private::)

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  ---
NOTE:
  use, public :: C
is not (yet) permitted, but might well be added in the future. See
https://github.com/j3-fortran/fortran_proposals/issues/88 and
https://mailman.j3-fortran.org/pipermail/j3/2019-November/thread.html#11753
Note the example 'use, public :: A; use, private :: A' by Bob, which can be
resolved via the quoted text previous comment of this PR.

[Bug fortran/92533] [F2018] Permit module names in access-stmt (public::/private::)

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #1)
> Note that one needs to handle:
> 
> module A; integer, parameter :: A1 = 1, A2 = 2; end module A
> module B; use A; end module B
> module C; use A; end module B

This code cannot possibly be correct.  Perhaps, not using
the semicolon when writing test code would be a good idea.

[Bug fortran/92533] [F2018] Permit module names in access-stmt (public::/private::)

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  ---
Note that one needs to handle:

module A; integer, parameter :: A1 = 1, A2 = 2; end module A
module B; use A; end module B
module C; use A; end module B
module D
  use B
  use C
  private
  private B
  public C
 ! private :: A1

That's resolved by:

"If an identifier is accessed by use association and not declared in the
module, and the name of every module from which it is accessed appears in an
access-stmt in the scoping unit, its default accessibility is PRIVATE if the
access-spec in every such access-stmt is PRIVATE, or PUBLIC if the access-spec
in any such access-stmt is PUBLIC."

[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64

[egallager at gcc dot gnu.org]

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

--- Comment #21 from Eric Gallager  ---
(In reply to Dávid Bolvanský from comment #20)
> Clang implemented [0] this diagnostic under -Wxor-used-as-pow.
> From user perspective it would be reasonable if GCC follows this naming.
> 
> [0] https://reviews.llvm.org/D63423

ok I retract my previous support for -Wexclusive-or and now back
-Wxor-used-as-pow instead.

[Bug other/64534] invalid -march value incosistency

[vityokster at gmail dot com]

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

--- Comment #2 from Viktor Yu. Kovalskii  ---
(In reply to Martin Sebor from comment #1)
> Confirmed:
> 
> $ echo | /home/msebor/build/gcc-trunk-svn/gcc/xgcc
> -B/home/msebor/build/gcc-trunk-svn/gcc -S -march=foobar -march=core2
> -o/dev/null -xc -
> 
> $ echo | /home/msebor/build/gcc-trunk-svn/gcc/xgcc
> -B/home/msebor/build/gcc-trunk-svn/gcc -S -march=foobar -march=native
> -o/dev/null -xc -
> :1:0: error: bad value (foobar) for -march= switch
> 
> This seems to be due to the special treatment of -march=native by the i386
> driver which forces it before any other -march= options, even if they are
> specified first on the command line.

Any progress?

[Bug c++/92539] New: [8/9/10 Regression] -Warray-bounds false positive (loop unroll?)

[nok.raven at gmail dot com]

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

Bug ID: 92539
   Summary: [8/9/10 Regression] -Warray-bounds false positive
(loop unroll?)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nok.raven at gmail dot com
  Target Milestone: ---

static bool
ischar(int ch)
{
return (0 == (ch & ~0xff) || ~0 == (ch | 0xff)) != 0;
}

static bool eat(char const*& first, char const* last)
{
if (first != last && ischar(*first)) {
++first;
return true;
}
return false;
}

static bool eat_two(char const*& first, char const* last)
{
auto save = first;
if (eat(first, last) && eat(first, last))
return true;
first = save;
return false;
}

static bool foo(char const*& first, char const* last)
{
auto local_iterator = first;
int i = 0;
for (; i < 3; ++i)
if (!eat_two(local_iterator, last))
return false;
first = local_iterator;
return true;
}

static bool test(char const* in, bool full_match = true)
{
auto last = in;
while (*last)
++last;
return foo(in, last) && (!full_match || (in == last));
}

int main()
{
return test("aa");
}

$ g++ -std=c++17 -O3 -Wall

: In function 'int main()':
:9:23: warning: array subscript 4 is outside array bounds of 'const
char [3]' [-Warray-bounds]
9 | if (first != last && ischar(*first)) {
  | ~~^
:9:23: warning: array subscript 5 is outside array bounds of 'const
char [3]' [-Warray-bounds]
9 | if (first != last && ischar(*first)) {
  | ~~^
:41:42: warning: array subscript 6 is outside array bounds of 'const
char [3]' [-Warray-bounds]
   41 | return foo(in, last) && (!full_match || (in == last));
  | ~^~~~

https://godbolt.org/z/86XVfe

The code is reduced Spirit.X3 test.

The -fsanitize=address and -fsanitize=undefined do not show any errors.

[Bug ipa/92538] Proposal for IPA init() constant propagation

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||4131

--- Comment #1 from Andrew Pinski  ---
This looks related to PR 4131.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
[Bug 4131] The C++ compiler doesn't place a const class object to ".rodata"
section with non trivial constructor

[Bug ipa/92538] New: Proposal for IPA init() constant propagation

[erick.oc...@theobroma-systems.com]

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

Bug ID: 92538
   Summary: Proposal for IPA init() constant propagation
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: erick.oc...@theobroma-systems.com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

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

Hello,

we've been working on an lto optimization and would like to receive some
feedback on this candidate patch.
At the moment the patch compiles correctly when applied to master.
We have some initial test cases in a separate repository and have compiled and
ran a small subset of CPU 2017 benchmarks with comparable results.

The proposed transformation (ipa-initcall-cp) is a variant of interprocedural
constant propagation.
ip-initcall-cp collects all variables with static lifetime that contain only a
single write (like in the cases of initialization functions) and propagates it
to reads across the whole link unit.

In order to run, apply the patch and compile with `-lto -finitcall-cp`.

In order for this transformation to be sound
* writes that can be reached from a function pointer,
* writes that can be reached from a function with outside visibility, and
* writes that may happen after any read
are not taken into account.

In order to determine that no read happens before the write, we have to:
* find the main function
* find the function and basic block of the write
*   for each read in another function
* make sure that call to write dominates all callees of the read function
*   for each read in the same function
* make sure that write dominates read

Some initial drawbacks:
* We've noticed that we have to disable ipa-cp in order for ipa-initcall-cp to
run successfully.
This is most likely due to some issue with clones and we will need to make some
design changes.
The function materialize all clones fails after ipa-initcall-cp if ipa-cp is
not commented out.
Suggestions are welcomed.
* At the moment, I still need to clean the code a bit, since it doesn't pass
the standards.
* I still need to add tests using the testsuite as opposed to running them
myself.

Some future work:
* At the moment, ipa-initcall-cp only propagates values from a single write.
However, we could conceivably improve this work to propagate the first n-writes
and specialize functions based on the constants.

[Bug libstdc++/92522] valid code using deque throws bad_alloc when compiled with -flto

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Even PR 53068 .

[Bug libstdc++/92522] valid code using deque throws bad_alloc when compiled with -flto

[johnilacqua at hotmail dot com]

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

--- Comment #2 from John  ---
(In reply to Richard Biener from comment #1)
> Isn't this undefined since you require 'test' to be constructed before
> 'sample'
> but the order of global CTORs is undefined between translation units?
> 
> IIRC there's a duplicate bugreport with further suggetions as to how to
> try to mimic non-LTO behavior here (sort CTORs in "link order").

Sorry, you're right, I completely missed that. Apologies, can close this as not
a bug. This is probably something that's difficult to identify and warn on,
isn't it?

[Bug c++/92536] [10 Regression] ICE when trying to using deduction guide following unknown type error

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-15
 CC||jason at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
ICE started with spaceship support in r277865

[Bug c++/91962] [10 Regression] ice in build_target_expr, at cp/tree.c:488

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
No but I'll commit it soon.

[Bug c++/91962] [10 Regression] ice in build_target_expr, at cp/tree.c:488

[dcb314 at hotmail dot com]

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

--- Comment #5 from David Binderman  ---
Still broken a few weeks later. Did the patch every make it into trunk ?

[Bug tree-optimization/92537] New: [10 Regression] internal compiler error: in vect_slp_analyze_node_operations, at tree-vect-slp.c:2775

[anlauf at gcc dot gnu.org]

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

Bug ID: 92537
   Summary: [10 Regression] internal compiler error: in
vect_slp_analyze_node_operations, at
tree-vect-slp.c:2775
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gcc dot gnu.org
  Target Milestone: ---

This is a recent regression occurring with Fortran code.  If it is a FE issue,
feel free to re-categorize.

The two modules below need to be compiled separately and with options

-O2 -march=skylake -ftree-vectorize

(or for any other modern x86_64 processor), to get:

during GIMPLE pass: slp
mod2.f90:5:0:

5 |   subroutine foo (pr)
  | 
internal compiler error: in vect_slp_analyze_node_operations, at
tree-vect-slp.c:2775
0xfc2c6b vect_slp_analyze_node_operations
../../trunk/gcc/tree-vect-slp.c:2775
0xfc341a vect_slp_analyze_operations(vec_info*)
../../trunk/gcc/tree-vect-slp.c:2862
0xfc902f vect_slp_analyze_bb_1
../../trunk/gcc/tree-vect-slp.c:3199
0xfc902f vect_slp_bb_region
../../trunk/gcc/tree-vect-slp.c:3260
0xfc902f vect_slp_bb(basic_block_def*)
../../trunk/gcc/tree-vect-slp.c:3395
0xfcbd7a execute
../../trunk/gcc/tree-vectorizer.c:1320


% cat mod1.f90
module mod1
  implicit none
  integer, parameter :: wp = kind (1.d0)
  interface p_min
 module procedure p_min_wp
  end interface
contains
  function p_min_wp (x) result (p_min)
real(wp), intent(in) :: x
real(wp) :: p_min
p_min = x
  end function p_min_wp
end module mod1

% cat mod2.f90
MODULE mod2
  use mod1, only: p_min, wp
  implicit none
contains
  subroutine foo (pr)
real(wp), pointer :: pr(:)
integer  ::  nzd
real(wp) ::  pmin
real(wp) ::  pmin_diag
integer  ::  i
nzd  = 15
allocate (pr(nzd))
pmin_diag = 4000._wp
pmin = p_min(pmin_diag)
pmin = min (pmin,pmin_diag)
pr(1) = log(pmin)
do i=1,nzd-1
   pr(i+1) = log(pmin) + i
end do
  end subroutine foo
end module mod2


Compilation passes e.g. with -O1, -fno-tree-vectorize, changing 1.d0 to 1.0,
changing the loop bounds, or several other minor variations of the code.

[Bug c++/92536] New: [10 Regression] ICE when trying to using deduction guide following unknown type error

[redi at gcc dot gnu.org]

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

Bug ID: 92536
   Summary: [10 Regression] ICE when trying to using deduction
guide following unknown type error
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

namespace std
{
  struct stop_token { };

  template
struct stop_callback
{
  template
  stop_callback(stop_token, C&&) { }
};

template
stop_callback(stop_token, _Callback) -> stop_callback<_Callback>;
}

int main()
{
  std::stop_token tok;
  std::function f([](){});
  std::stop_callback cb(tok, f);
}

This crashes when compiled with -std=gnu++17

stop.cc: In function 'int main()':
stop.cc:19:8: error: 'function' is not a member of 'std'
   19 |   std::function f([](){});
  |^~~~
stop.cc:1:1: note: 'std::function' is defined in header ''; did you
forget to '#include '?
  +++ |+#include 
1 | namespace std
stop.cc:19:25: error: 'f' was not declared in this scope
   19 |   std::function f([](){});
  | ^
stop.cc:20:31: error: class template argument deduction failed:
   20 |   std::stop_callback cb(tok, f);
  |   ^
stop.cc:20:31: internal compiler error: Segmentation fault
0xf80c3f crash_signal
/home/jwakely/src/gcc/gcc/gcc/toplev.c:328
0x85a1b5 add_candidates
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:5772
0x85efbb add_candidates
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:4453
0x85efbb perform_overload_resolution
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:4461
0x8656a2 build_new_function_call(tree_node*, vec**, int)
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:4535
0x9c207f do_class_deduction
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:28071
0x9c207f do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:28119
0x8eb86f cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/home/jwakely/src/gcc/gcc/gcc/cp/decl.c:7383
0x996e7e cp_parser_init_declarator
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:20727
0x976d22 cp_parser_simple_declaration
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:13624
0x978ae9 cp_parser_declaration_statement
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:13055
0x979733 cp_parser_statement
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:11380
0x97a6b8 cp_parser_statement_seq_opt
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:11742
0x97a797 cp_parser_compound_statement
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:11696
0x993110 cp_parser_function_body
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:22866
0x993110 cp_parser_ctor_initializer_opt_and_function_body
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:22917
0x996466 cp_parser_function_definition_after_declarator
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:28586
0x997273 cp_parser_function_definition_from_specifiers_and_declarator
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:28502
0x997273 cp_parser_init_declarator
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:20495
0x976d22 cp_parser_simple_declaration
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:13624
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/92532] ICE in gimple-ssa-sprintf.c

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Please fix this soon.  I think we still have the 48h rule?

[Bug c++/67491] [meta-bug] concepts issues

[Casey at Carter dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 90734, which changed state.

Bug 90734 Summary: [concepts] Pre-normalization substitution into constraints 
of templated function breaks subsumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90734

   What|Removed |Added

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

[Bug c++/90734] [concepts] Pre-normalization substitution into constraints of templated function breaks subsumption

[Casey at Carter dot net]

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

Casey Carter  changed:

   What|Removed |Added

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

--- Comment #4 from Casey Carter  ---
There's some confusion here as a result of my inadequate description in the
original bug. The line `static_assert(S1::f()); // Bogus error` is valid
but was not accepted and the line `static_assert(S2::f()); // Bogus
non-error` is invalid but was not rejected. This should have been tagged both
"rejects-valid" and "accepts-invalid" (or better yet, I should have filed
separate issues instead of conflating the two).

As Andrew says, trunk now both accepts and rejects the cases it should here.
I'll simply close this since I don't think it provides any useful or unique
test case.

[Bug middle-end/92532] ICE in gimple-ssa-sprintf.c

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Most likely a duplicate of pr92493.  (If not, please reopen this and attach a
translation unit that reproduces it.)

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

[Bug tree-optimization/92493] ICE in get_origin_and_offset at gimple-ssa-sprintf.c:2314

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
*** Bug 92532 has been marked as a duplicate of this bug. ***

[Bug ipa/92535] [10 regression] ICF is relatively expensive and became less effective

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka  ---
Forgot bloaty report for GCC9 and disabling ICF
$ bloaty libxul.so -- libxul.so.old 
 VM SIZE  FILE SIZE
 ++ GROWING++
  +2.3% +1.87Mi .text  +1.87Mi  +2.3%
  +5.4%  +423Ki .eh_frame   +423Ki  +5.4%
  +7.1%  +122Ki .eh_frame_hdr   +122Ki  +7.1%
  +0.6% +61.3Ki .rela.dyn  +61.3Ki  +0.6%
  +0.2% +29.8Ki .rodata+29.8Ki  +0.2%
  +0.4% +14.1Ki .data.rel.ro.local +14.1Ki  +0.4%
  +1.5% +12.0Ki .data.rel.ro   +12.0Ki  +1.5%
  +0.1%+224 .data +224  +0.1%

 -- SHRINKING  --
  [ = ]   0 .strtab -291Ki  -0.7%
  [ = ]   0 .symtab-46.6Ki  -0.3%
 -69.6%-240 [Unmapped] -3.12Ki -73.1%
  -0.0%-120 .bss 0  [ = ]

  +1.8% +2.51Mi TOTAL  +2.18Mi  +1.1%

[Bug ipa/92535] [10 regression] ICF is relatively expensive and became less effective

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  ---
Created attachment 47276
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47276=edit
Memory use of gcc9

[Bug ipa/92535] [10 regression] ICF is relatively expensive and became less effective

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  ---
Created attachment 47277
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47277=edit
Meory use of gcc9 with ICF disabled

[Bug ipa/92535] [10 regression] ICF is relatively expensive and became less effective

[hubicka at gcc dot gnu.org]

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

--- Comment #1 from Jan Hubicka  ---
Created attachment 47275
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47275=edit
memory use of GCC10 with icf disabled

[Bug ipa/92535] New: [10 regression] ICF is relatively expensive and became less effective

[hubicka at gcc dot gnu.org]

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

Bug ID: 92535
   Summary: [10 regression] ICF is relatively expensive and became
less effective
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 47274
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47274=edit
Memory use graph for linktime for GCC10

ICF currently is very conservative optimizing libxul.so saving only about 1.5%
of text segment:

$ bloaty libxul.so -- libxul.so.old2
 VM SIZE  FILE SIZE
 ++ GROWING++
  +1.5% +1.21Mi .text  +1.21Mi  +1.5%
  +4.4%  +351Ki .eh_frame   +351Ki  +4.4%
  +6.0%  +102Ki .eh_frame_hdr   +102Ki  +6.0%
  [ = ]   0 .strtab+62.4Ki  +0.2%
  +0.5% +52.6Ki .rela.dyn  +52.6Ki  +0.5%
  +0.1% +19.6Ki .rodata+19.6Ki  +0.1%
  +0.4% +13.2Ki .data.rel.ro.local +13.2Ki  +0.4%
  +1.3% +9.97Ki .data.rel.ro   +9.97Ki  +1.3%
  +0.2% +12 .gcc_except_table  +12  +0.2%

 -- SHRINKING  --
  [ = ]   0 .symtab-10.0Ki  -0.1%
  -0.0% -64 .data  -64  -0.0%
  -0.0% -16 .bss 0  [ = ]

 -+-+-+-+-+-+-+ MIXED  +-+-+-+-+-+-+-
   +76%+124 [Unmapped] -3.04Ki -77.5%

  +1.3% +1.75Mi TOTAL  +1.79Mi  +0.9%

This used to be 7% in GCC5 (at Firefox from 2015)

At the same time it is relatively expensive memory wise and compile time wise.

It increases peak memory use from 6GB to 7.5GB and compile time from:
real8m57.454s
user91m8.020s
sys 6m20.372s

to

real9m41.361s
user91m47.076s
sys 6m16.760s

For GCC 9 the code size improvement is 2.3%, build time change is:
real7m53.778s
user76m10.368s
sys 6m55.324s

to

real8m14.613s
user72m57.932s
sys 6m32.792s

and peak memory use is from 8gm to 10gb.

[Bug c++/89913] [8/9/10 Regression] ICE with invalid using declaration

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2019-11/msg01429.ht
   ||ml
 CC||egallager at gcc dot gnu.org
 Blocks|67491   |
Summary|[8/9/10 Regression] |[8/9/10 Regression] ICE
   |[concepts] ICE with invalid |with invalid using
   |using declaration   |declaration
   Severity|normal  |minor

--- Comment #4 from Eric Gallager  ---
(In reply to Andrew Sutton from comment #3)
> This isn't strictly related to concepts.

ok, removing that part then.

> 
> Resolution posted here:
> 
> https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01429.html
> 
> The tests target C++20, but this could be extended back to C++11. However,
> the diagnostic is different for pre-C++20.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug c++/90287] [concepts] bogus error on overload failure inside requires-expression

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |RESOLVED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2019-11/msg01051.ht
   ||ml
 CC||egallager at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Eric Gallager  ---
(In reply to Andrew Sutton from comment #1)
> This is a duplicate of 92186.
> 
> A resolution is available here:
> 
> https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01051.html

ok, closing as such. I see you're under the Write-After-Approval section of
MAINTAINERS, which means you should have an "at gcc dot gnu dot org" email
address, correct? If so, I recommend using that to log into bugzilla, as then
you can close stuff, mark as duplicates, & do other editing of bugs as well.

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

[Bug c++/92186] [concepts] requires expression outside of concept definition cannot return false

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||redbeard0531 at gmail dot com

--- Comment #3 from Eric Gallager  ---
*** Bug 90287 has been marked as a duplicate of this bug. ***

[Bug c++/67491] [meta-bug] concepts issues

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 90287, which changed state.

Bug 90287 Summary: [concepts] bogus error on overload failure inside 
requires-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90287

   What|Removed |Added

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

[Bug target/65649] gcc generates overlarge constants for microblaze-linux-gnu

[nsz at gcc dot gnu.org]

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

--- Comment #7 from nsz at gcc dot gnu.org ---
Author: nsz
Date: Fri Nov 15 17:39:14 2019
New Revision: 278308

URL: https://gcc.gnu.org/viewcvs?rev=278308=gcc=rev
Log:
microblaze: fix PR65649

microblaze-linux-musl build fails without this.

(This is a rebase of an earlier patch posted on bugzilla.)

gcc/ChangeLog:

2019-11-15  Nick Clifton  
Szabolcs Nagy  

PR target/65649
* config/microblaze/microblaze.c (print_operand): Print value as long.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/microblaze/microblaze.c

[Bug target/92534] New: [10 regression] gcc.dg/vect/bb-slp-42.c fails after r278262

[seurer at gcc dot gnu.org]

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

Bug ID: 92534
   Summary: [10 regression] gcc.dg/vect/bb-slp-42.c fails after
r278262
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

I am only seeing this on power 7 (thus BE).  Works fine on power 8 BE & LE and
power 9.

Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vect/bb-slp-42.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never   -maltivec -mvsx
-mno-allow-movmisalign -ftree-vectorize -fno-tree-loop-distribute-patterns
-fno-vect-cost-model -fno-common -O2 -fdump-tree-slp-details  -lm  -o
./bb-slp-42.exe(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vect/bb-slp-42.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -maltivec -mvsx
-mno-allow-movmisalign -ftree-vectorize -fno-tree-loop-distribute-patterns
-fno-vect-cost-model -fno-common -O2 -fdump-tree-slp-details -lm -o
./bb-slp-42.exe
PASS: gcc.dg/vect/bb-slp-42.c (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/build/gcc-test2/gcc::/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs
Execution timeout is: 300
spawn [open ...]
FAIL: gcc.dg/vect/bb-slp-42.c execution test
PASS: gcc.dg/vect/bb-slp-42.c scan-tree-dump slp1 "Found vectorizable
constructor"
PASS: gcc.dg/vect/bb-slp-42.c scan-tree-dump-times slp1 "vectorizing stmts
using SLP" 4
Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vect/bb-slp-42.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never  -flto -ffat-lto-objects
-maltivec -mvsx -mno-allow-movmisalign -ftree-vectorize
-fno-tree-loop-distribute-patterns -fno-vect-cost-model -fno-common -O2
-fdump-tree-slp-details  -lm  -o ./bb-slp-42.exe(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vect/bb-slp-42.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -flto -ffat-lto-objects
-maltivec -mvsx -mno-allow-movmisalign -ftree-vectorize
-fno-tree-loop-distribute-patterns -fno-vect-cost-model -fno-common -O2
-fdump-tree-slp-details -lm -o ./bb-slp-42.exe
PASS: gcc.dg/vect/bb-slp-42.c -flto -ffat-lto-objects (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/build/gcc-test2/gcc::/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs
Execution timeout is: 300
spawn [open ...]
FAIL: gcc.dg/vect/bb-slp-42.c -flto -ffat-lto-objects execution test
PASS: gcc.dg/vect/bb-slp-42.c -flto -ffat-lto-objects  scan-tree-dump slp1
"Found vectorizable constructor"
PASS: gcc.dg/vect/bb-slp-42.c -flto -ffat-lto-objects  scan-tree-dump-times
slp1 "vectorizing stmts using SLP" 4
testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vect/vect.exp
completed in 3 seconds

=== gcc Summary ===

# of expected passes6
# of unexpected failures2

[Bug ipa/92528] [10 Regression] ICE in ipa_get_parm_lattices since r278219

[dcb314 at hotmail dot com]

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

--- Comment #9 from David Binderman  ---
(In reply to Martin Liška from comment #2)
> @David: Are you reducing that or not?

I was, but other folks are more keen than me in this area
and so my efforts are overtaken by events. 

Good news on a prompt fix.

[Bug c++/89442] [concepts] missing "wrong number of template arguments" error in requires-clause

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #1 from Andrew Sutton  ---
The error is a little better in trunk, but I think this should be caught when
it's parsed: you can't ever use foo with one argument.

Looking into this, we aren't converting template arguments for dependent
variable templates in finish_id_expr, but we probably should.

I don't think this is strictly concepts-related.

[Bug ipa/92528] [10 Regression] ICE in ipa_get_parm_lattices since r278219

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor  ---
(In reply to Jan Hubicka from comment #6)
> There is no need to clear polymorphic call context. It does not refer to the
> parameters of caller. If it was valid for all possible contexts it is still
> valid. 
> 
> So I think ipa_set_jf_unknown shall not clear bits and m_vr.

I agree, it should not, scalar UNKNOWN is not necessarily related to
the non-scalar bits.  I'll put that to my TODO-list (but feel free to
move it out before I do :-)

[Bug fortran/92533] New: [F2018] Permit module names in access-stmt (public::/private::)

[burnus at gcc dot gnu.org]

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

Bug ID: 92533
   Summary: [F2018] Permit module names in access-stmt
(public::/private::)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Fortran 2018 now permits:

module A
  use B
  private :: B

Namely,
R827  access-stmt  is  access-spec[ [ :: ]access-id-list]
C870 (R828) Each access-name shall be the name of a module, variable,
procedure, derived type, named constant, or namelist group.

Fortran 2008 had:

R524  access-stmt  is access-spec[ [ ::  ]access-id -list]
C563(R525) Each use-name shall be the name of a named variable, procedure,
derived type, named constant, or namelist group.

Currently, the code gets rejected with:
   Error: PRIVATE attribute applied to MODULE …
or Error: PUBLIC attribute applied to MODULE …

[Bug c++/89913] [8/9/10 Regression] [concepts] ICE with invalid using declaration

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #3 from Andrew Sutton  ---
This isn't strictly related to concepts.

Resolution posted here:

https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01429.html

The tests target C++20, but this could be extended back to C++11. However, the
diagnostic is different for pre-C++20.

[Bug c++/90287] [concepts] bogus error on overload failure inside requires-expression

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #1 from Andrew Sutton  ---
This is a duplicate of 92186.

A resolution is available here:

https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01051.html

[Bug c++/91353] Implement P1331R2: Permitting trivial default initialization in constexpr contexts

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug middle-end/92532] New: ICE in

[segher at gcc dot gnu.org]

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

Bug ID: 92532
   Summary: ICE in
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

5c2bf77d1f6ae68d830c5157871089711a2a8eee (r278098) causes an ICE when building
the powerpc64 defconfig Linux kernel:

during GIMPLE pass: strlen
/home/segher/src/kernel/drivers/scsi/qla2xxx/qla_gs.c: In function
'qla2x00_fdmi_rhba':
/home/segher/src/kernel/drivers/scsi/qla2xxx/qla_gs.c:1530:1: internal compiler
error: Segmentation fault
 1530 | qla2x00_fdmi_rhba(scsi_qla_host_t *vha)
  | ^
0x1080a5a3 crash_signal
/home/segher/src/gcc/gcc/toplev.c:328
0x110ff030 get_origin_and_offset
/home/segher/src/gcc/gcc/gimple-ssa-sprintf.c:2358
0x11105e77 handle_printf_call(gimple_stmt_iterator*, vr_values const*)
/home/segher/src/gcc/gcc/gimple-ssa-sprintf.c:4666
  AR  drivers/usb/phy/built-in.a
0x10a0a497 strlen_check_and_optimize_call
/home/segher/src/gcc/gcc/tree-ssa-strlen.c:4799
0x10a0a497 check_and_optimize_stmt
/home/segher/src/gcc/gcc/tree-ssa-strlen.c:4939
0x10a0a497 strlen_dom_walker::before_dom_children(basic_block_def*)
/home/segher/src/gcc/gcc/tree-ssa-strlen.c:5166
0x110b2a33 dom_walker::walk(basic_block_def*)
/home/segher/src/gcc/gcc/domwalk.c:309
0x109fcfdf printf_strlen_execute
/home/segher/src/gcc/gcc/tree-ssa-strlen.c:5232
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/91365] Implement P1814R0: Class template argument deduction for alias templates

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/91366] Implement P1816R0: Class template argument deduction for aggregates

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |10.0

--- Comment #1 from Jason Merrill  ---
Done.

[Bug c++/88323] implement C++20 language features.

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323
Bug 88323 depends on bug 91366, which changed state.

Bug 91366 Summary: Implement P1816R0: Class template argument deduction for 
aggregates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91366

   What|Removed |Added

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

[Bug c++/90734] [concepts] Pre-normalization substitution into constraints of templated function breaks subsumption

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #3 from Andrew Sutton  ---
I think this error is correct (i.e., there is no defect in trunk):

   48 | static_assert(S2::f());// Bogus non-error

The requirements of this declaration:

static constexpr bool f() requires bool_ && true { return true; }

are incomparable with those of the overloads requiring Foo and Bar. The atomic
constraints bool_ and true are not identical to those pulled in by the
normalization of Same_impl.

[Bug c++/92531] [9/10 Regression] ICE in uses_template_parms, at cp/pt.c:10471

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Started to ICE with r241944, before that it was rejected.

[Bug middle-end/91515] missed optimization: no tailcall for types of class MEMORY

[Hi-Angel at yandex dot ru]

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

--- Comment #2 from Konstantin Kharlamov  ---
I think this is a duplicate of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71761

[Bug c++/92024] crash in check_local_shadow

[bernd.edlinger at hotmail dot de]

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

--- Comment #5 from Bernd Edlinger  ---
(In reply to Arseny Solokha from comment #4)
> Is there a backport pending? I cannot reproduce this ICE on release branches.

Hmm, interesting, I would have expected this to ICE.

However this patch is not complete yet as it seems,
since it exposed another hidden bug: #92365

With proposed patch here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00639.html

[Bug ipa/92528] [10 Regression] ICE in ipa_get_parm_lattices since r278219

[fxue at gcc dot gnu.org]

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

--- Comment #7 from fxue at gcc dot gnu.org ---
Author: fxue
Date: Fri Nov 15 15:03:24 2019
New Revision: 278300

URL: https://gcc.gnu.org/viewcvs?rev=278300=gcc=rev
Log:
2019-11-15  Feng Xue  

PR ipa/92528
* ipa-prop.c (update_jump_functions_after_inlining): Invalidate
aggregate jump function when inlined-to caller has no edge summary.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-prop.c

[Bug fortran/64120] [F03] Wrong handling of allocatable character string

[pault at gcc dot gnu.org]

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

--- Comment #14 from Paul Thomas  ---
(In reply to Paul Thomas from comment #13)
> (In reply to Jürgen Reuter from comment #12)

snip
> 
> It seems to me that what is true for an explicit save is true for an
> implicit one too and that the second testcase is invalid.

snip

Cancel that last. Intel advises that:

'When a SAVE statement does not explicitly contain a list, all allowable items
in the scoping unit are saved.'

Among the disallowed items are automatic variables so that, by this measure,
test 2 is valid.

Cheers

Paul

[Bug target/92462] [arm32] -ftree-pre makes a variable to be wrongly hoisted out

[wilco at gcc dot gnu.org]

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

--- Comment #19 from Wilco  ---
(In reply to Richard Biener from comment #18)
> So I see before DSE1:
> 
> (insn 16 15 17 2 (set (mem/c:SI (plus:SI (reg/f:SI 102 sfp)
> (const_int -8 [0xfff8])) [1 cur+0 S4 A64])
> (reg:SI 119 [ _13 ])) "t.ii":46:14 241 {*arm_movsi_insn}
>  (expr_list:REG_DEAD (reg:SI 119 [ _13 ])
> (nil)))
> (insn 17 16 18 2 (set (reg/f:SI 125)
> (plus:SI (reg/f:SI 102 sfp)
> (const_int -8 [0xfff8]))) "t.ii":48:26 7
> {*arm_addsi3}
>  (nil))
> (insn 18 17 19 2 (set (reg/f:SI 120 [ _14 ])
> (plus:SI (reg/f:SI 125)
> (reg/v:SI 118 [ offset ]))) "t.ii":48:26 7 {*arm_addsi3}
>  (nil))
> (insn 19 18 21 2 (set (reg:SI 126)
> (const_int 1 [0x1])) "t.ii":48:26 241 {*arm_movsi_insn}
>  (nil))
> (insn 21 19 22 2 (set (mem:QI (plus:SI (reg/f:SI 125)
> (reg/v:SI 118 [ offset ])) [0 *_14+0 S1 A8])
> (subreg:QI (reg:SI 126) 0)) "t.ii":48:26 251 {*arm_movqi_insn}
>  (expr_list:REG_DEAD (reg:SI 126)
> (nil)))
> (insn 22 21 23 2 (set (reg:SI 113 [ prephitmp_6 ])
> (mem/c:SI (plus:SI (reg/f:SI 102 sfp)
> (const_int -8 [0xfff8])) [1 cur+0 S4 A64]))
> "t.ii":50:18 241 {*arm_movsi_insn}
>  (nil))
> 
> where DSE1 then replaces the load in insn 22 with (reg:SI 119) (via a new
> pseudo).  But clearly insn 21 clobbers it (using alias-set zero).  This
> is on GIMPLE
> 
>   cur = _13;
>   _14 =  + offset_12;
>   *_14 = 1;
>   pretmp_22 = cur;
> 
> not sure why DSE1 performs CSE (heh), but clearly what it does is wrong.
> And yeah, probably tree PRE "enables" this miscompilation.  DSE has
> some special case with frame pointer bases and constant offsets.
> 
> But the target dependency might come in via section anchors since I see
> 
> **scanning insn=21
>   mem: (plus:SI (reg/f:SI 125)
> (reg/v:SI 118 [ offset ]))
> 
>after canon_rtx address: (plus:SI (plus:SI (reg/f:SI 102 sfp)
> (reg/v:SI 118 [ offset ]))
> (const_int -8 [0xfff8]))
> 
>after cselib_expand address: (plus:SI (plus:SI (and:SI (symbol_ref:SI
> ("*.LANCHOR0") [flags 0x182])
> (const_int 3 [0x3]))
> (reg/f:SI 102 sfp))
> (const_int -8 [0xfff8]))
> 
>after canon_rtx address: (plus:SI (plus:SI (and:SI (symbol_ref:SI
> ("*.LANCHOR0") [flags 0x182])
> (const_int 3 [0x3]))
> (reg/f:SI 102 sfp))
> (const_int -8 [0xfff8]))
>   varying cselib base=11:1018534969 offset = -8
>  processing cselib store [-8..-7)
> mems_found = 1, cannot_delete = false
> 
> where it's odd that we end up with an address like this?  I suspect that
> base_alias_check (my special friend) disambiguates the stack-based
> access with one that now appears as a *.LANCHOR0 based one.
> 
> We call canon_true_dependence with
> 
> (plus:SI (value:SI 11:1018534969 @0x3089c60/0x30f5ed0)
> (const_int -8 [0xfff8]))
> 
> for this and get_addr turns it into
> 
> (plus:SI (plus:SI (and:SI (symbol_ref:SI ("*.LANCHOR0") [flags 0x182])
> (const_int 3 [0x3]))
> (value:SI 8:8 @0x3089c18/0x30f5e40))
> (const_int -8 [0xfff8]))
> 
> and indeed find_base_term returns
> 
> (symbol_ref:SI ("*.LANCHOR0") [flags 0x182])
> 
> for this.  Which "obviously" doesn't alias with the stack based address
> because that one is "unique_base_value_p" (address:SI -3) so we win here:
> 
> 2229  if (unique_base_value_p (x_base) || unique_base_value_p (y_base))
> 2230return 0;
> 
> now I wonder where that LANCHOR thing comes from.  arm folks?

Well when you do:

int *p =  + ((intptr_t) & 3);

then you get the above expression when the global is addressed via an anchor.

But whether or not a target uses anchors doesn't matter - the example still
fails with -O1 -fno-section-anchors.

So I'm wondering whether the issue is in the special code that tries to
interpret an AND in an address, and mistakes the base as the symbol_ref
eventhough the real base is sfp.

[Bug c++/92531] [9/10 Regression] ICE in uses_template_parms, at cp/pt.c:10471

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug fortran/64120] [F03] Wrong handling of allocatable character string

[pault at gcc dot gnu.org]

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

--- Comment #13 from Paul Thomas  ---
(In reply to Jürgen Reuter from comment #12)
> Paul, getting back to this one? At first glance seems not overly much work
> left for the remaining case.

Hi Juergen,

I am in the midst of a triage of my assigned PRs and, this time, I started at
the oldest. There always seems to be an urgency associated with the most recent
because the reporters usually press for a fix in the weeks or months after
posting.

If 's' is declared thus:

character(x), allocatable, save :: s

it produces the error

Error: Automatic object ‘s’ at (1) cannot have the SAVE attribute

It seems to me that what is true for an explicit save is true for an implicit
one too and that the second testcase is invalid.

Either that or the automatic length should switch off the implicit save
attribute.

Note that this version works as expected:

program test
   logical :: L
   L = g(1)
   write(*,*) L
   L = g(2)
   write(*,*) L
   L = g(4)
   write(*,*) L
   L = g(1)
   write(*,*) L
contains
  logical function g(x)
  integer :: x
  character(:), allocatable :: s
  save
  if(.NOT.allocated(s)) then
allocate(character(len=x) :: s)
s='x'
g = .FALSE.
  elseif (x .eq. 4) then
s = 'abcd'
  else
g = .TRUE.
  end if
  write(*,*) "len(s)=", len(s), "s=", s
  end function g
end

[pault@pc30 69654]$ ./a.out
 len(s)=   1 s=x
 F
 len(s)=   1 s=x
 T
 len(s)=   4 s=abcd
 T
 len(s)=   4 s=abcd
 T

That is, a deferred character length respects the save attribute, whereas an
automatic length cannot.

What do you think?

Paul

[Bug tree-optimization/92515] [10 regression] ICE in many test cases after r278235

[rsandifo at gcc dot gnu.org]

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Fri Nov 15 14:37:57 2019
New Revision: 278295

URL: https://gcc.gnu.org/viewcvs?rev=278295=gcc=rev
Log:
Fix vector/scalar to vector/vector conversion (PR92515)

r278235 broke conversions of vector/scalar shifts into vector/vector
shifts on targets that only provide the latter.  We need to record
whether a conversion is required in that case too.

Also, the old useless_type_conversion_p condition seemed unnecessarily
strong, since the shift amount can have a different signedness from
the shifted value and its vector type is never assumed to be identical
to vectype.  The patch therefore uses tree_nop_conversion_p instead.

2019-11-15  Richard Sandiford  

gcc/
PR tree-optimization/92515
* tree-vect-stmts.c (vectorizable_shift): Record incompatible op1
types when converting a vector/scalar shift into a vector/vector one,
using tree_nop_conversion_p instead of useless_type_conversion_p.
Move the conversion code to the transform block.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug c++/90243] diagnostic notes that belong to a suppressed error about an uninitialized variable in a constexpr function are still shown

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||patrick at motec dot com.au

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

[Bug c++/92519] Spurious "note: ... has no user-provided default constructor"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
I fixed this on trunk, I suppose I should consider backporting it.

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

[Bug c++/92024] crash in check_local_shadow

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #4 from Arseny Solokha  ---
Is there a backport pending? I cannot reproduce this ICE on release branches.

[Bug c++/92531] [9/10 Regression] ICE in uses_template_parms, at cp/pt.c:10471

[asolokha at gmx dot com]

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

--- Comment #1 from Arseny Solokha  ---
Even this is enough:

template 
void ky () noexcept ([]{});

[Bug tree-optimization/92486] Wrong optimization: padding in structs is not copied even with memcpy

[jamborm at gcc dot gnu.org]

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

--- Comment #15 from Martin Jambor  ---
(In reply to rguent...@suse.de from comment #14)
> On Fri, 15 Nov 2019, jamborm at gcc dot gnu.org wrote:
>
> [...] But yes, for your example we'd copy-prop out c and b which
> might then have created "mismatching" accesses.  Btw, I had
> the impression that we propagate accesses from 'a' to b, c and d
> in the above case, if we do we only have to add "fake" accesses
> to the remaining parts?

we do, as long as they do not interfere (create partial a overlap)
with a pre-existing access.  So if total scalarization created such an
access, we would not.

> > 
> > Assuming we almost never want to decrease the step size all the way to
> > a char, this will not always help us to deal with the problem with
> > overlapping scalar accesses.
> 
> That's true, but if we do have scalar accesses then we can just reuse
> those.  For the original example with a char and an int and three
> bytes padding when we originally have a char access we'd have to
> come up with something for the three bytes padding.

Right, slightly more context aware total scalarization might do that,
and do that only when necessary.  Basically it would add addition of
accesses for total scalarization (almost) last.  Hmmm, I'll need to
think about all the implication of that.

> 
> The case of fully contained sub-accesses is probably easy to handle
> via BIT_FIELD_REFs

Yeah, I backed out of doing that for reasons I no longer remember...

> but when one access overlaps two others things
> get interesting ... (two BIT_FIELD_REFs plus one BIT_INSERT_EXPR
> for the combination).  Code generation might also become awkward.

...but never even wanted to deal with these situations and still kind
of don't :-)

[Bug c++/92531] New: [9/10 Regression] ICE in uses_template_parms, at cp/pt.c:10471

[asolokha at gmx dot com]

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

Bug ID: 92531
   Summary: [9/10 Regression] ICE in uses_template_parms, at
cp/pt.c:10471
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-10.0.0-alpha20191110 snapshot (r278028) and g++ 9.2 ICE when compiling the
following testcase w/ -std=c++17:

template 
struct zq {
  void ky () noexcept ([]{});
};

% g++-10.0.0-alpha20191110 -std=c++17 -c as6atodv.cc
as6atodv.cc:4:2: internal compiler error: in uses_template_parms, at
cp/pt.c:10471
4 | };
  |  ^
0x6302cc uses_template_parms(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/pt.c:10471
0x995c9b canonical_eh_spec(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/tree.c:2577
0x995ec2 build_cp_fntype_variant(tree_node*, cp_ref_qualifier, tree_node*,
bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/tree.c:2622
0x8ee22d cp_parser_class_specifier_1
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:23908
0x8ef662 cp_parser_class_specifier
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:23965
0x8ef662 cp_parser_type_specifier
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:17566
0x8f0516 cp_parser_decl_specifier_seq
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:14239
0x9138ad cp_parser_single_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:28986
0x913c5b cp_parser_template_declaration_after_parameters
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:28649
0x914363 cp_parser_explicit_template_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:28915
0x9174c3 cp_parser_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:13271
0x9179ad cp_parser_translation_unit
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:4721
0x9179ad c_parse_file()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/cp/parser.c:42900
0xa1a0d9 c_common_parse_file()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/c-family/c-opts.c:1183

As a side note, clang 9.0.0 and icc 19.0.1 accept the testcase w/ the first
line removed, while g++ rejects it:

--- /home/asolokha/t1/as6atodv.cc
+++ #
@@ -1,4 +1,3 @@
-template 
 struct zq {
   void ky () noexcept ([]{});
 };

[Bug ipa/92508] [10 Regression] ICE in do_estimate_edge_time, at ipa-inline-analysis.c:223 since r278159

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka  ---
Aha, that makes sense for sreal it is not sure that
  a == a * 1 / 1
and the code was inconsistent about guaring the noop scales.
Thanks for tracking this down! I suppose it would also make sense to
pre-compute 1/1 and use it instead of divisions.  I will look into it after
fixing other issues.

Honza

[Bug ipa/92528] [10 Regression] ICE in ipa_get_parm_lattices since r278219

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

   Assignee|hubicka at gcc dot gnu.org |fxue at os dot 
amperecomputing.com

--- Comment #6 from Jan Hubicka  ---
This is the same issue as I hit in Firefox build and we discussed at:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01351.html
Feng is right that ipa_set_jf_unknown is missing clear of agg.

> I checked update_jump_functions_after_inlining(), and found one suspicious 
> place:

>  for (i = 0; i < count; i++)
>{
>  struct ipa_jump_func *dst = ipa_get_ith_jump_func (args, i);
>  if (!top)
>{
>  ipa_set_jf_unknown (dst);
>  <   we should also invalidate dst->agg.items.

Yes following patch fixes it:

Index: ipa-prop.c
===
--- ipa-prop.c  (revision 278222)
+++ ipa-prop.c  (working copy)
@@ -514,6 +514,8 @@ ipa_set_jf_unknown (struct ipa_jump_func
   jfunc->type = IPA_JF_UNKNOWN;
   jfunc->bits = NULL;
   jfunc->m_vr = NULL;
+  jfunc->agg.by_ref = false;
+  jfunc->agg.items = NULL;
 }

 /* Set JFUNC to be a copy of another jmp (to be used by jump function

>  continue;
>}
>  class ipa_polymorphic_call_context *dst_ctx
>= ipa_get_ith_polymorhic_call_context (args, i);    An irrelevant 
> point:  and should we also do some kind of cleaning on dst_ctx?

There is no need to clear polymorphic call context. It does not refer to the
parameters of caller. If it was valid for all possible contexts it is still
valid. 

So I think ipa_set_jf_unknown shall not clear bits and m_vr.

Honza

[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly

[rearnsha at gcc dot gnu.org]

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

--- Comment #28 from Richard Earnshaw  ---
The last release of gcc-7 has now been made, so it's end-of-life and no further
fixes for it will be made.

[Bug ipa/92508] [10 Regression] ICE in do_estimate_edge_time, at ipa-inline-analysis.c:223 since r278159

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Disappeared on trunk with r278222.

[Bug c++/90243] diagnostic notes that belong to a suppressed error about an uninitialized variable in a constexpr function are still shown

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
This is still present on gcc-8-branch and gcc-9-branch.

[Bug tree-optimization/92512] [10 Regression] ICE in gimple_op, at gimple.h:2436

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Fri Nov 15 13:52:09 2019
New Revision: 278293

URL: https://gcc.gnu.org/viewcvs?rev=278293=gcc=rev
Log:
2019-11-15  Richard Biener  

PR tree-optimization/92512
* tree-vect-loop.c (check_reduction_path): Fix operand index
computability check.  Add check for second use in COND_EXPRs.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr92512.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug tree-optimization/92512] [10 Regression] ICE in gimple_op, at gimple.h:2436

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly

[mkuvyrkov at gcc dot gnu.org]

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

Maxim Kuvyrkov  changed:

   What|Removed |Added

 CC||mkuvyrkov at gcc dot gnu.org

--- Comment #27 from Maxim Kuvyrkov  ---
Hi,

GCC 7.5 released with this bug, manifested by 
=== gfortran Summary ===

FAIL: gfortran.dg/ieee/ieee_6.f90   -O0  execution test
FAIL: gfortran.dg/ieee/ieee_6.f90   -O1  execution test
FAIL: gfortran.dg/ieee/ieee_6.f90   -O2  execution test
FAIL: gfortran.dg/ieee/ieee_6.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/ieee/ieee_6.f90   -O3 -g  execution test
FAIL: gfortran.dg/ieee/ieee_6.f90   -Os  execution test
XPASS: gfortran.dg/ieee/ieee_8.f90   -O0  execution test
XPASS: gfortran.dg/ieee/ieee_8.f90   -O1  execution test
XPASS: gfortran.dg/ieee/ieee_8.f90   -O2  execution test
XPASS: gfortran.dg/ieee/ieee_8.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
XPASS: gfortran.dg/ieee/ieee_8.f90   -O3 -g  execution test
XPASS: gfortran.dg/ieee/ieee_8.f90   -Os  execution test

Do we care enough about this to fix on GCC-7?

[Bug c++/92530] Absent error on static_assert expression

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-15
 Ever confirmed|0   |1

[Bug tree-optimization/92506] [10 Regression] Wrong code with -fwrapv since r277979

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
I can confirm it's fixed.
Thanks for the quick patch.

[Bug ipa/92528] [10 Regression] ICE in ipa_get_parm_lattices since r278219

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org
   Assignee|marxin at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org

--- Comment #5 from Martin Liška  ---
It will be probably an artifact from Honza's changes:

$ (gdb) bt
#0  ipa_get_parm_lattices (info=0x77853480, i=1) at
/home/marxin/Programming/gcc/gcc/ipa-cp.c:386
#1  0x0191e42d in ipa_agg_value_from_node (info=0x77853480,
node=0x77833c60, item=0x7784b9a8) at
/home/marxin/Programming/gcc/gcc/ipa-cp.c:1612
#2  0x0191e639 in ipa_agg_value_set_from_jfunc (info=0x77853480,
node=0x77833c60, agg_jfunc=0x7784a4a8) at
/home/marxin/Programming/gcc/gcc/ipa-cp.c:1682
#3  0x00e1fda4 in evaluate_properties_for_edge
(e=e@entry=0x7785ac98, inline_p=inline_p@entry=true,
clause_ptr=clause_ptr@entry=0x7fffd290,
nonspec_clause_ptr=nonspec_clause_ptr@entry=0x7fffd294,
known_vals_ptr=known_vals_ptr@entry=0x7fffd2a8, 
known_contexts_ptr=known_contexts_ptr@entry=0x7fffd2b0,
known_aggs_ptr=0x7fffd2b8) at /home/marxin/Programming/gcc/gcc/vec.h:1424
#4  0x00e2fe30 in do_estimate_edge_time (edge=0x7785ac98) at
/home/marxin/Programming/gcc/gcc/ipa-inline-analysis.c:198
...
(gdb) p node->debug()
_GLOBAL__sub_I__Z3fn2v/25 ((static initializers for pr92528.cc))
@0x77833c60
  Type: function definition analyzed
  Visibility: prevailing_def_ironly artificial constructor
  References: _ZN12_GLOBAL__N_11bE/9 (addr)
  Referring: 
  Availability: available
  Function flags: count:1073741824 (estimated locally) body
only_called_at_startup static_constructor (priority:65535) executed_once
  Called by: 
  Calls: I::I(B)/7 (inlined) (1073741824 (estimated locally),1.00 per call)
(can throw external) B::B(char*)/38 (1073741824 (estimated locally),1.00 per
call) (can throw external) 
$ (gdb) p *info
$1 = {
  descriptors = 0x0, 
  lattices = 0x2870800, 
  ipcp_orig_node = 0x0, 
  known_csts = {
m_vec = 0x0
  }, 
  known_contexts = {
m_vec = 0x0
  }, 
  analysis_done = 1, 
  node_enqueued = 0, 
  do_clone_for_all_contexts = 0, 
  is_all_contexts_clone = 0, 
  node_dead = 0, 
  node_within_scc = 0, 
  node_calling_single_call = 0, 
  versionable = 1
}

[Bug ipa/92528] [10 Regression] ICE in ipa_get_parm_lattices since r278219

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Full backtrace with the reduced test-case:

$ during IPA pass: inline
pr92528.cc:61:1: internal compiler error: in ipa_get_parm_lattices, at
ipa-cp.c:386
   61 | }
  | ^
0x8ba588 ipa_get_parm_lattices
/home/marxin/Programming/gcc/gcc/ipa-cp.c:386
0x8ba588 ipa_get_parm_lattices
/home/marxin/Programming/gcc/gcc/ipa-cp.c:384
0x8ba588 ipa_agg_value_from_node
/home/marxin/Programming/gcc/gcc/ipa-cp.c:1612
0x190b4ec ipa_agg_value_set_from_jfunc(ipa_node_params*, cgraph_node*,
ipa_agg_jump_function*)
/home/marxin/Programming/gcc/gcc/ipa-cp.c:1682
0xe0a823 evaluate_properties_for_edge(cgraph_edge*, bool, unsigned int*,
unsigned int*, vec*,
vec*, vec*)
/home/marxin/Programming/gcc/gcc/ipa-fnsummary.c:573
0xe1a8af do_estimate_edge_time(cgraph_edge*)
/home/marxin/Programming/gcc/gcc/ipa-inline-analysis.c:198
0xe1b16a do_estimate_edge_size(cgraph_edge*)
/home/marxin/Programming/gcc/gcc/ipa-inline-analysis.c:317
0x1924537 estimate_edge_size
/home/marxin/Programming/gcc/gcc/ipa-inline.h:78
0x1924537 estimate_edge_growth
/home/marxin/Programming/gcc/gcc/ipa-inline.h:89
0x1924537 want_inline_small_function_p
/home/marxin/Programming/gcc/gcc/ipa-inline.c:844
0x19292c6 update_callee_keys
/home/marxin/Programming/gcc/gcc/ipa-inline.c:1470
0x192c8d6 inline_small_functions
/home/marxin/Programming/gcc/gcc/ipa-inline.c:2156
0x192c8d6 ipa_inline
/home/marxin/Programming/gcc/gcc/ipa-inline.c:2616
0x192c8d6 execute
/home/marxin/Programming/gcc/gcc/ipa-inline.c:3016

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[wschmidt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 92098, which changed state.

Bug 92098 Summary: [9 Regression] After r262333, the following code cannot be 
vectorized on powerpc64le.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92098

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|DUPLICATE   |---

[Bug tree-optimization/92098] [9 Regression] After r262333, the following code cannot be vectorized on powerpc64le.

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2019-11-15
 Resolution|DUPLICATE   |---
   Target Milestone|10.0|9.3
Summary|[10 Regression] After   |[9 Regression] After
   |r262333, the following code |r262333, the following code
   |cannot be vectorized on |cannot be vectorized on
   |powerpc64le.|powerpc64le.
 Ever confirmed|0   |1

--- Comment #2 from Bill Schmidt  ---
This was actually reported to us as a [9 regression], so until 92132 is
backported (and we need to check that the backport fixes the issue), this
should stay open, I guess.

[Bug c++/92078] error: 'struct std::ptr' redeclared with different access

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #3 from Andrew Sutton  ---
Patch here:

https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01293.html

[Bug c++/92313] Regression: ICE since 9.2 for templates derived from range-v3 code

[TonyELewis at hotmail dot com]

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

--- Comment #4 from Tony E Lewis  ---
This is now fixed.

The bug we decided this was probably a duplicate of
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92206) is now fixed. I've
confirmed that trunk (on Godbolt) is also now behaving itself with this bug's
repro cases.

Thanks.

[Bug tree-optimization/92515] [10 regression] ICE in many test cases after r278235

[rsandifo at gcc dot gnu.org]

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Fri Nov 15 12:57:47 2019
New Revision: 278292

URL: https://gcc.gnu.org/viewcvs?rev=278292=gcc=rev
Log:
[rs6000] Use VIEW_CONVERT_EXPR to reinterpret vectors (PR 92515)

The new tree-cfg.c checking in r278245 tripped on folds of
ALTIVEC_BUILTIN_VPERM_*, which were using gimple_convert
rather than VIEW_CONVERT_EXPR to reinterpret the contents
of a vector as a different type.

2019-11-15  Richard Sandiford  

gcc/
PR target/92515
* config/rs6000/rs6000-call.c (rs6000_gimple_fold_builtin): Use
VIEW_CONVERT_EXPR to reinterpret vectors as different types.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-call.c

[Bug rtl-optimization/92430] [9 Regression] Compile-time hog w/ -Os -fno-if-conversion -fno-tree-dce -fno-tree-loop-optimize -fno-tree-vrp

[iii at gcc dot gnu.org]

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

--- Comment #8 from iii at gcc dot gnu.org ---
Author: iii
Date: Fri Nov 15 12:55:05 2019
New Revision: 278291

URL: https://gcc.gnu.org/viewcvs?rev=278291=gcc=rev
Log:
Free dominance info at the beginning of pass_jump_after_combine

try_forward_edges does not update dominance info, and merge_blocks
relies on it being up-to-date.  In PR92430 stale dominance info makes
merge_blocks produce a loop in the dominator tree, which in turn makes
delete_basic_block loop forever.

Fix by freeing dominance info at the beginning of cleanup_cfg.

Also, since the whole point of this pass is to perform jump threading
(other cleanups are not valuable at this point), skip it completely when
flag_thread_jumps is not set.

gcc/ChangeLog:

2019-11-15  Ilya Leoshkevich  

Backport from mainline
PR rtl-optimization/92430
* cfgcleanup.c (pass_jump_after_combine::gate): New function.
(pass_jump_after_combine::execute): Free
dominance info at the beginning.

gcc/testsuite/ChangeLog:

2019-11-15  Ilya Leoshkevich  

Backport from mainline
PR rtl-optimization/92430
* gcc.dg/pr92430.c: New test (from Arseny Solokha).

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.dg/pr92430.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/cfgcleanup.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/84061] [8/9 Regression] gcc.dg/tree-ssa/loop-15.c XFAIL

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.0
Summary|[8/9/10 Regression] |[8/9 Regression]
   |gcc.dg/tree-ssa/loop-15.c   |gcc.dg/tree-ssa/loop-15.c
   |XFAIL   |XFAIL

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

[Bug c/92324] [10 Regression] ICE in expand_direct_optab_fn, at internal-fn.c:2890

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Fri Nov 15 12:48:34 2019
New Revision: 278289

URL: https://gcc.gnu.org/viewcvs?rev=278289=gcc=rev
Log:
2019-11-15  Richard Biener  

PR tree-optimization/92324
* tree-vect-loop.c (vect_create_epilog_for_reduction): Fix
singedness of SLP reduction epilouge operations.  Also reduce
the vector width for SLP reductions before doing elementwise
operations if possible.

* gcc.dg/vect/pr92324-4.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr92324-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug fortran/69654] ICE in gfc_trans_structure_assign

[pault at gcc dot gnu.org]

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

--- Comment #9 from Paul Thomas  ---
Author: pault
Date: Fri Nov 15 12:42:29 2019
New Revision: 278287

URL: https://gcc.gnu.org/viewcvs?rev=278287=gcc=rev
Log:
2019-11-15  Paul Thomas  

PR fortran/69654
* trans-expr.c (gfc_trans_structure_assign): Move assignment to
'cm' after treatment of C pointer types and test that the type
has been completely built before it. Add an assert that the
backend_decl for each component exists.

2019-11-15  Paul Thomas  

PR fortran/69654
* gfortran.dg/derived_init_6.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/derived_init_6.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/92528] [10 Regression] ICE in ipa_get_parm_lattices since r278219

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Created attachment 47273
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47273=edit
Reduced test-case

[Bug c++/92530] New: Absent error on static_assert expression

[pkeir at outlook dot com]

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

Bug ID: 92530
   Summary: Absent error on static_assert expression
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pkeir at outlook dot com
  Target Milestone: ---

Created attachment 47272
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47272=edit
The code described in the bug report.

The static_assert expression in the C++11 code below is not an integral
constant expression. GCC trunk compiles this, while Clang reports the error
correctly. To quote Clang's Richard Smith:

"The evaluation semantics of the expression 'x' (because it's of reference
type) involve locating the object that the reference binds to, which can't be
done in this case because we don't know the value of the function parameter
'x'. So the evaluation of the static_assert condition is non-constant, which is
invalid."

The language rule that's violated is here:
http://eel.is/c++draft/expr.const#4.12

template 
constexpr bool bar(T &)  { return true; }

template 
constexpr bool foo(T ) { static_assert(bar(x),""); return bar(x); }

int main(int argc, char *argv[])
{
  int i;
  constexpr bool y = foo(i);
  return 0;
}

[Bug ipa/92529] [10 Regression] Wrong code with ICF since r278207

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-11-15
  Known to work||9.2.0
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0

[Bug ipa/92529] New: [10 Regression] Wrong code with ICF since r278207

[marxin at gcc dot gnu.org]

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

Bug ID: 92529
   Summary: [10 Regression] Wrong code with ICF since r278207
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Following is miscompiled:

$ cat icf1.c
int
foo(volatile int a)
{
  return (char)a;
}

int
bar(volatile int a)
{
  return (short)a;
}

#pragma GCC optimize ("-O0")

int main(int argc, char **argv)
{
  int r = bar(1000);
  __builtin_printf ("global: %d\n", r);
  if (r != 1000)
__builtin_abort ();

  return 0;
}

$ gcc icf1.c -O2 && ./a.out 
global: -24
Aborted (core dumped)

[Bug tree-optimization/92486] Wrong optimization: padding in structs is not copied even with memcpy

[rguenther at suse dot de]

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

--- Comment #14 from rguenther at suse dot de  ---
On Fri, 15 Nov 2019, jamborm at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92486
> 
> --- Comment #13 from Martin Jambor  ---
> (In reply to rguent...@suse.de from comment #10)
> > [...] But total scalarization works with the premise
> > that we don't see any direct accesses to source or destination
> 
> That is not true, total scalarization just adds special artificial
> accesses to the aggregate to its data structures and hopes they will
> blend in nicely with whatever real accesses are already there, so
> that, for example, val can be propagated in:
> 
>   a.f = val;
>   d = c = b = a;
>   use (d.f);

OK, but these cases are handled by FRE just fine.  What is missing
elsewhere is the plain

 a = c = d;

where SRA manages to get rid of 'c' by total scalarization
(so the "SRA does aggregate copy prop" thing).

But yes, for your example we'd copy-prop out c and b which
might then have created "mismatching" accesses.  Btw, I had
the impression that we propagate accesses from 'a' to b, c and d
in the above case, if we do we only have to add "fake" accesses
to the remaining parts?

> This is a problem because SRA does not like scalar accesses within
> scalar accesses (I originally wanted to supported it but then backed
> out almost immediately) so if f did not happen to be exactly the size
> of the copy step, SRA would give up on the aggregate.  This is a
> limitation which we'd have to lift first, I'm afraid.
> 
> > so
> > I think we should simply change "total scalarization" to be
> > "emit the block-copy on GIMPLE".  Preferably without "crossing"
> > field boundaries but covering padding by choosing larger accesses.
> 
> Assuming we almost never want to decrease the step size all the way to
> a char, this will not always help us to deal with the problem with
> overlapping scalar accesses.

That's true, but if we do have scalar accesses then we can just reuse
those.  For the original example with a char and an int and three
bytes padding when we originally have a char access we'd have to
come up with something for the three bytes padding.

The case of fully contained sub-accesses is probably easy to handle
via BIT_FIELD_REFs but when one access overlaps two others things
get interesting ... (two BIT_FIELD_REFs plus one BIT_INSERT_EXPR
for the combination).  Code generation might also become awkward.

[Bug tree-optimization/92486] Wrong optimization: padding in structs is not copied even with memcpy

[jamborm at gcc dot gnu.org]

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

--- Comment #13 from Martin Jambor  ---
(In reply to rguent...@suse.de from comment #10)
> [...] But total scalarization works with the premise
> that we don't see any direct accesses to source or destination

That is not true, total scalarization just adds special artificial
accesses to the aggregate to its data structures and hopes they will
blend in nicely with whatever real accesses are already there, so
that, for example, val can be propagated in:

  a.f = val;
  d = c = b = a;
  use (d.f);

This is a problem because SRA does not like scalar accesses within
scalar accesses (I originally wanted to supported it but then backed
out almost immediately) so if f did not happen to be exactly the size
of the copy step, SRA would give up on the aggregate.  This is a
limitation which we'd have to lift first, I'm afraid.

> so
> I think we should simply change "total scalarization" to be
> "emit the block-copy on GIMPLE".  Preferably without "crossing"
> field boundaries but covering padding by choosing larger accesses.

Assuming we almost never want to decrease the step size all the way to
a char, this will not always help us to deal with the problem with
overlapping scalar accesses.

[Bug ipa/92528] [10 Regression] ICE in ipa_get_parm_lattices since r278219

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
  Known to work||9.2.0
   Last reconfirmed||2019-11-15
  Component|c++ |ipa
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1
Summary|ice in  |[10 Regression] ICE in
   |ipa_get_parm_lattices   |ipa_get_parm_lattices since
   ||r278219
   Target Milestone|--- |10.0
  Known to fail||10.0

--- Comment #2 from Martin Liška  ---
Started with r278219, let me take a look
@David: Are you reducing that or not?

[Bug c++/92528] ice in ipa_get_parm_lattices

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---

/home/dcb/gcc/results.278200/bin/gcc
/home/dcb/gcc/results.278250/bin/gcc
../tests/catch.hpp:9423:27: internal compiler error: in ipa_get_parm_lattices,
at ipa-cp.c:386

So the problem first seems to occur sometime between revision 278200
and 278250.

I'll have a go at reducing the code. Maybe the latest development
version of creduce is better at reducing C++ code than previous versions.

[Bug rtl-optimization/92462] [arm32] -ftree-pre makes a variable to be wrongly hoisted out

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-15
 CC||rearnsha at gcc dot gnu.org
  Component|target  |rtl-optimization
 Ever confirmed|0   |1
  Known to fail||10.0

--- Comment #18 from Richard Biener  ---
So I see before DSE1:

(insn 16 15 17 2 (set (mem/c:SI (plus:SI (reg/f:SI 102 sfp)
(const_int -8 [0xfff8])) [1 cur+0 S4 A64])
(reg:SI 119 [ _13 ])) "t.ii":46:14 241 {*arm_movsi_insn}
 (expr_list:REG_DEAD (reg:SI 119 [ _13 ])
(nil)))
(insn 17 16 18 2 (set (reg/f:SI 125)
(plus:SI (reg/f:SI 102 sfp)
(const_int -8 [0xfff8]))) "t.ii":48:26 7 {*arm_addsi3}
 (nil))
(insn 18 17 19 2 (set (reg/f:SI 120 [ _14 ])
(plus:SI (reg/f:SI 125)
(reg/v:SI 118 [ offset ]))) "t.ii":48:26 7 {*arm_addsi3}
 (nil))
(insn 19 18 21 2 (set (reg:SI 126)
(const_int 1 [0x1])) "t.ii":48:26 241 {*arm_movsi_insn}
 (nil))
(insn 21 19 22 2 (set (mem:QI (plus:SI (reg/f:SI 125)
(reg/v:SI 118 [ offset ])) [0 *_14+0 S1 A8])
(subreg:QI (reg:SI 126) 0)) "t.ii":48:26 251 {*arm_movqi_insn}
 (expr_list:REG_DEAD (reg:SI 126)
(nil)))
(insn 22 21 23 2 (set (reg:SI 113 [ prephitmp_6 ])
(mem/c:SI (plus:SI (reg/f:SI 102 sfp)
(const_int -8 [0xfff8])) [1 cur+0 S4 A64]))
"t.ii":50:18 241 {*arm_movsi_insn}
 (nil))

where DSE1 then replaces the load in insn 22 with (reg:SI 119) (via a new
pseudo).  But clearly insn 21 clobbers it (using alias-set zero).  This
is on GIMPLE

  cur = _13;
  _14 =  + offset_12;
  *_14 = 1;
  pretmp_22 = cur;

not sure why DSE1 performs CSE (heh), but clearly what it does is wrong.
And yeah, probably tree PRE "enables" this miscompilation.  DSE has
some special case with frame pointer bases and constant offsets.

But the target dependency might come in via section anchors since I see

**scanning insn=21
  mem: (plus:SI (reg/f:SI 125)
(reg/v:SI 118 [ offset ]))

   after canon_rtx address: (plus:SI (plus:SI (reg/f:SI 102 sfp)
(reg/v:SI 118 [ offset ]))
(const_int -8 [0xfff8]))

   after cselib_expand address: (plus:SI (plus:SI (and:SI (symbol_ref:SI
("*.LANCHOR0") [flags 0x182])
(const_int 3 [0x3]))
(reg/f:SI 102 sfp))
(const_int -8 [0xfff8]))

   after canon_rtx address: (plus:SI (plus:SI (and:SI (symbol_ref:SI
("*.LANCHOR0") [flags 0x182])
(const_int 3 [0x3]))
(reg/f:SI 102 sfp))
(const_int -8 [0xfff8]))
  varying cselib base=11:1018534969 offset = -8
 processing cselib store [-8..-7)
mems_found = 1, cannot_delete = false

where it's odd that we end up with an address like this?  I suspect that
base_alias_check (my special friend) disambiguates the stack-based
access with one that now appears as a *.LANCHOR0 based one.

We call canon_true_dependence with

(plus:SI (value:SI 11:1018534969 @0x3089c60/0x30f5ed0)
(const_int -8 [0xfff8]))

for this and get_addr turns it into

(plus:SI (plus:SI (and:SI (symbol_ref:SI ("*.LANCHOR0") [flags 0x182])
(const_int 3 [0x3]))
(value:SI 8:8 @0x3089c18/0x30f5e40))
(const_int -8 [0xfff8]))

and indeed find_base_term returns

(symbol_ref:SI ("*.LANCHOR0") [flags 0x182])

for this.  Which "obviously" doesn't alias with the stack based address
because that one is "unique_base_value_p" (address:SI -3) so we win here:

2229  if (unique_base_value_p (x_base) || unique_base_value_p (y_base))
2230return 0;

now I wonder where that LANCHOR thing comes from.  arm folks?

[Bug c/66773] sign-compare warning for == and != are pretty useless

[vincent-gcc at vinc17 dot net]

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

Vincent Lefèvre  changed:

   What|Removed |Added

 CC||vincent-gcc at vinc17 dot net

--- Comment #7 from Vincent Lefèvre  ---
(In reply to Segher Boessenkool from comment #1)
> There certainly are cases where these warnings are inconvenient, but
> there also are cases where they are quite useful -- e.g.
> 
> int f(void) { return 0x == -1; }

I'd say that the warning is inconvenient here, since if the developer really
wants to do a test equivalent to the above one, there seems no good way to
avoid the warning with portable code.

[Bug c++/92528] New: ice in ipa_get_parm_lattices

[dcb314 at hotmail dot com]

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

Bug ID: 92528
   Summary: ice in ipa_get_parm_lattices
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 47271
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47271=edit
gzipped C++ source code

The attached C++ code, when compiled by recent gcc trunk and -O2,
does this:

../tests/catch.hpp:9423:27: internal compiler error: in ipa_get_parm_lattices,
at ipa-cp.c:386
0x8a9119 ipa_get_parm_lattices
../../trunk/gcc/ipa-cp.c:386
0x8a995b ipa_get_parm_lattices
../../trunk/gcc/ipa-cp.c:4638
0x8a995b ipa_agg_value_from_node
../../trunk/gcc/ipa-cp.c:1612
0x1a7fc8c ipa_agg_value_set_from_jfunc(ipa_node_params*, cgraph_node*,
ipa_agg_jump_function*)
../../trunk/gcc/ipa-cp.c:1682

[Bug tree-optimization/92516] [10 Regression] ICE in vect_schedule_slp_instance, at tree-vect-slp.c:4095 since r278246

[dcb314 at hotmail dot com]

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

--- Comment #8 from David Binderman  ---
Reduced C++ code:

class a {
public:
  typedef int b;
  operator b();
};
class c {
public:
  constexpr int m_fn1() const;
  constexpr int d() const;
  int e;
  int f;
};
constexpr int c::m_fn1() const { return e; }
constexpr int c::d() const { return f; }
class g {
public:
  g();
  constexpr void i(const c &) noexcept;
  int j;
  int k;
  int l;
  int m;
};
constexpr void g::i(const c ) noexcept {
  int v = l - j, h = m - k;
  j = n.m_fn1() - v / 2;
  k = n.d() - h / 2;
  l = j + v;
  m = k + h;
}
class o {
  void m_fn4() const;
  a p;
} r;
void o::m_fn4() const {
  g q;
  c t;
  q.i(t);
  r.p || 0;
}

[Bug tree-optimization/92527] gcc.dg/vect/bb-slp-div-2.c etc. FAIL

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug tree-optimization/92527] New: gcc.dg/vect/bb-slp-div-2.c etc. FAIL

[ro at gcc dot gnu.org]

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

Bug ID: 92527
   Summary: gcc.dg/vect/bb-slp-div-2.c etc. FAIL
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: rsandifo at gcc dot gnu.org
  Target Milestone: ---
Target: sparc-sun-solaris2.11

Created attachment 47269
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47269=edit
32-bit sparc-sun-solaris2.11 bb-slp-div-2.c.168t.slp2

Between 20191113 (r278150) and 20191114 (r278256), the new
gcc.dg/vect/bb-slp-div-2.c
test FAILs on Solaris/SPARC (both 32 and 64-bit)

+FAIL: gcc.dg/vect/bb-slp-div-2.c -flto -ffat-lto-objects  scan-tree-dump slp2
"basic block vectorized"
+FAIL: gcc.dg/vect/bb-slp-div-2.c scan-tree-dump slp2 "basic block vectorized"

and the existing gcc.dg/vect/bb-slp-21.c test regressed:
+FAIL: gcc.dg/vect/bb-slp-21.c -flto -ffat-lto-objects  scan-tree-dump-times
slp2 "vectorizing stmts using SLP" 1
+FAIL: gcc.dg/vect/bb-slp-21.c scan-tree-dump-times slp2 "vectorizing stmts
using SLP" 1

Attaching the dumps.

[Bug tree-optimization/92527] gcc.dg/vect/bb-slp-div-2.c etc. FAIL

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  ---
Created attachment 47270
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47270=edit
32-bit sparc-sun-solaris2.11 bb-slp-21.c.168t.slp2

[Bug tree-optimization/92513] [10 Regression] ICE: tree check: expected ssa_name, have integer_cst in maybe_replace_use, at tree-into-ssa.c:1817

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||marxin at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Martin Liška  ---
(In reply to Arseny Solokha from comment #2)
> (In reply to Richard Biener from comment #1)
> > Hmm, I can't reproduce it, maybe a dup of PR92461?

Yes, it's also fixed with r278093.

> 
> Indeed, I also cannot reproduce it w/ 20191114 snapshot on gcc.godbolt.org.

[Bug tree-optimization/92039] [10 Regression] Spurious -Warray-bounds warnings building 32-bit glibc

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Fri Nov 15 09:09:16 2019
New Revision: 278281

URL: https://gcc.gnu.org/viewcvs?rev=278281=gcc=rev
Log:
2019-11-15  Richard Biener  

PR tree-optimization/92039
PR tree-optimization/91975
* tree-ssa-loop-ivcanon.c (constant_after_peeling): Revert
previous change, treat invariants consistently as non-constant.
(tree_estimate_loop_size): Ternary ops with just the first op
constant are not optimized away.

* gcc.dg/tree-ssa/cunroll-2.c: Revert to state previous to
unroller adjustment.
* g++.dg/tree-ssa/ivopts-3.C: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/tree-ssa/ivopts-3.C
trunk/gcc/testsuite/gcc.dg/tree-ssa/cunroll-2.c
trunk/gcc/tree-ssa-loop-ivcanon.c

[Bug tree-optimization/92039] [10 Regression] Spurious -Warray-bounds warnings building 32-bit glibc

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 92039, which changed state.

Bug 92039 Summary: [10 Regression] Spurious -Warray-bounds warnings building 
32-bit glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92039

   What|Removed |Added

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

[Bug tree-optimization/91975] worse code for small array copy using pointer arithmetic than array indexing

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Fri Nov 15 09:09:16 2019
New Revision: 278281

URL: https://gcc.gnu.org/viewcvs?rev=278281=gcc=rev
Log:
2019-11-15  Richard Biener  

PR tree-optimization/92039
PR tree-optimization/91975
* tree-ssa-loop-ivcanon.c (constant_after_peeling): Revert
previous change, treat invariants consistently as non-constant.
(tree_estimate_loop_size): Ternary ops with just the first op
constant are not optimized away.

* gcc.dg/tree-ssa/cunroll-2.c: Revert to state previous to
unroller adjustment.
* g++.dg/tree-ssa/ivopts-3.C: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/tree-ssa/ivopts-3.C
trunk/gcc/testsuite/gcc.dg/tree-ssa/cunroll-2.c
trunk/gcc/tree-ssa-loop-ivcanon.c

[Bug lto/48200] Implement function attribute for symbol versioning (.symver)

[hubicka at gcc dot gnu.org]

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

--- Comment #40 from Jan Hubicka  ---
I posted initial patch here
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01334.html