[Bug c/84685] New: Designated initializers warning

[davranfor at yahoo dot es]

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

Bug ID: 84685
   Summary: Designated initializers warning
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: davranfor at yahoo dot es
  Target Milestone: ---

Created attachment 43554
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43554=edit
Designated initializer warning using compound literal

Compiling with `-std=c99 -Wextra` and using a compound literal to initialize a
member in a designated initializer:

struct T { int a; int *b; int c; }; 

struct T t = {.b = (int[]){1}};

Raises a warning 

missing initializer for field ‘c’ of ‘struct T’
[-Werror=missing-field-initializers]

This happens when the initialized member is not the last member of the struct.

[Bug c++/54367] [meta-bug] lambda expressions

[jason at gcc dot gnu.org]

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

Bug 53157 Summary: within lambda, error: lvalue required as unary ‘&’ operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53157

   What|Removed |Added

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

[Bug c++/53157] within lambda, error: lvalue required as unary ‘&’ operand

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|--- |8.0

--- Comment #7 from Jason Merrill  ---
Fixed for GCC 8, I don't think we need this testcase as well as the others.

[Bug c++/56973] [DR 696] crash when capturing variables in nested lambdas

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|--- |8.0

--- Comment #8 from Jason Merrill  ---
Yes, this is  fixed now.

[Bug c++/54367] [meta-bug] lambda expressions

[jason at gcc dot gnu.org]

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

Bug 56973 Summary: [DR 696] crash when capturing variables in nested lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56973

   What|Removed |Added

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

[Bug middle-end/81657] [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call

[hjl.tools at gmail dot com]

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

--- Comment #21 from H.J. Lu  ---
(In reply to Martin Liška from comment #20)
> Ok, so the PR is still marked as P1, so we should probably focus on it.
> If I'm reading the discussion correctly, there's no consensus about what to
> do?

Please add a target hook to allow backend to keep tail call to mempcpy.

[Bug fortran/66128] ICE for some intrinsics with zero sized array parameter

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Patch submitted.

https://gcc.gnu.org/ml/fortran/2018-03/msg00010.html

This fixes additional failures not included in Gerhard's
testcases.

[Bug rtl-optimization/84660] Combine doing wrong optimization for 64 bits with SHIFT_COUNT_TRUNCATED target

[wilson at gcc dot gnu.org]

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

--- Comment #3 from Jim Wilson  ---
I screwed up the logic and need to redo the patch.  The basic idea is sound
though.

[Bug c++/61358] Bogus "duplicate label" error after label used within C++11 lambda

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||lh_mouse at 126 dot com

--- Comment #2 from Paolo Carlini  ---
*** Bug 71564 has been marked as a duplicate of this bug. ***

[Bug c++/54367] [meta-bug] lambda expressions

[paolo.carlini at oracle dot com]

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

Bug 71564 Summary: label inside a lambda conflicts (?) with another one outside 
it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71564

   What|Removed |Added

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

[Bug c++/71564] label inside a lambda conflicts (?) with another one outside it

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
Indeed, now that PR61358 is fixed in trunk, this one is fixed too. I will add a
testcase.

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

[Bug c++/71332] Passing non-copyable type by reference to variadic generic lambda after a copyable type by value results in a compile-time error

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #2 from Paolo Carlini  ---
Dup.

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

[Bug c++/54367] [meta-bug] lambda expressions

[paolo.carlini at oracle dot com]

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

Bug 71332 Summary: Passing non-copyable type by reference to variadic generic 
lambda after a copyable type by value results in a compile-time error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71332

   What|Removed |Added

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

[Bug c++/64095] [C++14] Ellipsis at end of generic lambda parameter-declaration-clause should be parsed as a parameter pack

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||vittorio.romeo at outlook dot 
com

--- Comment #7 from Paolo Carlini  ---
*** Bug 71332 has been marked as a duplicate of this bug. ***

[Bug c++/60230] internal compiler error on lambdas capturing multidimensional arrays with dynamic boundary

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||josutous at dodsi dot com

--- Comment #5 from Paolo Carlini  ---
*** Bug 69756 has been marked as a duplicate of this bug. ***

[Bug c++/54367] [meta-bug] lambda expressions

[paolo.carlini at oracle dot com]

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

Bug 69756 Summary: Passing a multidimensional variable-length array into a 
lambda (by reference) causes an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69756

   What|Removed |Added

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

[Bug c++/69756] Passing a multidimensional variable-length array into a lambda (by reference) causes an error

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
One more...

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

[Bug c++/64000] internal compiler error on lambda that captures 2-dimensional variable size array by reference

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
Note, in trunk we don't ICE anymore on this, I will add a testcase.

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

[Bug c++/60230] internal compiler error on lambdas capturing multidimensional arrays with dynamic boundary

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||tobias.polzer+gcc at gmail dot 
com

--- Comment #4 from Paolo Carlini  ---
*** Bug 64000 has been marked as a duplicate of this bug. ***

[Bug c++/54367] [meta-bug] lambda expressions

[paolo.carlini at oracle dot com]

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

Bug 64000 Summary: internal compiler error on lambda that captures 
2-dimensional variable size array by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64000

   What|Removed |Added

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

[Bug c++/58820] lambda multiple inheritance operator() not ambiguous

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  ---
Barring further comments, I'm going to add a testcase and close this.
(Note, current clang still accepts it)

[Bug c++/56973] [DR 696] crash when capturing variables in nested lambdas

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #7 from Paolo Carlini  ---
Jason, can we resolve this? I didn't investigate much but I see [DR 696] in the
subject and in your last patch, isn't obvious what is still missing?!?

[Bug c++/53157] within lambda, error: lvalue required as unary ‘&’ operand

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #6 from Paolo Carlini  ---
Jason, we now accept this. Should we resolve it for 8?
In case we may want to add a testcase.

[Bug demangler/82195] Undemangleable lambda

[paolo.carlini at oracle dot com]

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

--- Comment #9 from Paolo Carlini  ---
Nathan, can we close this as fixed, then?

[Bug c++/54367] [meta-bug] lambda expressions

[paolo.carlini at oracle dot com]

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

Bug 61135 Summary: It seems to be not able to call virtual method of literal 
object in lambda expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61135

   What|Removed |Added

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

[Bug c++/61135] It seems to be not able to call virtual method of literal object in lambda expression

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #13 from Paolo Carlini  ---
Completely fixed in trunk.

[Bug c++/61135] It seems to be not able to call virtual method of literal object in lambda expression

[paolo at gcc dot gnu.org]

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

--- Comment #12 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Sat Mar  3 00:28:03 2018
New Revision: 258165

URL: https://gcc.gnu.org/viewcvs?rev=258165=gcc=rev
Log:
2018-03-02  Paolo Carlini  

PR c++/61135
* g++.dg/cpp0x/lambda/lambda-61135.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-61135.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/84671] [6/7 Regression] Chrono literals don't accept apostrophe as separator

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
Fixed for 6.5 and 7.4

[Bug libstdc++/84671] [6/7 Regression] Chrono literals don't accept apostrophe as separator

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Author: redi
Date: Sat Mar  3 00:17:03 2018
New Revision: 258164

URL: https://gcc.gnu.org/viewcvs?rev=258164=gcc=rev
Log:
PR libstdc++/84671 handle digit separators in duration literals

Backport from mainline
2018-03-02  Jonathan Wakely  

PR libstdc++/84671
* include/bits/parse_numbers.h (_Number_help): Add partial
specialization to handle digit separators. Adjust partial
specialization for recursion temrination to require _Pow == 1ULL.
* testsuite/20_util/duration/literals/84671.cc: New

Added:
   
branches/gcc-7-branch/libstdc++-v3/testsuite/20_util/duration/literals/84671.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/bits/parse_numbers.h

[Bug c++/84667] unreasonable refusal to use assignment operator method

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Jonathan Wakely  ---
OK I've finished debugging this horribly obfuscated program, and this is not a
compiler bug.

This is copy-initialization:

  estrbuf copybuf1 = varbuf4.as_const();

That means it's equivalent to this:

  estrbuf copybuf1 = estrbuf(varbuf4.as_const());

This constructs a temporary strbuf which has the expected value (0x8000)
but then tries to copy-construct another estrbuf. Your copy constructor cannot
be used to copy temporaries, because you declared it so it only works for
lvalues:

  inline xstrbuf( xstrbuf& s )

so instead the temporary gets converted to its base class (via slicing) and
calls this constructor:

  inline xstrbuf( base_str s )

and that constructor sets bufParams to:

 bufParams = s.length | xstrbuf_bufUserAllocatedBit;

Which explains the unwanted 0xb in the value 800b, it comes from s.length

In the second case you use direct-initialization:

  estrbuf copybuf2( varbuf4.as_const() );

so there is no temporary, no slicing, and no copy that gets s.length in the
params.


You should fix your copy constructor to accept const-lvalues, and avoid
slicing, (and stop misusing the pure attribute, and remove the useless register
keywords, and use more whitespace to help readability, and stop using so many
macros, ...)

[Bug c++/68374] G++ -Wshadow doesn't warn about static member shadowing

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||paolo.carlini at oracle dot com
 Resolution|FIXED   |---

--- Comment #5 from Paolo Carlini  ---
Somebody closed this by mistake.

[Bug rtl-optimization/84660] Combine doing wrong optimization for 64 bits with SHIFT_COUNT_TRUNCATED target

[wilson at gcc dot gnu.org]

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

--- Comment #2 from Jim Wilson  ---
Created attachment 43553
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43553=edit
untested patch that works on testcase

[Bug rtl-optimization/84660] Combine doing wrong optimization for 64 bits with SHIFT_COUNT_TRUNCATED target

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-03
 CC||wilson at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jim Wilson  ---
The shift count is either 0x2e or 0x2f depending on input.  It gets anded with
0xf, and used in an SImode shift, which shift-truncates, so the and is
optimized away as unnecessary.  The SImode shift later gets converted to a
DImode shift, and the code is wrong at that point, because shift by 0x2e/0x2f
gives different results in SImode and DImode.

The bad conversion happens in force_int_to_mode, case ASHIFT.  There is code to
check for shift counts outside the range of mode, however, it is comparing
against the target mode, which is the wider mode.  This code was added by

commit 129e53549ca138dbffd64aa11c5b94688010127b
Author: kenner 
Date:   Fri Apr 9 01:39:46 1993 +

(force_to_mode, case xSHIFT): Don't narrow the mode unless we can be
sure that the shift count is smaller than the size of the mode.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@4050
138bc75d-0d04-0410-961\
f-82ee72b054a4

so this was clearly for the narrowing case.  We are missing a test for the
widening case, which is only necessary for targets that truncate shift counts.

Since the narrowing test is trivially true when widening, and the widening test
is trivially true when narrowing, I don't think we need to check for that, we
can just do both tests.

[Bug libstdc++/84671] [6/7 Regression] Chrono literals don't accept apostrophe as separator

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Fri Mar  2 23:52:06 2018
New Revision: 258159

URL: https://gcc.gnu.org/viewcvs?rev=258159=gcc=rev
Log:
PR libstdc++/84671 handle digit separators in duration literals

Backport from mainline
2018-03-02  Jonathan Wakely  

PR libstdc++/84671
* include/bits/parse_numbers.h (_Number_help): Add partial
specialization to handle digit separators. Adjust partial
specialization for recursion temrination to require _Pow == 1ULL.
* testsuite/20_util/duration/literals/84671.cc: New

Added:
   
branches/gcc-6-branch/libstdc++-v3/testsuite/20_util/duration/literals/84671.cc
Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/include/bits/parse_numbers.h

[Bug c/46921] Lost side effect when struct initializer expression uses comma operator

[dave.pagan at oracle dot com]

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

--- Comment #4 from Dave Pagan  ---
Patch submitted for review:

https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01471.html

[Bug c++/84684] inserting random code / flags produces wrong code

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-02
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Confirmed, valgrind shows a lot of errors like this:

==13397== Conditional jump or move depends on uninitialised value(s)
==13397==at 0xD1F55E: sparseset_bit_p(sparseset_def*, unsigned long) (in
/home/jwakely/gcc/7.3.0/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/cc1plus)
==13397==by 0xD1FF9B: mark_pseudo_regno_live(int) (in
/home/jwakely/gcc/7.3.0/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/cc1plus)
==13397==by 0xD2025C: mark_pseudo_reg_live(rtx_def*, unsigned int) (in
/home/jwakely/gcc/7.3.0/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/cc1plus)
==13397==by 0xD202CA: mark_ref_live(df_ref_d*) (in
/home/jwakely/gcc/7.3.0/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/cc1plus)
==13397==by 0xD22B05: process_bb_node_lives(ira_loop_tree_node*) (in
/home/jwakely/gcc/7.3.0/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/cc1plus)
==13397==by 0xCFA50D: ira_traverse_loop_tree(bool, ira_loop_tree_node*,
void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (in
/home/jwakely/gcc/7.3.0/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/cc1plus)
==13397==by 0xD23991: ira_create_allocno_live_ranges() (in
/home/jwakely/gcc/7.3.0/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/cc1plus)
==13397==by 0xCFE468: ira_build() (in
/home/jwakely/gcc/7.3.0/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/cc1plus)
==13397==by 0xCF53A5: ira(_IO_FILE*) (in
/home/jwakely/gcc/7.3.0/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/cc1plus)
==13397==by 0xCF5B48: (anonymous namespace)::pass_ira::execute(function*)
(in /home/jwakely/gcc/7.3.0/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/cc1plus)
==13397==by 0xE132FF: execute_one_pass(opt_pass*) (in
/home/jwakely/gcc/7.3.0/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/cc1plus)
==13397==by 0xE13650: execute_pass_list_1(opt_pass*) (in
/home/jwakely/gcc/7.3.0/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/cc1plus)
==13397==

[Bug fortran/66128] ICE for some intrinsics with zero sized array parameter

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl  ---
I've worked out the issues with regression in the testsuite.
(Well, I think I have.)

[Bug rtl-optimization/84682] internal compiler error: Segmentation fault (process_address_1)

[vegard.nossum at gmail dot com]

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

--- Comment #2 from Vegard Nossum  ---
I'm also seeing a different crash with this (using -O3):

int a;
void b() {
  float c;
  for (int d; d;)
;
  a = c;
  asm("" : : "pIr"(c));
}

Output:

$ xgcc -x c++ -S -Wall -fpermissive -O3 -
: In function 'void b()':
:4:15: warning: 'd' is used uninitialized in this function
[-Wuninitialized]
:6:5: warning: 'c' is used uninitialized in this function
[-Wuninitialized]
during RTL pass: reload
:8:1: internal compiler error: in emit_move_insn, at expr.c:3717
0x1e906d7 emit_move_insn(rtx_def*, rtx_def*)
/home/vegard/git/gcc/gcc/expr.c:3716
0x280edaa lra_emit_move(rtx_def*, rtx_def*)
/home/vegard/git/gcc/gcc/lra.c:497
0x28a3871 process_address_1
/home/vegard/git/gcc/gcc/lra-constraints.c:3368
0x28a7ba3 process_address
/home/vegard/git/gcc/gcc/lra-constraints.c:3521
0x28a7ba3 curr_insn_transform
/home/vegard/git/gcc/gcc/lra-constraints.c:3836
0x28bbf56 lra_constraints(bool)
/home/vegard/git/gcc/gcc/lra-constraints.c:4877
0x282c524 lra(_IO_FILE*)
/home/vegard/git/gcc/gcc/lra.c:2419
0x260b334 do_reload
/home/vegard/git/gcc/gcc/ira.c:5465
0x260b334 execute
/home/vegard/git/gcc/gcc/ira.c:5649

I'm not opening a new bug because the stack trace is quite similar and also it
seems that making very small changes to this test case makes it crash in the
original way, so I figure it's probably related.

[Bug c++/84684] New: inserting random code / flags produces wrong code

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

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

Bug ID: 84684
   Summary: inserting random code / flags produces wrong code
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
  Target Milestone: ---

Created attachment 43552
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43552=edit
static_assert's throw even though they should not

Hi gcc-team,

I'm really sorry for this really bad title, but I really don't know what is
going on and what the cause is.

When I compile the attached code it produces on my machine incorrect results
which is tested via static_asserts. When I add some code or add some compiler
flags a different static_assert throws. Also on different environment (e.g.
travis-ci, our build system,...) this code throws at different places. There is
also the possibility that it does not throw at all which would be my
expectation. I have different states of the reduced source code if this one
does not work for you.

> g++ -std=c++17 -Wall -Werror -fconcepts -o 
> union_composition_detail_test.cpp.o -c union_composition_detail_test.cpp

I even encountered states where the flags did not have any influence and the
problem persisted, but I ran more frequently in this issue with those flags.

The only observation I had was that
`value_to_char[i] = alphabet.assign_rank(i).to_char();`
seems to always work, but it might be a coincidence.

Thank you!


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

[Bug fortran/84674] [7/8 Regression] Derived type name change makes a program segfault, removing non_overridable helps

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
  Known to work||6.4.0
   Target Milestone|--- |7.4
Summary|Derived type name change|[7/8 Regression] Derived
   |makes a program segfault,   |type name change makes a
   |removing non_overridable|program segfault, removing
   |helps   |non_overridable helps
  Known to fail||7.3.0, 8.0

--- Comment #2 from Dominique d'Humieres  ---
Regression! We are looking for a commit between r254227 (2017-10-30, OK) and
r254498 (2017-11-07, wrong-code) that has been back-ported to gcc7, may be
r254244(?).

[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

[neil.n.carlson at gmail dot com]

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

--- Comment #13 from Neil Carlson  ---
And one more missed file due to a line split between the "call" and "abort". 
Here's the patch:

diff --git a/overload_1.f90 b/overload_1.f90
index afd4f81..66fbea4 100644
--- a/overload_1.f90
+++ b/overload_1.f90
@@ -162,8 +162,7 @@ contains
 r2 = (/ a.eq.b, a.ne.b, a.lt.b, a.le.b, a.gt.b, a.ge.b /)
 if (any (r1.neqv.r2)) STOP 1
 if (any (r1.neqv. &
- (/ .false.,.true.,.true., .true., .false.,.false. /) )) call&
- & abort
+ (/ .false.,.true.,.true., .true., .false.,.false. /) )) STOP 3
   end subroutine checkt

   subroutine checku
@@ -177,7 +176,6 @@ contains
 r2 = (/ a.eq.b, a.ne.b, a.lt.b, a.le.b, a.gt.b, a.ge.b /)
 if (any (r1.neqv.r2)) STOP 2
 if (any (r1.neqv. &
- (/ .false.,.true.,.true., .true., .false.,.false. /) )) call&
- & abort
+ (/ .false.,.true.,.true., .true., .false.,.false. /) )) STOP 4
   end subroutine checku
 end program main

[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

[neil.n.carlson at gmail dot com]

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

--- Comment #12 from Neil Carlson  ---
Argh... here's the *correct* patch

diff --git a/literal_character_constant_1.inc
b/literal_character_constant_1.inc
index ba24966..40375cd 100644
--- a/literal_character_constant_1.inc
+++ b/literal_character_constant_1.inc
@@ -9,12 +9,12 @@ c A tab is between 8 and 9.
   write(fil,'(a)') c
 #ifdef LL_NONE
   if(fil.ne. "12345678 9")
- &  call abort
+ &  stop 1
 #else
   if(fil.ne.
  &"1234567  8  9"
  &)
- &  call abort
+ &  stop 2
 #endif
   end

[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

[neil.n.carlson at gmail dot com]

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

--- Comment #11 from Neil Carlson  ---
One more missed file, an include file included by
literal_character_constant_1_x.F.  Here's the patch:

diff --git a/literal_character_constant_1.inc
b/literal_character_constant_1.inc
index ba24966..8beea79 100644
--- a/literal_character_constant_1.inc
+++ b/literal_character_constant_1.inc
@@ -9,12 +9,12 @@ c A tab is between 8 and 9.
   write(fil,'(a)') c
 #ifdef LL_NONE
   if(fil.ne. "12345678 9")
- &  call abort
+ &  call stop 1
 #else
   if(fil.ne.
  &"1234567  8  9"
  &)
- &  call abort
+ &  call stop 2
 #endif
   end

[Bug c++/79937] [6/7/8 Regression] ICE in replace_placeholders_r

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

--- Comment #10 from Jason Merrill  ---
Here's a wrong-code version that isn't fixed by Jakub's patch:

struct X {
  unsigned i;
  unsigned n = i;
};

X bar(X x) {
  return x;
}

int main()
{
  X x { 1, bar(X{2}).n };
  if (x.n != 2)
__builtin_abort();
}

though this isn't a regression.

[Bug rtl-optimization/84682] internal compiler error: Segmentation fault (process_address_1)

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-02
 CC||dmalcolm at gcc dot gnu.org
  Component|inline-asm  |rtl-optimization
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed.

Segfault reading through NULL in reload here:

process_address_1 (nop=nop@entry=0, check_only_p=check_only_p@entry=false,
before=before@entry=0x7fffcea0, 
after=after@entry=0x7fffcea8) at ../../src/gcc/lra-constraints.c:3424
3424  if (poly_int_rtx_p (*ad.disp, _offset)

(gdb) p ad.disp
$1 = (rtx *) 0x0

[Bug inline-asm/84683] New: internal compiler error: in move_for_stack_reg, at reg-stack.c:1173

[vegard.nossum at gmail dot com]

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

Bug ID: 84683
   Summary: internal compiler error: in move_for_stack_reg, at
reg-stack.c:1173
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vegard.nossum at gmail dot com
  Target Milestone: ---

Input:

void a(float b, double c) {
  for (int e = 0; e < 2; e++) {
asm volatile ("" : "+f" (c));
asm ("" : "+rm" (c = b));
  }
}

Output:

$ xgcc -x c++ -S -Wall -fpermissive -O3 -
: In function 'void a(float, double)':
:3:34: error: output constraint 0 must specify a single register
during RTL pass: stack
:6:1: internal compiler error: in move_for_stack_reg, at
reg-stack.c:1173
0x2d49787 move_for_stack_reg
/home/vegard/git/gcc/gcc/reg-stack.c:1173
0x2d5c1fa subst_stack_regs
/home/vegard/git/gcc/gcc/reg-stack.c:2437
0x2d5ced7 convert_regs_1
/home/vegard/git/gcc/gcc/reg-stack.c:3062
0x2d5ced7 convert_regs_2
/home/vegard/git/gcc/gcc/reg-stack.c:3197
0x2d64844 convert_regs
/home/vegard/git/gcc/gcc/reg-stack.c:3232
0x2d64844 reg_to_stack
/home/vegard/git/gcc/gcc/reg-stack.c:3357
0x2d64844 rest_of_handle_stack_regs
/home/vegard/git/gcc/gcc/reg-stack.c:3412
0x2d64844 execute
/home/vegard/git/gcc/gcc/reg-stack.c:3443

$ xgcc --version
xgcc (GCC) 8.0.1 20180301 (experimental)

Built from git c435a9e730c6e8f10da09d58b4fc9aaeb401b0d5 (r258097).

4.8.5 seems to produce this:

: In function 'void a(float, double)':
:3:33: error: output constraint 0 must specify a single register
 asm volatile ("" : "+f" (c));
 ^
:3:33: error: output constraint 0 must specify a single register
:3:33: error: implicitly popped regs must be grouped at top of stack
Compiler returned: 1

Test case was minimised by C-Reduce.

[Bug fortran/71085] ICE with some intrinsic functions specifying array function result dimension

[anlauf at gmx dot de]

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

--- Comment #3 from Harald Anlauf  ---
Patch submitted:

https://gcc.gnu.org/ml/fortran/2018-03/msg9.html

[Bug libstdc++/84671] [6/7 Regression] Chrono literals don't accept apostrophe as separator

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||8.0.1
   Target Milestone|--- |6.5
Summary|[6/7/8 Regression] Chrono   |[6/7 Regression] Chrono
   |literals don't accept   |literals don't accept
   |apostrophe as separator |apostrophe as separator

--- Comment #5 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug libstdc++/84671] [6/7/8 Regression] Chrono literals don't accept apostrophe as separator

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Fri Mar  2 20:38:50 2018
New Revision: 258157

URL: https://gcc.gnu.org/viewcvs?rev=258157=gcc=rev
Log:
PR libstdc++/84671 handle digit separators in duration literals

PR libstdc++/84671
* include/bits/parse_numbers.h (_Number_help): Add partial
specialization to handle digit separators. Adjust partial
specialization for recursion temrination to require _Pow == 1ULL.
* testsuite/20_util/duration/literals/84671.cc: New

Added:
trunk/libstdc++-v3/testsuite/20_util/duration/literals/84671.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/parse_numbers.h

[Bug c++/84578] [6/7 Regression] ICE with flexible array member and constexpr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
Summary|[6/7/8 Regression] ICE with |[6/7 Regression] ICE with
   |flexible array member and   |flexible array member and
   |constexpr   |constexpr

--- Comment #5 from Marek Polacek  ---
Fixed in GCC 8.  The patch doesn't apply cleanly and it's ICE on kind-of
invalid, so probably not going to backport.

[Bug c++/84578] [6/7/8 Regression] ICE with flexible array member and constexpr

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Fri Mar  2 20:27:46 2018
New Revision: 258156

URL: https://gcc.gnu.org/viewcvs?rev=258156=gcc=rev
Log:
PR c++/84578
* constexpr.c (get_array_or_vector_nelts): New.
(cxx_eval_array_reference): Use it.
(cxx_eval_vec_init_1): Likewise.
(cxx_eval_store_expression): Likewise.

* g++.dg/ext/flexary29.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/flexary29.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/84489] [6/7 Regression] Non-type template parameter dependency

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug inline-asm/84682] New: internal compiler error: Segmentation fault (process_address_1)

[vegard.nossum at gmail dot com]

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

Bug ID: 84682
   Summary: internal compiler error: Segmentation fault
(process_address_1)
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vegard.nossum at gmail dot com
  Target Milestone: ---

Input:

void b(char a) {
asm("" : : "pIr" (a));
}

Output:

$ xgcc -x c++ -S -Wall -
during RTL pass: reload
: In function 'void b(char)':
:3:1: internal compiler error: Segmentation fault
0x3155789 crash_signal
/home/vegard/git/gcc/gcc/toplev.c:325
0x28a3e20 process_address_1
/home/vegard/git/gcc/gcc/lra-constraints.c:3424
0x28a7ba3 process_address
/home/vegard/git/gcc/gcc/lra-constraints.c:3521
0x28a7ba3 curr_insn_transform
/home/vegard/git/gcc/gcc/lra-constraints.c:3836
0x28bbf56 lra_constraints(bool)
/home/vegard/git/gcc/gcc/lra-constraints.c:4877
0x282c524 lra(_IO_FILE*)
/home/vegard/git/gcc/gcc/lra.c:2419
0x260b334 do_reload
/home/vegard/git/gcc/gcc/ira.c:5465
0x260b334 execute
/home/vegard/git/gcc/gcc/ira.c:5649

$ xgcc --version
xgcc (GCC) 8.0.1 20180301 (experimental)

Built from git c435a9e730c6e8f10da09d58b4fc9aaeb401b0d5 (r258097).

Seems to have been introduced between 4.8.5 and 4.9.0.

Test case was minimised by C-Reduce.

[Bug c++/66564] ICE on explicit instantiation of nested template class

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||benni.buch at gmail dot com

--- Comment #2 from Paolo Carlini  ---
*** Bug 84678 has been marked as a duplicate of this bug. ***

[Bug c++/84678] ICE on invalid code with nested templates

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #2 from Paolo Carlini  ---
Dup.

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

[Bug debug/84620] DW_AT_GNU_entry_view should not use address class forms, but constant forms

[aoliva at gcc dot gnu.org]

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

--- Comment #4 from Alexandre Oliva  ---
Jakub, ok, I'll move the union field, but I thought it would be better to keep
it close to logically-similar entries.  If the point is just to make it
parallel to the order of the enum, maybe moving the enum would be better?

There's no guarantee it will fit in 16 bits; perhaps the assembler will error
out rather than just truncate the view number.  There's no real upper limit, so
uleb128 would be ideal, but since that's not viable ATM, I had to pick
something, and 16 bits would cover all really useful cases than 32 or even 64
bits would, while being more compact.  I was even tempted to go with 8 bits,
but thought that was pushing it.  I can make it 32 if you consider it better.

Why do you say it would be terribly expensive to let the assembler compute
offsets in .debug_info?

[Bug c++/84678] ICE on invalid code with nested templates

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-02
 Ever confirmed|0   |1

--- Comment #1 from Paolo Carlini  ---
Confirmed.

[Bug tree-optimization/84670] [8 Regression] ICE: in compute_antic_aux, at tree-ssa-pre.c:2148 with -O2 -fno-tree-dominator-opts

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #5 from Jeffrey A. Law  ---
Created attachment 43551
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43551=edit
x86_64 testcase

Attaching x86-64 testcase.  Compile with -Os -fno-strict-overflow

[Bug fortran/84672] -fcheck=bounds gives runtime error on allocation on assignment with implicit type conversion

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-02
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
This seems to have been fixed on trunk (8.0).

[Bug fortran/84615] [8 Regression] Executable Segfault for tests compiled with -fdefault-integer-8 and -m32

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
This has to be some issue with the charlen - possibly a
default integer being used in the wrong place after r256322.

I don't usually build 32-bit-capable compilers on my home system
(too slow), let's see if I can get something built on the compile farm.

[Bug c++/84662] [6/7 Regression] internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in is_bitfield_expr_with_lowered_type, at cp/typeck.c:1944

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] internal |[6/7 Regression] internal
   |compiler error: tree check: |compiler error: tree check:
   |expected class 'type', have |expected class 'type', have
   |'exceptional' (error_mark)  |'exceptional' (error_mark)
   |in  |in
   |is_bitfield_expr_with_lower |is_bitfield_expr_with_lower
   |ed_type, at |ed_type, at
   |cp/typeck.c:1944|cp/typeck.c:1944

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

[Bug fortran/84674] Derived type name change makes a program segfault, removing non_overridable helps

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-02
 CC||pault at gcc dot gnu.org,
   ||tkoenig at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Thomas Koenig  ---
This has to be one of the stranger bugs I have encountered...

It appears that the bug depends on the alphabetical ordering
of the type names. So, replace DerivedType in your code
by anything (such as "t2a") that comes later in the alphabet
than t2, the code compiles and runs fine.

Now, replacing DerivedType with t0 and t3, respectively, and
comparing the assembly dumps, shows some significant difference.

The t3 version has, right at the top

.file   "a.f90"
.text
.globl  __m_MOD___def_init_m_T3
.section.rodata
.align 4
.type   __m_MOD___def_init_m_T3, @object
.size   __m_MOD___def_init_m_T3, 4
__m_MOD___def_init_m_T3:
.zero   4
.globl  __m_MOD___vtab_m_T1
.align 32
.type   __m_MOD___vtab_m_T1, @object
.size   __m_MOD___vtab_m_T1, 64

and the t0 version (which does not work) has

.file   "a.f90"
.text
.globl  __m_MOD___def_init_m_T0
.section.rodata
.align 4
.type   __m_MOD___def_init_m_T0, @object
.size   __m_MOD___def_init_m_T0, 4
__m_MOD___def_init_m_T0:
.zero   4
.globl  __m_MOD___vtab_m_T0
.align 32
.type   __m_MOD___vtab_m_T0, @object
.size   __m_MOD___vtab_m_T0, 64

so whatever the def_init_m data structures are supposed to point to,
they appear to point to something wrong if things are out of
alphabetical order.

Wow, this has to be among the top 2% in weird gfortran bugs.

[Bug tree-optimization/84515] missed optimization: expected loop merging

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #4 from Jeffrey A. Law  ---
The degenerate PHI is a bit of a red-herring.  It's turned into a degenerate
via uncprop to discourage the unnecessary constant initialization.

Really the key here is we need to know the relationship between _20 and
count_11.  

That relationship is that count_11 >= _20

But EVRP never gives us that symbolic relationship so threading really never
gets a chance.

[Bug fortran/81827] Large compile time with derived-type rrays

[pault at gcc dot gnu.org]

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

--- Comment #19 from Paul Thomas  ---
There are at least three sources of the recursive code:
(i) The allocate statement. This checks to see if the allocate object and its
allocatable components are allocated and deallocates them if necessary. I must
check if the standard requires this!
(ii) The vtable 'final' procedure. This calls any user defined 'final'
procedures first, goes on to do the same for the allocatable components, and
then, after each 'final' call, dealloactes if necessary.
(iii) The vtable 'copy'. This is a deep copy of the object and its allocatable
components. It generates a load of code in consequence.

The answer is, yes, these recursive procedures are necessary. I just need to
find some less compile time intensive way of implementing them.

Cheers

Paul

[Bug c++/84489] [6/7 Regression] Non-type template parameter dependency

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Fri Mar  2 18:24:40 2018
New Revision: 258152

URL: https://gcc.gnu.org/viewcvs?rev=258152=gcc=rev
Log:
PR c++/84489 - dependent default template argument

* pt.c (type_unification_real): Handle early substitution failure.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/fntmpdefarg7.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/pt.c

[Bug tree-optimization/84646] Missed optimisation for hoisting conditions outside nested loops

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #2 from Jeffrey A. Law  ---
The backwards threader discovers the threads, but refuses to optimize them
because it thinks doing so will create an irreducible loop without enough
benefit.

[Bug middle-end/84681] New: tree-ter moving code too much

[amonakov at gcc dot gnu.org]

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

Bug ID: 84681
   Summary: tree-ter moving code too much
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64

The following code (derived from a hot loop in a Huffman encoder, reported by
Fabian Giesen) suffers from TER activity too much on x86-64. TER lifts
loads+zero_extends to the BB head, sinking variable-length shifts and
increasing register pressure too badly.

Not being very familiar with TER, I think it would be good to understand why
loads are lifted all the way up to BB head like that. That's probably not
supposed to happen (and may be fixable without a TER overhaul?)

unsigned long long f(unsigned char *from,
 unsigned char *from_end,
 unsigned long long *codes,
 unsigned char *lens)
{
unsigned char sym0, sym1, sym2;
unsigned long long bits0=0, bits1=0, bits2=0;
unsigned char count0=0, count1=0, count2=0;
do {
sym0 = *from++; bits0 |= codes[sym0] << count0; count0 += lens[sym0];
sym1 = *from++; bits1 |= codes[sym1] << count1; count1 += lens[sym1];
sym2 = *from++; bits2 |= codes[sym2] << count2; count2 += lens[sym2];
sym0 = *from++; bits0 |= codes[sym0] << count0; count0 += lens[sym0];
sym1 = *from++; bits1 |= codes[sym1] << count1; count1 += lens[sym1];
sym2 = *from++; bits2 |= codes[sym2] << count2; count2 += lens[sym2];
sym0 = *from++; bits0 |= codes[sym0] << count0; count0 += lens[sym0];
sym1 = *from++; bits1 |= codes[sym1] << count1; count1 += lens[sym1];
sym2 = *from++; bits2 |= codes[sym2] << count2; count2 += lens[sym2];
sym0 = *from++; bits0 |= codes[sym0] << count0; count0 += lens[sym0];
sym1 = *from++; bits1 |= codes[sym1] << count1; count1 += lens[sym1];
sym2 = *from++; bits2 |= codes[sym2] << count2; count2 += lens[sym2];
sym0 = *from++; bits0 |= codes[sym0] << count0; count0 += lens[sym0];
sym1 = *from++; bits1 |= codes[sym1] << count1; count1 += lens[sym1];
sym2 = *from++; bits2 |= codes[sym2] << count2; count2 += lens[sym2];
} while(from != from_end);
return bits0+bits1+bits2;
}

[Bug middle-end/81812] [7/8 Regression] Empty virtual function fails to compile

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC|paolo.carlini at oracle dot com|
 Resolution|--- |FIXED
   Target Milestone|7.4 |7.3

--- Comment #11 from Paolo Carlini  ---
Done.

[Bug target/84264] [8 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:10367 starting with r256656

[bergner at gcc dot gnu.org]

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

--- Comment #6 from Peter Bergner  ---
So we end up dropping into rs6000_emit_le_vsx_store from gen_movv4si via:

  if (!BYTES_BIG_ENDIAN
  && VECTOR_MEM_VSX_P (mode)
  && !TARGET_P9_VECTOR
  && !gpr_or_gpr_p (operands[0], operands[1])
  && (memory_operand (operands[0], mode)
  ^ memory_operand (operands[1], mode)))
{
  rs6000_emit_le_vsx_move (operands[0], operands[1], mode);
  DONE;
}

This is catching the case (during expand) where we have non LE friendly
loads/stores and we need to emit permutes with them.  In the case where we are
ICEing, we actually have a LE friendly Altivec mem:

Breakpoint 9, rs6000_emit_le_vsx_store (dest=0x3fffb580c888,
source=0x3fffb580ea90, mode=E_V4SImode)
at
/home/bergner/gcc/gcc-fsf-mainline-pr84264/gcc/config/rs6000/rs6000.c:10357
10357   {
(gdb) pr2 dest source
(mem/c:V4SI (and:DI (plus:DI (reg:DI 141)
(reg:DI 140))
(const_int -16 [0xfff0])) [1 args+0 S16 A128])
(reg:V4SI 142)

In this case, we can just emit the store normally and don't need to drop into
rs6000_emit_le_vsx_move at all.  Guarding the code above to ensure we don't
have an Altivec mem via altivec_indexed_or_indirect_operand() fixes the ICE:

Index: vector.md
===
--- vector.md   (revision 258115)
+++ vector.md   (working copy)
@@ -136,8 +136,10 @@ (define_expand "mov"
   && VECTOR_MEM_VSX_P (mode)
   && !TARGET_P9_VECTOR
   && !gpr_or_gpr_p (operands[0], operands[1])
-  && (memory_operand (operands[0], mode)
-  ^ memory_operand (operands[1], mode)))
+  && ((memory_operand (operands[0], mode)
+  && !altivec_indexed_or_indirect_operand(operands[0], mode))
+ ^ (memory_operand (operands[1], mode)
+&& !altivec_indexed_or_indirect_operand(operands[1],
mode
 {
   rs6000_emit_le_vsx_move (operands[0], operands[1], mode);
   DONE;

[Bug fortran/84675] Random FAIL: gfortran.dg/coarray_47.f90 -O (test for errors, line 12)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-03-02
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Should be fixed at r258128.

[Bug middle-end/81812] [7/8 Regression] Empty virtual function fails to compile

[paolo at gcc dot gnu.org]

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

--- Comment #10 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Fri Mar  2 18:06:44 2018
New Revision: 258150

URL: https://gcc.gnu.org/viewcvs?rev=258150=gcc=rev
Log:
2018-03-02  Paolo Carlini  

PR c++/81812
* g++.dg/torture/pr81812.C: New.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr81812.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/81812] [7/8 Regression] Empty virtual function fails to compile

[paolo.carlini at oracle dot com]

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

--- Comment #9 from Paolo Carlini  ---
This works in 7.3.0 too. I'm going to add the testcase and close the bug.

[Bug c++/84664] [8 Regression] internal compiler error: in cp_perform_integral_promotions, at cp/typeck.c:2172

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug c++/84663] [6/7/8 Regression] internal compiler error: tree check: expected array_type, have error_mark in cp_complete_array_type, at cp/decl.c:8334

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed in GCC 8.

[Bug c++/84664] [8 Regression] internal compiler error: in cp_perform_integral_promotions, at cp/typeck.c:2172

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Fri Mar  2 17:55:28 2018
New Revision: 258149

URL: https://gcc.gnu.org/viewcvs?rev=258149=gcc=rev
Log:
PR c++/84664
* typeck.c (cp_perform_integral_promotions): Check the result of
mark_rvalue_use.

* g++.dg/cpp0x/lambda/lambda-ice28.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice28.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/84663] [6/7/8 Regression] internal compiler error: tree check: expected array_type, have error_mark in cp_complete_array_type, at cp/decl.c:8334

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Fri Mar  2 17:54:23 2018
New Revision: 258148

URL: https://gcc.gnu.org/viewcvs?rev=258148=gcc=rev
Log:
PR c++/84663
* decl.c (cp_complete_array_type): Check error_mark_node.

* g++.dg/parse/array-size3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/parse/array-size3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/84171] [8 Regression] ICE with -Wsign-compare

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed.

[Bug c++/84171] [8 Regression] ICE with -Wsign-compare

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Fri Mar  2 17:51:24 2018
New Revision: 258147

URL: https://gcc.gnu.org/viewcvs?rev=258147=gcc=rev
Log:
PR c++/84171
* c-warn.c (warn_for_sign_compare): Bail out if any of the operands
is erroneous.

* g++.dg/warn/Wsign-compare-8.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wsign-compare-8.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-warn.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/84670] [8 Regression] ICE: in compute_antic_aux, at tree-ssa-pre.c:2148 with -O2 -fno-tree-dominator-opts

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On March 2, 2018 5:07:59 PM GMT+01:00, "romain.geissler at amadeus dot com"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84670
>
>Romain Geissler  changed:
>
>   What|Removed |Added
>
> CC||romain.geissler at amadeus dot com
>
>--- Comment #3 from Romain Geissler com> ---
>Hi,
>
>Note that in my case, this issue happens during a GNU toolchain
>bootstrap (ie
>gcc is not able to rebuild itself anymore).

If it gets too pervasive then please commit the obvious thing and disable the
assert for now. I'll likely will not be able to resolve this issue before
Monday. 

Richard.

[Bug c++/72752] [6 Regression] ICE: in retrieve_specialization, at cp/pt.c:1183

[paolo.carlini at oracle dot com]

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

--- Comment #15 from Paolo Carlini  ---
Thanks for the new bug. Note that this bug is marked as [6 Regression] and
still open, thus isn't surprising at all that some or even all the testcases
here fail in 6, actually it's expected. If you have testcases failing in 7 or
8, please open new bugs, for clarity. Thanks a lot again for your help!

[Bug inline-asm/84680] New: internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[vegard.nossum at gmail dot com]

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

Bug ID: 84680
   Summary: internal compiler error: Max. number of generated
reload insns per insn is achieved (90)
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vegard.nossum at gmail dot com
  Target Milestone: ---

Input:

void a() {
  double b;
  asm volatile("" : "=vp" (b) : "0" (__builtin_alloca));
}

Output:

$ xgcc -x c++ -S -Wall -
during RTL pass: reload
: In function 'void a()':
:4:1: internal compiler error: Max. number of generated reload insns per
insn is achieved (90)

0x28be84c lra_constraints(bool)
/home/vegard/git/gcc/gcc/lra-constraints.c:4801
0x282c524 lra(_IO_FILE*)
/home/vegard/git/gcc/gcc/lra.c:2419
0x260b334 do_reload
/home/vegard/git/gcc/gcc/ira.c:5465
0x260b334 execute
/home/vegard/git/gcc/gcc/ira.c:5649

$ xgcc --version
xgcc (GCC) 8.0.1 20180301 (experimental)

Built from git c435a9e730c6e8f10da09d58b4fc9aaeb401b0d5 (r258097).

Seems to start failing between 4.8.5 and 4.9.0.

Test case was minimised by C-Reduce.

[Bug target/70359] [6/7/8 Regression] Code size increase for ARM compared to gcc-5.3.0

[aldyh at gcc dot gnu.org]

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

--- Comment #28 from Aldy Hernandez  ---
(In reply to Richard Biener from comment #25)


> What usually makes things complicated in the end is when for an IV
> we get overlapping life-ranges for the before and after value because
> that inhibits coalescing.  Is this what happens here?
...
...
> So we indeed have p_20 and p_9 live as p_9 is used after the loop. 
> Originally
> this wasn't the case but fold_stmt in the first forwprop pass does this
> by means of following use-def chains.

I'm a bit confused.

Where are you looking, after the forprop1 pass?  Because after forwprop1 I see:

   :
  p_22 = p_8 + 4294967294;
  MEM[(char *)p_19 + 4294967295B] = 45;

   :
  # p_9 = PHI 
  return p_9;

Which as I understand has:

p_8  being the IV at the beginning of the last iteration.  
p_19 being the IV at the end of the last iteration.
p_22 being the IV at the end of the last iteration MINUS 1.

I don't see a p_20 anywhere.  Did you mean that p_8 and p_19 where both live at
the end of the loop?

Thanks for all the feedback BTW.

[Bug c++/84667] unreasonable refusal to use assignment operator method

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Elmar Stellnberger from comment #0)
> Things work well however if I use the standard constructor instead of an
> assignment:
> 
>   inline xstrbuf( base_str_const s ) : base_str(
> const_cast(s.chars), s.length ) { bufParams = xstrbuf_constBuf;
> };  

Instead of what? Where are we supposed to be looking?

>   Any feedback would be very appreciated!

Your code is almost unreadable.

[Bug c++/84667] unreasonable refusal to use assignment operator method

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-03-02
 Ever confirmed|0   |1

--- Comment #5 from Jonathan Wakely  ---
(In reply to Elmar Stellnberger from comment #1)
> sample program that evokes the error reduced to 20% of its original size

At least 90% of it is still completely irrelevant and we have to wade through
hundreds of lines of macros and unrelated junk. What exactly is the bug?

If you simply need to add const to your copy constructors and copy assignment
operators, well that's how C++ works.

[Bug c++/72752] [6 Regression] ICE: in retrieve_specialization, at cp/pt.c:1183

[benni.buch at gmail dot com]

 report.
See <http://gcc.gnu.org/bugs.html> for instructions.

$ g++-6 --version
g++ (GCC) 6.4.1 20180302
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Test case 1:

typedef void (*foo_t)();

void test(foo_t)
{}

template< typename >
struct A
{
  template< typename = void > static void foo();

  void bar()
  {
test(foo);
  }

  template< typename >
  void baz()
  {
test(foo);
  }
};

template< typename _T_ >
template< typename >
void A< _T_ >::foo()
{}


Test case 2:

typedef void (*foo_t)();

void test(foo_t)
{}

template< typename >
struct A
{
  template< typename = void > static void foo();

  void bar()
  {
test(foo<>);
  }

  template< typename >
  void baz()
  {
test(foo<>);
  }
};

template< typename _T_ >
template< typename >
void A< _T_ >::foo()
{}


Test case 3:

typedef void (*foo_t)();

void test(foo_t, foo_t)
{}

template< typename >
struct A
{
  template< typename = void > static void foo1();
  template< typename = void > static void foo2();

  void bar()
  {
test(foo1, foo2);
  }

  template< typename >
  void baz()
  {
test(foo1, foo2);
  }
};

template< typename _T_ >
template< typename >
void A< _T_ >::foo1()
{}

template< typename _T_ >
template< typename >
void A< _T_ >::foo2()
{}


Test case 4:

typedef void (*foo_t)();

void test(foo_t, foo_t)
{}

template< typename >
struct A
{
  template< typename = void > static void foo1();
  template< typename = void > static void foo2();

  void bar()
  {
test(foo1, foo2<>);
  }

  template< typename >
  void baz()
  {
test(foo1<>, foo2);
  }
};

template< typename _T_ >
template< typename >
void A< _T_ >::foo1()
{}

template< typename _T_ >
template< typename >
void A< _T_ >::foo2()
{}

[Bug libgomp/83590] [nvptx] openacc reduction C regressions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Should be fixed now.

[Bug c++/84662] [6/7/8 Regression] internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in is_bitfield_expr_with_lowered_type, at cp/typeck.c:1944

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar  2 17:07:39 2018
New Revision: 258146

URL: https://gcc.gnu.org/viewcvs?rev=258146=gcc=rev
Log:
PR c++/84662
* pt.c (tsubst_copy_and_build) : Use
RETURN instead of return.
: Likewise.
: If op0 is error_mark_node, just return
it instead of wrapping it into CONVERT_EXPR.

* g++.dg/cpp1y/pr84662.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr84662.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug inline-asm/84679] New: internal compiler error: in lra_eliminate_reg_if_possible, at lra-eliminations.c:1382

[vegard.nossum at gmail dot com]

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

Bug ID: 84679
   Summary: internal compiler error: in
lra_eliminate_reg_if_possible, at
lra-eliminations.c:1382
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vegard.nossum at gmail dot com
  Target Milestone: ---

Input:

void f() {
  int b;
  asm("" : "=mp" (b));
  (void) 
}


Output:

$ xgcc -x c++ -S -Wall -
during RTL pass: reload
: In function 'void f()':
:5:1: internal compiler error: in lra_eliminate_reg_if_possible, at
lra-eliminations.c:1382
0x28cfae3 lra_eliminate_reg_if_possible(rtx_def**)
/home/vegard/git/gcc/gcc/lra-eliminations.c:1382
0x289671b address_eliminator
/home/vegard/git/gcc/gcc/lra-constraints.c:362
0x289671b satisfies_address_constraint_p
/home/vegard/git/gcc/gcc/lra-constraints.c:411
0x289671b satisfies_address_constraint_p
/home/vegard/git/gcc/gcc/lra-constraints.c:423
0x289671b process_alt_operands
/home/vegard/git/gcc/gcc/lra-constraints.c:2281
0x28a8be3 curr_insn_transform
/home/vegard/git/gcc/gcc/lra-constraints.c:3860
0x28bbf56 lra_constraints(bool)
/home/vegard/git/gcc/gcc/lra-constraints.c:4877
0x282c524 lra(_IO_FILE*)
/home/vegard/git/gcc/gcc/lra.c:2419
0x260b334 do_reload
/home/vegard/git/gcc/gcc/ira.c:5465
0x260b334 execute
/home/vegard/git/gcc/gcc/ira.c:5649

$ xgcc --version
xgcc (GCC) 8.0.1 20180301 (experimental)

Built from git c435a9e730c6e8f10da09d58b4fc9aaeb401b0d5 (r258097).

Seems to have been introduced between 6.3.0 and 7.1.0.

Test case was minimised by C-Reduce.

[Bug c++/84489] [6/7 Regression] Non-type template parameter dependency

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Fri Mar  2 16:55:49 2018
New Revision: 258144

URL: https://gcc.gnu.org/viewcvs?rev=258144=gcc=rev
Log:
PR c++/84489 - dependent default template argument

* pt.c (type_unification_real): Handle early substitution failure.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/fntmpdefarg7.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/pt.c

[Bug c++/83555] Unnecessary null check when static_cast is used with references.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Fixed for 8.1+.

[Bug c++/84678] New: ICE on invalid code with nested templates

[benni.buch at gmail dot com]

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

Bug ID: 84678
   Summary: ICE on invalid code with nested templates
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: benni.buch at gmail dot com
  Target Milestone: ---

This was previously part of the Bug 72752 comment 11.


template< typename >
struct Outer{
template< typename >
struct Inner;
};

template<>
template< typename _T_ >
class Outer< _T_ >::Inner< _T_ >{};

template struct Outer< int >::Inner< int >;


Known to fail on GCC 5, 6, 7 and 8.


$ g++ -c main.cpp 
main.cpp:9:21: internal compiler error: in retrieve_specialization, at
cp/pt.c:1191
 class Outer< _T_ >::Inner< _T_ >{};
 ^~~~
0x605f2d retrieve_specialization
../../gcc/gcc/cp/pt.c:1188
0x9480dd tsubst_template_decl
../../gcc/gcc/cp/pt.c:12761
0x94495f tsubst_decl
../../gcc/gcc/cp/pt.c:12917
0x93e96f tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:13809
0x9331ad most_specialized_partial_spec
../../gcc/gcc/cp/pt.c:22468
0x9567bf instantiate_class_template_1
../../gcc/gcc/cp/pt.c:10519
0x9567bf instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:11052
0x99e07d complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:136
0x956130 do_type_instantiation(tree_node*, tree_node*, int)
../../gcc/gcc/cp/pt.c:22733
0x9095cf cp_parser_explicit_instantiation
../../gcc/gcc/cp/parser.c:16549
0x90fff1 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12730
0x910341 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12654
0x910634 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4561
0x910634 c_parse_file()
../../gcc/gcc/cp/parser.c:38993
0xa0f096 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1132
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ g++ --version
g++ (GCC) 8.0.1 20180302 (experimental)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++-7 main.cpp 
main.cpp:9:21: internal compiler error: in retrieve_specialization, at
cp/pt.c:1185
 class Outer< _T_ >::Inner< _T_ >{};
 ^~~~
0x5d2616 retrieve_specialization
../../gcc/gcc/cp/pt.c:1182
0x5e75e0 tsubst_decl
../../gcc/gcc/cp/pt.c:12190
0x5daa0f tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:13432
0x5dfcaa most_specialized_partial_spec
../../gcc/gcc/cp/pt.c:21952
0x5f2ceb instantiate_class_template_1
../../gcc/gcc/cp/pt.c:10330
0x5f2ceb instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:10898
0x656c35 complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:133
0x5f459b do_type_instantiation(tree_node*, tree_node*, int)
../../gcc/gcc/cp/pt.c:9
0x64adbf cp_parser_explicit_instantiation
../../gcc/gcc/cp/parser.c:16229
0x62bb71 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12464
0x6518cb cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12388
0x651bb2 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4368
0x651bb2 c_parse_file()
../../gcc/gcc/cp/parser.c:38454
0x7225a3 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1107
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ g++-7 --version
g++-7 (GCC) 7.3.1 20180226
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++-6 main.cpp 
main.cpp:9:21: internal compiler error: in retrieve_specialization, at
cp/pt.c:1183
 class Outer< _T_ >::Inner< _T_ >{};
 ^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ g++-6 --version
g++-6 (Ubuntu/Linaro 6.3.0-18ubuntu2~16.04) 6.3.0 20170519
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++-5 main.cpp 
main.cpp:9:21: internal compiler error: in retrieve_specialization, at
cp/pt.c:1061
 class Outer< _T_ >::Inner< _T_ >{};
 ^
Please submit a full bug report,
with prep

[Bug target/84627] powerpc excess padding generated for POWER9 target

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #3 from Segher Boessenkool  ---
The nops are to align the following code (a jump target) to the correct
alignment.  GAS used an ori 2,2,0 for the last nop, to make sure a new
dispatch group starts after it, for p8.  Does your GAS support power9?
Does binutils trunk behave this way too?  Plain nop is ever so slightly
more efficient, so it is prefered.

The generated code is

std 2,24(1)
.p2align 5,,31
.L3:
mr 12,30
mtctr 30
addi 31,31,-1
bctrl

so there is nothing GCC can do about this.  Please follow up to binutils
bugzilla if necessary.  Thanks!

[Bug target/70359] [6/7/8 Regression] Code size increase for ARM compared to gcc-5.3.0

[law at redhat dot com]

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

--- Comment #27 from Jeffrey A. Law  ---
Yea, we went through similar issues with Alex's work recently.  After that work
landed I went through all the BZs that I could find with autoinc
{pre,post}{inc,dec} that BZ could find in the hopes that his work would fix
some of them.

Sadly there was only 1 that was fixed.


--

So one concern if you try to expose autoincrement addressing in gimple is that
the RTL optimizers aren't prepared to handle until combine or later.  So
there's probably a fair amount of downstream work to do.

rth and I sketched out a pass that replace optimize_related_values and autoinc
passes using the concepts of PRE and SLSR many years ago.  It felt much cleaner
that what we've been doing and likely more powerful.  But we never went forward
with an implementation.

I got the sense from that recent BZ review that we're generally missing a fair
number of opportunities, but didn't dig into all of them to gain an
understanding of why we're doing so bad.

[Bug inline-asm/84677] New: internal compiler error: in extract_constrain_insn, at recog.c:2205

[vegard.nossum at gmail dot com]

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

Bug ID: 84677
   Summary: internal compiler error: in extract_constrain_insn, at
recog.c:2205
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vegard.nossum at gmail dot com
  Target Milestone: ---

Input:

void a() {
  double b;
  asm ("" : "+pz, y" (b));
}


Output:

$ xgcc -x c++ -S -
: In function 'void a()':
:4:1: error: unrecognizable insn:
(insn 7 11 5 2 (parallel [
(set (reg:DF 0 ax [orig:87 b ] [87])
(asm_operands:DF ("") ("=pz, y") 0 [
(reg:DF 0 ax [orig:87 b ] [87])
]
 [
(asm_input:DF ("0,0") :3)
]
 [] :3))
(clobber (reg:CCFP 18 fpsr))
(clobber (reg:CC 17 flags))
]) "":3 -1
 (nil))
during RTL pass: reload
:4:1: internal compiler error: in extract_constrain_insn, at
recog.c:2205
0x610903 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/vegard/git/gcc/gcc/rtl-error.c:108
0x610991 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/vegard/git/gcc/gcc/rtl-error.c:116
0x2d17a96 extract_constrain_insn(rtx_insn*)
/home/vegard/git/gcc/gcc/recog.c:2205
0x282f53f check_rtl
/home/vegard/git/gcc/gcc/lra.c:2155
0x282f53f lra(_IO_FILE*)
/home/vegard/git/gcc/gcc/lra.c:2573
0x260b334 do_reload
/home/vegard/git/gcc/gcc/ira.c:5465
0x260b334 execute
/home/vegard/git/gcc/gcc/ira.c:5649

$ xgcc --version
xgcc (GCC) 8.0.1 20180301 (experimental)

Built from git c435a9e730c6e8f10da09d58b4fc9aaeb401b0d5 (r258097).

7.3.0 seems fine with this.

Test case was minimised by C-Reduce.

[Bug ipa/84628] attribute(warning/error) functions should not be merged together

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar  2 16:19:43 2018
New Revision: 258140

URL: https://gcc.gnu.org/viewcvs?rev=258140=gcc=rev
Log:
PR ipa/84628
* expr.c (expand_expr_real_1) : Don't emit diagnostics
for error or warning attributes if CALL_FROM_THUNK_P is set.
Formatting fixes.

* gcc.dg/pr84628.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr84628.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug target/56540] No __SIZEOF__XXX__ macro for __float128

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar  2 16:18:06 2018
New Revision: 258139

URL: https://gcc.gnu.org/viewcvs?rev=258139=gcc=rev
Log:
PR target/56540
* config/pa/pa.h (TARGET_CPU_CPP_BUILTINS): Predefine
__SIZEOF_128__ macro if HPUX_LONG_DOUBLE_LIBRARY.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/pa/pa.h

[Bug target/56540] No __SIZEOF__XXX__ macro for __float128

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar  2 16:17:18 2018
New Revision: 258138

URL: https://gcc.gnu.org/viewcvs?rev=258138=gcc=rev
Log:
PR target/56540
* config/ia64/ia64.h (TARGET_CPU_CPP_BUILTINS): Predefine
__SIZEOF_{FPREG,FLOAT{80,128}}__ macros.

* gcc.target/ia64/pr56540.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/ia64/pr56540.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/ia64/ia64.h
trunk/gcc/testsuite/ChangeLog

[Bug c++/84676] [6/7/8 Regression] internal compiler error: Segmentation fault (build_new_op_1)

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Started with r208426.

[Bug c++/84676] [6/7/8 Regression] internal compiler error: Segmentation fault (build_new_op_1)

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Untested fix:

--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -5591,6 +5591,10 @@ build_new_op_1 (location_t loc, enum tree_code code, int
flags, tree arg1,
   || error_operand_p (arg3))
 return error_mark_node;

+  if (TREE_TYPE (arg1) == NULL_TREE
+  || TREE_TYPE (arg2) == NULL_TREE)
+return error_mark_node;
+
   bool ismodop = code == MODIFY_EXPR;
   if (ismodop)
 {

[Bug c++/84676] [6/7/8 Regression] internal compiler error: Segmentation fault (build_new_op_1)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||error-recovery
   Priority|P3  |P4
   Target Milestone|--- |6.5
Summary|internal compiler error:|[6/7/8 Regression] internal
   |Segmentation fault  |compiler error:
   |(build_new_op_1)|Segmentation fault
   ||(build_new_op_1)