[Bug fortran/77505] Negative character length not treated as LEN=0

[elizebethp at gmail dot com]

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

--- Comment #12 from Elizebeth Punnoose  ---
(In reply to kargl from comment #11)
> Fixed on trunk.  Closing.
> 
> Elizebeth, Thanks for the patch.

Thank you.

[Bug libgcc/68468] frv/bfin FDPIC toolchain build error

[wbx at openadk dot org]

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

Waldemar Brodkorb  changed:

   What|Removed |Added

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

--- Comment #11 from Waldemar Brodkorb  ---
is fixed with 242468

[Bug c++/78551] [5/6/7 Regression] Internal compiler error with constexpr initialization of union

[vlad at petric dot cc]

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

--- Comment #7 from Vlad Petric  ---
Ok, so the example that I started this bug with is not standard compliant
because it initialized different elements in a union with the constexpr
constructor.

The following does just one. I believe that the following is standard-compliant
code (though obviously I could be wrong)

And it generates a segfault.

struct A {
  union {
long s;
char d[4];
  };
  constexpr A (char x) : d("") { d[0] = x; }
};

A a{'a'};

[Bug libstdc++/78264] [7 regression] ICE in build_noexcept_spec, at cp/except.c:1196

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #5 from Eric Botcazou  ---
> Still present on Solaris.

Jason,

could you please have a look at this PR?  Your patch (r241944)

2016-11-07  Jason Merrill  

  Implement P0012R1, Make exception specifications part of the type
  system.

has introduced those massive regressions on Solaris, as I've just
verified on i386-pc-solaris2.12 and sparc-sun-solaris2.12 (but it
affects any Solaris version).

Thanks.
Rainer

[Bug fortran/78641] New: [OOP] ICE on polymorphic allocatable function in array constructor

[damian at sourceryinstitute dot org]

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

Bug ID: 78641
   Summary: [OOP] ICE on polymorphic allocatable function in array
constructor
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

gfortran 6.2.0 and 7.0.0 20161127 report an internal compiler error when an
allocatable polymorphic function appears in an array constructor: 

$ cat alloc-func-in-array-const.f90 
implicit none
  type foo
  end type
  type(foo) :: bar(1)
  bar = [f()]
contains
  function f() result(foobar)
 class(foo), allocatable :: foobar
allocate(foobar,source = foo())
  end function
end program

$ gfortran alloc-func-in-array-const.f90 
f951: internal compiler error: Segmentation fault: 11

f951: internal compiler error: Abort trap: 6
gfortran: internal compiler error: Abort trap: 6 (program f951)

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[kkojima at gcc dot gnu.org]

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

--- Comment #2 from Kazumoto Kojima  ---
Looks not enough.  Even with the patch, I got a similar ICE for lto case
in testsuite:

FAIL: gcc.dg/atomic/stdatomic-op-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (internal compiler error)

gcc.log says

/exp/ldroot/dodes/ORIG/trunk/gcc/testsuite/gcc.dg/atomic/stdatomic-op-1.c: In
function 'main':
/exp/ldroot/dodes/ORIG/trunk/gcc/testsuite/gcc.dg/atomic/stdatomic-op-1.c:341:1:
error: invalid rtl sharing found in the insn
(insn 1527 292 294 23 (set (reg:SI 147 t)
(eq:SI (subreg:SI (reg:QI 559) 0)
(const_int 0 [0])))
"/exp/ldroot/dodes/ORIG/trunk/gcc/testsuite/gcc.dg/atomic/stdatomic-op-1.c":94
-1
 (nil))
/exp/ldroot/dodes/ORIG/trunk/gcc/testsuite/gcc.dg/atomic/stdatomic-op-1.c:341:1:
error: shared rtx
(subreg:SI (reg:QI 559) 0)
/exp/ldroot/dodes/ORIG/trunk/gcc/testsuite/gcc.dg/atomic/stdatomic-op-1.c:341:1:
internal compiler error: internal consistency failure
0x829cca7 verify_rtx_sharing
../../ORIG/trunk/gcc/emit-rtl.c:2743

and it went away with the patch below.

diff --git a/config/sh/sh.md b/config/sh/sh.md
index c6956a0..667a9a5 100644
--- a/config/sh/sh.md
+++ b/config/sh/sh.md
@@ -607,7 +607,7 @@
{
  if (dump_file)
fprintf (dump_file, "tstsi_t: converting to cmpeqsi_t\n");
- emit_insn (gen_cmpeqsi_t (eop0.use_as_extended_reg (curr_insn),
+ emit_insn (gen_cmpeqsi_t (copy_rtx(eop0.use_as_extended_reg
(curr_insn)),
const0_rtx));
  DONE;
}

[Bug c++/78636] PPC Optimization Bug in Libelemental unit test

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-12-02
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
As I said on IRC, we need preprocessed source, as described at
https://gcc.gnu.org/bugs/ and as that also says, please try
-fsanitize=undefined 

We can't do anything with URLs (one of which doesn't even resolve) and logs.

[Bug fortran/78640] New: [F2015] gfortran accepts invalid allocatable polymorphic result in pure function

[damian at sourceryinstitute dot org]

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

Bug ID: 78640
   Summary: [F2015] gfortran accepts invalid allocatable
polymorphic result in pure function
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

Constraint C1589 in Draft 16-007r2 of the Fortran 2015 standard states

"A pure function shall not have a polymorphic allocatable result."

As demonstrated below, a 20161127 build of gfortran 7.0.0 accepts code that
violates the above constraint:

$ cat poly-alloc-result.f90 
  type foo
  end type
  type(foo) :: bar
  bar = f()
contains
  pure function f() result(y)
class(foo), allocatable :: y
allocate(foo::y)
  end function
end 

$ gfortran poly-alloc-result.f90 

$ ./a.out

$ gfortran --version
GNU Fortran (MacPorts gcc7 7-20161127_0) 7.0.0 20161127 (experimental)

[Bug c++/68159] Demangler crash (GDB PR 19190)

[natashenka at google dot com]

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

Natalie Silvanovich  changed:

   What|Removed |Added

 CC||natashenka at google dot com

--- Comment #14 from Natalie Silvanovich  ---
I'm still seeing this issue as well, out put is:

/build/gdb-cXfXJ3/gdb-7.11.1/gdb/cp-support.c:1595: demangler-warning: unable
to demangle
'_ZSt7forwardIRZN6WebKit29NetworkConnectionToWebProcess26writeBlobsToTemporaryFilesERKN3WTF6VectorINS2_6StringELm0ENS2_15CrashOnOverflowELm16EEEmEUlRT_E_EOS9_RNSt16remove_referenceIS9_E4typeE'
(demangler failed with signal 11)
Attempting to dump core.
/build/gdb-cXfXJ3/gdb-7.11.1/gdb/cp-support.c:1608: demangler-warning: unable
to demangle
'_ZSt7forwardIRZN6WebKit29NetworkConnectionToWebProcess26writeBlobsToTemporaryFilesERKN3WTF6VectorINS2_6StringELm0ENS2_15CrashOnOverflowELm16EEEmEUlRT_E_EOS9_RNSt16remove_referenceIS9_E4typeE'
(demangler failed with signal 11)
A problem internal to GDB has been detected,

I can provide a coredump if needed (I don't seem to have permissions to add an
attachment right now)

[Bug target/78639] Power9 bad code generation for cactusADM benchmark

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Created attachment 40222
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40222=edit
Bzip2 test case, compile with -g -O3 -mcpu=power9 -fgnu89-inline

[Bug target/78639] Power9 bad code generation for cactusADM benchmark

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Created attachment 40221
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40221=edit
Proposed patch to fix the problem

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
This fixes the ICE.  It does not produce the error in assigning
an out-of-range kind=4 character to a kind=1 character.

Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 243142)
+++ gcc/fortran/check.c (working copy)
@@ -3667,7 +3667,7 @@ gfc_check_range (gfc_expr *x)


 bool
-gfc_check_rank (gfc_expr *a ATTRIBUTE_UNUSED)
+gfc_check_rank (gfc_expr *a)
 {
   /* Any data object is allowed; a "data object" is a "constant (4.1.3),
  variable (6), or subobject of a constant (2.4.3.2.3)" (F2008, 1.3.45). 
*/
@@ -3676,9 +3676,16 @@ gfc_check_rank (gfc_expr *a ATTRIBUTE_UN

   /* Functions returning pointers are regarded as variable, cf. F2008, R602. 
*/
   if (a->expr_type == EXPR_FUNCTION)
-is_variable = a->value.function.esym
- ? a->value.function.esym->result->attr.pointer
- : a->symtree->n.sym->result->attr.pointer;
+{
+  if (a->value.function.esym)
+   is_variable = a->value.function.esym->result->attr.pointer;
+  else if (a->symtree->n.sym->result)
+   is_variable = a->symtree->n.sym->result->attr.pointer;
+  else if (a->symtree->n.sym->value)
+   is_variable = true;
+  else
+   gfc_internal_error ("gfc_check_rank(): invalid function result");
+}

   if (a->expr_type == EXPR_OP || a->expr_type == EXPR_NULL
   || a->expr_type == EXPR_COMPCALL|| a->expr_type == EXPR_PPC

[Bug target/78639] Power9 bad code generation for cactusADM benchmark

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-12-02
 CC||dje at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |meissner at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug target/78639] New: Power9 bad code generation for cactusADM benchmark

[meissner at gcc dot gnu.org]

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

Bug ID: 78639
   Summary: Power9 bad code generation for cactusADM benchmark
   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: ---

I was building the Spec 2006 benchmark targeting the forthcoming power9
processor and I noticed the cactusADM benchmark did not build.

The bug is due to my change on November 21st, 2016 (subversion id 242679).  If
a DImode value in an Altivec register is to be stored with a register+register
address, the compiler generated STXSD (register+offset) instead of STXSDX
(register+register).

In the movdi_internal64 pattern, I deleted a 'w' from the STXSD constraint,
which meant the constraint was using "Y" instead of "wY".  "Y" allows reg+reg,
while "wY" does not (and also enforces a stricter alignment check).

[Bug target/78614] [7 Regression] ICE error: invalid rtl sharing found in the insn (verify_rtx_sharing) gcc/emit-rtl.c:2743

[wschmidt at gcc dot gnu.org]

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

--- Comment #23 from Bill Schmidt  ---
I've backported the insn_is_swappable_p bugfix to gcc-5-branch and
gcc-6-branch.  Thanks again for fixing that, Alan!

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima  changed:

   What|Removed |Added

 CC||olegendo at gcc dot gnu.org

--- Comment #1 from Kazumoto Kojima  ---
Here is a trial patch

diff --git a/config/sh/sh.md b/config/sh/sh.md
index c6956a0..c83bf08 100644
--- a/config/sh/sh.md
+++ b/config/sh/sh.md
@@ -858,7 +858,8 @@
 operands of the tstsi_t insn, which is generally the case.  */
   if (dump_file)
fprintf (dump_file, "cmpeqsi_t: replacing with tstsi_t\n");
-  emit_insn (gen_tstsi_t (XEXP (op.set_src, 0), XEXP (op.set_src, 1)));
+  emit_insn (gen_tstsi_t (copy_rtx (XEXP (op.set_src, 0)),
+ XEXP (op.set_src, 1)));
   DONE;
 }

Oleg, could you take a look at the issue?  Although the patch fixes
the ICE, I'm not sure if it's OK and enough.

[Bug fortran/77505] Negative character length not treated as LEN=0

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #11 from kargl at gcc dot gnu.org ---
Fixed on trunk.  Closing.

Elizebeth, Thanks for the patch.

[Bug tree-optimization/78586] [7 Regression] Wrong code caused by printf-return-value

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
Author: jakub
Date: Thu Dec  1 23:15:57 2016
New Revision: 243145

URL: https://gcc.gnu.org/viewcvs?rev=243145=gcc=rev
Log:
PR tree-optimization/78586
* gimple-ssa-sprintf.c (format_integer): Don't handle NOP_EXPR,
CONVERT_EXPR or COMPONENT_REF here.  Formatting fix.  For
SSA_NAME_DEF_STMT with NOP_EXPR only change argtype if the rhs1's
type is INTEGER_TYPE or POINTER_TYPE.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c

[Bug fortran/77505] Negative character length not treated as LEN=0

[kargl at gcc dot gnu.org]

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

--- Comment #10 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Dec  1 23:11:35 2016
New Revision: 243143

URL: https://gcc.gnu.org/viewcvs?rev=243143=gcc=rev
Log:
2016-12-01  Elizebeth Punnoose  

PR fortran/77505
* trans-array.c (trans_array_constructor): Treat negative character
length as LEN = 0.


2016-12-01  Elizebeth Punnoose  

PR fortran/77505
* gfortran.dg/char_length_20.f90: New test.
* gfortran.dg/char_length_21.f90: Ditto.

Added:
trunk/gcc/testsuite/gfortran.dg/char_length_20.f90
trunk/gcc/testsuite/gfortran.dg/char_length_21.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/78638] [7 regression] test cases gcc.target/powerpc/rlwimi-0.c and rlwimi-2.c fail starting with r243000

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-12-01
 CC||segher at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Segher Boessenkool  ---
No, it most likely means not everything is optimised as it should any more.
But for some reason I do not see this.  Huh.

[Bug target/78577] Fix define_insn operand types for vexturhlx, vexturhrx, vextuwlx, and vextuwrx patterns

[kelvin at gcc dot gnu.org]

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

kelvin at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from kelvin at gcc dot gnu.org ---
committed patch after bootstrapping and regression testing.

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[iains at gcc dot gnu.org]

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

--- Comment #55 from Iain Sandoe  ---
(In reply to Jack Howarth from comment #54)
> Shouldn't this be closed now as resolved?

nope, it needs back-porting to 6.x and 5.x - will do that after it's been on
trunk a while.

[Bug target/78577] Fix define_insn operand types for vexturhlx, vexturhrx, vextuwlx, and vextuwrx patterns

[kelvin at gcc dot gnu.org]

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

--- Comment #1 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Thu Dec  1 22:52:07 2016
New Revision: 243141

URL: https://gcc.gnu.org/viewcvs?rev=243141=gcc=rev
Log:
gcc/ChangeLog:

2016-12-01  Kelvin Nilsen  

PR target/78577
* config/rs6000/vsx.md (vextuhlx): Revise mode of operand 2.
(vextuhrx): Likewise.
(vextuwlx): Likewise.
(vextuwrx): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/vsx.md

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[howarth.at.gcc at gmail dot com]

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

--- Comment #54 from Jack Howarth  ---
Shouldn't this be closed now as resolved?

[Bug rtl-optimization/78638] New: [7 regression] test cases gcc.target/powerpc/rlwimi-0.c and rlwimi-2.c fail starting with r243000

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 78638
   Summary: [7 regression] test cases
gcc.target/powerpc/rlwimi-0.c and rlwimi-2.c fail
starting with r243000
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

It looks like the counts of some of the assembler instructions changed with
this update and the test case needs updating.

make -k check-gcc RUNTESTFLAGS=powerpc.exp=rlwimi-0.c

FAIL: gcc.target/powerpc/rlwimi-0.c scan-assembler-times (?n)^\\s+[a-z] 19909
PASS: gcc.target/powerpc/rlwimi-0.c scan-assembler-times (?n)^\\s+blr 6750
PASS: gcc.target/powerpc/rlwimi-0.c scan-assembler-times (?n)^\\s+mr 11
PASS: gcc.target/powerpc/rlwimi-0.c scan-assembler-times (?n)^\\s+rldicl 6420
PASS: gcc.target/powerpc/rlwimi-0.c scan-assembler-times (?n)^\\s+rldimi 310
PASS: gcc.target/powerpc/rlwimi-0.c scan-assembler-times (?n)^\\s+rlwimi 6110
FAIL: gcc.target/powerpc/rlwimi-0.c scan-assembler-times (?n)^\\s+rotlwi 308
=== gcc Summary ===

# of expected passes6
# of unexpected failures2



gcc.target/powerpc/rlwimi-2.c fails similarly

FAIL: gcc.target/powerpc/rlwimi-2.c scan-assembler-times (?n)^\\s+[a-z] 20217
PASS: gcc.target/powerpc/rlwimi-2.c scan-assembler-times (?n)^\\s+blr 6750
PASS: gcc.target/powerpc/rlwimi-2.c scan-assembler-times (?n)^\\s+mr 11
PASS: gcc.target/powerpc/rlwimi-2.c scan-assembler-times (?n)^\\s+rldicl 6728
PASS: gcc.target/powerpc/rlwimi-2.c scan-assembler-times (?n)^\\s+rlwimi 1692
PASS: gcc.target/powerpc/rlwimi-2.c scan-assembler-times (?n)^\\s+mulli 5036

[Bug c/78568] [5/6/7 Regression] Wtype-limits warning regression

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
That is not how C++ c_fully_fold works.  There it can be called multiple times,
and it does some caching to avoid consuming too much time, but the caches can
be flushed at certain times.

[Bug fortran/37336] [F03] Finish derived-type finalization

[damian at sourceryinstitute dot org]

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

Bug 59694 Summary: [F03] no finalization of an unused variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59694

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

[Bug fortran/59694] [F03] no finalization of an unused variable

[damian at sourceryinstitute dot org]

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

Damian Rouson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Damian Rouson  ---
Marking as invalid.

[Bug other/78161] contrib/download_prerequisites fails on MacOS, Lubuntu, and Windows

[damian at sourceryinstitute dot org]

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

--- Comment #4 from Damian Rouson  ---
I'll close this because another developer is going to work on it so my last
comment no longer applies.

[Bug fortran/78279] ICE in identical_array_ref, at fortran/dependency.c:104

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Fixed on 5-branch, 6-branch, and trunk.

[Bug fortran/78279] ICE in identical_array_ref, at fortran/dependency.c:104

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Dec  1 21:28:41 2016
New Revision: 243134

URL: https://gcc.gnu.org/viewcvs?rev=243134=gcc=rev
Log:
2016-12-01  Steven G. Kargl  

PR fortran/78279
* dependency.c (identical_array_ref): Convert gcc_assert to conditional
and gfc_internal_error.

2016-12-01  Steven G. Kargl  

PR fortran/78279
* gfortran.dg/pr78279.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr78279.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/dependency.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/78279] ICE in identical_array_ref, at fortran/dependency.c:104

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Dec  1 21:05:49 2016
New Revision: 243133

URL: https://gcc.gnu.org/viewcvs?rev=243133=gcc=rev
Log:
016-12-01  Steven G. Kargl  

PR fortran/78279
* dependency.c (identical_array_ref): Convert gcc_assert to conditional
and gfc_internal_error.

2016-12-01  Steven G. Kargl  

PR fortran/78279
* gfortran.dg/pr78279.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr78279.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/dependency.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/78279] ICE in identical_array_ref, at fortran/dependency.c:104

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Dec  1 20:37:55 2016
New Revision: 243131

URL: https://gcc.gnu.org/viewcvs?rev=243131=gcc=rev
Log:
2016-12-01  Steven G. Kargl  

PR fortran/78279
* dependency.c (identical_array_ref): Convert gcc_assert to conditional
and gfc_internal_error.

2016-12-01  Steven G. Kargl  

PR fortran/78279
* gfortran.dg/pr78279.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr78279.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dependency.c
trunk/gcc/testsuite/ChangeLog

[Bug target/78631] [Intel MPX] libmpxwrappers shared library leads to a non-bounds-preserving memcpy()

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #1 from Ilya Enkovich  ---
PLT section is generated by linker. To have MPX friendly PLT you have to have
MPX enabled linker supporting '-z bndplt' flag and GCC should be configured
using MPX enabled toolchain to pass this linker option it by default.

Situation you describe might happen when you use old bfd or any version of
gold.

[Bug c++/56480] Explicit specialization in a namespace enclosing the specialized template

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|5.5 |7.0

--- Comment #11 from Jason Merrill  ---
Author: jason
Date: Sun Nov 13 06:51:23 2016
New Revision: 242348

URL: https://gcc.gnu.org/viewcvs?rev=242348=gcc=rev
Log:
DR 374 - specialization in outer namespace

PR c++/56840
* pt.c (check_specialization_namespace): Allow any enclosing
namespace.
(check_unqualified_spec_or_inst): New.
(check_explicit_specialization): Call it.
* parser.c (cp_parser_elaborated_type_specifier)
(cp_parser_class_head): Call it.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/explicit-inst1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/name-lookup.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c

[Bug target/78101] PowerPC 64-bit little endian fusion failure with -O3 -mcpu=power9

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #4 from Michael Meissner  ---
GCC 6 branch updated, svn id 243128.

[Bug target/78101] PowerPC 64-bit little endian fusion failure with -O3 -mcpu=power9

[meissner at gcc dot gnu.org]

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

--- Comment #3 from Michael Meissner  ---
Author: meissner
Date: Thu Dec  1 19:26:15 2016
New Revision: 243128

URL: https://gcc.gnu.org/viewcvs?rev=243128=gcc=rev
Log:
[gcc]
2016-12-01  Michael Meissner  

Back port from trunk
2016-11-17  Michael Meissner  

PR target/78101
* config/rs6000/predicates.md (fusion_addis_mem_combo_load): Add
the appropriate checks for SFmode/DFmode load/stores in GPR
registers.
(fusion_addis_mem_combo_store): Likewise.
* config/rs6000/rs6000.c (rs6000_init_hard_regno_mode_ok): Rename
fusion_fpr_* to fusion_vsx_* and add in support for ISA 3.0 scalar
d-form instructions for traditional Altivec registers.
(emit_fusion_p9_load): Likewise.
(emit_fusion_p9_store): Likewise.
* config/rs6000/rs6000.md (p9 fusion store peephole2): Remove
early clobber from scratch register.  Do not match if the register
being stored is the scratch register.
(fusion_vsx___load): Rename fusion_fpr_*
to fusion_vsx_* and add in support for ISA 3.0 scalar d-form
instructions for traditional Altivec registers.
(fusion_fpr___load): Likewise.
(fusion_vsx___store): Likewise.
(fusion_fpr___store): Likewise.

[gcc/testsuite]
2016-12-01  Michael Meissner  

Back port from trunk
2016-11-17  Michael Meissner  

PR target/78101
* gcc.target/powerpc/fusion4.c: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/fusion4.c
  - copied unchanged from r242983,
trunk/gcc/testsuite/gcc.target/powerpc/fusion4.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/predicates.md
branches/gcc-6-branch/gcc/config/rs6000/rs6000.c
branches/gcc-6-branch/gcc/config/rs6000/rs6000.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/78637] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: in pop_namespace, at cp/name-lookup.c:3826)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||6.2.0
   Keywords||ice-on-invalid-code
   Last reconfirmed||2016-12-01
 CC||marxin at gcc dot gnu.org,
   ||paolo.carlini at oracle dot com
 Ever confirmed|0   |1
Summary|ICE on invalid C++ code on  |[7 Regression] ICE on
   |x86_64-linux-gnu (internal  |invalid C++ code on
   |compiler error: in  |x86_64-linux-gnu (internal
   |pop_namespace, at   |compiler error: in
   |cp/name-lookup.c:3826)  |pop_namespace, at
   ||cp/name-lookup.c:3826)
   Target Milestone|--- |7.0
  Known to fail||7.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r236835.

[Bug c++/78635] [6/7 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:4989

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Confirmed, started with r234636.

[Bug debug/66149] ICE: tree check: expected field_decl, have template_decl in int_bit_position, at tree.h:5012 with -std=c++14 -gstabs

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #1 from David Edelsohn  ---
Fixed.

[Bug c++/78235] [7 Regression] libstdc++ testsuite run.cc ICE in int_bit_position

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #7 from David Edelsohn  ---
Fixed.

[Bug c++/78235] [7 Regression] libstdc++ testsuite run.cc ICE in int_bit_position

[dje at gcc dot gnu.org]

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

--- Comment #6 from David Edelsohn  ---
Author: dje
Date: Thu Dec  1 18:58:47 2016
New Revision: 243126

URL: https://gcc.gnu.org/viewcvs?rev=243126=gcc=rev
Log:
PR debug/66419
PR c++/78235
* dbxout.c (dbxout_type_fields): Skip TEMPLATE_DECLs.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dbxout.c

[Bug tree-optimization/66419] [6 regression] FAIL: gcc.target/aarch64/aapcs64/va_arg-6.c execution, -O3 -g

[dje at gcc dot gnu.org]

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

--- Comment #6 from David Edelsohn  ---
Author: dje
Date: Thu Dec  1 18:58:47 2016
New Revision: 243126

URL: https://gcc.gnu.org/viewcvs?rev=243126=gcc=rev
Log:
PR debug/66419
PR c++/78235
* dbxout.c (dbxout_type_fields): Skip TEMPLATE_DECLs.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dbxout.c

[Bug target/78255] [5/6/7 regression] Indirect sibling call causing wrong code generation for ARM

[law at redhat dot com]

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

--- Comment #9 from Jeffrey A. Law  ---
Also note that on some targets indirect calls have a different ABI than calls
to named function.  SO changing between direct and indirect calls is strictly
forbidden on some targets.

I suspect there's some magic we need to replicate in postreload-gcse from
cse/gcse/combine to prevent this from occurring unnecessarily.

[Bug c/78568] [5/6/7 Regression] Wtype-limits warning regression

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
c_fully_fold should not be asked to fold the same expression more than 
once.  When a subexpression is folded during parsing, for whatever reason, 
the result should be wrapped in a tree code that c_fully_fold does not 
recurse into, using c_wrap_maybe_const if no other such tree code is 
involved.

Thus, warning from c_fully_fold should be OK without generating duplicate 
warnings (if duplicates occur, that suggests something is failing to 
prevent multiple calls to c_fully_fold for the same expression).

[Bug c++/78637] New: ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: in pop_namespace, at cp/name-lookup.c:3826)

[chengniansun at gmail dot com]

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

Bug ID: 78637
   Summary: ICE on invalid C++ code on x86_64-linux-gnu (internal
compiler error: in pop_namespace, at
cp/name-lookup.c:3826)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20161201 (experimental) [trunk revision 243118] (GCC)
$
$ gcc-trunk small.C
small.C:4:14: error: ‘namespace X::Y { }’ redeclared as different kind of
symbol
 namespace X::Y z;
  ^
small.C:2:7: note: previous declaration ‘class X::Y’
 class Y;
   ^
small.C:4:16: error: expected ‘{’ before ‘z’
 namespace X::Y z;
^
small.C:4:16: error: ‘z’ does not name a type
small.C:4:17: internal compiler error: in pop_namespace, at
cp/name-lookup.c:3826
 namespace X::Y z;
 ^
0x890072 pop_namespace()
../../gcc-source-trunk/gcc/cp/name-lookup.c:3826
0x7d11bf cp_parser_namespace_definition
../../gcc-source-trunk/gcc/cp/parser.c:18226
0x7d07db cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12472
0x7d0ab4 cp_parser_declaration_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:12364
0x7d0df8 cp_parser_translation_unit
../../gcc-source-trunk/gcc/cp/parser.c:4368
0x7d0df8 c_parse_file()
../../gcc-source-trunk/gcc/cp/parser.c:38262
0x935c32 c_common_parse_file()
../../gcc-source-trunk/gcc/c-family/c-opts.c:1098
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
$ cat small.C
namespace X {
class Y;
}
namespace X::Y z;
$

[Bug middle-end/78629] vec.h: null pointer passed as argument 1, which is declared to never be null

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
Fixed by r243125, forgot to add PR number to changelog in the patch :/

[Bug c++/78636] PPC Optimization Bug in Libelemental unit test

[me at ryanlewis dot net]

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

--- Comment #2 from rhl  ---
Created attachment 40220
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40220=edit
and the output of valgrind after remove offending Output function in favor out
std::cout

[Bug c++/78636] PPC Optimization Bug in Libelemental unit test

[me at ryanlewis dot net]

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

--- Comment #1 from rhl  ---
Created attachment 40219
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40219=edit
this is the valgrind output when the segfault occurs

[Bug c++/78636] New: PPC Optimization Bug in Libelemental unit test

[me at ryanlewis dot net]

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

Bug ID: 78636
   Summary: PPC Optimization Bug in Libelemental unit test
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: me at ryanlewis dot net
  Target Milestone: ---

Created attachment 40218
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40218=edit
example of failing code (which isn't failing)

I am working on packaging libelemental for Fedora. I have found that a few of
our unit tests fail on PPC with in Release mode and pass in Debug mode, only on
this architecture. I suspect this to be a compiler bug, as the code is quite
vanilla. 


Here is the associated build log demonstrating how the software located here:
https://github.com/elemental/Elemental.git

was compiled and ran: 
https://copr-be.cloud.fedoraproject.org/results/rhl/elemental/fedora-24-ppc64le/00482253-elemental/build.log.gz

here are other examples of it failing (it looks like a timeout issue here):

https://kojipkgs.fedoraproject.org//work/tasks/5356/16555356/build.log


Here is an example of a failure in the debugger:

Program received signal SIGSEGV, Segmentation fault.
__memcpy_power7 () at ../sysdeps/powerpc/powerpc64/power7/memcpy.S:387
387 stvx6,0,dst
Missing separate debuginfos, use: dnf debuginfo-install
mpich-3.2-5.fc24.ppc64le
(gdb) bt
#0  __memcpy_power7 () at ../sysdeps/powerpc/powerpc64/power7/memcpy.S:387
#1  0x3fffb59da5f4 in std::char_traits::copy
(__n=13839561654909534208, __s2=, __s1=)
at
/usr/src/debug/gcc-6.2.1-20160916/obj-ppc64le-redhat-linux/ppc64le-redhat-linux/libstdc++-v3/include/bits/char_traits.h:290
#2  std::basic_streambuf::xsputn
(this=0x3fffe568, __s=, __n=11)
at
/usr/src/debug/gcc-6.2.1-20160916/obj-ppc64le-redhat-linux/ppc64le-redhat-linux/libstdc++-v3/include/bits/streambuf.tcc:90
#3  0x3fffb59c5cd4 in std::basic_streambuf::sputn (__n=11, __s=0x2000e0a8 "  runtime: ", this=)
at
/usr/src/debug/gcc-6.2.1-20160916/obj-ppc64le-redhat-linux/ppc64le-redhat-linux/libstdc++-v3/include/streambuf:451
#4  std::__ostream_write (__n=11, __s=0x2000e0a8
"  runtime: ", __out=...)
at
/usr/src/debug/gcc-6.2.1-20160916/obj-ppc64le-redhat-linux/ppc64le-redhat-linux/libstdc++-v3/include/bits/ostream_insert.h:50
#5  std::__ostream_insert (__out=...,
__s=0x2000e0a8 "  runtime: ", __n=11)
at
/usr/src/debug/gcc-6.2.1-20160916/obj-ppc64le-redhat-linux/ppc64le-redhat-linux/libstdc++-v3/include/bits/ostream_insert.h:101
#6  0x2000402c in std::operator<< 
(__s=0x2000e0a8 "  runtime: ", __out=...) at /usr/include/c++/6.2.1/ostream:561
#7  El::BuildStream (item=..., os=...) at
/home/fedora/rpmbuild/BUILD/Elemental-master/include/El/core/environment/impl.hpp:167
#8  El::Output () at
/home/fedora/rpmbuild/BUILD/Elemental-master/include/El/core/environment/impl.hpp:227
#9  main (argc=, argv=) at
/home/fedora/rpmbuild/BUILD/Elemental-master/examples/number_theory/ZDependenceSearch.cpp:86

I isolated this bit of code to produce an elemental free minimal test case,
but, it appears that it does not fail when freed from this example.

I ran the code through valgrind I have attached the output, and I also removed
the function El::Output() (in favor of std::cout) and the failure disappears. I
then reran valgrind again. I will attach the valgrind output for both runs.

[Bug tree-optimization/78608] gimple-ssa-sprintf.c:570:17: runtime error: negation of -9223372036854775808 cannot be represented in type 'long int'

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
I suspect the same problem should come up with a call to vsprintf.  The patch
below should handle this case but I haven't don't done a bootstrap-ubsan to
verify there are no others like it.

diff --git a/gcc/gimple-ssa-sprintf.c b/gcc/gimple-ssa-sprintf.c
index eceed3e..2b0781a 100644
--- a/gcc/gimple-ssa-sprintf.c
+++ b/gcc/gimple-ssa-sprintf.c
@@ -565,7 +565,13 @@ tree_digits (tree x, int base, bool plus, bool prefix)
   if (tree_fits_shwi_p (x))
{
  HOST_WIDE_INT i = tree_to_shwi (x);
- if (i < 0)
+ if (HOST_WIDE_INT_MIN == i)
+   {
+ /* Avoid undefined behavior due to negating a minimum.  */
+ absval = HOST_WIDE_INT_MAX;
+ res = 1;
+   }
+ else if (i < 0)
{
  absval = -i;
  res = 1;

[Bug tree-optimization/78608] gimple-ssa-sprintf.c:570:17: runtime error: negation of -9223372036854775808 cannot be represented in type 'long int'

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
  Known to fail||7.0

--- Comment #2 from Martin Sebor  ---
Thanks for the test case.  The code is invalid but GCC should handle it
gracefully.

[Bug sanitizer/77538] segmentation fault: thread sanitizer shadow stack overflow

[dvyukov at google dot com]

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

--- Comment #21 from Dmitry Vyukov  ---
> is that huge number abnormal?

Let's say it is atypical for C/C++ programs because of fixed-size stacks. But
tsan has limit of 64K frames in the latest version (maybe 4.8.2 had limit of
32K frames).
But do you actually have that many frame in the thread stack? If you do bt in
gdb, does it actually show tens of thousands of frames? We had bugs when shadow
stack is maintained incorrectly and frames "leak".

[Bug c++/77373] __attribute__((vector_size(N))) fails on AIX

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn  ---
 int D::f1() int D::f2() int main() int D::f1() [with int N = 4] int
D::f2() [with int N = 4] int D::f1() [with int N = 8] int D::f2()
[with int N = 8]
Analyzing compilation unit

#0  _Z11fancy_abortPKciS0_ (
file=0x11af5554 <_GLOBAL__F_final_solutions_obstack+29508>
"/home/dje/src/src/gcc/cgraph.h", line=0, function=0x2ff21880 "/�\030�")
at /home/dje/src/src/gcc/diagnostic.c:1446
#1  0x10a96f64 in symtab_node::get (decl=)
#2  0x100a3a94 in _Z17decl_section_namePK9tree_node (
node=0x103734b4 <_Z22resolve_unique_sectionP9tree_nodeii+40>)
at /home/dje/src/src/gcc/tree.c:700
#3  0x103734b4 in _Z22resolve_unique_sectionP9tree_nodeii (decl=0x7010b090, 
reloc=0, flag_function_or_data_sections=1)
at /home/dje/src/src/gcc/varasm.c:441
#4  0x102a8500 in _ZL27rs6000_xcoff_select_sectionP9tree_nodeiy (
decl=0x7010b090, reloc=0)
at /home/dje/src/src/gcc/config/rs6000/rs6000.c:35073
#5  0x1037f640 in _ZL20get_constant_sectionP9tree_nodej (
exp=0x1037fcfc <_ZL19build_constant_descP9tree_node+1232>, align=0)
at /home/dje/src/src/gcc/varasm.c:3210
#6  0x1037fcfc in _ZL19build_constant_descP9tree_node (
exp=0x11a546ac <_GLOBAL__F__Z19free_gimplify_stackv+49100>)
at /home/dje/src/src/gcc/varasm.c:3278
#7  0x10380a68 in _Z24tree_output_constant_defP9tree_node (
exp=0x1084b6f4
<_ZL25gimplify_init_constructorPP9tree_nodePP6gimpleS4_bb+3948>) at
/home/dje/src/src/gcc/varasm.c:3484
#8  0x1084b6f4 in _ZL25gimplify_init_constructorPP9tree_nodePP6gimpleS4_bb (
expr_p=0x2ff21f88, pre_p=0x2ff22194, post_p=0x2ff21e90, want_value=false, 
notify_temp_creation=54) at /home/dje/src/src/gcc/gimplify.c:4562
#9  0x1084c680 in _ZL24gimplify_modify_expr_rhsPP9tree_nodeS1_S1_PP6gimpleS4_b
(expr_p=0x2ff21f88, 
from_p=0x11a55ab0 <_GLOBAL__F__Z19free_gimplify_stackv+54224>, 
to_p=0x2ff21e90, pre_p=0x2ff22194, post_p=0x0, want_value=136)
at /home/dje/src/src/gcc/gimplify.c:4887
#10 0x108550e4 in _ZL20gimplify_modify_exprPP9tree_nodePP6gimpleS4_b (
expr_p=0x2ff21f88, pre_p=0x2ff22194, post_p=0x2ff21e90, want_value=false)
at /home/dje/src/src/gcc/gimplify.c:5223

[Bug c++/78589] g++ prints instead of a function name when warning in an OpenMP outlined function

[jamborm at gcc dot gnu.org]

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

--- Comment #6 from Martin Jambor  ---
(In reply to Martin Jambor from comment #4)
> I am testing a patch for gcc/cp/error.c that (apart from guarding
> against infinite recursion in some cases) should make g++ produce the
> same output as gcc does.

I have posted this patch to the mailing list:
https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00093.html

[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP

[hubicka at ucw dot cz]

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

--- Comment #9 from Jan Hubicka  ---
Hi,
here is patch adding the polymorphic case, too.

Honza

[Bug c++/78235] [7 Regression] libstdc++ testsuite run.cc ICE in int_bit_position

[dje at gcc dot gnu.org]

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

--- Comment #5 from David Edelsohn  ---
This fails in dbxout.c:dbxout_type_fields()

  /* Output the name, type, position (in bits), size (in bits) of each
 field that we can support.  */
  for (tem = TYPE_FIELDS (type); tem; tem = DECL_CHAIN (tem))
 ...
  if (VAR_P (tem))
{
 ...
 }
  else
{
  stabstr_C (',');
  stabstr_D (int_bit_position (tem));
  stabstr_C (',');
  stabstr_D (tree_to_uhwi (DECL_SIZE (tem)));
  stabstr_C (';');
}

tem is a TEMPLATE_DECL. It is occuring under the case for RECORD_TYPE,
UNION_TYPE and QUAL_UNION_TYPE.

Another part of dbxout.c states

  /* Skip methods that aren't FUNCTION_DECLs.  (In C++, these
 include TEMPLATE_DECLs.)  The debugger doesn't know what
 to do with such entities anyhow.  */

so I'm tempted to fix this by ignoring TEMPLATE_DECLs for in this logic as
well.

[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP

[hubicka at ucw dot cz]

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

--- Comment #8 from Jan Hubicka  ---
> Yes that's it, a single run shows 12% speedup with this patch!

Looks promising.  We probably should try to differentiate from polymorphic
calls
as virtual methods are also used in different patterns.  
let me cook the patch.

Honza

[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP

[wilco at gcc dot gnu.org]

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

--- Comment #7 from wilco at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #6)
> Created attachment 40216 [details]
> predict
> 
> Aha, indirect calls should probably be treated separately as their use cases
> are quite
> special. What about this patch? (Maritn, it would be great if you can run
> the analyze_brprob
> for it)

Yes that's it, a single run shows 12% speedup with this patch!

[Bug c++/78635] [6/7 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:4989

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-01
  Known to work||5.4.0
 Ever confirmed|0   |1
  Known to fail||6.2.0, 7.0

--- Comment #1 from Jonathan Wakely  ---
Previous releases diagnosed it correctly:

t.cc:6:47: error: too many initializers for ‘dirs_t’
 struct dirs_t a[2] = { { 1, 'a' }, { 1, 'b' } };
   ^
t.cc:6:47: error: too many initializers for ‘dirs_t’

[Bug c++/78635] New: [6/7 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:4989

[redi at gcc dot gnu.org]

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

Bug ID: 78635
   Summary: [6/7 Regression] internal compiler error: in
output_constructor_regular_field, at varasm.c:4989
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

struct dirs_t {
  int   x;
  char y[];
};

struct dirs_t a[2] = { { 1, 'a' }, { 1, 'b' } };

t.cc:6:48: internal compiler error: in output_constructor_regular_field, at
varasm.c:4989
 struct dirs_t a[2] = { { 1, 'a' }, { 1, 'b' } };
^
0x10a4a04 output_constructor_regular_field
/home/jwakely/src/gcc/gcc/gcc/varasm.c:4989
0x10a4a04 output_constructor
/home/jwakely/src/gcc/gcc/gcc/varasm.c:5297
0x10a4da4 output_constant
/home/jwakely/src/gcc/gcc/gcc/varasm.c:4674
0x10a4da4 assemble_variable_contents
/home/jwakely/src/gcc/gcc/gcc/varasm.c:2083
0x10ac609 assemble_variable(tree_node*, int, int, int)
/home/jwakely/src/gcc/gcc/gcc/varasm.c:2259
0x10b1e28 varpool_node::assemble_decl()
/home/jwakely/src/gcc/gcc/gcc/varpool.c:588
0x9b870b output_in_order
/home/jwakely/src/gcc/gcc/gcc/cgraphunit.c:2248
0x9b8add symbol_table::compile()
/home/jwakely/src/gcc/gcc/gcc/cgraphunit.c:2488
0x9bb592 symbol_table::compile()
/home/jwakely/src/gcc/gcc/gcc/cgraphunit.c:2558
0x9bb592 symbol_table::finalize_compilation_unit()
/home/jwakely/src/gcc/gcc/gcc/cgraphunit.c:2584
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/68945] enable libcilkrts on SPARC

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #15 from Rainer Orth  ---
Fixed for 7.1.

[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP

[hubicka at ucw dot cz]

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

--- Comment #6 from Jan Hubicka  ---
Aha, indirect calls should probably be treated separately as their use cases
are quite
special. What about this patch? (Maritn, it would be great if you can run the
analyze_brprob
for it)

Honza

[Bug bootstrap/78616] [7 regression] bootstrap fails for x86_64-darwin at stage1 after 243030 when the bootstrap compiler doesn't have strndup

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #8 from David Malcolm  ---
Thanks.  I'm working on a patch to remove the use of strndup.  Sorry for the
breakage.

[Bug tree-optimization/78598] tree-ssa-loop-prefetch.c:835:16: runtime error: signed integer overflow

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
Fixed.

[Bug fortran/77693] ICE in rtl_for_decl_init, at dwarf2out.c:17378

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #4 from Dominique d'Humieres  ---
Since a revision between r242901 and r243100 I get the following error:

data a /(1.,2.)/
  1
Error: NULL() initialization expected in DATA statement for 'a' at (1)

[Bug tree-optimization/78598] tree-ssa-loop-prefetch.c:835:16: runtime error: signed integer overflow

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
Author: trippels
Date: Thu Dec  1 14:59:03 2016
New Revision: 243113

URL: https://gcc.gnu.org/viewcvs?rev=243113=gcc=rev
Log:
Fix PR tree-optimization/78598 - tree-ssa-loop-prefetch.c:835:16: runtime
error: signed integer overflow

Using bootstrap-ubsan gcc to build mplayer shows:

tree-ssa-loop-prefetch.c:835:16: runtime error: signed integer overflow:
288230376151711743 * 64 cannot be represented in type 'long int'

Here signed und unsigned integers are mixed in a division resulting in
bogus values: (-83 + 64ULL -1) / 64ULL) == 288230376151711743

Fixed by casting the unsigned parameter to signed.

PR tree-optimization/78598
* tree-ssa-loop-prefetch.c (ddown): Cast to signed to avoid
overflows.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-loop-prefetch.c

[Bug c++/70909] Libiberty Demangler segfaults (4)

[nathan at gcc dot gnu.org]

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

--- Comment #21 from Nathan Sidwell  ---
Why doesn't a mark/walk/unmark idiom when walking a potentially circular data
structure work here?  I.e. add a mutable counter to demangle_component. 
Inc/dec at start/end of d_print_comp? IIUC if it gets to >1 there's a problem.

[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP

[wilco at gcc dot gnu.org]

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

wilco at gcc dot gnu.org changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #5 from wilco at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #4)
> Wilco,
> do you have a specific function where this happens?
> 
> Martin,
> do you know what is hitrate of call predictor here?  I am not sure how much
> we can do about this (it is all heuristics after all).

Top functions in the profile with this issue are EvElmList, Sum, EvAssList,
Diff, Prod. It's the macro EVAL, it does a test and then an indirect call. If
is used multiple times in a row all the extra taken branches start to take
their toll.

[Bug target/68945] enable libcilkrts on SPARC

[ro at gcc dot gnu.org]

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

--- Comment #14 from Rainer Orth  ---
Author: ro
Date: Thu Dec  1 14:48:49 2016
New Revision: 243112

URL: https://gcc.gnu.org/viewcvs?rev=243112=gcc=rev
Log:
Import libcilkrts Build 4467 (PR target/68945)

PR target/68945
Merge from upstream, version 2.0.4467.0.
Fix typo in git URL.
* aclocal.m4, configure, Makefile.in: Regenerate.

Added:
trunk/libcilkrts/runtime/config/sparc/
trunk/libcilkrts/runtime/config/sparc/cilk-abi-vla.c
trunk/libcilkrts/runtime/config/sparc/os-fence.h
trunk/libcilkrts/runtime/config/sparc/os-unix-sysdep.c
Modified:
trunk/libcilkrts/ChangeLog
trunk/libcilkrts/Makefile.am
trunk/libcilkrts/Makefile.in
trunk/libcilkrts/README
trunk/libcilkrts/configure
trunk/libcilkrts/configure.ac
trunk/libcilkrts/configure.tgt
trunk/libcilkrts/include/cilk/cilk_undocumented.h
trunk/libcilkrts/include/internal/cilk_version.h
trunk/libcilkrts/include/internal/rev.mk
trunk/libcilkrts/runtime/cilk-abi.c
trunk/libcilkrts/runtime/cilk_fiber-unix.cpp
trunk/libcilkrts/runtime/cilk_fiber.h
trunk/libcilkrts/runtime/config/arm/os-fence.h
trunk/libcilkrts/runtime/except-gcc.cpp
trunk/libcilkrts/runtime/global_state.cpp
trunk/libcilkrts/runtime/global_state.h
trunk/libcilkrts/runtime/jmpbuf.h
trunk/libcilkrts/runtime/linux-symbols.ver
trunk/libcilkrts/runtime/local_state.h
trunk/libcilkrts/runtime/mac-symbols.txt
trunk/libcilkrts/runtime/os-unix.c
trunk/libcilkrts/runtime/record-replay.cpp
trunk/libcilkrts/runtime/scheduler.c
trunk/libcilkrts/runtime/scheduler.h
trunk/libcilkrts/runtime/sysdep-unix.c

[Bug rtl-optimization/78634] New: [7 Regression] 30% performance drop after r242832.

[ysrumyan at gmail dot com]

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

Bug ID: 78634
   Summary: [7 Regression] 30% performance drop after r242832.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysrumyan at gmail dot com
  Target Milestone: ---

Created attachment 40215
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40215=edit
test-case to reproduce

We noticed a huge performance regression on x86 for one important benchmark
(the reproduced for which is attached). It is caused by additional
if-conversion which can be seen in ce2 dump:
IF-THEN-ELSE-JOIN block found, pass 1, test 12, then 13, else 14, join 15
scanning new insn with uid = 163.
scanning new insn with uid = 164.
scanning new insn with uid = 165.
scanning new insn with uid = 166.
scanning new insn with uid = 167.
scanning new insn with uid = 168.
scanning new insn with uid = 169.
if-conversion succeeded through noce_try_cmove_arith
deleting insn with uid = 85.
deleting block 14
Removing jump 78.
deleting insn with uid = 78.
deleting insn with uid = 80.
deleting block 13
Merging block 15 into block 12...
changing bb of uid 87
changing bb of uid 88
  from 15 to 12
changing bb of uid 89
  from 15 to 12
Merged blocks 12 and 15.
Conversion succeeded on pass 1.

On AVX2 machine we see:

time ./test1.1124.exe   // build by compiler before r242832.

real0m0.577s
user0m0.575s
sys 0m0.002s
time ./test1.1125.exe  // build by compiler after r242832.  

real0m0.888s
user0m0.886s
sys 0m0.001s

It is sufficient to compile it with -Ofast option to reproduce on x86.

[Bug target/78255] [5/6/7 regression] Indirect sibling call causing wrong code generation for ARM

[rearnsha at gcc dot gnu.org]

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

--- Comment #8 from Richard Earnshaw  ---
Hmm, why is this even being considered on ARM?

arm.h:#define NO_FUNCTION_CSE 1

doc/tm.texi
@defmac NO_FUNCTION_CSE
Define this macro to be true if it is as good or better to call a constant
function address than to call an address kept in a register.
@end defmac

[Bug target/78255] [5/6/7 regression] Indirect sibling call causing wrong code generation for ARM

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
(In reply to wilco from comment #5)
> (In reply to avieira from comment #4)
> > OK so after some extra debugging and digging I found that the postreload
> > pass is basically turning the direct sibcall into an indirect sibcall. It
> > takes cost into consideration, but does this only looking at the operands of
> > the call, i.e. the cost of a symbolref vs the cost of a register. It does
> > not take into consideration that it is doing a call. This doesn't seem like
> > a good idea to me.
> 
> Also it looks like various other targets may have the same issue as using
> one instruction for direct and indirect tailcalls is common among RISC
> targets.
> 
> So this is another generic cost issue whether it isn't possible to return
> correct costs.
> 

Regardless of whether the profitability logic is right or not, this is a
correctness question, so postreload should cancel this transformation
regardless of costs

[Bug target/70322] STV doesn't optimize andn

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

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

Untested patch I'm playing with.

[Bug target/78255] [5/6/7 regression] Indirect sibling call causing wrong code generation for ARM

[wilco at gcc dot gnu.org]

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

--- Comment #7 from wilco at gcc dot gnu.org ---
(In reply to ktkachov from comment #6)
> (In reply to wilco from comment #5)
> > (In reply to avieira from comment #4)
> > > OK so after some extra debugging and digging I found that the postreload
> > > pass is basically turning the direct sibcall into an indirect sibcall. It
> > > takes cost into consideration, but does this only looking at the operands 
> > > of
> > > the call, i.e. the cost of a symbolref vs the cost of a register. It does
> > > not take into consideration that it is doing a call. This doesn't seem 
> > > like
> > > a good idea to me.
> > 
> > Also it looks like various other targets may have the same issue as using
> > one instruction for direct and indirect tailcalls is common among RISC
> > targets.
> > 
> > So this is another generic cost issue whether it isn't possible to return
> > correct costs.
> > 
> 
> Regardless of whether the profitability logic is right or not, this is a
> correctness question, so postreload should cancel this transformation
> regardless of costs

The chosen pattern is legal so the transformation is effectively correct. We
could explicitly disallow making changes to calls and tailcalls, but what other
potentially incorrect transformations should we explicitly exclude?

[Bug driver/49726] [5/6/7 Regression] -g0 file.S -g does not produce debug info

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/78255] [5/6/7 regression] Indirect sibling call causing wrong code generation for ARM

[wilco at gcc dot gnu.org]

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

wilco at gcc dot gnu.org changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #5 from wilco at gcc dot gnu.org ---
(In reply to avieira from comment #4)
> OK so after some extra debugging and digging I found that the postreload
> pass is basically turning the direct sibcall into an indirect sibcall. It
> takes cost into consideration, but does this only looking at the operands of
> the call, i.e. the cost of a symbolref vs the cost of a register. It does
> not take into consideration that it is doing a call. This doesn't seem like
> a good idea to me.

Also it looks like various other targets may have the same issue as using one
instruction for direct and indirect tailcalls is common among RISC targets.

So this is another generic cost issue whether it isn't possible to return
correct costs.

> Apart from that, I am now looking into letting arm_get_frame_offsets
> recalculate the offsets and registers to push and pop past reload_completed.
> I am not convinced this is entirely safe yet...

Indeed, as long as leaf_function_p is used in backends recomputing won't work.
Also accidentally changing the elimination offsets after reload will cause
havoc...

[Bug middle-end/64516] [5 Regression] arm: wrong unaligned load generated

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/70909] Libiberty Demangler segfaults (4)

[mark at gcc dot gnu.org]

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

--- Comment #20 from Mark Wielaard  ---
Created attachment 40213
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40213=edit
Add is_cyclic check to d_lookup_template_argument

The patch that Marcel originally proposed tried to catch any recursive printing
and if so stop (but not fail) the demangling.

The reviews seemed to suggest that people found this a bit too costly and that
the check should be more specific and that it should produce an error.
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg02093.html
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01985.html

So maybe we should extract the cyclic detection so it can be used in "debug
mode" and inserted in the "right place".

The attached does that (minus adding a debug mode) and catches some of the
crashes.

[Bug tree-optimization/66598] [5 Regression] With -O3 gcc incorrectly assumes aligned SSE instructions (e.g. movapd) can be used

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/78633] New: [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[kkojima at gcc dot gnu.org]

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

Bug ID: 78633
   Summary: [7 Regression] [SH] libgcc/fp-bit.c:944:1: error:
invalid rtl sharing found in the insn
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kkojima at gcc dot gnu.org
  Target Milestone: ---
Target: sh*-*-*

Build fails during compiling libgcc.

../../../ORIG/trunk/libgcc/fp-bit.c: In function '__muldf3':
../../../ORIG/trunk/libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in
the insn
 }
 ^
(insn 804 311 318 28 (set (reg:SI 147 t)
(eq:SI (and:SI (subreg:SI (reg/v:DI 205 [ high ]) 0)
(const_int 1 [0x1]))
(const_int 0 [0]))) "../../../ORIG/trunk/libgcc/fp-bit.c":881 -1
 (nil))
../../../ORIG/trunk/libgcc/fp-bit.c:944:1: error: shared rtx
(subreg:SI (reg/v:DI 205 [ high ]) 0)
../../../ORIG/trunk/libgcc/fp-bit.c:944:1: internal compiler error: internal
consistency failure
0x8386b17 verify_rtx_sharing
../../ORIG/trunk/gcc/emit-rtl.c:2743
0x8386a28 verify_rtx_sharing
../../ORIG/trunk/gcc/emit-rtl.c:2758
0x8386a28 verify_rtx_sharing
../../ORIG/trunk/gcc/emit-rtl.c:2758
0x8386a28 verify_rtx_sharing
../../ORIG/trunk/gcc/emit-rtl.c:2758
0x8386feb verify_insn_sharing
../../ORIG/trunk/gcc/emit-rtl.c:2829
0x838b256 verify_rtl_sharing()
../../ORIG/trunk/gcc/emit-rtl.c:2852
0x8606233 execute_function_todo
../../ORIG/trunk/gcc/passes.c:1982
0x8606a9b do_per_function
../../ORIG/trunk/gcc/passes.c:1649
0x8606c1d execute_todo
../../ORIG/trunk/gcc/passes.c:2015

It looks that re-enabled RTL sharing verification reveals some rtl sharing
issue of this target.

[Bug target/67288] [5/6/7 regression] non optimal simple function (useless additional shift/remove/shift/add)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c/67410] [5 Regression] c/c-typeck.c references out of bounds array

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/68390] [5 Regression] Incorrect code due to indirect tail call of varargs function with hard float ABI

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/69019] [5 regression] Failure of test case gcc.target/powerpc/ti_math1.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug libstdc++/71415] [DR 2725] std::filesystem::exists that does not throw sets error code if file does not exist

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #7 from Jonathan Wakely  ---
I fixed this in r241417 and will be backporting it soon.

[Bug lto/69188] [5/6/7 Regression] ICE when linking objects at different optimization levels with LTO and profile generation enabled. (Works with 4.9.3.)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-01
 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Known to work||4.9.4
 Ever confirmed|0   |1
  Known to fail||5.4.0, 6.2.0, 7.0

--- Comment #18 from Richard Biener  ---
Confirmed.

lto1: internal compiler error: in lto_varpool_replace_node, at
lto/lto-symtab.c:122
0x62e519 lto_varpool_replace_node
/space/rguenther/src/gcc-git/gcc/lto/lto-symtab.c:122
0x62f67a lto_symtab_merge_symbols_1
/space/rguenther/src/gcc-git/gcc/lto/lto-symtab.c:882
0x62f67a lto_symtab_merge_symbols()
/space/rguenther/src/gcc-git/gcc/lto/lto-symtab.c:939
0x62352e read_cgraph_and_symbols
/space/rguenther/src/gcc-git/gcc/lto/lto.c:2930
0x62352e lto_main()
/space/rguenther/src/gcc-git/gcc/lto/lto.c:3304
Please submit a full bug report,

The test is just using -O -fprofile-generate -flto -fPIC and letting option
auto-deduce work at link time (no options given). One file is built with -O0.

118 static void
119 lto_varpool_replace_node (varpool_node *vnode,
120   varpool_node *prevailing_node)
121 {
122   gcc_assert (!vnode->definition || prevailing_node->definition);
123   gcc_assert (!vnode->analyzed || prevailing_node->analyzed);
124
125   prevailing_node->clone_referring (vnode);
126   if (vnode->force_output)
(gdb) p vnode->definition
$1 = 1
(gdb) p prevailing_node->definition
$2 = 0
(gdb) p vnode->analyzed
$3 = 1
(gdb) p prevailing_node->analyzed
$4 = 0

[Bug target/69311] [5 Regression] ICE (cc1 killed) on s390x-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/70778] [5 regression] internal compiler error: in tsubst, at cp/pt.c:12158

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||6.2.0, 7.0
  Known to fail|7.0 |5.4.0

[Bug c++/71195] [5 Regression] ICE in classify_argument on invalid code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/71506] [5 Regression] ICE with libvpx with -floop-interchange: isl_constraint.c:627: expecting integer value

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/71784] [5/6/7 Regression] ICE on invalid code in push_access_scope, at cp/pt.c:229

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
   Priority|P3  |P4

[Bug rtl-optimization/71724] [5/6/7 Regression] ICE: Segmentation fault, deep recursion between combine_simplify_rtx and subst

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/71875] [5 Regression] template specialization compile error

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/72707] [5/6/7 regression] local anonymous union member hides names in the same scope

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-01
 Ever confirmed|0   |1

[Bug rtl-optimization/78596] combine.c:12561:14: runtime error: left shift of negative value -9

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
fixed.

[Bug fortran/72716] [5/6 Regression] ICE in gfc_resolve_omp_declare_simd, at fortran/openmp.c:5156

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
  Known to work||7.0

[Bug target/72717] [5/6/7 Regression] ICE: in emit_move_insn, at expr.c:3693 with vector shift @ powerpc64le

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c/72816] [5 Regression] ICE on x86_64-linux-gnu (tree check: expected tree that contains ‘decl with RTL’ structure, have ‘field_decl’ in set_decl_rtl, at emit-rtl.c:1282)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug rtl-optimization/78596] combine.c:12561:14: runtime error: left shift of negative value -9

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
Author: trippels
Date: Thu Dec  1 14:04:13 2016
New Revision: 243111

URL: https://gcc.gnu.org/viewcvs?rev=243111=gcc=rev
Log:
Fix rtl-optimization/78596 - combine.c:12561:14: runtime error: left shift of
negative value

PR rtl-optimization/78596
* combine.c (simplify_comparison): Cast to unsigned to avoid
left shifting of negative value.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c