[Bug target/71670] powerpc64le ICE in extract_constrain_insn with -mcpu=power9

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Author: segher
Date: Tue Jun 28 05:56:41 2016
New Revision: 237813

URL: https://gcc.gnu.org/viewcvs?rev=237813=gcc=rev
Log:
rs6000: Fix split of ashdi3_extswsli_dot for memory (PR71670)

The splitter for ashdi3_extswsli_dot for cr0 with memory uses emit_insn
gen_ashdi3_extswsli_dot, which does not work because that emits a scratch,
while the splitter runs after reload so there should be a real register
instead.  We can laboriously fix that up, or emit using
gen_ashdi3_extswsli_dot2 instead.  This patch does the latter.


PR target/71670
* config/rs6000/rs6000.md (ashdi3_extswsli_dot): Use
gen_ashdi3_extswsli_dot2 instead of gen_ashdi3_extswsli_dot.

gcc/testsuite/
PR target/71670
* gcc.target/powerpc/pr71670.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr71670.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/71640] [7 Regression] include/c++/7.0.0/bits/hashtable.h:293:7: error: too many template parameters in template redeclaration

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
See: PR71679

[Bug c++/71679] New: gcc silently accepts parameter number mismatch in template redeclaration

[trippels at gcc dot gnu.org]

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

Bug ID: 71679
   Summary: gcc silently accepts parameter number mismatch in
template redeclaration
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

markus@x4 tmp % cat llvm.ii
namespace name {
template  struct A;
}
struct B {
  template  friend struct name::A;
};

markus@x4 tmp % icpc -c llvm.ii
llvm.ii(5): warning #549: too many template parameters -- does not match
previous declaration (declared at line 2)
template  friend struct name::A;
  ^
markus@x4 tmp % clang++ -c llvm.ii
llvm.ii:5:3: error: too many template parameters in template redeclaration
  template  friend struct name::A;
  ^~~
llvm.ii:2:1: note: previous template declaration is here
template  struct A;
^~
1 error generated.

markus@x4 tmp % g++ -Wall -Wextra -c llvm.ii
markus@x4 tmp %

[Bug libstdc++/71640] [7 Regression] include/c++/7.0.0/bits/hashtable.h:293:7: error: too many template parameters in template redeclaration

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #3 from Markus Trippelsdorf  ---
Ok. I will open a new bug for the accept invalid issue.

[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88

[saaadhu at gcc dot gnu.org]

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

--- Comment #14 from Senthil Kumar Selvaraj  ---
Filed https://sourceware.org/bugzilla/show_bug.cgi?id=20302 to have the linker
treat -T like all other options - i.e. consider the last occurrence of an
option rather than the first one.

[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers

[fortranbug at gmail dot com]

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

--- Comment #7 from fortranbug at gmail dot com ---
(In reply to fortranbug from comment #6)
> Thank you for the suggested workaround. This can certainly be helpful in the
> short term.  However, we would not want to rely on tuning compiler
> optimization switches in the future to ensure correct code operation.  (Our
> system is used by a community of users and it is not possible for us to
> ensure that they all use specific optimizations switches.)
> 
> Can someone clarify the status of this bug report?  Is this a recognized
> issue that will be addressed at some point?

Any thoughts on this?  I'm not sure what the process is for bug reports for
gfortran.  Should we expect a response as to whether this is accepted as a bug
report?

[Bug c++/71675] __atomic_compare_exchange_n returns wrong type for typed enum

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-28
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.3.0, 6.1.0, 7.0

--- Comment #1 from Martin Sebor  ---
Confirmed the same error with all versions of GCC that support the built-in and
class enums.  It seems as though the built-in's return type is actually /type/
(referring to the type pointed to by the first argument, the same as in
__atomic_load_n and  __atomic_exchange_n) rather than bool, and the function
returns the original value.  It feels like a documentation bug.

[Bug target/71656] ICE in reload when generating code for -mcpu=power9 -mpower9-dform-vector

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2016-06-28
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #4 from Peter Bergner  ---
Leaving as open until committed to the FS 6 branch.

[Bug target/71656] ICE in reload when generating code for -mcpu=power9 -mpower9-dform-vector

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #3 from Peter Bergner  ---
Fixed on trunk.  I'll let it burn in on trunk for a little while, before
backporting the fix to the FSF 6 branch.

[Bug target/71656] ICE in reload when generating code for -mcpu=power9 -mpower9-dform-vector

[bergner at gcc dot gnu.org]

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

--- Comment #2 from Peter Bergner  ---
Author: bergner
Date: Tue Jun 28 01:28:28 2016
New Revision: 237811

URL: https://gcc.gnu.org/viewcvs?rev=237811=gcc=rev
Log:
gcc/
PR target/71656
* config/rs6000/rs6000-cpus.def (ISA_3_0_MASKS_SERVER): Add
OPTION_MASK_P9_DFORM_VECTOR.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Do not
disable -mpower9-dform-vector when using reload.
(quad_address_p): Remove 'gpr_p' argument and all associated code.
New 'strict' argument.  Update all callers.  Add strict addressing
support.
(rs6000_legitimate_offset_address_p): Remove call to
virtual_stack_registers_memory_p.
(rs6000_legitimize_reload_address): Add quad address support.
(rs6000_legitimate_address_p): Move call to quad_address_p above
call to virtual_stack_registers_memory_p.  Adjust quad_address_p args
to account for new strict usage.
(rs6000_output_move_128bit): Adjust quad_address_p args to account
for new strict usage.
* config/rs6000/predicates.md (quad_memory_operand): Likewise.

gcc/testsuite/
PR target/71656
* gcc.target/powerpc/pr71656-1.c: New test.
* gcc.target/powerpc/pr71656-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr71656-1.c
trunk/gcc/testsuite/gcc.target/powerpc/pr71656-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/predicates.md
trunk/gcc/config/rs6000/rs6000-cpus.def
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug target/71670] powerpc64le ICE in extract_constrain_insn with -mcpu=power9

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Target|powerpc64le-linux   |powerpc*-*-*
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-06-27
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||6.1.1, 7.0

[Bug c/71567] Incorrect loop optimization

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #10 from Andrew Pinski  ---
-fsanitize=undefined can be used to find some of these.

This enables:

-fsanitize=bounds
This option enables instrumentation of array bounds. Various out of bounds
accesses are detected. Flexible array members, flexible array member-like
arrays, and initializers of variables with static storage are not instrumented. 

Note the last part of it too because without dummy, GCC considers the array as
"flexible array member-like arrays"

[Bug c/71567] Incorrect loop optimization

[tyoma.ariv at gmail dot com]

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

Artem  changed:

   What|Removed |Added

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

--- Comment #9 from Artem  ---
The described behaviour of optimizer seems to be very dengerous because it is
hard to indicate such kind of errors (it cannot be indicated during
compilation, cppcheck does not report such kind of errors, such errors could
not be reproduced in debug mode and could exist alive in silent mode for
years).
Is it possible to report such kind of errors during compilation? Looks like
such kind of errors could be indicated during compilation or static code
anlisys.

[Bug other/71627] AVR error: unable to find a register to spill in class 'POINTER_X_REGS'

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target|AVR |avr
 Status|UNCONFIRMED |NEW
Version|4.9.2   |6.1.1
   Keywords||ice-on-invalid-code, ra
   Last reconfirmed||2016-06-27
  Component|c   |other
   Host|Linux Debian GNU/Linux  |
 Blocks||56183
 Ever confirmed|0   |1
  Build|AVR |


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183
[Bug 56183] [meta-bug][avr] Problems with register allocation

[Bug c/71627] AVR error: unable to find a register to spill in class 'POINTER_X_REGS'

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||gjl at gcc dot gnu.org

--- Comment #2 from Georg-Johann Lay  ---
Created attachment 38779
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38779=edit
ice.c: preprocessed C source

Confirmed for 4.9.2, 5.2 and 6.1.

Also confirmed for the following test case (no need for headers) with
-mmcu=atmega128 -O1:

extern volatile __memx const long  a, b, c, d, e, f;
extern volatile long result;

extern void vfunc (const char*, ...);

void foo (void)
{
   result = a + b + c + d + e + f;
   vfunc ("text", a, b, c, d, e, f, result);
}

[Bug fortran/70673] [5/6/7 Regression] ICE with module containing functions with allocatable character scalars

[pault at gcc dot gnu.org]

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

--- Comment #8 from Paul Thomas  ---
Author: pault
Date: Mon Jun 27 20:57:13 2016
New Revision: 237805

URL: https://gcc.gnu.org/viewcvs?rev=237805=gcc=rev
Log:
2016-06-27  Paul Thomas  

PR fortran/70673
* frontend-passes.c (realloc_string_callback): Add a call to
gfc_dep_compare_expr.

2016-06-27  Paul Thomas  

PR fortran/70673
* gfortran.dg/pr70673.f90: New test.

Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/70673] [5/6/7 Regression] ICE with module containing functions with allocatable character scalars

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas  ---
Author: pault
Date: Mon Jun 27 20:54:56 2016
New Revision: 237804

URL: https://gcc.gnu.org/viewcvs?rev=237804=gcc=rev
Log:
2016-06-27  Paul Thomas  

PR fortran/70673
* frontend-passes.c (realloc_string_callback): Add a call to
gfc_dep_compare_expr.

2016-06-27  Paul Thomas  

PR fortran/70673
* gfortran.dg/pr70673.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr70673.f90
Modified:
branches/gcc-5-branch/gcc/fortran/frontend-passes.c

[Bug libstdc++/71640] [7 Regression] include/c++/7.0.0/bits/hashtable.h:293:7: error: too many template parameters in template redeclaration

[fdumont at gcc dot gnu.org]

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

--- Comment #2 from François Dumont  ---
Author: fdumont
Date: Mon Jun 27 20:41:59 2016
New Revision: 237803

URL: https://gcc.gnu.org/viewcvs?rev=237803=gcc=rev
Log:
2016-06-27  François Dumont  

PR libstdc++/71640
* include/bits/hashtable.h: Remove _Unique_keya parameter in _Insert
friend declaration.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/hashtable.h

[Bug target/71678] New: [avr] ICE from switch / case on long long (casesi + DImode)

[gjl at gcc dot gnu.org]

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

Bug ID: 71678
   Summary: [avr] ICE from switch / case on long long  (casesi +
DImode)
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---
Target: avr

Created attachment 38778
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38778=edit
ice-casesi.c: C test case

$ avr-gcc -mmcu=atmega128 ice-casesi.c -Os -S -fno-tree-switch-conversion

unsigned char foo (long long x) 
{
unsigned char y = 0;
switch (x)
{
case 0: y = 67; break;
case 1: y = 20; break;
case 2: y = 109; break;
case 3: y = 33; break;
case 4: y = 44; break;
case 5: y = 37; break;
case 6: y = 10; break;
case 7: y = 11; break;
}
return y;
}

will throw an ICE:

ice-casesi.c: In function 'foo':
ice-casesi.c:16:1: error: unrecognizable insn:
 }
 ^
(insn 55 54 56 4 (parallel [
(set (reg:HI 47)
(minus:HI (subreg:HI (subreg:SI (reg:DI 44) 0) 0)
(reg:HI 45)))
(clobber (scratch:QI))
]) ice-casesi.c:4 -1
 (nil))
ice-casesi.c:16:1: internal compiler error: in extract_insn, at recog.c:2287

ice-casesi.c:16:1: internal compiler error: Segmentation fault


Problem is the casesi expander and its explicit SUBREG.  Here casesi from
current trunk, but the define_expand looks the same sice r31935:


(define_expand "casesi"
  [(parallel [(set (match_dup 6)
   (minus:HI (subreg:HI (match_operand:SI 0 "register_operand"
"") 0)
 (match_operand:HI 1 "register_operand" "")))
  (clobber (scratch:QI))])
   ...


I used avr-gcc 5.2.1 but affected are all versions of avr-gcc (maybe with a
slightly different test case with more cases or so).

[Bug target/71677] PowerPC ISA 3.0 DImode load/store needs a fix

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Created attachment 38777
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38777=edit
-save-temps file that generates the wrong input with -O3 -mcpu=power9

[Bug target/71677] New: PowerPC ISA 3.0 DImode load/store needs a fix

[meissner at gcc dot gnu.org]

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

Bug ID: 71677
   Summary: PowerPC ISA 3.0 DImode load/store needs a fix
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

If you build the Spec 2006 xalancbmk benchmark for ISA 3.0 (power9), it fails
building the XalanNamespacesStack.cpp file.  The problem is indexed addressing
also matches the %Y constraint as well as the %Z constraint, and it puts out
the lxsd instruction instead of the lxsdx instruction.  The ISA 3.0 store
alternatives have the same problem.

[Bug fortran/70673] [5/6/7 Regression] ICE with module containing functions with allocatable character scalars

[pault at gcc dot gnu.org]

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

--- Comment #6 from Paul Thomas  ---
Author: pault
Date: Mon Jun 27 19:18:21 2016
New Revision: 237802

URL: https://gcc.gnu.org/viewcvs?rev=237802=gcc=rev
Log:
2016-06-27  Paul Thomas  

PR fortran/70673
* frontend-passes.c (realloc_string_callback): Add a call to
gfc_dep_compare_expr.

2016-06-27  Paul Thomas  

PR fortran/70673
* gfortran.dg/pr70673.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr70673.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/frontend-passes.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result

[ch3root at openwall dot com]

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

--- Comment #19 from Alexander Cherepanov  ---
(In reply to jos...@codesourcery.com from comment #3)
> Except within a larger object, I'm not aware of any reason the cases of 
> two objects following or not following each other in memory must be 
> mutually exclusive.

Apparently some folks use linker scripts to get a specific arrangement of
objects.

A fresh example is a problem in Linux -- https://lkml.org/lkml/2016/6/25/77 . A
simplified example from http://pastebin.com/4Qc6pUAA :

extern int __start[];
extern int __end[];

extern void bar(int *);

void foo()
{
for (int *x = __start; x != __end; ++x)
bar(x);
}

This is optimized into an infinite loop by gcc 7 at -O.

[Bug c++/71639] [5.2.0] c++11 list initializer and std::transform - error?

[FBergemann at web dot de]

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

Frank Bergemann  changed:

   What|Removed |Added

 CC||FBergemann at web dot de

--- Comment #6 from Frank Bergemann  ---
Sorry, my fault!
You can set this RESOLVED INVALID.
It's about iterator invalidation because of capacity change.

best regards,
Frank

[Bug target/71676] New: [avr] casesi won't handle switch values larger than 16 bits

[gjl at gcc dot gnu.org]

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

Bug ID: 71676
   Summary: [avr] casesi won't handle switch values larger than 16
bits
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---
Target: avr

Created attachment 38776
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38776=edit
bug-casesi.c: C test case

This is a funny wrong code bug that is present since the avr backend has been
added to GCC in r31935.  casesi reads

https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/avr/avr.md?view=markup=31935#l1760

(define_expand "casesi"
  [(parallel [(set (match_dup 6)
   (minus:HI (subreg:HI (match_operand:SI 0 "register_operand"
"") 0)
 (match_operand:HI 1 "register_operand" "")))
  (clobber (scratch:QI))])
   (parallel [(set (cc0)
   (compare (match_dup 6)
(match_operand:HI 2 "register_operand" "")))
  (clobber (match_scratch:QI 9 ""))])
   ...

which means that switch / case won't handle large values correctly provided
casesi is used.

The following code shows the problem.  Compile with

$ avr-gcc -mmcu=atmega128 bug-casesi.c -save-temps -dp -Os

volatile unsigned char y;

__attribute__((noinline,noclone))
unsigned char foo (unsigned long x) 
{
switch (x)
{
case 0: y = 67; break;
case 1: y = 20; break;
case 2: y = 109; break;
case 3: y = 33; break;
case 4: y = 44; break;
case 5: y = 37; break;
case 6: y = 10; break;
case 7: y = 98; break;
}
return y;
}

int main (void)
{
if (0 != foo (7L + 0x1L))
__builtin_abort();
return 0;
}


As casesi takes HImode SUBREG of x, only the lower 16 bits of x (R22 and R23)
are used to determine whether the switch has to be entered or not.  avr-gcc-5.2
generates:

foo:
cpi r22,8;  9   *cmphi/6
cpc r23,__zero_reg__
brsh .L2 ;  10  branch
movw r30,r22 ;  91  *movhi/1
subi r30,lo8(-(gs(.L4))) ;  11  *addhi3/2
sbci r31,hi8(-(gs(.L4)))
jmp __tablejump2__   ;  12  *tablejump/3

Hence 0x10007 will be treated the same way as 0x7.

[Bug rtl-optimization/71673] [7 Regression] FAIL: c-c++-common/torture/builtin-arith-overflow-p-19.c -O2 (internal compiler error)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|arm, sparc  |arm*-*, sparc*-*,
   ||aarch64*-*

--- Comment #4 from Andrew Pinski  ---
Also been failing on aarch64 lately too; I was going to file a bug report today
until I saw this one.

[Bug c/71613] Useful warnings silenced when macros from system headers are used

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com  ---
Rather than piecemeal fixes with no evidence of completeness, I think we 
should disable the smarts around system header macro locations determining 
whether diagnostics appear (i.e., the system-header tests for disabling 
diagnostics should all use the expansion location), until we have a proper 
design for avoiding such issues and have systematically reviewed all 
diagnostics for conforming to such a design (if the design needs each 
diagnostic function call to be reviewed).

[Bug c/71613] Useful warnings silenced when macros from system headers are used

[ch3root at openwall dot com]

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

--- Comment #5 from Alexander Cherepanov  ---
This bug also affects -pedantic-errors, i.e. it's not merely a cosmetic 
bug but also a conformance issue. I don't know how -std=c11 can ignore 
constraint violations but -pedantic-errors is supposed to fix it.

BTW gcc extension "non-int enum constants" is not documented?

[Bug c++/71675] New: __atomic_compare_exchange_n returns wrong type for typed enum

[js at alien8 dot de]

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

Bug ID: 71675
   Summary: __atomic_compare_exchange_n returns wrong type for
typed enum
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: js at alien8 dot de
  Target Milestone: ---

Consider the following code:

enum class foo : unsigned char {
FOO, BAR
};

foo v;

bool bar(foo old_v, foo new_v)
{
return __atomic_compare_exchange_n(, _v, new_v, true,
   __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST);
}

This fails to compile with 

% g++ -std=c++14 -c problem.cpp
reader.cpp: In function ‘bool bar(foo, foo)’:
reader.cpp:10:99: error: cannot convert ‘foo’ to ‘bool’ in return
 return __atomic_compare_exchange_n(, _v, new_v, true,
__ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST);

According to the manual __atomic_compare_exchange_n returns a bool, so this
error is bogus. The expected behavior is for __atomic_compare_exchange_n to
return a bool in the first place.

Manually casting the result of __atomic_compare_exchange_n to bool generates
the expected result.

The issue appears with gcc 5.3.1 20160406 (Red Hat 5.3.1-6) on Fedora 23 x86_64
and also with gcc 6.1 (tested using https://gcc.godbolt.org/)

[Bug middle-end/36550] Wrong "may be used uninitialized" warning (conditional PHIs)

[manu at gcc dot gnu.org]

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

--- Comment #14 from Manuel López-Ibáñez  ---
Predicate analysis is not able to figure out this case because it cannot see
that the default def is also conditional on cond1_8(D) != 0, thus warn_15 is
never warn_5(D)(13). 

(The callgraph is also a bit of a mess).

This case seems easier to fix, but still would need someone to figure out how
to evaluate and combine the predicates for default defs.


[WORKLIST]: add to initial list: warn_15 = PHI 
[CHECK]: examining phi: warn_15 = PHI 

[CHECK] Found def edge 1 in warn_15 = PHI 
[BEFORE SIMPLICATION -- [USE]:
warn_16 = PHI 
is guarded by :

cond2_4(D) != 0


[BEFORE NORMALIZATION --[USE]:
warn_16 = PHI 
is guarded by :

cond2_4(D) != 0


[AFTER NORMALIZATION -- [USE]:
warn_16 = PHI 
is guarded by :

cond2_4(D) != 0

[BEFORE SIMPLICATION -- [DEF]:
warn_15 = PHI 
is guarded by :

cond2_4(D) != 0 (.AND.) cond1_8(D) != 0


[BEFORE NORMALIZATION --[DEF]:
warn_15 = PHI 
is guarded by :

cond2_4(D) != 0 (.AND.) cond1_8(D) != 0


[AFTER NORMALIZATION -- [DEF]:
warn_15 = PHI 
is guarded by :

cond1_8(D) != 0 (.AND.) cond2_4(D) != 0


[CHECK]: Found unguarded use: warn_16 = PHI 
[WORKLIST]: Update worklist with phi: warn_16 = PHI 
[CHECK]: examining phi: warn_16 = PHI 
[CHECK]: Found unguarded use: a = warn_16;

[Bug c++/41437] No access control for classes in template functions

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #9 from Martin Sebor  ---
I'm not sure the original test case and the one in comment #8 are the same bug.
 The former doesn't seem to have ever been rejected, while the latter used to
until r231354 when it became accepted.

r231354 | jason | 2015-12-06 23:35:14 -0500 (Sun, 06 Dec 2015) | 4 lines

Fix parse/no-type-defn1.C with -std=c++1z.

* parser.c (struct tentative_firewall): New.
(cp_parser_template_id, cp_parser_decltype_expr): Use it.

I'm also not sure bug 45775 referenced in comment #3 is a duplicate of this
one.  I haven't been able to find a GCC revision that accepts the test case
there.

Finally, bug 40843 was fixed by r190830 which was committed to resolve bug
50545 and bug 51222, so it also doesn't seem to be a duplicate of this one.

[Bug target/71655] [7 Regression] GCC trunk ICE on westmere target

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|GCC trunk ICE on westmere   |[7 Regression] GCC trunk
   |target  |ICE on westmere target

[Bug tree-optimization/71488] [6 Regression] Wrong code for vector comparisons with ivybridge and westmere targets

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
Summary|[6/7 Regression] Wrong code |[6 Regression] Wrong code
   |for vector comparisons with |for vector comparisons with
   |ivybridge and westmere  |ivybridge and westmere
   |targets |targets

--- Comment #14 from Jakub Jelinek  ---
Caused PR71655.

[Bug c++/71658] User-defined conversion operator from a wrapper class to the wrapped type does not compile.

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
I believe the test case is invalid.

In a call to an operator, operator overload resolution in [over.match.oper]
considers three sets of candidate functions:
1) member candidates (operators defined as members one of the operands)
2) non-member candidates (only non-member functions are considered)
3) built-in candidates (operators that take types to which the operands can be
converted)

In the test case, sets (1) and (2) are obviously empty.  Set (3) is also empty
because there is no well-formed implicit conversion sequence ([over.best.ics])
from Z1 to int (the conversion exists but would require two user-defined
conversions, one from Z1 to Z and another from Z to int; such conversions are
not well-formed).

Like GCC, both Clang 3.8 and EDG eccp 3.11 also reject the program.

The expression "Z(x0)+Z(x1)" is valid because the types of the operands are Z
and thus do not require the second implicit user-defined conversion that makes
set (3) above empty.

[Bug target/71655] GCC trunk ICE on westmere target

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-06-27
 CC||ienkovich at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ienkovich at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Ilya Enkovich  ---
Confirm.  Caused by r237706.

[Bug c++/71350] [4.8/4.9/5/6/7 regression] ICE on trailing return type declaration with initializer list

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
Summary|internal compiler error on  |[4.8/4.9/5/6/7 regression]
   |trailing return type|ICE on trailing return type
   |declaration with|declaration with
   |initializer list|initializer list

--- Comment #2 from Martin Sebor  ---
The likely root cause is r184876:

r184876 | jason | 2012-03-03 19:55:44 -0500 (Sat, 03 Mar 2012) | 5 lines

Core 1270
* call.c (build_aggr_conv): Call reshape_init.
(convert_like_real): Likewise.
* typeck2.c (process_init_constructor): Clear TREE_CONSTANT if
not all constant.

[Bug c++/71664] valid C++11 code with qualified enumerator lookup rejected

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-27
 CC||msebor at gcc dot gnu.org
 Blocks||12944
 Ever confirmed|0   |1
  Known to fail||4.6.4, 4.8.5, 4.9.3, 5.3.0,
   ||6.1.0, 7.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  Both Clang 3.8 and EDG eccp 4.11 successfully compile the program.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12944
[Bug 12944] [meta-bug] C++ name-lookup problems

[Bug middle-end/36550] Wrong "may be used uninitialized" warning (conditional PHIs)

[rootkit85 at yahoo dot it]

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

rootkit85 at yahoo dot it  changed:

   What|Removed |Added

 CC||rootkit85 at yahoo dot it

--- Comment #13 from rootkit85 at yahoo dot it  ---
can it be the same as this bug I'm experimenting?

/*/
/*
 * compile with:
 * gcc -Wall -Werror -Os -c test.c -o test.o
 */

int a;
int b;

void warn_func(int cond1, int cond2)
{
int warn;

if (cond2)
warn = a;

if (cond1)
b = 1;

if (cond2)
a = warn;
}
/*/

I can reproduceit only with -Os, and it makes libgo compilation fail because of
this:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgo/runtime/mprof.goc#l403

[Bug libstdc++/71660] [5/6/7 regression] alignment of std::atomic<8 byte primitive type> (long long, double) is wrong on x86

[thiago at kde dot org]

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

--- Comment #3 from Thiago Macieira  ---
(In reply to Jakub Jelinek from comment #1)
> Foir double-word compare and exchange you need double-word alignment, so I
> think the current alignment is correct.

The instruction manual says that CMPXCHG16B requires 128-bit alignment, but
doesn't say the same for CMPXCHG8B. It says that the AC(0) alignment check
fault could happen if it's not aligned, but doesn't say what the required
alignment is.

[Bug rtl-optimization/71673] [7 Regression] FAIL: c-c++-common/torture/builtin-arith-overflow-p-19.c -O2 (internal compiler error)

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #3 from Christophe Lyon  ---
For the record, the test fails at -O0 too, as well as on aarch64 targets.

[Bug middle-end/69526] ivopts candidate strangeness

[rdapp at linux dot vnet.ibm.com]

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

--- Comment #24 from rdapp at linux dot vnet.ibm.com ---
Created attachment 38775
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38775=edit
Updated patch and test, match.pd/VRP

(In reply to amker from comment #23)
> Hmm, not sure if I mis-understood your point.
> I think there is no *overflow* concept for a VR_RANGE (or a variable),
> overflow is always a semantic concept for an (arithmetic) operation.  Take
> below loop as an example:
> 
> unsigned int i;
> for (i = 4; i != 2; i += 2)
>   {
> //
>   }
> 
> Variable i has VR_RANGE [0, MAX_VALUE - 1], but it does overflow in the loop.

Yes, a variable by itself cannot overflow, only an operation can. VRP for
example has a function extract_range_from_binary_expr_1 that performs some
overflow checking internally. It does so by comparing the minima and maxima of
the respective ranges from both operands. I assumed an overflow there would
somehow be propagated into the ranges, hence the question how to access the
cast expression in match.pd.

Guess I was thinking too complicated, getting the range of both operands and
checking if their common minimum is smaller than the maximum should suffice for
now.

Attached is the current version of the patch, no regressions on s390x and
x86-64. The test could be made a bit more specific I suppose, currently it
counts the number of "gimple_simplified"s.

[Bug libstdc++/71660] [5/6/7 regression] alignment of std::atomic<8 byte primitive type> (long long, double) is wrong on x86

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-27
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
However alignof(std::atomic) != alignof(_Atomic long long) for
x86-32, which is wrong, since that was the point of PR65147.

#ifdef __cplusplus
#include 
using std::atomic_llong;
#else
#include 
#include 
#endif

#include 

struct InStruct { long long x; };
struct AtomicStruct { int i; atomic_llong x; };

int main()
{
  printf("%zu %zu %zu %zu\n",
  alignof(struct InStruct),
  alignof(atomic_llong),
  sizeof(struct AtomicStruct),
  alignof(struct AtomicStruct));
}

With GCC this prints 4 4 12 4 but with G++ it prints 4 8 16 8

We might need a front-end attribute so std::atomic can emulate what the C
front-end does with _Atomic.

[Bug ada/71674] New: An exception is thrown on a valid code

[porton at narod dot ru]

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

Bug ID: 71674
   Summary: An exception is thrown on a valid code
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: porton at narod dot ru
  Target Milestone: ---

The following valid code throws an exception:

--  test_count.adb start
with Ada.Strings.Fixed, Ada.Integer_Text_IO;
use  Ada.Strings.Fixed, Ada.Integer_Text_IO;

procedure Test_Count is
   S : constant String (Positive'Last - 2 .. Positive'Last) := "Ada";
begin
   Put (Count (Source =>S, Pattern =>"AA"));
   Put (Count (Source =>S (S'First .. S'Last - 1), Pattern =>"A"));
   Put (Count (Source =>S, Pattern =>"A"));
end;
--  test_count.adb end

Here is the program run:

$ ./test_count 
  0  1

raised STORAGE_ERROR : stack overflow or erroneous memory access


I mark severity minor, because this error is unlikely to appear in a real code.

When fixing this bug, attention should be taken not to make new code much
slower than the existing code.

[Bug rtl-optimization/71673] [7 Regression] FAIL: c-c++-common/torture/builtin-arith-overflow-p-19.c -O2 (internal compiler error)

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|arm |arm, sparc
 CC||ro at gcc dot gnu.org

--- Comment #2 from Rainer Orth  ---
The patch works on Solaris/SPARC, which is also affected.

Thanks.
  Rainer

[Bug rtl-optimization/71673] [7 Regression] FAIL: c-c++-common/torture/builtin-arith-overflow-p-19.c -O2 (internal compiler error)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 38774
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38774=edit
gcc7-pr71673.patch

Untested fix.

[Bug middle-end/71626] [4.9/5/6/7 regression] ICE at -O1 and above on x86_64-linux-gnu (in output_constant_pool_2, at varasm.c:3837)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 38773
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38773=edit
gcc7-pr71626.patch

Untested fix.

[Bug c++/71671] g++: internal compiler error: Killed (program cc1plus)

[trippels at gcc dot gnu.org]

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

--- Comment #9 from Markus Trippelsdorf  ---
Well, we need to full gcc invocation of:
   CXX  graph_blockmodel.lo

So please run "make VERBOSE=1" and post the full gcc command line and 
the preprocessed testcase.
All other output is useless.

[Bug middle-end/71626] [4.9/5/6/7 regression] ICE at -O1 and above on x86_64-linux-gnu (in output_constant_pool_2, at varasm.c:3837)

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
One possibility would be to allow SUBREG of constant for the V1XXmode vectors
like:
--- gcc/varasm.c.jj 2016-06-10 20:24:03.0 +0200
+++ gcc/varasm.c2016-06-27 11:43:25.330955071 +0200
@@ -3834,6 +3834,17 @@ output_constant_pool_2 (machine_mode mod
 machine_mode submode = GET_MODE_INNER (mode);
unsigned int subalign = MIN (align, GET_MODE_BITSIZE (submode));

+   /* For V1??mode, allow SUBREGs.  */
+   if (GET_CODE (x) == SUBREG
+   && GET_MODE_NUNITS (mode) == 1
+   && GET_MODE_BITSIZE (submode) == GET_MODE_BITSIZE (mode)
+   && SUBREG_BYTE (x) == 0
+   && GET_MODE (SUBREG_REG (x)) == submode)
+ {
+   output_constant_pool_2 (submode, SUBREG_REG (x), align);
+   break;
+ }
+
gcc_assert (GET_CODE (x) == CONST_VECTOR);
units = CONST_VECTOR_NUNITS (x);

Without -fpic the result looks good, but with -fpic it forces something that
needs relocations into .rodata.cst.* constants, which I think is bad.  Though,
can't find right now where we normally avoid pushing relocatable stuff through
force_const_mem...

Another option is to do something in the i386 vector move expansion.

[Bug c++/71671] g++: internal compiler error: Killed (program cc1plus)

[shopping_vineeshvs at outlook dot com]

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

vineeshvs  changed:

   What|Removed |Added

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

--- Comment #8 from vineeshvs  ---
(In reply to Markus Trippelsdorf from comment #6)
> Just run make with VERBOSE=1, then look for the line where
> graph_blockmodel.lo
> gets compiled, add --save-temps to the compiler invocation and attach the 
> (compressed) *.ii file.

'make' will take some time to finish. Meanwhile please check the results of the
previous 'make' without any arguments. I have attached it with name ' Results
of 'make' command in terminal (without any other arguments)'

[Bug c++/71671] g++: internal compiler error: Killed (program cc1plus)

[shopping_vineeshvs at outlook dot com]

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

--- Comment #7 from vineeshvs  ---
Created attachment 38772
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38772=edit
Results of 'make' command in terminal (without any other arguments)

[Bug rtl-optimization/71673] [7 Regression] FAIL: c-c++-common/torture/builtin-arith-overflow-p-19.c -O2 (internal compiler error)

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |7.0
  Known to fail||7.0

[Bug rtl-optimization/71673] New: [7 Regression] FAIL: c-c++-common/torture/builtin-arith-overflow-p-19.c -O2 (internal compiler error)

[ktkachov at gcc dot gnu.org]

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

Bug ID: 71673
   Summary: [7 Regression] FAIL:
c-c++-common/torture/builtin-arith-overflow-p-19.c -O2
 (internal compiler error)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
Target: arm

The new test introduced with r237754 ICEs on arm targets:
FAIL: c-c++-common/torture/builtin-arith-overflow-p-19.c   -O2  (internal
compiler error)
FAIL: c-c++-common/torture/builtin-arith-overflow-p-19.c   -O2  (test for
excess errors)
FAIL: c-c++-common/torture/builtin-arith-overflow-p-19.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  (internal compiler error)
FAIL: c-c++-common/torture/builtin-arith-overflow-p-19.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  (test for excess errors)
FAIL: c-c++-common/torture/builtin-arith-overflow-p-19.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  (internal compiler error)
FAIL: c-c++-common/torture/builtin-arith-overflow-p-19.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  (test for excess errors)

The backtrace is:
$SRC/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-p-19.c: In
function 't100_1add':
$SRC/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow.h:97:7: internal
compiler error: Segmentation fault
$SRC/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-p-19.c:32:1:
note: in expansion of macro 'TP'
$SRC/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-p-19.c:63:1:
note: in expansion of macro 'TESTS'
0xb24ce0 crash_signal
$SRC/gcc/toplev.c:335
0xabea37 commutative_operand_precedence(rtx_def*)
$SRC/gcc/rtlanal.c:3367
0xabeb58 swap_commutative_operands_p(rtx_def*, rtx_def*)
$SRC/gcc/rtlanal.c:3437
0x78baf4 do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int,
machine_mode, rtx_def*, rtx_code_label*, rtx_code_label*, int)
$SRC/gcc/dojump.c:988
0x927065 expand_arith_overflow_result_store
$SRC/gcc/internal-fn.c:468
0x92cb83 expand_arith_overflow
$SRC/gcc/internal-fn.c:1812
0x92cf05 expand_ADD_OVERFLOW
$SRC/gcc/internal-fn.c:1920
0x928170 expand_internal_call(internal_fn, gcall*)
$SRC/gcc/internal-fn.c:2396
0x92819e expand_internal_call(gcall*)
$SRC/gcc/internal-fn.c:2404
0x713765 expand_call_stmt
$SRC/gcc/cfgexpand.c:2573
0x713765 expand_gimple_stmt_1
$SRC/gcc/cfgexpand.c:3574
0x713765 expand_gimple_stmt
$SRC/gcc/cfgexpand.c:3740
0x717424 expand_gimple_basic_block
$SRC/gcc/cfgexpand.c:5747
0x71aaee execute
$SRC/gcc/cfgexpand.c:6362
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/71671] g++: internal compiler error: Killed (program cc1plus)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #6 from Markus Trippelsdorf  ---
Just run make with VERBOSE=1, then look for the line where graph_blockmodel.lo
gets compiled, add --save-temps to the compiler invocation and attach the 
(compressed) *.ii file.

[Bug debug/71667] [7 Regression] ICE in as_a, at is-a.h:192 w/ -g -O2 -ftree-vectorize

[alahay01 at gcc dot gnu.org]

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

alahay01 at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug debug/71667] [7 Regression] ICE in as_a, at is-a.h:192 w/ -g -O2 -ftree-vectorize

[alahay01 at gcc dot gnu.org]

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

alahay01 at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from alahay01 at gcc dot gnu.org ---
"-g" is the important thing here.

A statement has been marked live, and a use of it outside the loop is a DEBUG
stmt.

vectorizable_live_operation fails trying to treat the DEBUG stmt as a phi.

[Bug c++/71671] g++: internal compiler error: Killed (program cc1plus)

[shopping_vineeshvs at outlook dot com]

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

--- Comment #5 from vineeshvs  ---
(In reply to Markus Trippelsdorf from comment #4)
> > RAM: 3.7 GiB
> 
> Well, you probably just need more RAM. 
> Look for OOM killer messages in your system log.
> 
> And please attach the preprocessed graph_blockmodel.ii file.
> (See https://gcc.gnu.org/bugs/)

Hi,

Thanks for the suggestions.

I was also trying the suggestions given in the link
https://bitcointalk.org/index.php?topic=304389.0 where they suggest to increase
the swap memory size using the following set of commands (before doing 'make')

dd if=/dev/zero of=/var/swap.img bs=1024k count=1000
mkswap /var/swap.img
swapon /var/swap.img

It worked. I have successfully installed Python Graph tool.

Don't know if it was the correct workaround. Any suggestions.

Now that I have installed it, how do I get the preprocessed graph_blockmodel.ii
?

https://gcc.gnu.org/bugs/ suggests that I need to do the 'make' again with
'-save-temps added to the complete compilation command'

Not sure if I can reproduce the error. Any suggestions?

Thanks for the quick responses.

[Bug tree-optimization/71661] [7 Regression] wrong code at -O3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Started with r236831.

[Bug c++/71662] [4.9/5/6/7 Regression] ICE on invalid C++11 code with unqualified name look up: in tsubst_copy, at cp/pt.c:14010

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-27
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |4.9.4
Summary|ICE on invalid C++11 code   |[4.9/5/6/7 Regression] ICE
   |with unqualified name look  |on invalid C++11 code with
   |up: in tsubst_copy, at  |unqualified name look up:
   |cp/pt.c:14010   |in tsubst_copy, at
   ||cp/pt.c:14010
 Ever confirmed|0   |1

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

[Bug c++/71665] [4.9/5/6/7 Regression] ICE on invalid C++ code with non-integral constant enumerator value: in cxx_eval_constant_expression, at cp/constexpr.c:3918

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-27
 CC||jakub at gcc dot gnu.org,
   ||paolo at gcc dot gnu.org
   Target Milestone|--- |4.9.4
Summary|ICE on invalid C++ code |[4.9/5/6/7 Regression] ICE
   |with non-integral constant  |on invalid C++ code with
   |enumerator value: in|non-integral constant
   |cxx_eval_constant_expressio |enumerator value: in
   |n, at cp/constexpr.c:3918   |cxx_eval_constant_expressio
   ||n, at cp/constexpr.c:3918
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
With -std=c++1y started already with r205449, otherwise started when -std=c++14
became the default.

[Bug debug/71667] [7 Regression] ICE in as_a, at is-a.h:192 w/ -g -O2 -ftree-vectorize

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Started with r237064.

[Bug libstdc++/71660] [5/6/7 regression] alignment of std::atomic<8 byte primitive type> (long long, double) is wrong on x86

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Foir double-word compare and exchange you need double-word alignment, so I
think the current alignment is correct.

[Bug c++/71671] g++: internal compiler error: Killed (program cc1plus)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-06-27
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Markus Trippelsdorf  ---
> RAM: 3.7 GiB

Well, you probably just need more RAM. 
Look for OOM killer messages in your system log.

And please attach the preprocessed graph_blockmodel.ii file.
(See https://gcc.gnu.org/bugs/)

[Bug gcov-profile/71672] New: inlining indirect calls does not work with autofdo

[andi-gcc at firstfloor dot org]

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

Bug ID: 71672
   Summary: inlining indirect calls does not work with autofdo
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andi-gcc at firstfloor dot org
  Target Milestone: ---

The current mainline version of autofdo doesn't inline indirect calls based on
profiling data.

I instrumented a bootstrap and it never triggers.

gcc.dg/tree-prof/indir-call-prof.c

also fails (needs the patch kit in
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01786.html applied first). 

I did some debugging and it seems to give up in update_inlined_ind_target()
here

 772   /* Program behavior changed, original promoted (and inlined) target is
not
 773  hot any more. Will avoid promote the original target.
 774 
 775  To check if original promoted target is still hot, we check the total
 776  count of the unpromoted targets (stored in old_info). If it is no
less
 777  than half of the callsite count (stored in INFO), the original
promoted
 778  target is considered not hot any more.  */
 779   if (total >= info->count / 2)

but even with the test commented out it doesn't work.