[Bug fortran/65532] [5 Regression] Unexpected error with legacy code (D1MACH)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-24
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
It indeed is r221586.

[Bug lto/65536] New: [5 regression] LTO line number information garbled

[hubicka at gcc dot gnu.org]

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

Bug ID: 65536
   Summary: [5 regression] LTO line number information garbled
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org

As shown in https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01151.html
warnings seems to come out wrong with large programs.  I did not manage to
reproduce it with small testcase.  Columns tends to be 0 and line numbers
(somewhat) off usually pointing to the begging of type definition instead of
the field in question but sometimes they just point in further distance.

This reproduce both on Fireofx and Chromium

The problem goes away with:

Index: lto-streamer-in.c
===
--- lto-streamer-in.c   (revision 221582)
+++ lto-streamer-in.c   (working copy)
@@ -200,7 +200,7 @@ lto_input_location (struct bitpack_d *bp
   if (column_change)
 current_col = bp_unpack_var_len_unsigned (bp);

-  if (file_change)
+  if (file_change || 1)
 {
   if (prev_file)
linemap_add (line_table, LC_LEAVE, false, NULL, 0);

(which also quite significantly increases memory use).  The warnings seems to
be right on beggining and gets worse at end, so I suspect it is some kind of
overflow in libcpp.

The problem stays with:

Index: lto-streamer-in.c
===
--- lto-streamer-in.c   (revision 221582)
+++ lto-streamer-in.c   (working copy)
@@ -207,7 +207,7 @@ lto_input_location (struct bitpack_d *bp

   linemap_add (line_table, LC_ENTER, false, current_file, current_line);
 }
-  else if (line_change)
+  else if (line_change || 1)
 linemap_line_start (line_table, current_line, current_col);

   return linemap_position_for_column (line_table, current_col);

One obvious thing is that linemap_line_start takes argument 3 to be max column
hint, but we pass current_col that is not cool.

I see that libcpp seems to drop the column info after some threshold (that is
clearly too small for LTO) but why the line numbers are off?

[Bug target/65535] New: powerpc64-freebsd build failure

[msebor at gcc dot gnu.org]

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

Bug ID: 65535
   Summary: powerpc64-freebsd build failure
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org

Building gcc for powerpc64-freebsd fails with the error below.  Looks like the
FBSD_MAJOR macro is defined to nothing:

$ grep FBSD_MAJOR ./gcc/tm.h
#ifndef FBSD_MAJOR
# define FBSD_MAJOR

Defining the macro to an integer such as 10 lets the build succeed.

g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../ppc64fbsd-src/gcc
-I../../ppc64fbsd-src/gcc/build -I../../ppc64fbsd-src/gcc/../include 
-I../../ppc64fbsd-src/gcc/../libcpp/include  \
-o build/print-rtl.o ../../ppc64fbsd-src/gcc/print-rtl.c
In file included from ./tm.h:21:0,
 from ../../ppc64fbsd-src/gcc/print-rtl.c:30:
../../ppc64fbsd-src/gcc/config/freebsd-spec.h:108:16: error: operator '<' has
no left operand
 #if FBSD_MAJOR < 5
^
../../ppc64fbsd-src/gcc/config/freebsd-spec.h:130:16: error: operator '<' has
no left operand
 #if FBSD_MAJOR < 6
^
Makefile:2422: recipe for target 'build/gensupport.o' failed
make[1]: *** [build/gensupport.o] Error 1
make[1]: *** Waiting for unfinished jobs
Makefile:2422: recipe for target 'build/print-rtl.o' failed
make[1]: *** [build/print-rtl.o] Error 1
rm gcov-tool.pod gcj-dbtool.pod gfortran.pod jcf-dump.pod jv-convert.pod
grmic.pod gcj.pod fsf-funding.pod cpp.pod gcov.pod gij.pod gc-analyze.pod
gcc.pod gfdl.pod
make[1]: Leaving directory '/home/msebor/build/powerpc64-freebsd/gcc'
Makefile:4129: recipe for target 'all-gcc' failed
make: *** [all-gcc] Error 2

[Bug middle-end/65534] tailcall not optimized away

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-24
 CC||hubicka at gcc dot gnu.org,
   ||mliska at suse dot cz
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

[Bug middle-end/65534] tailcall not optimized away

[hubicka at ucw dot cz]

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

--- Comment #1 from Jan Hubicka  ---
> #ifndef OPTIMIZE_MANUALLY
> void setutent(void) {
> ((void)0);
> __setutent_unlocked();
> ((void)0);
> }
> #else
> extern __typeof (__setutent_unlocked) setutent
> __attribute__ ((alias ("__setutent_unlocked")));
> #endif

I do not think GCC can safely optimize this, becuase in the first
case &setutent != &__setutent_unlocked, wile in the optimized
case the addresses are equal.

This is something we looked into with Martin Liska but was late for
GCC 5.  We have -fmerge-all-constants, we may want to introduce something
like -fmerge-all-functions declaring that this special case does not matter
(curiously enough there is real world code that actually compares the addresses
of otherwise equivalent functions, like in GCC PCH implementation).

Second thing is to make ipa-ICF to discover wrappers and consider them
semantically equivalent to their target.  Something I also discussed with
Martin.

So hopefully early next stage1 this can be implemented.

Honza

[Bug middle-end/65533] [5 Regression] 252.eon in SPEC CPU 2000 failed to build

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-24
 CC||rguenther at suse dot de
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
It was caused by r221592.

[Bug middle-end/35341] Early exit loop with short known trip count not unrolled

[aldot at gcc dot gnu.org]

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

 CC||aldot at gcc dot gnu.org

--- Comment #1 from Bernhard Reutner-Fischer  ---
Did you forget to specify -funroll-loops?

gcc-4.2 -O2 -funroll-loops and gcc-4.4 as well as 5.0 with these options
basically generate this optimized dump, which IIUC is what you want.

;; Function foo (foo)

Analyzing Edge Insertions.
foo ()
{
  int temp.34;
  int temp.31;
  int temp.29;
  int temp.26;
  int temp.25;

:
  temp.25 = a[0];
  temp.26 = temp.25 + temp.25;
  a[0] = temp.26;
  if (temp.26 == 10)
goto ;
  else
goto ;

:
  temp.29 = a[2] + a[1];
  a[2] = temp.29;
  if (temp.29 == 10)
goto ;
  else
goto ;

:
  temp.31 = temp.29 + a[4];
  a[4] = temp.31;
  if (temp.31 == 10)
goto ;
  else
goto ;

:
  temp.34 = a[6] + a[3];
  a[6] = temp.34;
  if (temp.34 == 10)
goto ;
  else
goto ;

:
  a[8] = [plus_expr] a[8] + a[4];

:
  return 0;

}

[Bug ipa/65502] pure-const should play well with clobbers.

[hubicka at ucw dot cz]

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

--- Comment #5 from Jan Hubicka  ---
> I think we can safely ignore clobbers when scanning functions for
> pure/constness.

Yes (it is what the patch does), but doing so may cause worse code in the
function calling these destructors.  DCE will remove the destructor call and we
will lose information about memory location being dead.
I think we may want to output the clobber after destructors calls in this case.

[Bug c/65534] New: tailcall not optimized away

[aldot at gcc dot gnu.org]

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

Bug ID: 65534
   Summary: tailcall not optimized away
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aldot at gcc dot gnu.org
CC: hubicka at ucw dot cz, rguenth at gcc dot gnu.org

Maybe this could be optimized by a thunk or by creating the alias automatically
or the like? Or is tailcall supposed to do this already?

trunk@221345
$ gcc -Os -c missed-opt.c -o missed-opt.plain.o
$ gcc -Os -c missed-opt.c -o missed-opt.manual.o -DOPTIMIZE_MANUALLY
$ size missed-opt.*.o
   text   databssdechexfilename
 86  0  0 86 56missed-opt.manual.o
104  0  0104 68missed-opt.plain.o

$ cat missed-opt.c ; echo EOF
static int fd = -1;
extern void dummy0(void);
extern void dummy1(int);
extern void setutent(void) __attribute__ ((__nothrow__ ));
extern __typeof (setutent) setutent __asm__ ("" "__GI_setutent")
__attribute__ ((visibility ("hidden")));
extern void getutent(void) __attribute__ ((__nothrow__ ));
extern __typeof (getutent) getutent __asm__ ("" "__GI_getutent")
__attribute__ ((visibility ("hidden")));
static void __setutent_unlocked(void) {
if (fd < 0) {
dummy0();
if (fd < 0) {
dummy0();
if (fd < 0)
return;
}
return;
}
dummy1(fd);
}
#ifndef OPTIMIZE_MANUALLY
void setutent(void) {
((void)0);
__setutent_unlocked();
((void)0);
}
#else
extern __typeof (__setutent_unlocked) setutent
__attribute__ ((alias ("__setutent_unlocked")));
#endif
extern __typeof (setutent) __EI_setutent __asm__("" "setutent");
extern __typeof (setutent) __EI_setutent
__attribute__((alias ("" "__GI_setutent")));

static void __getutent_unlocked(void) {
if (fd < 0)
__setutent_unlocked();
}

#ifndef OPTIMIZE_MANUALLY
void getutent(void) {
((void)0);
__getutent_unlocked();
((void)0);
}
#else
extern __typeof (__getutent_unlocked) getutent
__attribute__ ((alias ("__getutent_unlocked")));
#endif
extern __typeof (getutent) __EI_getutent __asm__("" "getutent");
extern __typeof (getutent) __EI_getutent
__attribute__((alias ("" "__GI_getutent")));

EOF

[Bug middle-end/65533] New: [5 Regression] 252.eon in SPEC CPU 2000 failed to build

[hjl.tools at gmail dot com]

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

Bug ID: 65533
   Summary: [5 Regression] 252.eon in SPEC CPU 2000 failed to
build
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com

On Linux/x86-64, r221604 gave

g++ -c -o ggHMatrix3.o   -DSPEC_CPU2000_LP64 -DHAS_ERRLIST-I. -DNDEBUG
-O3 -funroll-loops -ffast-math   ggHMatrix3.cc
ggHMatrix3.cc: In function 'ggHPoint3 operator*(const ggHMatrix3&, const
ggHPoint3&)':
ggHMatrix3.cc:303:11: internal compiler error: in quick_push, at vec.h:867
 ggHPoint3 operator*(const ggHMatrix3 &m, const ggHPoint3 &p) {
   ^
0xedabf3 vec<_slp_tree*, va_heap, vl_embed>::quick_push(_slp_tree* const&)
../../src-trunk/gcc/vec.h:867
0xedabf3 vec<_slp_tree*, va_heap, vl_ptr>::quick_push(_slp_tree* const&)
../../src-trunk/gcc/vec.h:1525
0xedabf3 vec<_slp_tree*, va_heap, vl_ptr>::safe_push(_slp_tree* const&)
../../src-trunk/gcc/vec.h:1538
0xedabf3 vect_build_slp_tree
../../src-trunk/gcc/tree-vect-slp.c:955
0xeda6a9 vect_build_slp_tree
../../src-trunk/gcc/tree-vect-slp.c:1054
0xeda445 vect_build_slp_tree
../../src-trunk/gcc/tree-vect-slp.c:1010
0xedc2bc vect_analyze_slp_instance
../../src-trunk/gcc/tree-vect-slp.c:1636
0xedda56 vect_analyze_slp(_loop_vec_info*, _bb_vec_info*, unsigned int)
../../src-trunk/gcc/tree-vect-slp.c:1768
0xeddf29 vect_slp_analyze_bb_1
../../src-trunk/gcc/tree-vect-slp.c:2300
0xeddf29 vect_slp_analyze_bb(basic_block_def*)
../../src-trunk/gcc/tree-vect-slp.c:2421
0xee0332 execute
../../src-trunk/gcc/tree-vectorizer.c:657
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/65532] [5 Regression] Unexpected error with legacy code (D1MACH)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #2 from Dominique d'Humieres  ---
I suspect r221586: I don't see the errors at r221569.

> I found a workaround by changing the dimension of the arrays in
> lines 7-11 to 2 instead of 4 (the original code also supports
> dated hardware).

Confirmed.

[Bug fortran/65532] [5 Regression] Unexpected error with legacy code (D1MACH)

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

  Known to work||4.9.0
  Known to fail||5.0

--- Comment #1 from Harald Anlauf  ---
I found a workaround by changing the dimension of the arrays in
lines 7-11 to 2 instead of 4 (the original code also supports
dated hardware).

[Bug fortran/65532] New: [5 Regression] Unexpected error with legacy code (D1MACH)

[anlauf at gmx dot de]

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

Bug ID: 65532
   Summary: [5 Regression] Unexpected error with legacy code
(D1MACH)
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gmx dot de

Created attachment 35119
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35119&action=edit
Bug demo.

Dear all,

after updating to trunk rev. 221607, I found a problem which I reduced
to the attached example.

Commenting out the call to d1mach or commenting out in d1mach the
data statements in lines 21-25 makes the error messages disappear.

Here's the error messages I get:

% gfc-trunk -c gfcbug131.f90
gfcbug131.f90:10:23:

 INTEGER :: diver(4)
   1
Error: Different shape for array assignment at (1) on dimension 1 (4 and 2)
gfcbug131.f90:8:23:

 INTEGER :: large(4)
   1
Error: Different shape for array assignment at (1) on dimension 1 (4 and 2)
gfcbug131.f90:11:23:

 INTEGER :: LOG10(4)
   1
Error: Different shape for array assignment at (1) on dimension 1 (4 and 2)
gfcbug131.f90:9:23:

 INTEGER :: right(4)
   1
Error: Different shape for array assignment at (1) on dimension 1 (4 and 2)
gfcbug131.f90:7:23:

 INTEGER :: small(4)
   1
Error: Different shape for array assignment at (1) on dimension 1 (4 and 2)

[Bug testsuite/65506] [5 Regression] FAIL: gcc.dg/pr29215.c scan-tree-dump-not gimple "memcpy"

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||olegendo at gcc dot gnu.org

--- Comment #7 from Oleg Endo  ---
*** Bug 65529 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/65529] [5 Regression][SH] gcc.dg/pr29215.c failing

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #1 from Oleg Endo  ---
Duplicate of PR 65506.

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

[Bug ipa/62051] [4.9/5 Regression] Undefined reference to vtable with -O2 and -fdevirtualize-speculatively

[hubicka at ucw dot cz]

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

--- Comment #7 from Jan Hubicka  ---
> 
> Yes, though I think for such a class we probably want to consider all virtual
> methods unreachable unless they have explicit default visibility; in the
> testcase the main program isn't being compiled with -fvisibility=hidden, so
> ~Derived has implicit default visibility.

Yes, I think this makes sense.  Do you think you can implement the C++ FE part
that will mark classes having methods with visibility specified?
We do not LTO stream TYPE_METHODS so this is bit hard to determine at
gimple-fold
time.  At some point I tried to enable TYPE_METHODS streaming but it had bad
effect on firefox LTO linktimes by significantly increasing strongly connected
component size.

[Bug target/65531] New: ICE: symtab_node::verify failed: Two symbols with same comdat_group are not linked by the same_comdat_group list. with -fcheck-pointer-bounds -mmpx

[zsojka at seznam dot cz]

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

Bug ID: 65531
   Summary: ICE: symtab_node::verify failed: Two symbols with same
comdat_group are not linked by the same_comdat_group
list. with -fcheck-pointer-bounds -mmpx
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz

Created attachment 35118
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35118&action=edit
reduced testcase

Compiler output:
$ gcc -fcheck-pointer-bounds -mmpx testcase.C 
testcase.C:10:4: error: Two symbols with same comdat_group are not linked by
the same_comdat_group list.
 S s;
^
_ZN1SD1Ev.chkp/11 (S::~S(#'pointer_bounds_type' not supported by
dump_type#, void, ...)) @0x7f52d8b0f310
  Type: function definition analyzed alias cpp_implicit_alias
  Visibility: external public weak comdat comdat_group:_ZN1SD5Ev one_only
  Same comdat group as: _ZN1SD1Ev/2
  Address is taken.
  References: _ZN1SD2Ev.chkp/10 (alias)
  Referring: _ZN1SD1Ev/2 (chkp)
  Availability: available
  First run: 0
  Function flags:
  Called by: 
  Calls: 
  Is instrumented version.
_ZN1SD2Ev.chkp/10 (S::~S(#'pointer_bounds_type' not supported by
dump_type#, void, ...)) @0x7f52d8b0f188
  Type: function definition analyzed
  Visibility: external public weak comdat comdat_group:_ZN1SD5Ev one_only
artificial
  Same comdat group as: _ZN1SD2Ev/1
  Address is taken.
  References: 
  Referring: _ZN1SD1Ev.chkp/11 (alias)_ZN1SD2Ev/1 (chkp)
  Availability: available
  First run: 0
  Function flags: body
  Called by: _ZN1SD2Ev/1 (1.00 per call) 
  Calls: 
  Is instrumented version.
testcase.C:10:4: internal compiler error: symtab_node::verify failed
0x9dc3c4 symtab_node::verify_symtab_nodes()
/mnt/svn/gcc-trunk/gcc/symtab.c:1140
0xc28668 symbol_table::remove_unreachable_nodes(_IO_FILE*)
/mnt/svn/gcc-trunk/gcc/ipa.c:686
0xd0d4bd execute_todo
/mnt/svn/gcc-trunk/gcc/passes.c:2023
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ gcc -v 
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-221530-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-221530-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl
Thread model: posix
gcc version 5.0.0 20150320 (experimental) (GCC) 

Tested revisions:
r221530 - ICE

[Bug testsuite/65506] [5 Regression] FAIL: gcc.dg/pr29215.c scan-tree-dump-not gimple "memcpy"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/65523] ICE: in gimple_op, at gimple.h:2270 with -fcheck-pointer-bounds -mmpx

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug testsuite/65506] [5 Regression] FAIL: gcc.dg/pr29215.c scan-tree-dump-not gimple "memcpy"

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Mon Mar 23 20:04:43 2015
New Revision: 221607

URL: https://gcc.gnu.org/viewcvs?rev=221607&root=gcc&view=rev
Log:
2015-03-23  Jakub Jelinek  

PR testsuite/65506
* gcc.dg/pr29215.c: Dump and analyze ccp1 dump instead of
gimple dump.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr29215.c

[Bug target/65523] ICE: in gimple_op, at gimple.h:2270 with -fcheck-pointer-bounds -mmpx

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Mar 23 20:03:50 2015
New Revision: 221606

URL: https://gcc.gnu.org/viewcvs?rev=221606&root=gcc&view=rev
Log:
PR target/65523
* tree-chkp.c (chkp_build_returned_bound): Ignore
ERF_RETURNS_ARG calls if they have fewer than needed arguments.

* gcc.target/i386/pr65523.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr65523.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-chkp.c

[Bug c++/59256] qualified name in friend function declaration doesn't match previous declaration in inline namespace

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug lto/65475] [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Mon Mar 23 19:51:51 2015
New Revision: 221605

URL: https://gcc.gnu.org/viewcvs?rev=221605&root=gcc&view=rev
Log:
PR ipa/65475
* g++.dg/lto/pr65475_0.C: Use dg-lto-options instead of
dg-options.
* g++.dg/lto/pr65475b_0.C: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/lto/pr65475_0.C
trunk/gcc/testsuite/g++.dg/lto/pr65475b_0.C

[Bug other/65530] New: [meta-bug] -mmpx -fcheck-pointer-bounds failures

[hjl.tools at gmail dot com]

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

Bug ID: 65530
   Summary: [meta-bug] -mmpx -fcheck-pointer-bounds failures
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: enkovich.gnu at gmail dot com
  Reporter: hjl.tools at gmail dot com

This meta-bug tracks all known -mmpx -fcheck-pointer-bounds failures.

[Bug tree-optimization/65529] New: [5 Regression][SH] gcc.dg/pr29215.c failing

[olegendo at gcc dot gnu.org]

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

Bug ID: 65529
   Summary: [5 Regression][SH] gcc.dg/pr29215.c failing
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*

The test case for PR 29215 started to fail on SH:

FAIL: gcc.dg/pr29215.c scan-tree-dump-not gimple "memcpy"

Looking at the assembly output of the test case, the memcpy is optimized away,
albeit at a later stage during compilation through builtin expansion.

One option would be to scan the final assembly output for 'memcpy' symbols:

Index: gcc/testsuite/gcc.dg/pr29215.c
===
--- gcc/testsuite/gcc.dg/pr29215.c(revision 221603)
+++ gcc/testsuite/gcc.dg/pr29215.c(working copy)
@@ -1,6 +1,6 @@
 /* PR middle-end/29215 */
 /* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-gimple" } */
+/* { dg-options "-O2" } */

 char buf[5 * sizeof (int) + 1] __attribute__((aligned (__alignof__ (int;

@@ -29,5 +29,4 @@
   return 0;
 }

-/* { dg-final { scan-tree-dump-not "memcpy" "gimple" } } */
-/* { dg-final { cleanup-tree-dump "gimple" } } */
+/* { dg-final { scan-assembler-not "memcpy" } } */

However, PR 29215 was specifically about optimizing away memcpy at the tree
level, so I'm not sure whether this is an appropriate "fix".  Something else
must have changed to trigger the new failure ...

In the gimple dump, the foo is:

foo (int arg1, int arg2, int arg3, int arg4, int arg5)
{
  unsigned int D.1477;
  void * D.1478;
  void * D.1479;
  void * D.1480;
  void * D.1481;

  D.1477 = MEM[(char * {ref-all})&arg1];
  MEM[(char * {ref-all})&buf] = D.1477;
  D.1478 = &buf + 4;
  __builtin_memcpy (D.1478, &arg2, 4);
  D.1479 = &buf + 8;
  __builtin_memcpy (D.1479, &arg3, 4);
  D.1480 = &buf + 12;
  __builtin_memcpy (D.1480, &arg4, 4);
  D.1481 = &buf + 16;
  __builtin_memcpy (D.1481, &arg5, 4);
}

On 4.9 it looked like this:

foo (int arg1, int arg2, int arg3, int arg4, int arg5)
{
  int D.1387;
  int D.1388;
  int D.1389;
  int D.1390;
  int D.1391;

  D.1387 = MEM[(char * {ref-all})&arg1];
  MEM[(char * {ref-all})&buf] = D.1387;
  D.1388 = MEM[(char * {ref-all})&arg2];
  MEM[(char * {ref-all})&buf + 4B] = D.1388;
  D.1389 = MEM[(char * {ref-all})&arg3];
  MEM[(char * {ref-all})&buf + 8B] = D.1389;
  D.1390 = MEM[(char * {ref-all})&arg4];
  MEM[(char * {ref-all})&buf + 12B] = D.1390;
  D.1391 = MEM[(char * {ref-all})&arg5];
  MEM[(char * {ref-all})&buf + 16B] = D.1391;
}

[Bug other/65528] New: [mpx] internal compiler error: in expand_expr_addr_expr_1, at expr.c:7761

[hjl.tools at gmail dot com]

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

Bug ID: 65528
   Summary: [mpx] internal compiler error: in
expand_expr_addr_expr_1, at expr.c:7761
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com

With this patch:

https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01211.html

when GCC is configured with

--enable-libmpx --with-build-config="bootstrap-mpx"

I got

/export/build/gnu/gcc-test/build-x86_64-linux/./prev-gcc/xg++
-B/export/build/gnu/gcc-test/build-x86_64-linux/./prev-gcc/
-B/usr/gcc-5.0.0/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/export/build/gnu/gcc-test/build-x86_64-linux/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/export/build/gnu/gcc-test/build-x86_64-linux/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/export/build/gnu/gcc-test/build-x86_64-linux/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu

-I/export/build/gnu/gcc-test/build-x86_64-linux/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
 -I/export/gnu/import/git/sources/gcc/libstdc++-v3/libsupc++
-L/export/build/gnu/gcc-test/build-x86_64-linux/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/export/build/gnu/gcc-test/build-x86_64-linux/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -fcheck-pointer-bounds -mmpx
-DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -Ic-family
-I/export/gnu/import/git/sources/gcc/gcc
-I/export/gnu/import/git/sources/gcc/gcc/c-family
-I/export/gnu/import/git/sources/gcc/gcc/../include
-I/export/gnu/import/git/sources/gcc/gcc/../libcpp/include 
-I/export/gnu/import/git/sources/gcc/gcc/../libdecnumber
-I/export/gnu/import/git/sources/gcc/gcc/../libdecnumber/bid -I../libdecnumber
-I/export/gnu/import/git/sources/gcc/gcc/../libbacktrace   -o
c-family/stub-objc.o -MT c-family/stub-objc.o -MMD -MP -MF
c-family/.deps/stub-objc.TPo
/export/gnu/import/git/sources/gcc/gcc/c-family/stub-objc.c
/export/gnu/import/git/sources/gcc/gcc/c-family/stub-objc.c: In function
‘tree_node* objc_rewrite_function_call.chkp(tree, #‘pointer_bounds_type’ not
supported by dump_type#, tree, #‘pointer_bounds_type’ not supported
by dump_type#, void, ...)’:
/export/gnu/import/git/sources/gcc/gcc/c-family/stub-objc.c:104:1: internal
compiler error: in expand_expr_addr_expr_1, at expr.c:7761
 objc_rewrite_function_call (tree function, tree ARG_UNUSED (first_param))
 ^
0xb6844a expand_expr_addr_expr_1
/export/gnu/import/git/sources/gcc/gcc/expr.c:7761
0xb68ae4 expand_expr_addr_expr
/export/gnu/import/git/sources/gcc/gcc/expr.c:7850
0xb74308 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/export/gnu/import/git/sources/gcc/gcc/expr.c:10724
0xb68f1b expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/export/gnu/import/git/sources/gcc/gcc/expr.c:8018
0xa20d5b expand_normal
/export/gnu/import/git/sources/gcc/gcc/expr.h:260
0xa2d4d5 expand_return
/export/gnu/import/git/sources/gcc/gcc/cfgexpand.c:3231
0xa2dc5e expand_gimple_stmt_1
/export/gnu/import/git/sources/gcc/gcc/cfgexpand.c:3373
0xa2e1c3 expand_gimple_stmt
/export/gnu/import/git/sources/gcc/gcc/cfgexpand.c:3497
0xa3528d expand_gimple_basic_block
/export/gnu/import/git/sources/gcc/gcc/cfgexpand.c:5509
0xa36f3a execute
/export/gnu/import/git/sources/gcc/gcc/cfgexpand.c:6127
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make: *** [c-family/stub-objc.o] Error 1
[hjl@gnu-mic-2 gcc]$

[Bug target/65505] [5 Regression][SH] ICE in sh_disp_addr_displacement

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #5 from Oleg Endo  ---
Fixed for GCC 5.

[Bug target/65527] New: ICE: in expand_builtin_with_bounds, at builtins.c:7120 with -fcheck-pointer-bounds -mmpx

[zsojka at seznam dot cz]

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

Bug ID: 65527
   Summary: ICE: in expand_builtin_with_bounds, at builtins.c:7120
with -fcheck-pointer-bounds -mmpx
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz

Created attachment 35117
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35117&action=edit
reduced testcase

Compiler output:
$ gcc -Os -fcheck-pointer-bounds -mmpx testcase.c
testcase.c: In function 'foo.chkp':
testcase.c:7:3: internal compiler error: in expand_builtin_with_bounds, at
builtins.c:7120
   f (&i);
   ^
0x7cf7e0 expand_builtin_with_bounds(tree_node*, rtx_def*, rtx_def*,
machine_mode, int)
/mnt/svn/gcc-trunk/gcc/builtins.c:7119
0x904b27 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/mnt/svn/gcc-trunk/gcc/expr.c:10487
0x7ff238 expand_expr
/mnt/svn/gcc-trunk/gcc/expr.h:254
0x7ff238 expand_call_stmt
/mnt/svn/gcc-trunk/gcc/cfgexpand.c:2399
0x7ff238 expand_gimple_stmt_1
/mnt/svn/gcc-trunk/gcc/cfgexpand.c:3343
0x7ff238 expand_gimple_stmt
/mnt/svn/gcc-trunk/gcc/cfgexpand.c:3497
0x803cb4 expand_gimple_basic_block
/mnt/svn/gcc-trunk/gcc/cfgexpand.c:5509
0x8067a6 execute
/mnt/svn/gcc-trunk/gcc/cfgexpand.c:6127
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ gcc -v
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-221530-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-221530-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl
Thread model: posix
gcc version 5.0.0 20150320 (experimental) (GCC) 

Tested revisions:
r221530 - ICE

[Bug target/65505] [5 Regression][SH] ICE in sh_disp_addr_displacement

[olegendo at gcc dot gnu.org]

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

--- Comment #4 from Oleg Endo  ---
Author: olegendo
Date: Mon Mar 23 18:57:58 2015
New Revision: 221604

URL: https://gcc.gnu.org/viewcvs?rev=221604&root=gcc&view=rev
Log:
gcc/
PR target/65505
* config/sh/predicates.md (simple_mem_operand,
displacement_mem_operand): Add test for reg.
(short_displacement_mem_operand): Test for displacement_mem_operand
before invoking sh_disp_addr_displacement.
* config/sh/constraints.md (Sdd, Sra): Simplify.
* config/sh/sync.md (atomic_mem_operand_0, atomic_mem_operand_1):
Remove redundant displacement_mem_operand tests.

gcc/testsuite/
PR target/65505
* gcc.target/sh/torture/pr65505.c: New.

Added:
trunk/gcc/testsuite/gcc.target/sh/torture/pr65505.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/constraints.md
trunk/gcc/config/sh/predicates.md
trunk/gcc/config/sh/sync.md
trunk/gcc/testsuite/ChangeLog

[Bug ada/65519] [5 regression] unable to coalesce ssa_names 2 and 87 which are marked as MUST COALESCE

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #7 from Eric Botcazou  ---
> I don't think that gimple_build can fail, so maybe the way out is to test
>   stmt_references_abnormal_ssa_name (SSA_NAME_DEF_STMT (ops[x]))
> instead of just
>   SSA_NAME_OCCURS_IN_ABNORMAL_PHI (ops [x]))
> in replace_stmt_with_simplification.

Richard, does gimple-fold.c only fold the outermost expression like
fold-const.c or does it work recursively?  In the former case, the above change
would be OK but, in the latter case, some changes in genmatch.c itself might be
needed.

[Bug target/65296] [avr] fix various issues with specs file generation

[gjl at gcc dot gnu.org]

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

--- Comment #7 from Georg-Johann Lay  ---
Author: gjl
Date: Mon Mar 23 18:19:01 2015
New Revision: 221602

URL: https://gcc.gnu.org/viewcvs?rev=221602&root=gcc&view=rev
Log:
PR target/65296
* config/avr/driver-avr.c (avr_devicespecs_file): Allow to specify
the same -mmcu=MCU more than once.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/driver-avr.c

[Bug ipa/62051] [4.9/5 Regression] Undefined reference to vtable with -O2 and -fdevirtualize-speculatively

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
(In reply to Jan Hubicka from comment #5)
> I suppose we could make C++ FE to track if a type has methods with
> visibility default declared (I can't track that from symbol table as they
> may be unreachable). In such case we may want to consider methods of that
> type with non-default visibility and no resolution info to be
> !can_refer_decl_in_current_unit_p
> 
> Jason, would that make sense to you?

Yes, though I think for such a class we probably want to consider all virtual
methods unreachable unless they have explicit default visibility; in the
testcase the main program isn't being compiled with -fvisibility=hidden, so
~Derived has implicit default visibility.

[Bug ipa/65516] lto1: internal compiler error: in get_odr_type, at ipa-devirt.c:1809

[hubicka at ucw dot cz]

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

--- Comment #9 from Jan Hubicka  ---
this was also my bug. Sorry for that.  It is fixed on current mainlie.

[Bug testsuite/65526] testsuite checks for arm vectorization support on non-arm targets

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Patch preapproved for trunk.  Please mail it to gcc-patches though.

[Bug testsuite/63175] [4.9 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1

[msebor at gcc dot gnu.org]

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

--- Comment #38 from Martin Sebor  ---
Author: msebor
Date: Mon Mar 23 17:37:25 2015
New Revision: 221601

URL: https://gcc.gnu.org/viewcvs?rev=221601&root=gcc&view=rev
Log:
2015-03-23  Martin Sebor  

PR testsuite/63175
* gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c: Scan
assembly for lvx in addition to lxv.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c

[Bug libstdc++/65147] alignment of std::atomic object is not correct

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
I think std::atomic should increase the alignment of its T member. That will
have the advantage of being layout-compatible with _Atomic T.

[Bug testsuite/65526] New: testsuite checks for arm vectorization support on non-arm targets

[msebor at gcc dot gnu.org]

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

Bug ID: 65526
   Summary: testsuite checks for arm vectorization support on
non-arm targets
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org

Created attachment 35116
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35116&action=edit
Patch to avoid unnecessary testsuite checks.

Running the test suite on powerpc64 (and likely any other architecture) with
the runtest -v option produces output like the following, indicating that gcc
is being invoked to determine whether the target has ARM vectorization support
even though the target is known to be one other than ARM.

check_compile tool: gcc for arm_vect_no_misalign
doing compile
pid is 99288 -99288
close result is 99288 exp6 0 1
output is arm_vect_no_misalign99107.c:3:3: error: #error !__arm__ || (__ARMEL__
&& __ARM_FEATURE_UNALIGNED)
 status 1
compiler exited with status 1

The attached patch adds tests to lib/target-supports.exp to avoid these
unnecessary checks.

[Bug lto/65515] [5 Regression] FAIL: gcc.c-torture/compile/limits-fndefn.c -O2 -flto -flto-partition=none (ICE) -- SIGSEGV for stack growth failure

[dave.anglin at bell dot net]

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

--- Comment #5 from dave.anglin at bell dot net ---
On 2015-03-23 12:39 PM, jakub at gcc dot gnu.org wrote:
> Doesn't seem to be specific to hppa, on x86_64-linux I can reproduce it as
> well, and need ulimit -s 46000 to pass.
> The Fedora default of ulimit -sH unlimited and ulimit -sS 8192 works, because
> gcc automatically attempts to raise stack limit to 64MB if possible.
Unfortunately, this doesn't happen on hpux.  To increase limit, one 
needs to bump kernel
maxssiz and rebuild kernel.

Dave

[Bug libstdc++/65147] alignment of std::atomic object is not correct

[alexey.lapshin at oracle dot com]

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

--- Comment #3 from Alexey Lapshin  ---
(In reply to Jason Merrill from comment #2)
> This does seem like a bug.

What is a proper behavior for G++ in this case ?

should it always align std::atomic object of size 8 at 8 bytes ?

Or should G++ just never inline implementation for atomic routine ?

(see bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65149 when implementation
of atomic routine was inlined for incorrectly aligned atomic object, which
leads to BusError)

[Bug ada/65524] gnatbind generates decrementing the unexisting elab-counter into finalize_library

[demoonlit at panathenaia dot halfmoon.jp]

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

--- Comment #2 from yuta tomino  ---
Created attachment 35115
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35115&action=edit
example

I found the way of reproducing.

A tiny change of a-tags.ads is necessary.
Insert "is null" into Ada.Tags.Register_Tag to suppress the elaboration.
(Is there a pragma or restriction for this purpose?)

Note, Unregister_Tag is unrelated.

And, make a package as Pure or Preelaborate. Add a tagged type.
So the package would have _finalize_spec without _elabs.

(The direct cause of this case is the asymmetry that _elabs is not generated if
Register_Tag is null, against that,
_fialize_spec is always generated even if Unregister_Tag is null.
Register/Unregister_XXX are sometimes suppressed in parts of customized
runtimes.
My customized runtime satisfies the conditions about this time.
However, the way is only example for reproducing.
I think another approach is possibility because Build_Finalizer in exp_ch7.adb
is very complex...)

And then, prepare a main subprogram using the package. Compile and gnatbind.
See b~main.adb.

The log of compiling the attached example:

 % gnatmake -a -gnatp -g main
 gnatbind -x main.ali
 gnatlink main.ali -g
 b~main.adb:31:10: "E81" is undefined (more references follow)
 b~main.adb:34:07: "E05" is undefined (more references follow)
 gnatmake: *** link failed.

By the way, sorry, I realized that my first patch is not proper fix.
For multiple-elaboration, an elaboration-counter should be generated and
incremented in adainit when a _finalize_spec/body is existing, even if _elabs
is not existing.

Thanks.

[Bug lto/65515] [5 Regression] FAIL: gcc.c-torture/compile/limits-fndefn.c -O2 -flto -flto-partition=none (ICE) -- SIGSEGV for stack growth failure

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
This is from:
644  else if (TREE_CODE (expr) == FUNCTION_TYPE
645   || TREE_CODE (expr) == METHOD_TYPE)
646DFS_follow_tree_edge (TYPE_ARG_TYPES (expr));
where TYPE_ARG_TYPES contains a huge TREE_LIST chain (11 TREE_LIST nodes).
>From quick look at DFS::DFS_write_tree and DFS::DFS_write_tree_body, we don't
really have anything there like GTY chain_next, which is clearly highly
desirable here.  Dunno if order matters here, if not, then for TS_LIST counting
number of elements and if it is longer than say 10 or 100, use the vector +
DFS_write_node from the end to start, could work.

[Bug libstdc++/64967] [5 Regression] Bootstrap fails due to errors in libstdc++ sources with `--enable-symvers=gnu-versioned-namespace'

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Fixed. Changing gnu-versioned-namespace to the new ABI can happen after GCC 5.

[Bug libstdc++/64967] [5 Regression] Bootstrap fails due to errors in libstdc++ sources with `--enable-symvers=gnu-versioned-namespace'

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Mon Mar 23 16:47:18 2015
New Revision: 221600

URL: https://gcc.gnu.org/viewcvs?rev=221600&root=gcc&view=rev
Log:
PR libstdc++/64967
* acinclude.m4: Disable dual ABI when gnu-versioned-namespace in use.
* configure: Regenerate.
* src/c++11/compatibility-c++0x.cc (error_category), generic_category,
system_category): Use macros for versioned namespace.
* src/c++11/futex.cc: Add missing end macro for versioned namespace.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/acinclude.m4
trunk/libstdc++-v3/configure
trunk/libstdc++-v3/src/c++11/compatibility-c++0x.cc
trunk/libstdc++-v3/src/c++11/futex.cc

[Bug lto/65515] [5 Regression] FAIL: gcc.c-torture/compile/limits-fndefn.c -O2 -flto -flto-partition=none (ICE) -- SIGSEGV for stack growth failure

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Target|hppa64-hp-hpux11.11 |
 CC||jakub at gcc dot gnu.org
   Host|hppa64-hp-hpux11.11 |
  Build|hppa64-hp-hpux11.11 |

--- Comment #3 from Jakub Jelinek  ---
Doesn't seem to be specific to hppa, on x86_64-linux I can reproduce it as
well, and need ulimit -s 46000 to pass.
The Fedora default of ulimit -sH unlimited and ulimit -sS 8192 works, because
gcc automatically attempts to raise stack limit to 64MB if possible.

Backtrace during crash is:
#0  0x00bacbd0 in DFS::DFS_write_tree (this=, ob=, 
from_state=, expr=, 
ref_p=, this_ref_p=, 
single_p=) at ../../gcc/lto-streamer-out.c:1343
#1  0x00ba499f in DFS::DFS_write_tree_body (this=0x7fffdca0,
ob=0x3e4d9b0, expr=0x7fffef9d57f8, expr_state=0x2522dc0, ref_p=false,
single_p=false) at ../../gcc/lto-streamer-out.c:539
#2  0x00bacf50 in DFS::DFS_write_tree (this=0x7fffdca0,
ob=0x3e4d9b0, from_state=0x2522db0, expr=0x7fffef9d57f8, ref_p=false,
this_ref_p=false, single_p=false) at ../../gcc/lto-streamer-out.c:1376
#3  0x00ba5dae in DFS::DFS_write_tree_body (this=0x7fffdca0,
ob=0x3e4d9b0, expr=0x7fffef9d5820, expr_state=0x2522db0, ref_p=false,
single_p=false) at ../../gcc/lto-streamer-out.c:659
#4  0x00bacf50 in DFS::DFS_write_tree (this=0x7fffdca0,
ob=0x3e4d9b0, from_state=0x2522da0, expr=0x7fffef9d5820, ref_p=false,
this_ref_p=false, single_p=false) at ../../gcc/lto-streamer-out.c:1376
...
#198591 0x00ba5dae in DFS::DFS_write_tree_body (this=0x7fffdca0,
ob=0x3e4d9b0, expr=0x7fffef5a2fa0, expr_state=0x3d3f1d0, ref_p=false,
single_p=false) at ../../gcc/lto-streamer-out.c:659
#198592 0x00bacf50 in DFS::DFS_write_tree (this=0x7fffdca0,
ob=0x3e4d9b0, from_state=0x3d3f1c0, expr=0x7fffef5a2fa0, ref_p=false,
this_ref_p=false, single_p=false) at ../../gcc/lto-streamer-out.c:1376
#198593 0x00ba5dae in DFS::DFS_write_tree_body (this=0x7fffdca0,
ob=0x3e4d9b0, expr=0x7fffef5a2fc8, expr_state=0x3d3f1c0, ref_p=false,
single_p=false) at ../../gcc/lto-streamer-out.c:659
#198594 0x00bacf50 in DFS::DFS_write_tree (this=0x7fffdca0,
ob=0x3e4d9b0, from_state=0x3d3f1b0, expr=0x7fffef5a2fc8, ref_p=false,
this_ref_p=false, single_p=false) at ../../gcc/lto-streamer-out.c:1376
#198595 0x00ba5acb in DFS::DFS_write_tree_body (this=0x7fffdca0,
ob=0x3e4d9b0, expr=0x71975d20, expr_state=0x3d3f1b0, ref_p=false,
single_p=false) at ../../gcc/lto-streamer-out.c:646
#198596 0x00bacf50 in DFS::DFS_write_tree (this=0x7fffdca0,
ob=0x3e4d9b0, from_state=0x3d3f1a0, expr=0x71975d20, ref_p=false,
this_ref_p=false, single_p=false) at ../../gcc/lto-streamer-out.c:1376
#198597 0x00ba499f in DFS::DFS_write_tree_body (this=0x7fffdca0,
ob=0x3e4d9b0, expr=0x719791b0, expr_state=0x3d3f1a0, ref_p=false,
single_p=false) at ../../gcc/lto-streamer-out.c:539
#198598 0x00bacf50 in DFS::DFS_write_tree (this=0x7fffdca0,
ob=0x3e4d9b0, from_state=0x0, expr=0x719791b0, ref_p=false,
this_ref_p=false, single_p=false) at ../../gcc/lto-streamer-out.c:1376
#198599 0x00ba483e in DFS::DFS (this=0x7fffdca0, ob=0x3e4d9b0,
expr=0x719791b0, ref_p=false, this_ref_p=false, single_p=false) at
../../gcc/lto-streamer-out.c:512
#198600 0x00bad6fc in lto_output_tree (ob=0x3e4d9b0,
expr=0x719791b0, ref_p=false, this_ref_p=false) at
../../gcc/lto-streamer-out.c:1571
#198601 0x00bafa3d in write_global_stream (ob=0x3e4d9b0,
encoder=0x3e4d6f0) at ../../gcc/lto-streamer-out.c:2359
#198602 0x00bafb70 in lto_output_decl_state_streams (ob=0x3e4d9b0,
state=0x3e4d6d0) at ../../gcc/lto-streamer-out.c:2406
#198603 0x00bb0af1 in produce_asm_for_decls () at
../../gcc/lto-streamer-out.c:2776
#198604 0x00c25e21 in write_lto () at ../../gcc/passes.c:2408
#198605 0x00c26030 in ipa_write_summaries_1 (encoder=0x29263d0) at
../../gcc/passes.c:2469
#198606 0x00c26285 in ipa_write_summaries () at ../../gcc/passes.c:2529
#198607 0x0084127d in ipa_passes () at ../../gcc/cgraphunit.c:2199
#198608 0x008415e6 in symbol_table::compile (this=0x7185e000) at
../../gcc/cgraphunit.c:2295
#198609 0x00841908 in symbol_table::finalize_compilation_unit
(this=0x7185e000) at ../../gcc/cgraphunit.c:2444
#198610 0x0069ceb9 in c_write_global_declarations () at
../../gcc/c/c-decl.c:10801
#198611 0x00d1ebad in compile_file () at ../../gcc/toplev.c:608
#198612 0x00d21067 in do_compile () at ../../gcc/toplev.c:2076
#198613 0x00d21295 in toplev::main (this=0x7fffe010, argc=20,
argv=0x7fffe118) at ../../gcc/toplev.c:2174
#198614 0x01660011 in main (argc

[Bug fortran/56226] Add support for DEC UNION and MAP extensions

[joel.matz at horizonbtc dot com]

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

Joel Matz  changed:

   What|Removed |Added

 CC||joel.matz at horizonbtc dot com

--- Comment #8 from Joel Matz  ---
Any word on this?  I would certainly be willing to help test.

[Bug target/60408] ARM: inefficient code for vget_lane_f32 intrinsic

[wilson at tuliptree dot org]

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

--- Comment #3 from Jim Wilson  ---
Even if we could fix the vec_extract constraints, we still end up with 3
instructions, as the optimizer can't do anything interesting with the
vec_extract RTL.

For a 32-bit SFmode value though, we can just use a subreg instead of a vector
extract.  The ARM port models the vector registers as 32-bit registers, so a
subreg for a 32-bit mode will always be valid.  Using a subreg instead of a
vector extract here, I get 2 instructions.
vmov.f32 s15, s0
vadd.f32 s0, s1, s15
That is because the register allocator thinks it needs a temp because
inputs and ouputs partially overlap.  That is a harder problem to fix.

Subregs should also work for 64-bit modes.

I have an experimental patch which is mostly untested.  I don't know if this
works for both big-endian and little-endian.  I don't know if this works for
all 32-bit modes and all vector types.  Etc.  All I know is that it seems to
work for this testcase.

[Bug target/60408] ARM: inefficient code for vget_lane_f32 intrinsic

[wilson at tuliptree dot org]

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

Jim Wilson  changed:

   What|Removed |Added

 CC||wilson at tuliptree dot org

--- Comment #2 from Jim Wilson  ---
Created attachment 35114
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35114&action=edit
patch to use subregs instead of vec_extract

[Bug c++/65525] New: ICE: sorry, unimplemented: unexpected AST of kind mem_ref (-std=c++14, ICE: in potential_constant_expression_1, at cp/constexpr.c:4432)

[marciso.gcc at gmail dot com]

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

Bug ID: 65525
   Summary: ICE: sorry, unimplemented: unexpected AST of kind
mem_ref (-std=c++14, ICE: in
potential_constant_expression_1, at
cp/constexpr.c:4432)
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marciso.gcc at gmail dot com

// The following code triggers "unimplemented ICE" when compiled with
"-std=c++14";
// "-std=c++11" compiles fine.

// g++ -std=c++14 test.cpp
// Tested with:
//   g++ (GCC) 5.0.0 20150308 (experimental)
//   g++ (GCC) 5.0.0 20150323 (experimental)

struct A
{
int x;
char y; // Actually, short and bool (types smaller than int?) trigger this
ICE too
// Also: the problem doesn't occur if you put the smaller type first, e.g.
"char x; int y;"

A(int x) {} // custom ctor needed for ICE
};

int main()
{
A a{0}, x{1}, y{2};

x = a; // OK
y = a; // OK
x = y = a; // ICE: sorry, unimplemented: unexpected AST of kind mem_ref
// internal compiler error: in potential_constant_expression_1, at
cp/constexpr.c:4432

return 0;
}

/*
./gcc/bin/g++ -std=c++14test.cpp   -o test
test.cpp: In function ‘int main()’:
test.cpp:20:13: sorry, unimplemented: unexpected AST of kind mem_ref
 x = y = a; // ICE: sorry, unimplemented: unexpected AST of kind mem_ref
 ^
test.cpp:20:13: internal compiler error: in potential_constant_expression_1, at
cp/constexpr.c:4432
0x843238 potential_constant_expression_1
../../gcc/cp/constexpr.c:4432
0x842eca potential_constant_expression_1
../../gcc/cp/constexpr.c:4049
0x8423e5 potential_constant_expression_1
../../gcc/cp/constexpr.c:4379
0x74c3d2 cp_parser_constant_expression
../../gcc/cp/parser.c:8672
0x74c0b4 cp_parser_assignment_expression
../../gcc/cp/parser.c:8434
0x74e80d cp_parser_expression
../../gcc/cp/parser.c:8569
0x74f0f6 cp_parser_expression_statement
../../gcc/cp/parser.c:9976
0x73c8b5 cp_parser_statement
../../gcc/cp/parser.c:9827
0x73d422 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:10099
0x73d57b cp_parser_compound_statement
../../gcc/cp/parser.c:10053
0x75233b cp_parser_function_body
../../gcc/cp/parser.c:19185
0x75233b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:19221
0x75cbaa cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:23464
0x75da23 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:23376
0x75da23 cp_parser_init_declarator
../../gcc/cp/parser.c:17055
0x75efbc cp_parser_simple_declaration
../../gcc/cp/parser.c:11592
0x75f313 cp_parser_block_declaration
../../gcc/cp/parser.c:11466
0x767879 cp_parser_declaration
../../gcc/cp/parser.c:11363
0x767afa cp_parser_declaration_seq_opt
../../gcc/cp/parser.c:11249
0x767e0f cp_parser_translation_unit
../../gcc/cp/parser.c:4100
Please submit a full bug report,

[Bug ada/65519] [5 regression] unable to coalesce ssa_names 2 and 87 which are marked as MUST COALESCE

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
The problematic statement is created by the gimple-match stuff:

Applying pattern match.pd:761, gimple-match.c:1727
Applying pattern match.pd:625, gimple-match.c:1525
gimple_simplified to _71 = I.3_30(ab) & 4294967295;
_45 = _71;

and falls through the cracks of replace_stmt_with_simplification:

  /* Play safe and do not allow abnormals to be mentioned in
 newly created statements.  See also maybe_push_res_to_seq.  */
  if ((TREE_CODE (ops[0]) == SSA_NAME
   && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (ops[0]))
  || (ops[1]
  && TREE_CODE (ops[1]) == SSA_NAME
  && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (ops[1]))
  || (ops[2]
  && TREE_CODE (ops[2]) == SSA_NAME
  && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (ops[2])))
return false;

because ops[0] is already the new SSA_NAME (_71), which was created by:

tree
gimple_build (gimple_seq *seq, location_t loc,
  enum tree_code code, tree type, tree op0, tree op1,
  tree (*valueize)(tree))
{
  tree res = gimple_simplify (code, type, op0, op1, seq, valueize);
  if (!res)
{
  if (gimple_in_ssa_p (cfun))
res = make_ssa_name (type);
  else
res = create_tmp_reg (type);
  gimple stmt = gimple_build_assign (res, code, op0, op1);
  gimple_set_location (stmt, loc);
  gimple_seq_add_stmt_without_update (seq, stmt);
}
  return res;
}

I don't think that gimple_build can fail, so maybe the way out is to test
  stmt_references_abnormal_ssa_name (SSA_NAME_DEF_STMT (ops[x]))
instead of just
  SSA_NAME_OCCURS_IN_ABNORMAL_PHI (ops [x]))
in replace_stmt_with_simplification.

[Bug bootstrap/65522] [5 Regression] Svn revision 221590 fails bootstrap - ../libiberty/libiberty.a(cplus-dem.o): In function `ada_demangle': cplus-dem.c:(.text+0xdb8): multiple definition of `ada_dem

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug libstdc++/64967] [5 Regression] Bootstrap fails due to errors in libstdc++ sources with `--enable-symvers=gnu-versioned-namespace'

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Looks reasonable.

[Bug bootstrap/65522] [5 Regression] Svn revision 221590 fails bootstrap - ../libiberty/libiberty.a(cplus-dem.o): In function `ada_demangle': cplus-dem.c:(.text+0xdb8): multiple definition of `ada_dem

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Mon Mar 23 15:49:02 2015
New Revision: 221599

URL: https://gcc.gnu.org/viewcvs?rev=221599&root=gcc&view=rev
Log:
PR bootstrap/65522
* ipa-devirt.c: Remove duplicate demangle.h include.

* adadecode.c (ada_demangle): Guard with IN_RTS instead of IN_GCC.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/adadecode.c
trunk/gcc/ipa-devirt.c

[Bug libstdc++/64967] [5 Regression] Bootstrap fails due to errors in libstdc++ sources with `--enable-symvers=gnu-versioned-namespace'

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #2)
> Or drop the gnu-versioned-namespace support altogether.

I'd like to do that ... maybe for GCC 6 though. It seems a bit late now to
remove it without deprecation.

> Anyway, if you don't, bumping it to _8 and always using the new ABI sounds
> like a good plan to me.

That proved quite difficult. My plan for now is to simply force
--disable-libstdcxx-dual-abi when gnu-versioned-namespace is in use, so it
bootstraps and can be used, just without the new GCC 5 hotness.

[Bug rtl-optimization/60851] [4.9 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2117 with -flive-range-shrinkage -mdispatch-scheduler -march=bdver4

[rth at gcc dot gnu.org]

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

--- Comment #14 from Richard Henderson  ---
(In reply to Uroš Bizjak from comment #13)
> In 4.9 branch, the check is located in three different places throughout
> constrain_operands. There was a big cleanup by Richard Sandiford in this
> area [1].

Looks good.

[Bug target/65496] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2318 with -O3 -fsched2-use-superblocks -mavx512dq --param=max-pending-list-length=0

[rth at gcc dot gnu.org]

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

--- Comment #3 from Richard Henderson  ---
(In reply to Jakub Jelinek from comment #2)
> Richard, any thoughts what to do about this?  Avoid scheduling frame related
> instructions across conditional jumps?  Something else?

Yes, for the short term that will have to be a requirement in order to
keep the unwind info happy.

Something for the next stage1 is

(1) Avoiding the use of bare /f, and thus also REG_FRAME_RELATED_EXPR,
using instead always REG_CFA_*.  I suspect that this insn 620 shouldn't
actually be frame related at all, but is a part of a larger dwarf
expression we're intending to construct.

(2) Once we have an unambiguous note for everything, we can allow these
insns to be scheduled across a conditional jump if we strip and collect
those notes and place them after the conditional jump, probably on a
fake insn like

  (insn/f (use (const_int 0))
 (expr-list:REG_CFA_...
   (expr-list:REG_CFA_...
 (expr-list:REG_CFA_...

[Bug ipa/62051] [4.9/5 Regression] Undefined reference to vtable with -O2 and -fdevirtualize-speculatively

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P2
 CC||jakub at gcc dot gnu.org

[Bug target/65504] [4.9 Regression] select case with strings and -fgcse -O

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.9/5 Regression] select   |[4.9 Regression] select
   |case with strings and   |case with strings and
   |-fgcse -O   |-fgcse -O

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

[Bug tree-optimization/65518] [4.8/4.9 Regression] gcc consumes all memory with -O3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.8.5
Summary|gcc consumes all memory |[4.8/4.9 Regression] gcc
   |with -O3|consumes all memory with
   ||-O3

--- Comment #5 from Jakub Jelinek  ---
Must be a regression, at least from the times when we didn't have any
vectorizer.

[Bug target/65504] [4.9/5 Regression] select case with strings and -fgcse -O

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
Author: jakub
Date: Mon Mar 23 15:31:59 2015
New Revision: 221597

URL: https://gcc.gnu.org/viewcvs?rev=221597&root=gcc&view=rev
Log:
PR target/65504
* config/i386/i386.c (ix86_copy_addr_to_reg): Set REG_POINTER
on the pseudo.
(expand_set_or_movmem_prologue_epilogue_by_misaligned_moves): Set
REG_POINTER on *destptr after adjusting it for prologue size.

* gfortran.dg/pr65504.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr65504.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/65521] [5 Regression] nondeterministic -fcompare-debug failures

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #11 from Markus Trippelsdorf  ---
Fixed. Thanks!

[Bug ipa/65521] [5 Regression] nondeterministic -fcompare-debug failures

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Mon Mar 23 15:17:20 2015
New Revision: 221596

URL: https://gcc.gnu.org/viewcvs?rev=221596&root=gcc&view=rev
Log:
PR ipa/65521
* ipa-icf.c (sem_item::update_hash_by_addr_refs): Hash
ultimate_alias_target ()->order ints instead of
ultimate_alias_target () pointers.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr65521.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-icf.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/65518] gcc consumes all memory with -O3

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Mar 23 14:59:57 2015
New Revision: 221595

URL: https://gcc.gnu.org/viewcvs?rev=221595&root=gcc&view=rev
Log:
2015-03-23  Richard Biener  

PR tree-optimization/65518
* tree-vect-stmts.c (vectorizable_load): Reject single-element
interleaving cases we generate absymal code for.

* gcc.dg/vect/pr65518.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr65518.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug tree-optimization/65518] gcc consumes all memory with -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||5.0
  Known to fail|5.0 |4.8.3, 4.9.2

--- Comment #3 from Richard Biener  ---
Fixed on trunk sofar.

[Bug testsuite/65506] [5 Regression] FAIL: gcc.dg/pr29215.c scan-tree-dump-not gimple "memcpy"

[dave.anglin at bell dot net]

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

--- Comment #4 from dave.anglin at bell dot net ---
On 2015-03-23 10:05 AM, jakub at gcc dot gnu.org wrote:
> Indeed, have verified this with the cross-compiler and the attached patch
> should cure this.
I have applied the patch for testing but hit pr65522 regression. 
Restarted build without ada.
Will take about a day to confirm fix.

Dave

[Bug testsuite/65506] [5 Regression] FAIL: gcc.dg/pr29215.c scan-tree-dump-not gimple "memcpy"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|rguenth at gcc dot gnu.org |jakub at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
Looks good to me.

[Bug libstdc++/65500] [5 Regression] FAIL: 17_intro/headers/c++2014/all_attributes.cc (test for excess errors)

[dave.anglin at bell dot net]

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

--- Comment #3 from dave.anglin at bell dot net ---
On 2015-03-23 10:02 AM, redi at gcc dot gnu.org wrote:
> 3) Use fixincludes to change either the definition of __LWP_RWLOCK_VALID to
> (short)0x8c91 or change the definition of PTHREAD_RWLOCK_INITIALIZER to use
> (short)__LWP_RWLOCK_VALID
Instead of (short)0x8c91, I am testing patch with value changed to 
-29551.  The libstdc++
testsuite was clean with hppa64.  However, I hit a new issue in 32-bit 
build this morning.

Dave

[Bug c++/59254] confusing diagnostic for undefined template shadowed by declaration in inline namespace

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-23
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Confirmed on trunk.

The difference between 'struct' and 'class' in my original example is not
relevant:

namespace outer {
  inline namespace inner {
template struct A;
  }

  template struct A;

  template struct A;
}

[Bug bootstrap/65522] [5 Regression] Svn revision 221590 fails bootstrap - ../libiberty/libiberty.a(cplus-dem.o): In function `ada_demangle': cplus-dem.c:(.text+0xdb8): multiple definition of `ada_dem

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #35109|0   |1
is obsolete||
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Created attachment 35112
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35112&action=edit
gcc5-pr65522.patch

I'm actually testing a slightly adjusted variant that keeps the compatibility
ada_demangle in libgnat* for ABI reasons, but not in gnat1 which doesn't use it
and thus can link against libiberty.

[Bug ada/65524] gnatbind generates decrementing the unexisting elab-counter into finalize_library

[charlet at gcc dot gnu.org]

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

Arnaud Charlet  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-03-23
 CC||charlet at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Arnaud Charlet  ---
Sounds interesting/puzzling. But we really need a reproducer/test case to work
from.

[Bug c++/59256] qualified name in friend function declaration doesn't match previous declaration in inline namespace

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--- Comment #3 from Jonathan Wakely  ---
Uh, just rediscovered this and recreated exactly the same reduced testcase!

Also, this variation which should not compile (because lookup should fail for
N::f):

namespace N
{
  namespace detail
  {
inline namespace ver
{
  template
void f();
}
  }

  template
void
detail::f() { }
}

int main()
{
  N::f();
}

Somehow the fact N::detail::ver is an inline namespace causes N::detail::f to
also be declared in N.

[Bug ada/65524] New: gnatbind generates decrementing the unexisting elab-counter into finalize_library

[demoonlit at panathenaia dot halfmoon.jp]

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

Bug ID: 65524
   Summary: gnatbind generates decrementing the unexisting
elab-counter into finalize_library
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: demoonlit at panathenaia dot halfmoon.jp

I found some cases that gnatbind generates decrementing the unexisting
elaboration counter of each package Exxx.

   E142 : Short_Integer; pragma Import (Ada, E142, "system__exn_lli_E");
   ... some Exxx are declared ...

   procedure finalize_library is
   begin
  ...
  E132 := E132 - 1; -- * E132 is not declared in above *
  ...
   end finalize_library;

A cause is a package having _finalize_spec/_finalize_body without
_elabs/_elabb.
I still have not been able to make the minimal example, but have made a patch.

In bindgen.adb, Gen_Elab_Externals refers U.Set_Elab_Entity to generate Exxx.
However, Gen_Finalize_Library does not refer it.

--- a/gcc/ada/bindgen.adb
+++ b/gcc/ada/bindgen.adb
@@ -1434,7 +1434,9 @@ package body Bindgen is
 --  has a finalizer. In that case, this is where we decrement
 --  the elaboration entity.

-if U.Utype = Is_Body and then Uspec.Has_Finalizer then
+if U.Utype = Is_Body and then Uspec.Has_Finalizer
+   and then Uspec.Set_Elab_Entity
+then
if not Lib_Final_Built then
   Gen_Header;
   Lib_Final_Built := True;
@@ -1548,7 +1550,9 @@ package body Bindgen is

 WBI ("  begin");

-if U.Utype /= Is_Spec then
+if U.Utype /= Is_Spec
+   and then Uspec.Set_Elab_Entity
+then
Set_String (" E");
Set_Unit_Number (Unum);
Set_String (" := E");

[Bug c++/65047] [c++17] Add support for nested namespace defintions.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-23
 Ever confirmed|0   |1

--- Comment #5 from Jonathan Wakely  ---
There's a much older patch referred to in PR 21494

[Bug c++/21494] condensed nested namespaces

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Something like this is in the C++17 WP

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

[Bug c++/65047] [c++17] Add support for nested namespace defintions.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||bkoz at gcc dot gnu.org

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

[Bug ada/65519] [5 regression] unable to coalesce ssa_names 2 and 87 which are marked as MUST COALESCE

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
It's forwprop4 propagating an abnormal SSA name:

  :
  [...]
  I.3_30(ab) = I.3_1 + 1;
  _31 = (interfaces__unsigned_32) I.3_30(ab);

[...]

  :
  _43 = v.P_ARRAY;
  _45 = (sizetype) _31;

is changed into:

  :
  _43 = v.P_ARRAY;
  _71 = I.3_30(ab) & 4294967295;

but I.3_87(ab) is live in BB 13.

[Bug testsuite/65506] [5 Regression] FAIL: gcc.dg/pr29215.c scan-tree-dump-not gimple "memcpy"

[jakub at gcc dot gnu.org]

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

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

Indeed, have verified this with the cross-compiler and the attached patch
should cure this.

[Bug libstdc++/65500] [5 Regression] FAIL: 17_intro/headers/c++2014/all_attributes.cc (test for excess errors)

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to dave.anglin from comment #1)
> At one time, GCC was permissive about system header issues, particularly
> when they aren't
> really a problem.  Is this still the case?

It is, yes, but this specific diagnostic is an error not just a warning and it
doesn't get disabled in system headers.

> It looks like an include hack would fix but there's probably more issues
> like this.

I think this isn't a widespread problem. We only use these
PTHREAD_XXX_INITIALIZER macros in a handful of places, and the other ones have
been there for some time without problems.

The choices seem to be:

1) Add an autoconf check to see if we can use the PTHREAD_RWLOCK_INITIALIZER
macro in this way, so that it falls back to the constructor+destructor if the
INITIALIZER macro can't be used.

2) Change the front-end to suppress narrowing errors in system headers.

3) Use fixincludes to change either the definition of __LWP_RWLOCK_VALID to
(short)0x8c91 or change the definition of PTHREAD_RWLOCK_INITIALIZER to use
(short)__LWP_RWLOCK_VALID


I don't like (1) because it would be a bit fragile and could introduce silent
ABI issues. If a later release of HPUX changes the INITIALIZER macro to avoid
the narrowing conversion, or if a later release of G++ does (2), then the
result of the autoconf check would change and would silently change whether a
std::shared_timed_mutex uses a constructor/destructor or not. Different
translation units built by different versions of GCC would disagree on how to
construct the objects.

Neither (1) nor (2) helps user code that wants to do:

  pthread_rwlock_t lock = PTHREAD_RWLOCK_INITIALIZER;

which presumably fails with the same error when using g++ -std=c++11.

So I think a fixincludes to cast the constant to (short) is the best option. If
__LWP_RWLOCK_T is only used in the definition of PTHREAD_RWLOCK_INITIALIZER
then changing its definition is probably the simplest:

#define __LWP_RWLOCK_VALID  (short)0x8c91


I don't have any HPUX machines to try that with, would you be able to?

[Bug target/65504] [4.9/5 Regression] select case with strings and -fgcse -O

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug tree-optimization/65494] [5 Regression] Loop is not vectorized because of operand canonicalization.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/65523] ICE: in gimple_op, at gimple.h:2270 with -fcheck-pointer-bounds -mmpx

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux and aarch64-linux

[clyon at gcc dot gnu.org]

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

--- Comment #57 from clyon at gcc dot gnu.org ---
Cherry-picked r230324 and committed in GCC as r221593, to fix aarch64 problems.

I'm not sure whether the "old arm" and hppa problems have been fixed?

[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux and aarch64-linux

[clyon at gcc dot gnu.org]

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

--- Comment #56 from clyon at gcc dot gnu.org ---
Author: clyon
Date: Mon Mar 23 13:43:22 2015
New Revision: 221593

URL: https://gcc.gnu.org/viewcvs?rev=221593&root=gcc&view=rev
Log:
2015-03-23  Christophe Lyon  

PR sanitizer/59009
* sanitizer_common/sanitizer_platform_limits_posix.cc: Cherry pick
upstream r230324.
* sanitizer_common/sanitizer_platform.h: Likewise.
* sanitizer_common/sanitizer_common_syscalls.inc: Likewise.


Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/sanitizer_common/sanitizer_common_syscalls.inc
trunk/libsanitizer/sanitizer_common/sanitizer_platform.h
trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc

[Bug c++/64931] ICE on function with deduced return type and input is instantiated template class

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Slightly more reduced:

template
struct S {
  T data[32];
};

auto
foo (S & x)
{
  return x;
}

The problem is that we create a RESULT_DECL with NULL DECL_SIZE, and gimplifier
ICEs on that.  The RESULT_DECL is created in convert_for_initialization called
from check_return_expr I think.

[Bug target/65504] [4.9/5 Regression] select case with strings and -fgcse -O

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

[Bug bootstrap/65522] [5 Regression] Svn revision 221590 fails bootstrap - ../libiberty/libiberty.a(cplus-dem.o): In function `ada_demangle': cplus-dem.c:(.text+0xdb8): multiple definition of `ada_dem

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
> Ah, except ada_demangle is also exported from libgnat*.so - wonder why the
> RTS is built with IN_GCC.

This is explained in gcc-interface/Makefile.in.

> In that case, guess the Ada folks need to decide which one of the two to
> keep, and/or if one of them (either adadecode.[ch], or {include,libiberty}/*
> one shouldn't be renamed to something else.

I think your patch is fine, but I'll let Arno approve it.

[Bug target/65456] powerpc64le autovectorized copy loop missed optimization

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from Bill Schmidt  ---
(In reply to David Edelsohn from comment #10)
> I believe that the choice to scalarize is based on the vector cost model.

Hm, that would be interesting.  The applied patch changes the cost model to
favor the unaligned store on VSX.  Might be a place where it should be using
the cost model but perhaps isn't?  I'll look into it later this week.

[Bug bootstrap/65522] [5 Regression] Svn revision 221590 fails bootstrap - ../libiberty/libiberty.a(cplus-dem.o): In function `ada_demangle': cplus-dem.c:(.text+0xdb8): multiple definition of `ada_dem

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||charlet at gcc dot gnu.org,
   ||ebotcazou at gcc dot gnu.org
   Assignee|jakub at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org

--- Comment #3 from Jakub Jelinek  ---
Ah, except ada_demangle is also exported from libgnat*.so - wonder why the RTS
is built with IN_GCC.
In that case, guess the Ada folks need to decide which one of the two to keep,
and/or if one of them (either adadecode.[ch], or {include,libiberty}/* one
shouldn't be renamed to something else.
I haven't found any uses of either of those, except the libiberty demangler
that calls ada_demangle but it could very well call a static routine instead.

[Bug bootstrap/65522] [5 Regression] Svn revision 221590 fails bootstrap - ../libiberty/libiberty.a(cplus-dem.o): In function `ada_demangle': cplus-dem.c:(.text+0xdb8): multiple definition of `ada_dem

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||jakub at gcc dot gnu.org

[Bug libgcc/57221] [4.8/4.9/5 regression] libgcc symbol visibility changes break Android blobs

[mkuvyrkov at gcc dot gnu.org]

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

--- Comment #9 from Maxim Kuvyrkov  ---
Hi Bero,

I'm working on reproducing this.  How do you build the android toolchain?  Is
it manual or do you have this scripted?

In particular, do you use a pre-generated sysroot with Bionic or do you build
the C library as part of the toolchain?

Thanks.

[Bug libstdc++/24196] Using string instances to pass arguments to dlls fails

[redi at gcc dot gnu.org]

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

Bug 24882 Summary: [meta-bug] Non-refcounted, moveable basic_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24882

   What|Removed |Added

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

[Bug libstdc++/19495] basic_string::_M_rep() can produce an unnaturally aligned pointer to _Rep

[redi at gcc dot gnu.org]

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

Bug 24882 Summary: [meta-bug] Non-refcounted, moveable basic_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24882

   What|Removed |Added

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

[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string

[redi at gcc dot gnu.org]

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

Bug 24882 Summary: [meta-bug] Non-refcounted, moveable basic_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24882

   What|Removed |Added

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

[Bug libstdc++/16612] empty basic_strings can't live in shared memory

[redi at gcc dot gnu.org]

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

Bug 24882 Summary: [meta-bug] Non-refcounted, moveable basic_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24882

   What|Removed |Added

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

[Bug libstdc++/24882] [meta-bug] Non-refcounted, moveable basic_string

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Done for GCC 5

[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string

[redi at gcc dot gnu.org]

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

--- Comment #51 from Jonathan Wakely  ---
This is no longer an issue when using the new non-reference-counted std::string
implementation in GCC 5.

[Bug bootstrap/65522] [5 Regression] Svn revision 221590 fails bootstrap - ../libiberty/libiberty.a(cplus-dem.o): In function `ada_demangle': cplus-dem.c:(.text+0xdb8): multiple definition of `ada_dem

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Seems the ada/adadecode.[ch] (ada_demangle) function is totally unused.

[Bug tree-optimization/65494] [5 Regression] Loop is not vectorized because of operand canonicalization.

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Mon Mar 23 12:47:54 2015
New Revision: 221592

URL: https://gcc.gnu.org/viewcvs?rev=221592&root=gcc&view=rev
Log:
2015-03-23  Richard Biener  

PR tree-optimization/65494
* tree-vect-slp.c (vect_build_slp_tree): Do not (re-)allocate
matches here.
(vect_analyze_slp_instance): But do that here, always and once.

* gcc.dg/vect/pr65494.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr65494.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-slp.c

[Bug target/65504] [4.9/5 Regression] select case with strings and -fgcse -O

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
Created attachment 35108
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35108&action=edit
gcc5-pr65504.patch

Patch I'm going to bootstrap/regtest now.

[Bug libstdc++/65473] Including does not define __GLIBCXX__

[ldionne.2 at gmail dot com]

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

--- Comment #2 from Louis Dionne  ---
Does the standard specify which headers should define those macros? If not,
then it's a QOI issue that could easily be solved. In all cases, does stdcxx
document which headers must be included in order to get those definitions? I
couldn't find it.

[Bug rtl-optimization/65504] [4.9/5 Regression] select case with strings and -fgcse -O

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #16 from Jakub Jelinek  ---
--- gcc/config/i386/i386.c.jj2015-03-23 08:47:53.0 +0100
+++ gcc/config/i386/i386.c2015-03-23 13:11:43.416147457 +0100
@@ -23457,12 +23457,19 @@ counter_mode (rtx count_exp)
 static rtx
 ix86_copy_addr_to_reg (rtx addr)
 {
+  rtx reg;
   if (GET_MODE (addr) == Pmode || GET_MODE (addr) == VOIDmode)
-return copy_addr_to_reg (addr);
+{
+  reg = copy_addr_to_reg (addr);
+  REG_POINTER (reg) = 1;
+  return reg;
+}
   else
 {
   gcc_assert (GET_MODE (addr) == DImode && Pmode == SImode);
-  return gen_rtx_SUBREG (SImode, copy_to_mode_reg (DImode, addr), 0);
+  reg = copy_to_mode_reg (DImode, addr);
+  REG_POINTER (reg) = 1;
+  return gen_rtx_SUBREG (SImode, reg, 0);
 }
 }

@@ -24354,6 +24361,8 @@ expand_set_or_movmem_prologue_epilogue_b
   *destptr = expand_simple_binop (GET_MODE (*destptr), PLUS, *destptr,
   GEN_INT (prolog_size),
   NULL_RTX, 1, OPTAB_DIRECT);
+  if (REG_P (*destptr) && REG_P (saveddest) && REG_POINTER (*saveddest))
+REG_POINTER (*destptr) = 1;
   *destptr = expand_simple_binop (GET_MODE (*destptr), AND, *destptr,
   GEN_INT (-desired_align),
   *destptr, 1, OPTAB_DIRECT);
@@ -24363,8 +24372,8 @@ expand_set_or_movmem_prologue_epilogue_b
saveddest, 1, OPTAB_DIRECT);
   /* Adjust srcptr and count.  */
   if (!issetmem)
-*srcptr = expand_simple_binop (GET_MODE (*srcptr), MINUS, *srcptr,
saveddest,
-*srcptr, 1, OPTAB_DIRECT);
+*srcptr = expand_simple_binop (GET_MODE (*srcptr), MINUS, *srcptr,
+   saveddest, *srcptr, 1, OPTAB_DIRECT);
   *count = expand_simple_binop (GET_MODE (*count), PLUS, *count,
 saveddest, *count, 1, OPTAB_DIRECT);
   /* We copied at most size + prolog_size.  */

fixes this for me.  Without the REG_POINTER flags, aliasing is really confused
on what is a pointer and what is not, as the prologue of the misaligned memcpy
uses
adjusteddest = dest & -align;
src = src - (adjusteddest - dest)
and from these only one has REG_POINTER flag after the propagation, so aliasing
makes a wrong decision from that.