[Bug target/69896] [6 Regression] wrong code with -frename-registers @ x64_64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-22
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r230216.  But I agree it most likely just made a latent bug
reproduceable on this testcase.

[Bug target/69895] [5/6] dependency of gcc-plugin.h not installed on m68k-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Created attachment 37750
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37750&action=edit
gcc6-pr69895.patch

Untested fix.  Also included c6x and aarch64, because grep shows they have the
same problem.

[Bug target/69894] [6 Regression] dependency of gcc-plugin.h not installed on aarch64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Fix included in my PR69895 fix.

[Bug c++/69892] Missing -Wuninitialized warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Please see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69723#c7 , that seems
to be pretty much the same thing as here.

[Bug c++/69889] [6 Regression] ICE: in assign_temp, at function.c:961

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-22
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r232168.

[Bug c/69900] New: [6 Regression] Unhelpful diagnostic about Ignored options

[rguenth at gcc dot gnu.org]

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

Bug ID: 69900
   Summary: [6 Regression] Unhelpful diagnostic about Ignored
options
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

[  182s] ../grub-core/lib/pbkdf2.c:34:32: error: '-Wunreachable-code' is not an
option that controls warnings [-Werror=pragmas]
[  182s]  #pragma GCC diagnostic ignored "-Wunreachable-code"
[  182s] ^~~~
[  182s] cc1: all warnings being treated as errors

from

#pragma GCC diagnostic ignored "-Wunreachable-code"

I think CL_IGNORED flags should behave differently here.

[Bug bootstrap/69885] [6 Regression] ICE in maybe_legitimize_operand, at optabs.c:6903 on m68k-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug c/69900] [6 Regression] Unhelpful diagnostic about Ignored options

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug c++/69884] [6 Regression] warning: ignoring attributes on template argument

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-22
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

[Bug tree-optimization/69882] [6 regression] Excessive reduction statements generated by SLP

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/69876] Offloaded code: missing -Wuninitialized diagnostic

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-22
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Thus confirmed.

[Bug middle-end/69715] [4.9 regression] ICE: in store_bit_field_1, at expmed.c:839

[rguenther at suse dot de]

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

--- Comment #16 from rguenther at suse dot de  ---
On Mon, 22 Feb 2016, kip at thevertigo dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69715
> 
> --- Comment #15 from Kip Warner  ---
> Thank you for your hard work, Richard. It's very appreciated. I can't imagine
> what it would be like to debug GCC.
> 
> Which stable version of GCC should I look for that will be the newest to carry
> your fix? I'm guessing > 5.3 or 4.9.(>4)?

Yes, the next that will be released, thus 5.4 or 4.9.4.

[Bug target/69894] [6 Regression] dependency of gcc-plugin.h not installed on aarch64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug c++/69889] [6 Regression] ICE: in assign_temp, at function.c:961

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/69886] ICE: in process_insert_insn, at gcse.c:1976 with --param=gcse-unrestricted-cost=0 @ aarch64

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-22
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed on all branches.

[Bug rtl-optimization/69887] [4.9/5/6 Regression] gcc ICE at -O1 and above on x86_64-linux-gnu in mark_jump_label_1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug rtl-optimization/69887] [4.9/5/6 Regression] gcc ICE at -O1 and above on x86_64-linux-gnu in mark_jump_label_1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-22
  Known to work||4.3.6
   Target Milestone|--- |4.9.4
Summary|gcc ICE at -O1 and above on |[4.9/5/6 Regression] gcc
   |x86_64-linux-gnu in |ICE at -O1 and above on
   |mark_jump_label_1   |x86_64-linux-gnu in
   ||mark_jump_label_1
 Ever confirmed|0   |1
  Known to fail||4.7.4, 5.3.0

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[rguenth at gcc dot gnu.org]

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

--- Comment #63 from Richard Biener  ---
(In reply to Dominique d'Humieres from comment #59)
> > We already warn about mismatches sizes at LTO link time
> 
> Confirmed
> 
> [Book15] f90/bug% gfc -c -O2 pr69368_a.f90 -flto
> [Book15] f90/bug% gfc -O2 pr69368_a.o pr69368_b.f90 -flto
> pr69368_a.f90:3:0: warning: type of 'blk' does not match original
> declaration [-Wlto-type-mismatch]
>COMMON /BLK/ K(1)
>  
> pr69368_b.f90:3:0: note: 'blk' was previously declared here
>COMMON /BLK/ K(64)
>  
> pr69368_b.f90:3:0: note: code may be misoptimized unless
> -fno-strict-aliasing is used
> 
> and the executable gives the expected output. IMO the second note is bogus
> (pr68717).
> 
> If I replace
> 
>COMMON /BLK/ K(1)
> 
> with
> 
>COMMON /BLK/ K(2)
> 
> the executable gives the expected output also for all the compiling options
> I have tried.
> 
> AFAICT the code (invalid for any value of I and J)
> 
>   FUNCTION FOO(I, J)
>   COMMON /BLK/ K(1)
>   FOO = K(I) + K(J) + K(2*I) + K(2*J)
>   END FUNCTION
> 
> is optimized as
> 
>   FOO = K(I) + K(I) + K(I) + K(I)
> 
> Although I know that a compiler can do whatever it deems suitable with
> invalid code, I don't understand the rationale of the above "optimization":
> it is as invalid as the original code.

There is obviously no "rationale".  Fact is that we don't exploit the
undefinedness explicitely but just as a side-effect of how CSE works in
DOM now.  This means we don't propagate '1' as the only valid value of I
but just CSE the last three loads to the first as we know they are the
same (without knowing the actual value).

> Another thing I don't understand is that the following code is not
> "optimized" while as invalid as the one above:
> 
>   INTEGER FUNCTION FOO(I, J, K)
>   INTEGER K(1)
>   FOO = K(I) + K(J) + K(2*I) + K(2*J)
>   END FUNCTION
> 
>   INTEGER FOO
>   INTEGER K(64)
>   DO I=1,64
>   K(I)=I
>   END DO
>   IF (FOO(5,12,K).NE.51) CALL ABORT
>   END

Sth to do with K being passed as a pointer and thus K being treated as
a "flexible array" (we can't know whether the caller passed the address
of a last member of a struct).

[Bug middle-end/37448] cannot compile big function

[rguenth at gcc dot gnu.org]

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

--- Comment #54 from Richard Biener  ---
Author: rguenth
Date: Mon Feb 22 09:32:35 2016
New Revision: 233598

URL: https://gcc.gnu.org/viewcvs?rev=233598&root=gcc&view=rev
Log:
2016-02-22  Richard Biener  

PR ipa/37448
* ipa-inline-transform.c (inline_call): When not updating
overall summaries adjust self size by the growth estimate.
* ipa-inline.c (inline_to_all_callers_1): Add to the callers
hash-set, do not update overall summaries here.  Renamed from ...
(inline_to_all_callers): ... this which is now wrapping the
above and performing delayed overall summary update.
(early_inline_small_functions): Delay updating of the overall
summary.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline-transform.c
trunk/gcc/ipa-inline.c

[Bug middle-end/37448] cannot compile big function

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||6.0
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
  Known to fail||5.3.0

--- Comment #55 from Richard Biener  ---
Fixed for GCC 6.

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[rguenth at gcc dot gnu.org]

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

--- Comment #64 from Richard Biener  ---
(In reply to Dominique d'Humieres from comment #61)
> Another oddity of the "optimization" introduced by r232508 is the following
> test (borrowed from https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01356.html)
> 
> [Book15] f90/bug% cat pr69368_1_a.f90
>   SUBROUTINE FOO
>   IMPLICIT DOUBLE PRECISION (X)
>   INTEGER J
> !  COMMON /MYCOMMON / X(1031)
>   COMMON /MYCOMMON / X(1)
>   DO 10 J=1,1024
>  X(J+1)=X(J+7)
>   10  CONTINUE
>   RETURN
>   END
> [Book15] f90/bug% cat pr69368_1_b.f90
>   IMPLICIT DOUBLE PRECISION (X)
>   COMMON /MYCOMMON/ X(1031)
>   DO I=1,1031
>   X(I)=I
>   END DO
>   call FOO()
>   print *, X(1025)
>   IF (X(1025).NE.1031) CALL ABORT
>   END
> 
> The test fails if pr69368_1_a.f90 is compiled with -O2 (FOO is compiled as a
> simple RETURN). Now if I replace
> 
>   COMMON /MYCOMMON / X(1)
> 
> with
> 
>   COMMON /MYCOMMON / X(2)
> 
> I get at compile tile with -O2
> 
> pr69368_1_a_1.f90:7:0:
> 
>   X(J+1)=X(J+7)
>  
> Warning: iteration 1 invokes undefined behavior
> [-Waggressive-loop-optimizations]
> pr69368_1_a_1.f90:6:0:
> 
>DO 10 J=1,1024
>  
> note: within this loop
> 
> and the test succeeds. Any reason why there is no warning for "COMMON
> /MYCOMMON / X(1)"?

Because it's not a loop optimization that optimizes it.

> Also the following invalid code
> 
> [Book15] f90/bug% cat pr69368_1_c.f90
>   SUBROUTINE FOO(X)
>   IMPLICIT DOUBLE PRECISION (X)
>   INTEGER J
>   DIMENSION X(1)
>   DO 10 J=1,1024
>  X(J+1)=X(J+7)
>   10  CONTINUE
>   RETURN
>   END
> [Book15] f90/bug% cat pr69368_1_d.f90
>   IMPLICIT DOUBLE PRECISION (X)
>   DIMENSION X(1031)
>   DO I=1,1031
>   X(I)=I
>   END DO
>   call FOO(X)
>   print *, X(1025)
>   IF (X(1025).NE.1031.0) CALL ABORT
>   END
> 
> gives the expected result.

Well, undefined behavior doesn't guarantee a "not expected" result ;)

[Bug middle-end/47344] [4.9/5/6 Regression][meta-bug] GCC gets slower and uses more memory

[rguenth at gcc dot gnu.org]

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

Bug 37448 Summary: cannot compile big function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448

   What|Removed |Added

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

[Bug c++/69874] Program crashes when an exception is thrown to second base class reference

[maysam.kind at gmail dot com]

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

--- Comment #8 from maysam.kind at gmail dot com ---
(In reply to Markus Trippelsdorf from comment #7)
> Will do. But lets reopen this bug for the original issue.

Thanks for the prompt responses.
Is there anything that you require from me?
Can you share the glibc ticket number?
Thanks in advance

[Bug target/69888] ICE: SIGSEGV in decide_alg (i386.c:26169) due to infinite (?) recursion with -minline-all-stringops -mmemset-strategy=no_stringop:-1:noalign

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-02-22
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 37751
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37751&action=edit
gcc6-pr69888.patch

Untested fix.

[Bug c++/69874] Program crashes when an exception is thrown to second base class reference

[trippels at gcc dot gnu.org]

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

--- Comment #9 from Markus Trippelsdorf  ---
(In reply to maysam.kind from comment #8)
> (In reply to Markus Trippelsdorf from comment #7)
> > Will do. But lets reopen this bug for the original issue.
> 
> Thanks for the prompt responses.
> Is there anything that you require from me?
> Can you share the glibc ticket number?
> Thanks in advance

Sorry for the confusion. The glibc issue has nothing to do with this
bug. I just noticed it while looking at your issue.
https://sourceware.org/bugzilla/show_bug.cgi?id=19679

There is nothing more for you to do. The bug is already fixed in gcc-5 and
gcc-6.

[Bug tree-optimization/69224] [4.9/5/6 Regression] -Warray-bounds false positive with -O3 and struct pointer parameter

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|c   |tree-optimization
  Known to work||4.6.4, 4.7.3
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=68963
   Target Milestone|--- |4.9.4
Summary|-Warray-bounds false|[4.9/5/6 Regression]
   |positive with -O3 and   |-Warray-bounds false
   |struct pointer parameter|positive with -O3 and
   ||struct pointer parameter
  Known to fail||4.8.5, 6.0

--- Comment #2 from Richard Biener  ---
Possibly related to PR68963.

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[dominiq at lps dot ens.fr]

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

--- Comment #65 from Dominique d'Humieres  ---
> There is obviously no "rationale".  Fact is that we don't exploit the
> undefinedness explicitely but just as a side-effect of how CSE works in
> DOM now.  This means we don't propagate '1' as the only valid value of I
> but just CSE the last three loads to the first as we know they are the
> same (without knowing the actual value).

How can K(1) and K(2*1) be the same without using undefinedness explicitely?

[Bug c++/69901] New: Iniitializing non-const global array variable from runtime const global variable does not copy all values properly

[piotrwn1 at gmail dot com]

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

Bug ID: 69901
   Summary: Iniitializing non-const global array variable from
runtime const global variable does not copy all values
properly
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: piotrwn1 at gmail dot com
  Target Milestone: ---

We discovered this in our project working under gcc4.9.2 (-std=c++14) but it is
also present in gcc5.2 - whilst not present in clang.

The code below does not copy b1 to b2 properly:
  - b2[0].c.a is 0
  - b1.c.a

Making b1 compiler time constant (by making makeA() function constexpr) "fixes"
the problem:

#include 

struct A 
{
int a;
};

struct B
{
int b;
A c;
};

/*constexpr*/ //<-- contstexpr here "fixes" the problem
A makeA()   
{
A a = {2};
return a;
}

const B b1 = {1, makeA()};

B b2[] = { b1 };


int main()
{
std::cout << b2[0].c.a << std::endl; // 0 (should be 2)
std::cout << b1.c.a << std::endl;// 2
}

The link to coliru: http://coliru.stacked-crooked.com/a/4f1ef718fea4e76f

The original example was with std::vector and much more complicated structs. We
did an effort to simplify example. Simplifying more also "fixes" the problem.

BR,
Piotr Nycz (piotrwn1(at)gmail.com)

[Bug c++/69902] New: Bogus -Wnonnull-compare for: dynamic_cast(&ref) == nullptr

[sbergman at redhat dot com]

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

Bug ID: 69902
   Summary: Bogus -Wnonnull-compare for: dynamic_cast(&ref) ==
nullptr
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

With GCC built from trunk@233597:

> $ cat test.cc
> struct A { virtual ~A(); };
> struct B: A {};
> bool f(A & a) { return dynamic_cast(&a) == nullptr; }

> $ gcc/trunk/inst/bin/g++ -Werror -Wnonnull-compare test.cc
> test.cc: In function ‘bool f(A&)’:
> test.cc:3:46: error: nonnull argument ‘a’ compared to NULL 
> [-Werror=nonnull-compare]
>  bool f(A & a) { return dynamic_cast(&a) == nullptr; }
> ~~^~
> cc1plus: all warnings being treated as errors

(The warning goes away when changing "== nullptr" to "!= nullptr", or when
adding -fsyntax-only.)

[Bug fortran/66408] deferred-length character & overloaded assignment

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||baradi09 at gmail dot com

--- Comment #6 from Dominique d'Humieres  ---
*** Bug 63232 has been marked as a duplicate of this bug. ***

[Bug fortran/63232] Deferred length character field of derived type looses its value when used in subroutine call

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Dominique d'Humieres  ---
> Do we need to add the test to the gfortran tests?

I convinced myself that this PR is a duplicate of pr66408.

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

[Bug fortran/68241] [meta-bug] Deferred-length character

[dominiq at lps dot ens.fr]

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

Bug 63232 Summary: Deferred length character field of derived type looses its 
value when used in subroutine call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63232

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[jakub at gcc dot gnu.org]

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

--- Comment #66 from Jakub Jelinek  ---
(In reply to Dominique d'Humieres from comment #65)
> > There is obviously no "rationale".  Fact is that we don't exploit the
> > undefinedness explicitely but just as a side-effect of how CSE works in
> > DOM now.  This means we don't propagate '1' as the only valid value of I
> > but just CSE the last three loads to the first as we know they are the
> > same (without knowing the actual value).
> 
> How can K(1) and K(2*1) be the same without using undefinedness explicitely?

They can't, but why does that matter for undefined behavior?
The CSE code in DOM doesn't try to analyze the array indices at all, it is
enough for it to prove that in valid program they must be all same.
Whether the compiler could with additional efforts prove they are different or
not (it can't e.g. without LTO and without seeing caller that passes two
different variables).

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[dominiq at lps dot ens.fr]

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

--- Comment #67 from Dominique d'Humieres  ---
> > How can K(1) and K(2*1) be the same without using undefinedness explicitely?

> They can't, but why does that matter for undefined behavior?
> The CSE code in DOM doesn't try to analyze the array indices at all, it is
> enough for it to prove that in valid program they must be all same.

How can you "prove" that I and 2*I are the same in a valid program?

> Whether the compiler could with additional efforts prove they are different or
> not (it can't e.g. without LTO and without seeing caller that passes two
> different variables).

If you trust

  COMMON /BLK/ K(1)

then

   FOO = K(I) + K(J) + K(2*I) + K(2*J)

is invalid for any value of I and J: K(I) + K(J) is valid iff I=J=1, then
the access to K(2) is out of bound, hence invalid.

[Bug bootstrap/69885] [6 Regression] ICE in maybe_legitimize_operand, at optabs.c:6903 on m68k-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-02-22
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 37753
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37753&action=edit
gcc6-pr69885.patch

Bet this is related to my recent shift expansion changes (to handle invalid
shift counts).  The m68k backend is buggy, in expanders it really has to
specify mode of the operands.

[Bug bootstrap/69885] [6 Regression] ICE in maybe_legitimize_operand, at optabs.c:6903 on m68k-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4

--- Comment #2 from Jakub Jelinek  ---
The fix is untested (except for the testcase).

[Bug target/69888] ICE: SIGSEGV in decide_alg (i386.c:26169) due to infinite (?) recursion with -minline-all-stringops -mmemset-strategy=no_stringop:-1:noalign

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #1)

> Untested fix.
Looks OK, but please introduce a temporary variable, something like:

--cut here--
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index a1c87ab..6457293 100644   
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -26152,20 +26152,23 @@ decide_alg (HOST_WIDE_INT count, HOST_WIDE_INT
expected_size,
  || !alg_usable_p (algs->unknown_size, memset, have_as)))
 {
   enum stringop_alg alg;
+  HOST_WIDE_INT new_size;

-  /* If there aren't any usable algorithms, then recursing on
- smaller sizes isn't going to find anything.  Just return the
- simple byte-at-a-time copy loop.  */
-  if (!any_alg_usable_p)
+  if (max <= 0)
+   max = 4096;
+  /* If there aren't any usable algorithms or if recursing with the
+same arguments as before, then recursing on smaller sizes or
+same size isn't going to find anything.  Just return the simple
+byte-at-a-time copy loop.  */
+  new_size = max / 2;
+  if (!any_alg_usable_p || new_size == orig_expected_size)
 {
   /* Pick something reasonable.  */
   if (TARGET_INLINE_STRINGOPS_DYNAMICALLY)
 *dynamic_check = 128;
   return loop_1_byte;
 }
-  if (max <= 0)
-   max = 4096;
-  alg = decide_alg (count, max / 2, min_size, max_size, memset,
+  alg = decide_alg (count, new_size, min_size, max_size, memset,
zero_memset, have_as, dynamic_check, noalign);
   gcc_assert (*dynamic_check == -1);
   if (TARGET_INLINE_STRINGOPS_DYNAMICALLY)
--cut here--

[Bug tree-optimization/69882] [6 regression] Excessive reduction statements generated by SLP

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
The IL you refer to makes sense to me, the vectorizer sees

t.f90:13:0: note: Final SLP tree for instance:
t.f90:13:0: note: node
t.f90:13:0: note:   stmt 0 M.0_140 = MAX_EXPR <_139, c_I_lsm.10_129>;
t.f90:13:0: note:   stmt 1 M.0_143 = MAX_EXPR <_142, c_I_lsm.11_130>;
t.f90:13:0: note: node
t.f90:13:0: note:   stmt 0 _139 = *a_22(D)[_138];
t.f90:13:0: note:   stmt 1 _142 = *a_22(D)[_141];
t.f90:13:0: note: === vect_make_slp_decision ===
t.f90:13:0: note: Decided to SLP 1 instances. Unrolling factor 2

and thus it is a SLP reduction of two scalars.  Not sure how it became that,
the simple testcase became a whack-a-mole due to earlier opts.

  :
  # k_127 = PHI 
  # c_I_lsm.10_129 = PHI 
  # c_I_lsm.11_130 = PHI 
  _136 = (integer(kind=8)) k_127;
  _137 = _136 * 4;
  _138 = _137 + -4;
  _139 = *a_22(D)[_138];
  M.0_140 = MAX_EXPR ;
  _141 = _137 + -3;
  _142 = *a_22(D)[_141];
  M.0_143 = MAX_EXPR ;
  k_154 = k_127 + 1;
  if (k_127 == 26)
goto ;
  else
goto ;

  :
  # c_I_lsm.13_234 = PHI 
  # c_I_lsm.12_219 = PHI 
  # M.0_218 = PHI 
  # M.0_217 = PHI 
  goto ;

so we produce vectorized reductions for _218 and _217.

loop unswitching produces all those cases.  Simplifying the testcase to
a constant 'y' makes it still fail but very much easier to analyze.

[Bug tree-optimization/69882] [6 regression] Excessive reduction statements generated by SLP

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Created attachment 37752
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37752&action=edit
simplified testacse

[Bug target/69888] ICE: SIGSEGV in decide_alg (i386.c:26169) due to infinite (?) recursion with -minline-all-stringops -mmemset-strategy=no_stringop:-1:noalign

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #2)
> (In reply to Jakub Jelinek from comment #1)
> 
> > Untested fix.
> Looks OK, but please introduce a temporary variable, something like:
>
> +  HOST_WIDE_INT new_size;

HOST_WIDE_INT new_expected_size;

would be even better.

[Bug c++/69902] [6 Regression] Bogus -Wnonnull-compare for: dynamic_cast(&ref) == nullptr

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-22
 CC||trippels at gcc dot gnu.org
Summary|Bogus -Wnonnull-compare |[6 Regression] Bogus
   |for: dynamic_cast(&ref) |-Wnonnull-compare for:
   |== nullptr  |dynamic_cast(&ref) ==
   ||nullptr
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
More r233472 outfall. Confirmed.

[Bug tree-optimization/69882] [6 regression] Excessive reduction statements generated by SLP

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Ok, I think what goes wrong is

t.f90:13:0: note: Detected interleaving load *a_19(D)[_54] and *a_19(D)[_18]
t.f90:13:0: note: Detected interleaving load of size 4 starting with _55 =
*a_19(D)[_54];
t.f90:13:0: note: There is a gap of 2 elements after the group

but we end up loading 4 elements without handling the gap!

I have a patch  (that also makes vectorizing the testcase no longer
profitable).
w/o cost model we get

.L5:
vmovupd (%rcx), %xmm0
addl$1, %r9d
addq$64, %rcx
vmovupd -32(%rcx), %xmm1
vinsertf128 $0x1, -48(%rcx), %ymm0, %ymm0
vinsertf128 $0x1, -16(%rcx), %ymm1, %ymm1
cmpl%edx, %r9d
vinsertf128 $1, %xmm1, %ymm0, %ymm0
vmaxpd  %ymm0, %ymm2, %ymm2
jb  .L5

which indeed looks not too profitable to me.

[Bug target/69810] PowerPC64: unrecognizable insn

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
It also happens with 4.8, which does not have the EXTQI patch yet, and
not the WORD_REGISTER_OPERATIONS either.  It wasn't hidden, just no one
ever noticed :-)

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

[redi at gcc dot gnu.org]

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

--- Comment #18 from Jonathan Wakely  ---
(In reply to Bernd Edlinger from comment #13)
> (In reply to Jonathan Wakely from comment #12)
> > (In reply to Bernd Edlinger from comment #9)
> > > right now I am trying to boot-strap this:
> > > 
> > > Index: c/cstddef
> > > ===
> > > --- c/cstddef (revision 233581)
> > > +++ c/cstddef (working copy)
> > > @@ -31,10 +31,11 @@
> > >  
> > >  #pragma GCC system_header
> > >  
> > > -#define __need_size_t
> > > -#define __need_ptrdiff_t
> > > -#define __need_NULL
> > > -#define __need_offsetof
> > > +#undef __need_wchar_t
> > > +#undef __need_size_t
> > > +#undef __need_ptrdiff_t
> > > +#undef __need_NULL
> > > +#undef __need_wint_t
> > >  #include_next 
> > 
> > 
> > How do you plan to test this change? Do you have a target that uses this
> > header?
> > 
> 
> Yes, I do have such targets.
> We use eCos at Softing as real time O/S a lot.

Great, that's good to know.

> I think I will build an ecos cross compiler, did so last year with
> gcc-5.1, (and had quite a lot of trouble with the bugs in
> ecos headers)
> 
> ./gcc-5.1.0/configure --prefix=/home/ed/gnu/arm-eabi --target=arm-eabi
> --with-newlib --enable-languages=c,c++ --disable-hosted-libstdcxx
> --disable-__cxa-atexit --disable-libquadmath --disable-decimal-float
> 
> > 
> > >  #endif
> > > Index: c_global/cstddef
> > > ===
> > > --- c_global/cstddef  (revision 233581)
> > > +++ c_global/cstddef  (working copy)
> > > @@ -41,6 +41,11 @@
> > >  
> > >  #pragma GCC system_header
> > >  
> > > +#undef __need_wchar_t
> > > +#undef __need_size_t
> > > +#undef __need_ptrdiff_t
> > > +#undef __need_NULL
> > > +#undef __need_wint_t
> > >  #include 
> > >  #include 
> > 
> > This isn't incorrect, but it should not be necessary. This macros are
> > internal implementation details of the standard library headers, and user
> > code (like GMP) should not be defining those macros. If GMP wants size_t it
> > should include  and if it wants std::size_t it should include
> > , and it should not try to play silly games to only get part of the
> > header.
> > 
> > 
> 
> Yeah, shit happens.
> Anyway boot-strap & reg-testing OK on x86_64-pc-linux-gnu.
> gcc-4.9 builds successfully (minus Ada, see pr69883 :()

I'm in two minds whether we should fix that shit in the library or not.

> > > Index: c_std/cstddef
> > > ===
> > > --- c_std/cstddef (revision 233581)
> > > +++ c_std/cstddef (working copy)
> > > @@ -41,6 +41,11 @@
> > >  
> > >  #pragma GCC system_header
> > >  
> > > +#undef __need_wchar_t
> > > +#undef __need_size_t
> > > +#undef __need_ptrdiff_t
> > > +#undef __need_NULL
> > > +#undef __need_wint_t
> > >  #include 
> > >  #include 
> > 
> > How do you plan to test this?
> 
> no idea yet.
> under what condition is that header used?

For targets that choose to use it or with --enable-cheaders=c_std, but I don't
know of any targets where that is the default or needed, so don't know how to
test it. It is to be expected that you can't just use --enable-cheaders=c_std
on a target where that isn't usually used (and I'm not surprised if those
headers are also currently broken).


> Why does it only differ in the comment from the
> previous header?
> 
> why are the both files different?
> diff c_global/cstddef c_std/cstddef
> 26c26
> <  *  This is a Standard C++ Library file.  You should @c \#include this file
> ---
> >  *  This is a Standard C++ Library file.  You should @c #include this file
> 
> is this a mistake?


Maybe. It's only a comment, I'm not very concerned.

[Bug c/69900] [6 Regression] Unhelpful diagnostic about Ignored options

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-02-22
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 37754
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37754&action=edit
gcc6-pr69900.patch

We shouldn't lose the information that -Wunreachable-code used to be a warning
option.

[Bug target/69886] ICE: in process_insert_insn, at gcse.c:1976 with --param=gcse-unrestricted-cost=0 @ aarch64

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
The hoisting pass ends up creating:
(insn 88 0 0 (set (reg:OI 136)
(const_int 0 [0])) -1
 (nil))

which isn't valid on aarch64.
want_to_gcse_p should have rejected it via
can_assign_to_reg_without_clobbers_p.
But can_assign_to_reg_without_clobbers_p doesn't see the OImode so it only
tries to create a normal word_mode move of const_int 0 which it thinks is ok,
so it allows the instruction, which is bogus.

I have an idea for a simple fix.

[Bug tree-optimization/68963] [4.9/5/6 Regression] O3 vs. O2 discards part of loop and terminates early

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
static bool
idx_infer_loop_bounds (tree base, tree *idx, void *dta)
{
...
  /* If access is not executed on every iteration, we must ensure that overlow
may
 not make the access valid later.  */
  if (!dominated_by_p (CDI_DOMINATORS, loop->latch, gimple_bb (data->stmt))
  && scev_probably_wraps_p (initial_condition_in_loop_num (ev, loop->num),
step, data->stmt, loop, true))
reliable = false;

  record_nonwrapping_iv (loop, init, step, data->stmt, low, high, reliable,
upper);
  return true;


I think we simply cannot make a bound from a not always executing array ref
reliable, even if the IV doesn't wrap.  And of course the above fails to reset
'upper'.

Testing

Index: gcc/tree-ssa-loop-niter.c
===
--- gcc/tree-ssa-loop-niter.c   (revision 233598)
+++ gcc/tree-ssa-loop-niter.c   (working copy)
@@ -3183,14 +3183,18 @@ idx_infer_loop_bounds (tree base, tree *
   && tree_int_cst_compare (next, high) <= 0)
 return true;

-  /* If access is not executed on every iteration, we must ensure that overlow
may
- not make the access valid later.  */
-  if (!dominated_by_p (CDI_DOMINATORS, loop->latch, gimple_bb (data->stmt))
-  && scev_probably_wraps_p (initial_condition_in_loop_num (ev, loop->num),
-   step, data->stmt, loop, true))
+  /* If access is not executed on every iteration we cannot derive any
+ upper bound.  */
+  if (!dominated_by_p (CDI_DOMINATORS, loop->latch, gimple_bb (data->stmt)))
+upper = false;
+  /* If the IV of the access may wrap then the array size is not good for
+ an estimate either.  */
+  if (scev_probably_wraps_p (initial_condition_in_loop_num (ev, loop->num),
+step, data->stmt, loop, true))
 reliable = false;

-  record_nonwrapping_iv (loop, init, step, data->stmt, low, high, reliable,
upper);
+  record_nonwrapping_iv (loop, init, step, data->stmt, low, high,
+reliable, upper);
   return true;
 }

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

[bernd.edlinger at hotmail dot de]

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

--- Comment #19 from Bernd Edlinger  ---
(In reply to Jonathan Wakely from comment #18)
> > Yes, I do have such targets.
> > We use eCos at Softing as real time O/S a lot.
> 
> Great, that's good to know.
>
> > I think I will build an ecos cross compiler, did so last year with
> > gcc-5.1, (and had quite a lot of trouble with the bugs in
> > ecos headers)
> > 
> > ./gcc-5.1.0/configure --prefix=/home/ed/gnu/arm-eabi --target=arm-eabi
> > --with-newlib --enable-languages=c,c++ --disable-hosted-libstdcxx
> > --disable-__cxa-atexit --disable-libquadmath --disable-decimal-float
> > 

Actually when I look closely, it used c_global but w/o hosted-libstdcxx:

ed@w-ed:~/gnu/gcc-build-arm/arm-eabi/libstdc++-v3/include$ ls -ls cstddef
4 lrwxrwxrwx 1 ed ed 65 Feb 21 08:32 cstddef ->
/home/ed/gnu/gcc-6-20160214/libs

So at the moment I am not sure how to test the c/stddef.

But I am sure that #define __need_offsetof can simply not work.

I am not sure if it can compile at all, because if I try
there are the same bogus symlinks to missing c/-headers.

But before the build reaches the point where that matters,
the cstdlib simply includes  which fails to declare
std::abort.

Is this c/cstdlib intended for targets that have C++ aware stdlib.h?


> > > 
> > > >  #endif
> > > > Index: c_global/cstddef
> > > > ===
> > > > --- c_global/cstddef(revision 233581)
> > > > +++ c_global/cstddef(working copy)
> > > > @@ -41,6 +41,11 @@
> > > >  
> > > >  #pragma GCC system_header
> > > >  
> > > > +#undef __need_wchar_t
> > > > +#undef __need_size_t
> > > > +#undef __need_ptrdiff_t
> > > > +#undef __need_NULL
> > > > +#undef __need_wint_t
> > > >  #include 
> > > >  #include 
> > > 
> > > This isn't incorrect, but it should not be necessary. This macros are
> > > internal implementation details of the standard library headers, and user
> > > code (like GMP) should not be defining those macros. If GMP wants size_t 
> > > it
> > > should include  and if it wants std::size_t it should include
> > > , and it should not try to play silly games to only get part of 
> > > the
> > > header.
> > > 
> > > 
> > 
> > Yeah, shit happens.
> > Anyway boot-strap & reg-testing OK on x86_64-pc-linux-gnu.
> > gcc-4.9 builds successfully (minus Ada, see pr69883 :()
> 
> I'm in two minds whether we should fix that shit in the library or not.
> 

When we leave it as it is, everyone will point with the finger
on us, because it looks like a gcc-bug.

Alternative would be to detect that any of the 6 known
__need_-defines are present when invoking cstddef and
give an explicit #error, but this mis-use worked previously.
Or maybe a #warning would be a compromise?

What do you think?

> 
> For targets that choose to use it or with --enable-cheaders=c_std, but I
> don't know of any targets where that is the default or needed, so don't know
> how to test it. It is to be expected that you can't just use
> --enable-cheaders=c_std on a target where that isn't usually used (and I'm
> not surprised if those headers are also currently broken).
> 

What I tried yesterday, that's probably worth fixing too.


Bernd.

[Bug tree-optimization/69224] [4.9/5/6 Regression] -Warray-bounds false positive with -O3 and struct pointer parameter

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Ok, so we have

for (int j = 0; j < s->d - 1; j++) {
if ((c[i] >= s->x[j]) && (c[i] <= s->x[j + 1])) {
b[2*j][i] = s->x[j];
break;
}
}

and we can conclude j is in [0, 4] because of the c[i] >= s->x[j] check.
But we can _not_ conclude it is in [0, 3] because of the short-circuited
c[i] <= s->x[j+1] check.  So we're left with

 if (c[4] >= s->x[4])
  {
if (c[5] <= s->x[j + 1])
  {
 ...
  }
  }

in the last iteration.  The only issue is that we warn "is above array bounds"
rather than "may be" (well, if the access is executed then it _is_ above
array bounds, we never warn "maybe", all array-bound warnigns are "maybe"
in some way, unless in main() and always executable).

So I think we can't do anything here but not optimize (completely peel).

The issue is that usually VRP doesn't warn if it gets a range for the
access that is [0, 5] because its ranges are conservative and that would
result in way too many diagnostics.  Now the complete peeling makes the
ranges very precise (single element) and we get those false positive
warnings.

Fact is that at runtime unless s->d is "proper" (I guess it's 5) the
access may be out of bounds.

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

[redi at gcc dot gnu.org]

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

--- Comment #20 from Jonathan Wakely  ---
(In reply to Bernd Edlinger from comment #19)
> But I am sure that #define __need_offsetof can simply not work.

So don't define that. It's undefined behaviour.

> I am not sure if it can compile at all, because if I try
> there are the same bogus symlinks to missing c/-headers.
> 
> But before the build reaches the point where that matters,
> the cstdlib simply includes  which fails to declare
> std::abort.
> 
> Is this c/cstdlib intended for targets that have C++ aware stdlib.h?

Yes.

> When we leave it as it is, everyone will point with the finger
> on us, because it looks like a gcc-bug.
> 
> Alternative would be to detect that any of the 6 known
> __need_-defines are present when invoking cstddef and
> give an explicit #error, but this mis-use worked previously.
> Or maybe a #warning would be a compromise?
> 
> What do you think?

I think if we do anything then I prefer your original suggestion to just #undef
them.

But I'm not yet convinced we should do anything. This already failed with old
versions of GCC:

// get size_t
#define __need_size_t
#include 
// get everything else
#include 
std::max_align_t m;

[Bug target/51996] ICE in extract_insn gcc.dg/pr48335-5.c

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #3 from Ramana Radhakrishnan  ---
Fixed presumably in 4.9.0
The 4.8 branch is closed, I'm not sure if the commit ever went there.

[Bug target/47562] [meta-bug] keep track of Neon Intrinsics enhancements

[ramana at gcc dot gnu.org]

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

Bug 51980 Summary: ARM - Neon code polluted by useless stores to the stack with 
vuzpq / vzipq / vtrnq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51980

   What|Removed |Added

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

[Bug target/51980] ARM - Neon code polluted by useless stores to the stack with vuzpq / vzipq / vtrnq

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #15 from Ramana Radhakrishnan  ---
Presumed fixed in 4.9.0 by that commit.

[Bug c++/69902] [6 Regression] Bogus -Wnonnull-compare for: dynamic_cast(&ref) == nullptr

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |6.0

[Bug bootstrap/69885] [6 Regression] ICE in maybe_legitimize_operand, at optabs.c:6903 on m68k-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #3 from Matthias Klose  ---
this fixes the bootstrap, tested with a cross build.

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

[bernd.edlinger at hotmail dot de]

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

--- Comment #21 from Bernd Edlinger  ---
(In reply to Jonathan Wakely from comment #20)
> (In reply to Bernd Edlinger from comment #19)
> > But I am sure that #define __need_offsetof can simply not work.
> 
> So don't define that. It's undefined behaviour.
> 


hmmm...

I am not sure it I tried to ride on a dead horse here...

Maybe I should just leave the c/* and c_std/* headers as they are.
I should just leave the attachment here, if some one has use for
c_std/* headers.


> > I am not sure if it can compile at all, because if I try
> > there are the same bogus symlinks to missing c/-headers.
> > 
> > But before the build reaches the point where that matters,
> > the cstdlib simply includes  which fails to declare
> > std::abort.
> > 
> > Is this c/cstdlib intended for targets that have C++ aware stdlib.h?
> 
> Yes.
> 
> > When we leave it as it is, everyone will point with the finger
> > on us, because it looks like a gcc-bug.
> > 
> > Alternative would be to detect that any of the 6 known
> > __need_-defines are present when invoking cstddef and
> > give an explicit #error, but this mis-use worked previously.
> > Or maybe a #warning would be a compromise?
> > 
> > What do you think?
> 
> I think if we do anything then I prefer your original suggestion to just
> #undef them.
> 
> But I'm not yet convinced we should do anything. This already failed with
> old versions of GCC:
> 
> // get size_t
> #define __need_size_t
> #include 
> // get everything else
> #include 
> std::max_align_t m;

Yes, but I don't know how often I've boot-strapped gcc-4.9 already
and I never noticed anything of that undefined behaviour until now.

The problem is that header A can define __need_size_t, and include
the wrong system header file.  That leaks into header B
which includes  and now we get a cryptic error,
while previously we just did not have the std::max_align_t,
which is also bad, if you need it but if you don't need it,
you will never know.


BTW: we have a similar problem with cstdarg:

#define __need___va_list
#include 

fails to compile.

and c/cstdarg has:
#undef __need___va_list
#include_next 


I would like to add this to c_global/cstdarg:

 #pragma GCC system_header

+#ifdef __need___va_list
+#warning __need___va_list is not supported in cstdarg
+#undef __need___va_list
+#endif
 #include 
 #include 

that would be rather comfortable for the user.

[Bug target/69895] [5/6] dependency of gcc-plugin.h not installed on m68k-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #2 from Matthias Klose  ---
the patch installs the m68k files.

[Bug lto/51765] Testsuite ICEs with -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Loads of -flto ICEs left:

FAIL: g++.dg/cpp1y/var-templ16.C  -std=c++14 (internal compiler error)
FAIL: g++.dg/cpp1y/var-templ16.C  -std=c++14 (test for excess errors)
FAIL: g++.dg/cpp1y/var-templ27.C  -std=c++14 (internal compiler error)
FAIL: g++.dg/cpp1y/var-templ27.C  -std=c++14 (test for excess errors)
FAIL: g++.dg/ext/mvc1.C  -std=c++11 (internal compiler error)
FAIL: g++.dg/ext/mvc1.C  -std=c++11 (test for excess errors)
WARNING: g++.dg/ext/mvc1.C  -std=c++11 compilation failed to produce executable
FAIL: g++.dg/ext/mvc1.C  -std=c++14 (internal compiler error)
FAIL: g++.dg/ext/mvc1.C  -std=c++14 (test for excess errors)
WARNING: g++.dg/ext/mvc1.C  -std=c++14 compilation failed to produce executable
FAIL: g++.dg/ext/mvc1.C  -std=c++98 (internal compiler error)
FAIL: g++.dg/ext/mvc1.C  -std=c++98 (test for excess errors)

FAIL: g++.dg/lto/pr64076 cp_lto_pr64076_0.o-cp_lto_pr64076_1.o link, -O0 -flto
-
flto-partition=1to1 -fno-use-linker-plugin  (internal compiler error)
FAIL: g++.dg/lto/pr64076 cp_lto_pr64076_0.o-cp_lto_pr64076_1.o link, -O0 -flto
-
flto-partition=none -fuse-linker-plugin (internal compiler error)
FAIL: g++.dg/lto/pr64076 cp_lto_pr64076_0.o-cp_lto_pr64076_1.o link, -O0 -flto
-
fuse-linker-plugin -fno-fat-lto-objects  (internal compiler error)

FAIL: g++.old-deja/g++.ext/anon3.C  -std=c++11 (internal compiler error)
FAIL: g++.old-deja/g++.ext/anon3.C  -std=c++11 (test for excess errors)
FAIL: g++.old-deja/g++.ext/anon3.C  -std=c++14 (internal compiler error)
FAIL: g++.old-deja/g++.ext/anon3.C  -std=c++14 (test for excess errors)
FAIL: g++.old-deja/g++.ext/anon3.C  -std=c++98 (internal compiler error)
FAIL: g++.old-deja/g++.ext/anon3.C  -std=c++98 (test for excess errors)
FAIL: g++.old-deja/g++.mike/p5611.C  -std=c++11 (internal compiler error)
FAIL: g++.old-deja/g++.mike/p5611.C  -std=c++11 (test for excess errors)
WARNING: g++.old-deja/g++.mike/p5611.C  -std=c++11 compilation failed to
produce
 executable
FAIL: g++.old-deja/g++.mike/p5611.C  -std=c++14 (internal compiler error)
FAIL: g++.old-deja/g++.mike/p5611.C  -std=c++14 (test for excess errors)
WARNING: g++.old-deja/g++.mike/p5611.C  -std=c++14 compilation failed to
produce
 executable
FAIL: g++.old-deja/g++.mike/p5611.C  -std=c++98 (internal compiler error)
FAIL: g++.old-deja/g++.mike/p5611.C  -std=c++98 (test for excess errors)


FAIL: gcc.target/i386/mvc1.c (internal compiler error)
FAIL: gcc.target/i386/mvc1.c (test for excess errors)
WARNING: gcc.target/i386/mvc1.c compilation failed to produce executable
FAIL: gcc.target/i386/mvc3.c  (test for errors, line 4)
FAIL: gcc.target/i386/mvc4.c (internal compiler error)
FAIL: gcc.target/i386/mvc4.c (test for excess errors)


FAIL: gnat.dg/discr44.adb (internal compiler error)
FAIL: gnat.dg/discr44.adb 4 blank line(s) in output
FAIL: gnat.dg/specs/access2.ads (internal compiler error)
FAIL: gnat.dg/specs/access2.ads (test for excess errors)

AIL: go.test/test/chan/select5.go -O (internal compiler error)
FAIL: go.test/test/chan/select5.go -O (test for excess errors)
FAIL: go.test/test/chan/select5.go execution
FAIL: go.test/test/fixedbugs/bug206.go -O (internal compiler error)
FAIL: go.test/test/fixedbugs/bug206.go -O (test for excess errors)
FAIL: go.test/test/fixedbugs/bug206.go execution
FAIL: go.test/test/fixedbugs/bug392.dir/pkg2.go  -O (internal compiler error)
FAIL: go.test/test/fixedbugs/bug392.dir/pkg2.go  -O (test for excess errors)
FAIL: go.test/test/fixedbugs/bug392.dir/pkg3.go  -O (test for excess errors)
FAIL: go.test/test/fixedbugs/issue4932.dir/state2.go  -O (internal compiler
erro
r)
FAIL: go.test/test/fixedbugs/issue4932.dir/state2.go  -O (test for excess
errors
)
FAIL: go.test/test/fixedbugs/issue5291.dir/prog.go,  -O2 -g  (internal compiler 
error)
FAIL: go.test/test/fixedbugs/issue5910.dir/main.go  -O (internal compiler
error)
FAIL: go.test/test/fixedbugs/issue5910.dir/main.go  -O (test for excess errors)
FAIL: go.test/test/index0.go -O (internal compiler error)
FAIL: go.test/test/index0.go -O (test for excess errors)
FAIL: go.test/test/index0.go execution
FAIL: go.test/test/index1.go -O (internal compiler error)
FAIL: go.test/test/index1.go -O (test for excess errors)
FAIL: go.test/test/index1.go execution
FAIL: go.test/test/index2.go -O (internal compiler error)
FAIL: go.test/test/index2.go -O (test for excess errors)
FAIL: go.test/test/index2.go execution

FAIL: libgomp.c++/udr-13.C (internal compiler error)
FAIL: libgomp.c++/udr-13.C (test for excess errors)
WARNING: libgomp.c++/udr-13.C compilation failed to produce executable
FAIL: libgomp.c++/udr-3.C (internal compiler error)
FAIL: libgomp.c++/udr-3.C (test for excess errors)
WARNING: libgomp.c++/udr-3.C compilation failed to produce executable

[Bug lto/51765] Testsuite ICEs with -flto

[rguenth at gcc dot gnu.org]

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

Bug 52651 Summary: Fortran testsuite ICEs with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52651

   What|Removed |Added

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

[Bug fortran/52651] Fortran testsuite ICEs with -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Confirmed fixed.

[Bug target/54089] [SH] Refactor shift patterns

[olegendo at gcc dot gnu.org]

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

--- Comment #44 from Oleg Endo  ---
Author: olegendo
Date: Mon Feb 22 13:33:31 2016
New Revision: 233601

URL: https://gcc.gnu.org/viewcvs?rev=233601&root=gcc&view=rev
Log:
gcc/
PR target/69806
PR target/54089
* config/sh/sh.c (sh_lshrsi_clobbers_t_reg_p, sh_dynamicalize_shift_p):
Handle negative shift counts.
* config/sh/sh.md (ashlsi3, lshrsi3_n, lshrsi3_n_clobbers_t): Don't use
force_reg on the shift constant.
(lshrsi3): Likewise.  Expand into lshrsi3_n* instead of lshrsi3_d.
(lshrsi3_d): Handle negative shift counts.

gcc/testsuite/
PR target/69806
PR target/54089
* gcc.target/sh/pr54089-10.c: New.


Added:
trunk/gcc/testsuite/gcc.target/sh/pr54089-10.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.c
trunk/gcc/config/sh/sh.md
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/69806] [6 Regression][SH] Combine doesn't see constant

[olegendo at gcc dot gnu.org]

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

--- Comment #11 from Oleg Endo  ---
Author: olegendo
Date: Mon Feb 22 13:33:31 2016
New Revision: 233601

URL: https://gcc.gnu.org/viewcvs?rev=233601&root=gcc&view=rev
Log:
gcc/
PR target/69806
PR target/54089
* config/sh/sh.c (sh_lshrsi_clobbers_t_reg_p, sh_dynamicalize_shift_p):
Handle negative shift counts.
* config/sh/sh.md (ashlsi3, lshrsi3_n, lshrsi3_n_clobbers_t): Don't use
force_reg on the shift constant.
(lshrsi3): Likewise.  Expand into lshrsi3_n* instead of lshrsi3_d.
(lshrsi3_d): Handle negative shift counts.

gcc/testsuite/
PR target/69806
PR target/54089
* gcc.target/sh/pr54089-10.c: New.


Added:
trunk/gcc/testsuite/gcc.target/sh/pr54089-10.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.c
trunk/gcc/config/sh/sh.md
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/69896] [6 Regression] wrong code with -frename-registers @ x64_64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Yeah, in *.postreload we had:
(insn 250 28 30 2 (set (reg:TI 3 bx [235])
(mem/j/c:TI (plus:DI (reg/f:DI 7 sp)
(const_int 704 [0x2c0])) [1 v32u128_1+0 S16 A256]))
pr69896.c:13 84 {*movti_internal}
 (nil))
(insn 30 250 273 2 (set (reg:TI 40 r11 [orig:98 _15 ] [98])
(reg:TI 3 bx [235])) pr69896.c:13 84 {*movti_internal}
 (nil))
(note 273 30 31 2 NOTE_INSN_DELETED)
(insn 31 273 32 2 (set (reg:SI 3 bx [orig:99 _16 ] [99])
(reg:SI 40 r11 [orig:98 _15 ] [98])) pr69896.c:13 86 {*movsi_internal}
 (nil))
...
(insn 271 37 278 2 (set (mem/c:TI (plus:DI (reg/f:DI 7 sp)
(const_int 32 [0x20])) [6 %sfp+-352 S16 A128])
(reg:TI 40 r11 [orig:98 _15 ] [98])) pr69896.c:13 84 {*movti_internal}
 (nil))
(uses of reg:SI 3 bx [orig:99 _16 ] [99]) were removed during *.postreload).
Then in *.split2 we get:
(insn 279 28 280 2 (set (reg:DI 3 bx [235])
(mem/j/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 704 [0x2c0])) [1 v32u128_1+0 S8 A256])) pr69896.c:13
85 {*movdi_internal}
 (nil))
(insn 280 279 281 2 (set (reg:DI 4 si [+8 ])
(mem/j/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 712 [0x2c8])) [1 v32u128_1+8 S8 A64])) pr69896.c:13
85 {*movdi_internal}
 (nil))
(insn 281 280 282 2 (set (reg:DI 40 r11 [orig:98 _15 ] [98])
(reg:DI 3 bx [235])) pr69896.c:13 85 {*movdi_internal}
 (nil))
(insn 282 281 273 2 (set (reg:DI 41 r12 [ _15+8 ])
(reg:DI 4 si [+8 ])) pr69896.c:13 85 {*movdi_internal}
 (nil))
(note 273 282 31 2 NOTE_INSN_DELETED)
(insn 31 273 32 2 (set (reg:SI 3 bx [orig:99 _16 ] [99])
(reg:SI 40 r11 [orig:98 _15 ] [98])) pr69896.c:13 86 {*movsi_internal}
 (nil)) 
...
(insn 283 37 284 2 (set (mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 32 [0x20])) [6 %sfp+-352 S8 A128])
(reg:DI 40 r11 [orig:98 _15 ] [98])) pr69896.c:13 85 {*movdi_internal}
 (nil))
(insn 284 283 278 2 (set (mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 40 [0x28])) [6 %sfp+-344 S8 A64])
(reg:DI 41 r12 [ _15+8 ])) pr69896.c:13 85 {*movdi_internal}
 (nil))

I believe it is the *.pro_and_epilogue pass that makes the invalid
transformation:
 (insn 31 273 32 2 (set (reg:SI 3 bx [orig:99 _16 ] [99])
-(reg:SI 40 r11 [orig:98 _15 ] [98])) pr69896.c:13 86 {*movsi_internal}
+(reg:SI 3 bx [orig:98 _15 ] [98])) pr69896.c:13 86 {*movsi_internal}
  (nil))
is fine, but
 (insn 283 37 284 2 (set (mem/c:DI (plus:DI (reg/f:DI 7 sp)
 (const_int 32 [0x20])) [6 %sfp+-352 S8 A128])
-(reg:DI 40 r11 [orig:98 _15 ] [98])) pr69896.c:13 85 {*movdi_internal}
+(reg:DI 3 bx [orig:98 _15 ] [98])) pr69896.c:13 85 {*movdi_internal}
  (nil))
is wrong, unless insn 31 is removed or turned into DImode assignment instead of
SImode.
 (insn 284 283 278 2 (set (mem/c:DI (plus:DI (reg/f:DI 7 sp)
 (const_int 40 [0x28])) [6 %sfp+-344 S8 A64])
-(reg:DI 41 r12 [ _15+8 ])) pr69896.c:13 85 {*movdi_internal}
+(reg:DI 4 si [orig:41 _15+8 ] [41])) pr69896.c:13 85 {*movdi_internal}
  (nil))
 (note 278 284 251 2 NOTE_INSN_DELETED)
 (insn 251 278 38 2 (set (reg:SI 4 si [236])
-(reg:SI 40 r11 [orig:98 _15 ] [98])) pr69896.c:13 86 {*movsi_internal}
+(reg:SI 3 bx [orig:98 _15 ] [98])) pr69896.c:13 86 {*movsi_internal}
  (nil))
 (insn 38 251 39 2 (set (mem/c:SI (plus:DI (reg/f:DI 7 sp)
 (const_int 88 [0x58])) [3  S4 A64])
-(reg:SI 4 si [236])) pr69896.c:13 86 {*movsi_internal}
+(reg:SI 3 bx [236])) pr69896.c:13 86 {*movsi_internal}
  (nil))
are all fine.  -fno-shrink-wrapping indeed fixes this, as the invalid
transformation is not performed.

[Bug target/69810] PowerPC64: unrecognizable insn

[dje at gcc dot gnu.org]

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

--- Comment #6 from David Edelsohn  ---
The bug definitely predated the EXTQI change.  It was introduced when Red Hat
added the splitters for non-cr0 compares.

EXTQI is used for plain zero_extendqi2 and extendqi2. 
zero_extendqihi2 and extendqihi2 clearly are needed and make sense, so
restricting EXTQI is overkill.

I could change only the _dot and _dot2 patterns, but

andi. %0,%1,0xff

and

extsb. %0,%1

do properly represent zero_extendqihi2 / extendqihi2, and calculate the
implicit compare correctly.  The only problem is the splitter because the
compare pattern requires at least SImode.

The way it's currently written, the single instruction uses an HImode
temporary, but the two instruction sequence would need an SImode temporary,
which GCC cannot represent.

One solution is limit the dot patterns to SImode.  I don't know if there is a
way to handle the cmphi.

[Bug rtl-optimization/55190] ivopts causes loop setup bloat

[olegendo at gcc dot gnu.org]

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

--- Comment #9 from Oleg Endo  ---
As of r233601 the issue still persists.

[Bug bootstrap/69885] [6 Regression] ICE in maybe_legitimize_operand, at optabs.c:6903 on m68k-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Feb 22 14:22:07 2016
New Revision: 233603

URL: https://gcc.gnu.org/viewcvs?rev=233603&root=gcc&view=rev
Log:
PR target/69885
* config/m68k/m68k.md (ashldi3, ashrdi3, lshrdi3): Use
SImode for last match_operand.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr69885.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/m68k/m68k.md
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/69885] [6 Regression] ICE in maybe_legitimize_operand, at optabs.c:6903 on m68k-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/69810] PowerPC64: unrecognizable insn

[dje at gcc dot gnu.org]

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

--- Comment #7 from David Edelsohn  ---
Created attachment 37755
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37755&action=edit
extqihi patch

Because this idiom occurs so rarely (like never, except for an artificial
csmith testcase :-), the easiest solution that preserves the optimization seems
to be a patch that changes the splitter to a normal combiner pattern and emits
the extend and compare instructions as a single output template.  The operand
is correctly sign-extended to SImode, the "HImode" temporary holds an SImode
value, and the compare instruction can use the "HImode" value as input, but it
is difficult to represent this in a pattern.  So punt.

[Bug c++/69903] New: Function template specialization with CRTP-class causes compiler segfault

[tolstokor at gmail dot com]

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

Bug ID: 69903
   Summary: Function template specialization with CRTP-class
causes compiler segfault
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tolstokor at gmail dot com
  Target Milestone: ---

Created attachment 37756
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37756&action=edit
Preprocessed source file

The bug exists in versions from 4.8.1 to latest 5.3.0, including ARM and ARM64
compiler versions, with any compiler flags and optimization level. Platform
independent: most Linux distributives and MinGW (Windows) version crashes while
compiling this code:

// CRTP
template 
struct A {

  // Default behavior
  template 
  inline static void f() {
volatile int x = i;
  };

  inline static void F() {
T::template f<0>();
T::template f<1>();
T::template f<2>();
  }
};

struct B : A { /* empty */ };

// Specification for i == 2
template<>
void B::f<2>() {
  volatile int y = 777;
};

int main() {
  B::F();
}

Error messages like this:

/tmp/gcc-explorer-compiler116122-74-ozif0b/example.cpp: In instantiation of
'static void A::f() [with int i = 2; T = B]':
13 : required from 'static void A::F() [with T = B]'
26 : required from here
7 : internal compiler error: Segmentation fault
volatile int x = i;
^

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccmxbU4L.out file, please attach this to
your bugreport.
Compilation failed

[Bug tree-optimization/69882] [6 regression] Excessive reduction statements generated by SLP

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Mon Feb 22 14:53:17 2016
New Revision: 233605

URL: https://gcc.gnu.org/viewcvs?rev=233605&root=gcc&view=rev
Log:
2016-02-22  Richard Biener  

PR tree-optimization/69882
* tree-vect-slp.c (vect_attempt_slp_rearrange_stmts): Properly
preserve permutations present because of gaps.
(vect_supported_load_permutation_p): Always continue checking
permutations after vect_attempt_slp_rearrange_stmts.

* gfortran.dg/vect/pr69882.f90: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/vect/pr69882.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-slp.c

[Bug tree-optimization/69882] [6 regression] Excessive reduction statements generated by SLP

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/69760] [4.9/5/6 Regression] Wrong 64-bit memory address caused by an unneeded overflowing 32-bit integer multiplication on x86_64 under -O2 and -O3 code optimization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Investigating.

[Bug libstdc++/69893] [6 Regression] Conflicting declarations in and

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
The problem is in TR1, which parallel mode uses:

#include 
#include 

[Bug libstdc++/69893] [6 Regression] Conflicting declarations in and

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
And this already failed with GCC 5 and -std=c++11

#include 
using std::acosh;
#include 

[Bug c++/69903] Function template specialization with CRTP-class causes compiler segfault

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-22
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.8.5, 4.9.4, 5.3.1, 6.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed on 4.8 and upwards on arm, aarch64, x86
I don't have access to earlier versions, so cannot determine whether this is a
regression.

[Bug c++/69098] [5/6 regression] Member function pointer template flagged with 'is not a function template'

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Is this fixed now?

[Bug c++/69903] Function template specialization with CRTP-class causes compiler segfault

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
More complete stack trace:
ice.c:7:23: internal compiler error: in add_stmt, at cp/semantics.c:385
 volatile int x = i;
   ^
0x772687 add_stmt(tree_node*)
$TOP/gcc/cp/semantics.c:385
0x775891 finish_compound_stmt(tree_node*)
$TOP/gcc/cp/semantics.c:1412
0x640498 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
$TOP/gcc/cp/pt.c:15233
0x684609 instantiate_decl(tree_node*, int, bool)
$TOP/gcc/cp/pt.c:21945
0x68a9aa instantiate_pending_templates(int)
$TOP/gcc/cp/pt.c:22064
0x6cd75f c_parse_final_cleanups()
$TOP/gcc/cp/decl2.c:4599
0x879627 c_common_parse_file()
$TOP/gcc/c-family/c-opts.c:1091
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/69879] Create a pointer to the default operator new and delete

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-02-22
 Ever confirmed|0   |1

[Bug c++/69098] [5/6 regression] Member function pointer template flagged with 'is not a function template'

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #14 from Patrick Palka  ---
Oops yeah, fixed for GCC 6.

[Bug c++/69903] Function template specialization with CRTP-class causes compiler segfault

[tolstokor at gmail dot com]

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

--- Comment #3 from Alexander  ---
NOTE:
Functions' interior isn't important here, they can be empty, I used volatile
variables just to check assembler output.

[Bug c++/69903] Function template specialization with CRTP-class causes compiler segfault

[tolstokor at gmail dot com]

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

--- Comment #4 from Alexander  ---
About versions:
this code didn't crash until 4.7.3 version, I checked it with
http://gcc.godbolt.org/

[Bug rtl-optimization/69896] [6 Regression] wrong code with -frename-registers @ x64_64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 37757
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37757&action=edit
gcc6-pr69896.patch

Untested fix.  regcprop (which is invoked on the first bb by
prepare_shrink_wrap) ignores noop_p moves, which is fine if they are done in
the mode we remember for the register, but if it is narrower, it is wrong.
The patch removes them if DCE would remove them, and keeps around otherwise
(but in that case makes sure we actually update the mode etc.).

[Bug rtl-optimization/69904] New: [6 Regression] shrink-wrapping creates weird atomic compare exchange loop on arm

[ktkachov at gcc dot gnu.org]

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

Bug ID: 69904
   Summary: [6 Regression] shrink-wrapping creates weird atomic
compare exchange loop on arm
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
CC: segher at gcc dot gnu.org
  Target Milestone: ---
Target: arm

Consider the code:

#include 


atomic_uint foo;
atomic_uint bar;
int glob;


int main(void)
{
  glob = atomic_compare_exchange_strong (&foo, &bar, 0);
  return glob;
}

At -O2 -march=armv7-a GCC 5 generates:
main:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
movwr2, #:lower16:bar
movwr3, #:lower16:foo
movtr2, #:upper16:bar
movtr3, #:upper16:foo
mov r0, #0
str lr, [sp, #-4]!
ldr r1, [r2]
dmb sy
.L3:
ldrex   ip, [r3]
cmp ip, r1
bne .L4
strex   lr, r0, [r3]
cmp lr, #0
bne .L3
.L4:
movwr3, #:lower16:glob
moveq   r1, #1
movne   r1, r0
movtr3, #:upper16:glob
dmb sy
mov r0, r1
strne   ip, [r2]
str r1, [r3]
ldr pc, [sp], #4

GCC 6 generates:
main:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
movwr2, #:lower16:bar
movtr2, #:upper16:bar
movwr3, #:lower16:foo
mov r0, #0
ldr r1, [r2]
movtr3, #:upper16:foo
dmb ish
ldrex   ip, [r3]
cmp ip, r1
bne .L14
str lr, [sp, #-4]! // Stack push moved below barrier
.L8:
strex   lr, r0, [r3]
cmp lr, #0
bne .L3
.L4:
movwr3, #:lower16:glob
movtr3, #:upper16:glob
moveq   r1, #1
movne   r1, r0
dmb ish
mov r0, r1
strne   ip, [r2]
str r1, [r3]
ldr pc, [sp], #4  //pop stack and return
.L3:
ldrex   ip, [r3]
cmp ip, r1
beq .L8
b   .L4
.L14:
movwr3, #:lower16:glob
movtr3, #:upper16:glob
moveq   r1, #1
movne   r1, r0
dmb ish
mov r0, r1
strne   ip, [r2]
str r1, [r3]
bx  lr  // simple return


Notice how the stack push "str lr, [sp, #-4]!" got moved below the barrier "dmb
ish". It turns that this is not fatal from a correctness perspective because if
that push is executed after the load-exclusive has executed then in ARMv7-A it
may clear the exclusive monitor (according to the architecture it is
implementation defined whether it clears the exclusive monitor or not), causing
the store-exclusive after .L8 to fail, which will cause the control flow to
jump to .L3 and replay the load-exclusive/store-exclusive pair without the
intervening stack push. So it all sort of works out in the end, but is really
suboptimal and not the sequence one would expect for this code

This occurs during shrink-wrapping. -fno-shrink-wrap "fixes" this.

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

[bernd.edlinger at hotmail dot de]

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

--- Comment #22 from Bernd Edlinger  ---
yes, I would really have liked the warning, but...

/../gcc-trunk/gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc-trunk/gcc/../libbacktrace -I/home/ed/gnu/gcc-build/./isl/include
-I/home/ed/gnu/gcc-trunk/isl/include  -o c/c-lang.o -MT c/c-lang.o -MMD -MP -MF
c/.deps/c-lang.TPo ../../gcc-trunk/gcc/c/c-lang.c
In file included from /home/ed/gnu/gcc-build/./gmp/gmp.h:51:0,
 from ../../gcc-trunk/gcc/system.h:669,
 from ../../gcc-trunk/gcc/c/c-lang.c:22:
/home/ed/gnu/gcc-build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/cstddef:53:2:
error: #warning __need_size_t is not supported in cstddef [-Werror=cpp]
 #warning __need_size_t is not supported in cstddef
  ^~~
cc1plus: all warnings being treated as errors

...but it would force us to update all of gmp/mpfr/mpc immediately.

anyway that move is probably overdue now, but that should definitely
be on our gcc-7 to-do list.  Jakub?

BTW: From the gmp-6.1.0/ChangeLog I see:
2013-10-08  Marc Glisse  

* doc/mdate-sh, doc/texinfo.tex, install-sh, missing, ylwrap: Remove.
* .bootstrap: Use autoreconf (and in particular automake -a).

* gmp-h.in: Remove __need_size_t. Include , not .

* tests/mpf/reuse.c (main): Use small numbers as exponents.

[Bug target/69810] PowerPC64: unrecognizable insn

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |7.0

[Bug c++/69902] [6 Regression] Bogus -Wnonnull-compare for: dynamic_cast(&ref) == nullptr

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 37758
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37758&action=edit
gcc6-pr69902.patch

Untested fix.

[Bug c++/69842] [6 Regression] Parameter deduction in polymorphic lambdas

[carlphilippreh at gmail dot com]

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

Philipp  changed:

   What|Removed |Added

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

--- Comment #4 from Philipp  ---
Thank you for providing a fix for the test case so quickly. However, the issue
resurfaces in a slightly more involved example using a variadic lambda, which I
tested using gcc-6-20160221. Again, this code is accepted by gcc-5.3 and clang. 


#include 
#include 

template
void sink(T &&)
{
static_assert(std::is_same::value,"");
}

int main()
{
auto const g([](auto &&...  _var) {
sink(std::forward(_var)...);
});

g(0);
}

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Severity|normal  |major

--- Comment #68 from Thomas Koenig  ---
The problem here is that there is a large existing codebase
which depends on memory management which was

- illegal from the start

- the only game in town if you wanted to do any
  sort of dynamic memory management.

because FORTRAN 66 and 77 explicitly forbade any sort
of dynamic memory management. We can lament the fact
fifty years later, but we cannot change it.

The idea was to use

  COMMON /FOO/ A(1)

in a subroutine (even a library), and use

  COMMON /FOO/ A(1)

or whatever 'dynamic' size you needed for your memory
in the main program.

This idiom appears to be common enough that, if we
don't support it, or support it only with a severe
performance penalty, we will simply push people away from
gfortran.

[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #27 from Paolo Carlini  ---
Many thanks once more, David!

[Bug target/69841] Wrong template instantiation in C++11 on armv7l

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-22
 CC||jgreenhalgh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from James Greenhalgh  ---
Confirmed, I'm trying to figure out what is going wrong.

[Bug tree-optimization/33562] [4.9/5/6 Regression] aggregate DSE disabled

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P2  |P4

--- Comment #23 from Jeffrey A. Law  ---
Pushing this to a P4 given that the regression, while real, is very rare in
real world code.

A fix for the regression as well as further enhancements to DSE is queued for
gcc-7.

[Bug c++/69898] Possibility for function with cv-qualifier-seq be adjusted to function pointer

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
I would argue that the code should be ill-formed, because the attempt to form a
pointer to a function with cv-qualifier-seq is invalid, see

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1417

[Bug rtl-optimization/69887] [4.9/5/6 Regression] gcc ICE at -O1 and above on x86_64-linux-gnu in mark_jump_label_1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
void *a[6];

void
foo ()
{
  __builtin_setjmp (a);
  __builtin_longjmp (a, 1);
}

The problem is that pass_expand::execute in
  /* At the moment not all abnormal edges match the RTL
 representation.  It is safe to remove them here as
 find_many_sub_basic_blocks will rediscover them.
 In the future we should get this fixed properly.  */
  if ((e->flags & EDGE_ABNORMAL)
  && !(e->flags & EDGE_SIBCALL))
remove_edge (e);
  else
ei_next (&ei);
removes the abnormal edges, but find_many_sub_basic_blocks doesn't actually
recreate any corresponding edge from the REG_NON_LOCAL_GOTO JUMP_INSN (the
label is not marked as forced_label, just LABEL_PRESERVED_P), thus the cfg
cleanup at the end of expand pass attempts to remove the
__builtin_setjmp_receiver basic block as unreachable.  As the label is
LABEL_PRESERVED_P, it doesn't actually delete the label, just turns it into
NOTE_INSN_DELETED_LABEL, and there is some insn earlier (expanded from
__builtin_setjmp_setup) that references that deleted label through LABEL_REF.
Later on CSE determines that the REG_NON_LOCAL_GOTO JUMP_INSN can only jump to
the particular (deleted) label, and bumps its LABEL_NUSES (probably rtl
checking would ICE here, non-rtl checking just silently turns that
NOTE_INSN_DELETED_LABEL into NOTE_INSN_DELETED_DEBUG_LABEL.
Thus, a quick hack could be to tweak cse.c to follow mark_jump_label_1 and
don't touch LABEL_NUSES on deleted labels.  But, it still looks wrong to me,
we'd then attempt to jump into a middle of basic block.
So I bet we want to do something during find_many_sub_basic_blocks or elsewhere
during expansion, so that we keep the setjmp receiver basic block alive.

[Bug c++/69898] Possibility for function with cv-qualifier-seq be adjusted to function pointer

[wandersys at aim dot com]

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

--- Comment #2 from wander  ---
(In reply to Daniel Krügler from comment #1)
> I would argue that the code should be ill-formed, because the attempt to
> form a pointer to a function with cv-qualifier-seq is invalid, see
> 
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1417

I am talking about the same :)

[Bug target/69868] vec_perm built-in is not handled by swap optimization on powerpc64le

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from Bill Schmidt  ---
Created attachment 37759
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37759&action=edit
Tentative patch (needs refactoring)

Attaching a tested patch that solves the problem for this case without
regressing the test suite.  This patch is a bit rough and will need some
refactoring.  I'll upload another version when I get some more time to work on
this.  Patch will be queued up for next stage 1.

[Bug target/69895] [5/6] dependency of gcc-plugin.h not installed on m68k-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Feb 22 19:55:47 2016
New Revision: 233611

URL: https://gcc.gnu.org/viewcvs?rev=233611&root=gcc&view=rev
Log:
PR target/69894
PR target/69895
* config/m68k/t-opts (OPTIONS_H_EXTRA): Add m68k-microarchs.def
and m68k-devices.def.
* config/c6x/t-c6x (OPTIONS_H_EXTRA): Add c6x-isas.def.
* config/aarch64/t-aarch64 (OPTIONS_H_EXTRA): Add aarch64-arches.def.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/t-aarch64
trunk/gcc/config/c6x/t-c6x
trunk/gcc/config/m68k/t-opts

[Bug target/69894] [6 Regression] dependency of gcc-plugin.h not installed on aarch64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Mon Feb 22 19:55:47 2016
New Revision: 233611

URL: https://gcc.gnu.org/viewcvs?rev=233611&root=gcc&view=rev
Log:
PR target/69894
PR target/69895
* config/m68k/t-opts (OPTIONS_H_EXTRA): Add m68k-microarchs.def
and m68k-devices.def.
* config/c6x/t-c6x (OPTIONS_H_EXTRA): Add c6x-isas.def.
* config/aarch64/t-aarch64 (OPTIONS_H_EXTRA): Add aarch64-arches.def.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/t-aarch64
trunk/gcc/config/c6x/t-c6x
trunk/gcc/config/m68k/t-opts

[Bug target/69894] [6 Regression] dependency of gcc-plugin.h not installed on aarch64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/69895] [5/6 Regression] dependency of gcc-plugin.h not installed on m68k-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-22
   Target Milestone|--- |5.4
Summary|[5/6] dependency of |[5/6 Regression] dependency
   |gcc-plugin.h not installed  |of gcc-plugin.h not
   |on m68k-linux-gnu   |installed on m68k-linux-gnu
 Ever confirmed|0   |1

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

[Bug c++/69905] New: Digit separators break literal operators

[public at alisdairm dot net]

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

Bug ID: 69905
   Summary: Digit separators break literal operators
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: public at alisdairm dot net
  Target Milestone: ---

The following code fails to compile when the macro is defined:

#include 
using namespace std::literals;

#if defined SHOW_BUG
auto x = 1'23s
#else
auto x = 123s;
#endif

I /think/ this is a problem in the front-end, rather than the library, as the
digit separator should not be visible to the library call.