[Bug tree-optimization/66677] [6 Regression] ICE: in vect_transform_stmt, at tree-vect-stmts.c:7626

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/66677] [6 Regression] ICE: in vect_transform_stmt, at tree-vect-stmts.c:7626

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Jun 29 07:30:47 2015
New Revision: 225112

URL: https://gcc.gnu.org/viewcvs?rev=225112&root=gcc&view=rev
Log:
2015-06-29  Richard Biener  

PR tree-optimization/66677
* tree-vect-stmts.c (vect_transform_stmt): Make assert about
STMT_VINFO_VEC_STMT clobbering less strict.

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

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

[Bug ada/63310] Ada bootstrap error with -fcompare-debug

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Botcazou  ---
Is this still an issue?  Assuming yes, I'll address it.

[Bug c++/66121] [5 Regression] internal compiler error: in strip_typedefs, at cp/tree.c:1369

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to work||4.9.2, 6.0
   Target Milestone|--- |5.2
Summary|internal compiler error: in |[5 Regression] internal
   |strip_typedefs, at  |compiler error: in
   |cp/tree.c:1369  |strip_typedefs, at
   ||cp/tree.c:1369
  Known to fail||5.1.0

--- Comment #2 from Richard Biener  ---
Still a regression for GCC 5 (works with 4.9.2 for me and indeed fixed on
trunk).

[Bug tree-optimization/64130] vrp: handle non zero constant divided by range cannot be zero.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #12 from Richard Biener  ---
Fixed on trunk.

[Bug debug/66688] [6 Regression] compare debug failure building Linux kernel on ppc64le

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug middle-end/66685] [6 Regression] conftest.c:16:1: internal compiler error: in as_a, at is-a.h:192

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug lto/66687] WPA link fau: internal compiler error: bytecode stream: found non-null terminated string

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Are you sure you produced all LTO bytecode with exactly the same compiler?
Reminds me to bump the LTO bytecode version again on trunk (it's still the same
as that on the GCC 5 branch...)

[Bug c/66683] Large macro with float multiplications fails

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||compile-time-hog,
   ||memory-hog
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-06-29
 Ever confirmed|0   |1

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

[Bug middle-end/60291] [4.8 Regression] slow compile times for any mode (-O0/-O1/-O2) on large .c source file (30MBs)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||cr88192 at gmail dot com

--- Comment #22 from Richard Biener  ---
*** Bug 66682 has been marked as a duplicate of this bug. ***

[Bug c/66682] Lots of macro expansion, very slow compilation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Biener  ---
(In reply to Mikhail Maltsev from comment #6)
> Created attachment 35859 [details]
> Sampling profile of cc1
> 
> It's hard to say what's wrong here (why do we perform so many lookups in
> mem_attrs hash table? collisions?) without looking further.

Yes, global variables.  See PR60291.

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

[Bug target/64833] [SH]: Error: pcrel too far when compiling imagemagick and graphicsmagick on Debian sh4

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #13 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #12)
> I could reproduce the problem on trunk with '-DXS_VERSION=\"6.89\" -fwrapv
> -fno-strict-aliasing -fopenmp -O2 -fstack-protector-strong -fexceptions
> -fPIC'
> with the cross sh4-unknown-linux-gnu compiler.

Indeed, the bug is still there [1]:

gcc -std=gnu99 -c  -I../ -I.. -I/usr/include/X11 -I/usr/include/freetype2
-I/usr/include/libxml2 -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -mieee -fwrapv
-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -fopenmp -Wall -g -fno-strict-aliasing -O2 -Wall
-pthread -O2 -g   -DVERSION=\"1.3.20\" -DXS_VERSION=\"1.3.20\" -fPIC
"-I/usr/lib/sh4-linux-gnu/perl/5.20/CORE"  -D_FILE_OFFSET_BITS=64
-D_LARGE_FILES=1 -DHAVE_CONFIG_H Magick.c
(...)
Magick.c: At top level:
Magick.xs:247:4: warning: 'LogEventTypes' defined but not used
[-Wunused-variable]
   *LogEventTypes[] =
^
{standard input}: Assembler messages:
{standard input}:15085: Error: pcrel too far
{standard input}:15086: Error: pcrel too far
make[2]: *** [Magick.o] Error 1

Adrian

> [1] 
> http://buildd.debian-ports.org/status/fetch.php?pkg=graphicsmagick&arch=sh4&ver=1.3.20-3%2Bdeb8u1&stamp=1435541933

[Bug c/66683] Large macro with float multiplications fails

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Note that most of the memory goes to building the expression in GCCs internal
representation.  The most compile-time spent in a single routine is parsing
the float constants (real_from_string, running into mpfr mpfr_strtofr
and real_from_mpfr).

Memory requirement could be reduced if sharing REAL_CSTs, but of course
adjusting the testcase to use different float values would make that even
worse.

[Bug c++/65750] [4.9/5 Regression] misinterpret in a virtual member function with a C++11 style function signature

[paolo at gcc dot gnu.org]

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

--- Comment #9 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Jun 29 09:34:58 2015
New Revision: 225114

URL: https://gcc.gnu.org/viewcvs?rev=225114&root=gcc&view=rev
Log:
/cp
2015-06-29  Adam Butcher  

PR c++/65750
* parser.c (cp_parser_simple_type_specifier): Don't synthesize
implicit template parm if 'auto' is a placeholder for trailing
return type.

/testsuite
2015-06-29  Adam Butcher  

PR c++/65750
* g++.dg/cpp0x/trailing11.C: New.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/trailing11.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/parser.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/65750] [4.9/5 Regression] misinterpret in a virtual member function with a C++11 style function signature

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #10 from Paolo Carlini  ---
Fixed for 5.2 too.

[Bug tree-optimization/66652] try_transform_to_exit_first_loop_alt generates incorrect loop

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
Created attachment 35873
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35873&action=edit
tentative patch

currently doing bootstrap and reg-test on x86_64.

[Bug c/66322] Linus Torvalds: -Wswitch-bool produces dubious warnings, fails to notice really bad things

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Author: mpolacek
Date: Mon Jun 29 13:12:44 2015
New Revision: 225116

URL: https://gcc.gnu.org/viewcvs?rev=225116&root=gcc&view=rev
Log:
PR c/66322
* c-common.c (check_case_bounds): Add bool * parameter.  Set
OUTSIDE_RANGE_P.
(c_add_case_label): Add bool * parameter.  Pass it down to
check_case_bounds.
(c_do_switch_warnings): Add bool parameters.  Implement -Wswitch-bool
warning here.
* c-common.h (c_add_case_label, c_do_switch_warnings): Update
declarations.

* c-typeck.c (struct c_switch): Add BOOL_COND_P and OUTSIDE_RANGE_P.
(c_start_case): Set BOOL_COND_P and OUTSIDE_RANGE_P.  Don't warn
about -Wswitch-bool here.
(do_case): Update c_add_case_label call.
(c_finish_case): Update c_do_switch_warnings call.

* decl.c (struct cp_switch): Add OUTSIDE_RANGE_P.
(push_switch): Set OUTSIDE_RANGE_P.
(pop_switch): Update c_do_switch_warnings call.
(finish_case_label): Update c_add_case_label call.
* semantics.c (finish_switch_cond): Don't warn about -Wswitch-bool
here.

* function.c (stack_protect_epilogue): Remove a cast to int.
* doc/invoke.texi: Update -Wswitch-bool description.

* c-c++-common/pr60439.c: Add dg-prune-output and add switch cases.
* c-c++-common/pr66322.c: New test.
* g++.dg/eh/scope1.C: Remove dg-warning.

Added:
trunk/gcc/testsuite/c-c++-common/pr66322.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/semantics.c
trunk/gcc/doc/invoke.texi
trunk/gcc/function.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/pr60439.c
trunk/gcc/testsuite/g++.dg/eh/scope1.C

[Bug fortran/58861] Realloc on assignment: Bogus "Array bound mismatch" error with -fcheck=bounds

[elrond1111 at yahoo dot com]

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

Kyle Horne  changed:

   What|Removed |Added

 CC||elrond at yahoo dot com

--- Comment #4 from Kyle Horne  ---
Created attachment 35874
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35874&action=edit
Minimal case

Another minimal use case that triggers erroneous bounds check errors

[Bug fortran/66695] New: [4.9, 5 Regression] ICE with binding-name equal to overloaded name of use-associated procedure

[vladimir.fuka at gmail dot com]

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

Bug ID: 66695
   Summary: [4.9, 5 Regression] ICE with binding-name equal to
overloaded name of use-associated procedure
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vladimir.fuka at gmail dot com
  Target Milestone: ---

The following code compiles with 4.8.5, and 4.9.0 and causes ICE with 4.9.2 and
5.1.1


module mod
  implicit none
contains
integer function F()
end function
end module

module mod_C
  use mod
  implicit none
contains
  subroutine s()  bind(C, name="f")
integer :: x
  x = F()
  end subroutine
end module




> gfortran-5 -v -c binding_ice.f90 
Using built-in specs.
COLLECT_GCC=gfortran-5
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada,go
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/5
--enable-ssp --disable-libssp --disable-libvtv --enable-libmpx --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--with-default-libstdcxx-abi=c++98 --enable-version-specific-runtime-libs
--enable-linker-build-id --enable-linux-futex --program-suffix=-5
--without-system-libunwind --enable-multilib --with-arch-32=i586
--with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 5.1.1 20150622 [gcc-5-branch revision 224722] (SUSE Linux) 
COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=x86-64'
 /usr/lib64/gcc/x86_64-suse-linux/5/f951 binding_ice.f90 -quiet -dumpbase
binding_ice.f90 -mtune=generic -march=x86-64 -auxbase binding_ice -version
-fintrinsic-modules-path /usr/lib64/gcc/x86_64-suse-linux/5/finclude -o
/tmp/ccpIdj5s.s
GNU Fortran (SUSE Linux) version 5.1.1 20150622 [gcc-5-branch revision 224722]
(x86_64-suse-linux)
compiled by GNU C version 5.1.1 20150622 [gcc-5-branch revision
224722], GMP version 5.1.3, MPFR version 3.1.2, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (SUSE Linux) version 5.1.1 20150622 [gcc-5-branch revision
224722] (x86_64-suse-linux)
compiled by GNU C version 5.1.1 20150622 [gcc-5-branch revision
224722], GMP version 5.1.3, MPFR version 3.1.2, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
binding_ice.f90:15:0:

   x = F()
 1
internal compiler error: in fold_convert_loc, at fold-const.c:2235
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug tree-optimization/66652] try_transform_to_exit_first_loop_alt generates incorrect loop

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||patch, wrong-code

--- Comment #4 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg02084.html

[Bug target/64833] [SH]: Error: pcrel too far when compiling imagemagick and graphicsmagick on Debian sh4

[olegendo at gcc dot gnu.org]

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

--- Comment #14 from Oleg Endo  ---
(In reply to Kazumoto Kojima from comment #12) 
> diff --git a/config/sh/sh.c b/config/sh/sh.c
> index 0139095..86cbea7 100644
> --- a/config/sh/sh.c
> +++ b/config/sh/sh.c
> @@ -5261,6 +5261,11 @@ find_barrier (int num_mova, rtx_insn *mova, rtx_insn
> *from)
>  && GET_CODE (PATTERN (from)) == UNSPEC_VOLATILE
>  && XINT (PATTERN (from), 1) == UNSPECV_CONST_END)
>   return from;
> +  /* get_attr_length might return the length of the original worker
> +  for casesi_worker_2.  Get uncached length for it.  */
> +  else if (NONJUMP_INSN_P (from)
> +&& recog_memoized (from) == CODE_FOR_casesi_worker_2)
> + inc = insn_default_length (from);
>  
>if (BARRIER_P (from))
>   {

I was trying to understand what's happening there ... it's a bit confusing.  A
cleaner way would probably be to add a function in final.c to update the cached
length value for the INSN_UID in final.c.  Then, invoke that function for the
insn in fixup_mova when the pattern rtx is changed from casesi_worker_1 to
casesi_worker_2.  However, I guess that all the other insn length dependent
values will have to be re-calculated to get a consistent state.

Wouldn't it be easier/safer to just set the length of casesi_worker_1 to "8"?

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[olegendo at gcc dot gnu.org]

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

--- Comment #39 from Oleg Endo  ---
Can we close this PR as fixed?

[Bug middle-end/8743] receiving result from __builtin_return_address() beyond stack top causes segfault

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #12 from Martin Sebor  ---
A GCC patch to issue a warning for potentially unsafe calls to
__builtin_return_address() and __builtin_frame_address() posted here:

https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00886.html

[Bug c/66516] missing diagnostic on taking the address of a builtin function

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg02043.html

[Bug jit/66539] Missing parentheses in jit dumps

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Author: dmalcolm
Date: Mon Jun 29 15:27:39 2015
New Revision: 225125

URL: https://gcc.gnu.org/viewcvs?rev=225125&root=gcc&view=rev
Log:
PR jit/66539: Add parentheses as needed to gcc_jit_object_get_debug_string

Backport of r224531 (8154a3514d5fc8067a6928531d5f61cd768bd62c) and
r224535 (1828cd755cf5e4a34d5638f543a059f3562ad957) from trunk

gcc/jit/ChangeLog:
Backport from mainline r224531
2015-06-16  David Malcolm  

PR jit/66539
* jit-recording.c: Within namespace gcc::jit::recording::
(rvalue::get_debug_string_parens): New function.
(binary_op::make_debug_string): Update to mimic C precedence
rules.
(binary_op_precedence): New array.
(binary_op::get_precedence): New function.
(comparison::make_debug_string): Update to mimic C precedence
rules.
(comparison_precedence): New array.
(comparison::get_precedence): New function.
(cast::make_debug_string): Update to mimic C precedence rules.
(call::make_debug_string): Likewise.
(call_through_ptr::make_debug_string): Likewise.
(array_access::make_debug_string): Likewise.
(access_field_of_lvalue::make_debug_string): Likewise.
(access_field_rvalue::make_debug_string): Likewise.
(dereference_field_rvalue::make_debug_string): Likewise.
(dereference_rvalue::make_debug_string): Likewise.
(get_address_of_lvalue::make_debug_string): Likewise.
* jit-recording.h: Within namespace gcc::jit::recording::
(precedence): New enum.
(rvalue::rvalue): Initialize field "m_parenthesized_string".
(rvalue::get_debug_string_parens): New method.
(rvalue::get_precedence): New pure virtual function.
(rvalue::m_parenthesized_string): New field.
(param::get_precedence): New function.
(global::get_precedence): New function.
(memento_of_new_rvalue_from_const::get_precedence): New function.
(memento_of_new_string_literal::get_precedence): New function.
(unary_op::get_precedence): New function.
(binary_op::get_precedence): New function.
(comparison::get_precedence): New function.
(cast::get_precedence): New function.
(call::get_precedence): New function.
(call_through_ptr::get_precedence): New function.
(array_access::get_precedence): New function.
(access_field_of_lvalue::get_precedence): New function.
(access_field_rvalue::get_precedence): New function.
(dereference_field_rvalue::get_precedence): New function.
(dereference_rvalue::get_precedence): New function.
(get_address_of_lvalue::get_precedence): New function.
(local::get_precedence): New function.

gcc/testsuite/ChangeLog:
Backport from mainline r224531
2015-06-16  David Malcolm  

PR jit/66539
* jit.dg/all-non-failing-tests.h: Add test-debug-strings.c.
* jit.dg/test-debug-strings.c: New test case.
* jit.dg/test-quadratic.c (make_calc_discriminant): Verify that
the discriminant has a sane debug string.


Added:
branches/gcc-5-branch/gcc/testsuite/jit.dg/test-debug-strings.c
Modified:
branches/gcc-5-branch/gcc/jit/ChangeLog
branches/gcc-5-branch/gcc/jit/jit-recording.c
branches/gcc-5-branch/gcc/jit/jit-recording.h
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/jit.dg/all-non-failing-tests.h
branches/gcc-5-branch/gcc/testsuite/jit.dg/test-quadratic.c

[Bug jit/66627] Tracker bug for jit bugs affecting ravi

[dmalcolm at gcc dot gnu.org]

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

Bug 66539 Summary: Missing parentheses in jit dumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66539

   What|Removed |Added

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

[Bug jit/66539] Missing parentheses in jit dumps

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm  ---
(In reply to David Malcolm from comment #2)
> Should be fixed in trunk for GCC 6 as of r224531.
> 
> May be a candidate for applying to the GCC 5 branch, so keeping open for now.

Should be fixed in gcc-5-branch (for gcc 5.2) as of r225125; resolving as
fixed.

[Bug c++/66666] ARM wrong copy constructor address on multiple inheritance

[antonio.poggiali at datalogic dot com]

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

--- Comment #9 from Antonio Poggiali  ---
(In reply to Antonio Poggiali from comment #8)
> Hi all, I'm also trying the backport.
> 
> https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cgraphunit.
> c?revision=221077&view=markup&pathrev=221077
> 
> Is only this part of code to be backported?
> 
> Regards

Sorry, this code:

https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cgraphunit.c?r1=221077&r2=221076&pathrev=221077

I'm having cut and paste problems lately...

[Bug c++/66666] ARM wrong copy constructor address on multiple inheritance

[antonio.poggiali at datalogic dot com]

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

--- Comment #8 from Antonio Poggiali  ---
Hi all, I'm also trying the backport.

https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cgraphunit.c?revision=221077&view=markup&pathrev=221077

Is only this part of code to be backported?

Regards

[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins

[mwahab at gcc dot gnu.org]

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

--- Comment #63 from mwahab at gcc dot gnu.org ---
Author: mwahab
Date: Mon Jun 29 16:03:34 2015
New Revision: 225132

URL: https://gcc.gnu.org/viewcvs?rev=225132&root=gcc&view=rev
Log:
2015-06-29  Matthew Wahab  

PR target/65697
* config/armc/arm.c (arm_split_atomic_op): For ARMv8, replace an
initial acquire barrier with final barrier.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c

[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins

[mwahab at gcc dot gnu.org]

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

--- Comment #64 from mwahab at gcc dot gnu.org ---
Author: mwahab
Date: Mon Jun 29 16:09:10 2015
New Revision: 225133

URL: https://gcc.gnu.org/viewcvs?rev=225133&root=gcc&view=rev
Log:
2015-06-29  Matthew Wahab  

PR target/65697
* config/armc/arm.c (arm_split_compare_and_swap): For ARMv8, replace an
initial acquire barrier with final barrier.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c

[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins

[mwahab at gcc dot gnu.org]

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

--- Comment #65 from mwahab at gcc dot gnu.org ---
Author: mwahab
Date: Mon Jun 29 16:12:12 2015
New Revision: 225134

URL: https://gcc.gnu.org/viewcvs?rev=225134&root=gcc&view=rev
Log:
2015-06-29  Matthew Wahab  

PR target/65697
* gcc.target/arm/armv-sync-comp-swap.c: New.
* gcc.target/arm/armv-sync-op-acquire.c: New.
* gcc.target/arm/armv-sync-op-full.c: New.
* gcc.target/arm/armv-sync-op-release.c: New.


Added:
trunk/gcc/testsuite/gcc.target/arm/armv8-sync-comp-swap.c   (with props)
trunk/gcc/testsuite/gcc.target/arm/armv8-sync-op-acquire.c   (with props)
trunk/gcc/testsuite/gcc.target/arm/armv8-sync-op-full.c   (with props)
trunk/gcc/testsuite/gcc.target/arm/armv8-sync-op-release.c   (with props)
Modified:
trunk/gcc/ChangeLog

Propchange: trunk/gcc/testsuite/gcc.target/arm/armv8-sync-comp-swap.c
('svn:eol-style' added)

Propchange: trunk/gcc/testsuite/gcc.target/arm/armv8-sync-comp-swap.c
('svn:keywords' added)

Propchange: trunk/gcc/testsuite/gcc.target/arm/armv8-sync-op-acquire.c
('svn:eol-style' added)

Propchange: trunk/gcc/testsuite/gcc.target/arm/armv8-sync-op-acquire.c
('svn:keywords' added)

Propchange: trunk/gcc/testsuite/gcc.target/arm/armv8-sync-op-full.c
('svn:eol-style' added)

Propchange: trunk/gcc/testsuite/gcc.target/arm/armv8-sync-op-full.c
('svn:keywords' added)

Propchange: trunk/gcc/testsuite/gcc.target/arm/armv8-sync-op-release.c
('svn:eol-style' added)

Propchange: trunk/gcc/testsuite/gcc.target/arm/armv8-sync-op-release.c
('svn:keywords' added)

[Bug fortran/66605] -Wunused-parameter causes internal compiler error with gfortran 5.1.0

[manu at gcc dot gnu.org]

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

--- Comment #15 from Manuel López-Ibáñez  ---
Author: manu
Date: Mon Jun 29 16:25:26 2015
New Revision: 225135

URL: https://gcc.gnu.org/viewcvs?rev=225135&root=gcc&view=rev
Log:
Wunused-parameter warnings are given from cgraph::finalize_function,
which is the middle-end. This is an oddity compared to other
-Wunused-* warnings. Moreover, Fortran has its own definition of
-Wunused-parameter that conflicts with the middle-end definition.

This patch moves the middle-end part of Wunused-parameter to the C/C++
FEs. I'm not sure if other FEs expected this warning to work. If so,
they do not seem to test for it. Ada, for example, explicitly disables
it.

gcc/ChangeLog:

2015-06-29  Manuel López-Ibáñez  

PR fortran/66605
* cgraphunit.c (cgraph_node::finalize_function): Do not call
do_warn_unused_parameter.
* function.c (do_warn_unused_parameter): Move from here.
* function.h (do_warn_unused_parameter): Do not declare.

gcc/c-family/ChangeLog:

2015-06-29  Manuel López-Ibáñez  

PR fortran/66605
* c-common.c (do_warn_unused_parameter): Move here.
* c-common.h (do_warn_unused_parameter): Declare.

gcc/ada/ChangeLog:

2015-06-29  Manuel López-Ibáñez  

PR fortran/66605
* gcc-interface/misc.c (gnat_post_options): No need to disable
warn_unused_parameter anymore.

gcc/cp/ChangeLog:

2015-06-29  Manuel López-Ibáñez  

PR fortran/66605
* decl.c (finish_function): Call do_warn_unused_parameter.

gcc/testsuite/ChangeLog:

2015-06-29  Manuel López-Ibáñez  

PR fortran/66605
* gfortran.dg/wunused-parameter.f90: New test.

gcc/c/ChangeLog:

2015-06-29  Manuel López-Ibáñez  

PR fortran/66605
* c-decl.c (finish_function): Call do_warn_unused_parameter.

Added:
trunk/gcc/testsuite/gfortran.dg/wunused-parameter.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/misc.c
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/cgraphunit.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/function.c
trunk/gcc/function.h
trunk/gcc/testsuite/ChangeLog

[Bug fortran/66605] -Wunused-parameter causes internal compiler error with gfortran 5.1.0

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

  Known to work||6.0

--- Comment #16 from Manuel López-Ibáñez  ---
FIXED in GCC 6.

This is probably a regression, but I'm not sure if a backport would be
accepted. Otherwise, one of the brute-force fixes, like the one in comment #9,
should be enough to fix the ICE.

[Bug c++/66666] ARM wrong copy constructor address on multiple inheritance

[mikpelinux at gmail dot com]

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

--- Comment #10 from Mikael Pettersson  ---
(In reply to Antonio Poggiali from comment #9)
> Sorry, this code:
> 
> https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cgraphunit.
> c?r1=221077&r2=221076&pathrev=221077

Yes, but I'm not convinced it's the real fix.

[Bug ada/63310] Ada bootstrap error with -fcompare-debug

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Jun 29 17:45:34 2015
New Revision: 225139

URL: https://gcc.gnu.org/viewcvs?rev=225139&root=gcc&view=rev
Log:
PR ada/63310
* gcc-interface/utils.c (gnat_write_global_declarations): Always
build the dummy global variable if code was generated.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/utils.c

[Bug ada/63310] Ada bootstrap error with -fcompare-debug

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|4.9.4   |6.0

--- Comment #6 from Eric Botcazou  ---
Hopefully fixed.

[Bug c++/66696] New: confusing diagnostic on a friend main definition returning void

[msebor at gcc dot gnu.org]

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

Bug ID: 66696
   Summary: confusing diagnostic on a friend main definition
returning void
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

When main is defined with the wrong return type, GCC issues a clear message
pointing out the error:

$ cat u.c && ~/bin/gcc-5.1.0/bin/g++ -c -fno-diagnostics-show-caret -o/dev/null
u.c
void main (void) { }

u.c:1:16: error: ‘::main’ must return ‘int’

But when main is defined to return void as a friend function of a class GCC
issues the following cryptic error message.  In addition, in this case GCC
makes it possible to demote the error to a warning via -fpermissive.

GCC should treat these cases the same way (as Clang does).

$ cat u.c && ~/bin/gcc-5.1.0/bin/g++ -c -o/dev/null u.cstruct S {
friend void main (void) { }
};

u.c: In function ‘void main()’:
u.c:2:31: error: return-statement with a value, in function returning 'void'
[-fpermissive]
 friend void main (void) { }
   ^

[Bug c++/65977] Constexpr should be allowed in declaration of friend template specialization

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-06-29
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

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

[Bug target/66697] New: Feature request: -mstackrealign and force_align_arg_pointer for x86_64

[bucaneer at gmail dot com]

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

Bug ID: 66697
   Summary: Feature request: -mstackrealign and
force_align_arg_pointer for x86_64
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bucaneer at gmail dot com
  Target Milestone: ---

-mstackrealign option and force_align_arg_pointer attribute work for 32bit x86,
but not x86_64.

In particular, this makes Wine unable to deal with some untidy 64bit Windows
apps: https://bugs.winehq.org/show_bug.cgi?id=27680

[Bug c++/66698] New: Multiple inheritance from instantiations of template class and what about access to member functions

[apyszczuk at gmail dot com]

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

Bug ID: 66698
   Summary: Multiple inheritance from instantiations of template
class and what about access to member functions
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: apyszczuk at gmail dot com
  Target Milestone: ---

Let's take a look at the code:

template 
class S {
public:
void add (C c) { ++cnt; }
size_t size () const { return cnt; }

private:
size_t cnt {}; 
};

struct Foo1 {};
struct Foo2 {};
struct Foo3 {};

class Z : public S, public S, public S {
public:
using S::add;
using S::add;
using S::add;

using S::size;// (1)
using S::size;// (2)
using S::size;// (3)
};

And usage looks like this:

Z z;

z.add (Foo1 {});
z.add (Foo1 {});
z.add (Foo2 {});

cout << z.size () << endl;

This code compiles fine with gcc-5.1 (c++11), but this code does not compile
under clang-3.5 (c++11 - sorry, I do not have newer version of clang).

Clang produces "error: call to member function 'size' is ambiguous" which is
basically (from my point of view) correct, but gcc compiles it and returns 2.

Ok, but here is much more fun, if I switch the order of lines marked with
comments (1) and (2), to get something like this:

using S::size;// (2)
using S::size;// (1)

The code still compiles on gcc and the result is: 1.

As you can imagine, if you write line (3) before these two, you will get 0.

So, from what I see, gcc gets first using declaration of S::size, ignores
rest of them and uses this one.

Is it a bug?

This question (bug) can be seen at
http://stackoverflow.com/questions/31104690/multiple-inheritance-from-instantiations-of-template-class-and-what-about-access
but I didn't receive reasonable answer there.

Best,

Artur

[Bug libstdc++/66699] New: Incorrect order of destruction for std::tuple elements

[antoshkka at gmail dot com]

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

Bug ID: 66699
   Summary: Incorrect order of destruction for std::tuple elements
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

According to C++ Standard:
"An instantiation of tuple with two arguments is similar to an instantiation of
pair with the same two arguments."

The following small example prints the order of tuple and pair elements
destruction:

#include 
#include 

struct print_num {
int num_;
~print_num() {
std::cerr << num_;
}
};


int main() {
{
std::cerr << "pair : ";
std::pair p;
std::get<0>(p).num_ = 0;
std::get<1>(p).num_ = 1;
}

{
std::cerr << "\ntuple: ";
std::tuple t;
std::get<0>(t).num_ = 0;
std::get<1>(t).num_ = 1;
}
}

Program outputs
pair : 10
tuple: 01


It seems that destruction of a tuple from last to first element is more correct
than the current approach with destruction from the first element to last.

[Bug libstdc++/66699] Incorrect order of destruction for std::tuple elements

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I don't see why you think this is an issue because:
f(temp(), temp());

The C++ does not specifies which one gets constructed first or second.

[Bug c++/65977] Constexpr should be allowed in declaration of friend template specialization

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Jun 29 22:02:08 2015
New Revision: 225148

URL: https://gcc.gnu.org/viewcvs?rev=225148&root=gcc&view=rev
Log:
/cp
2015-06-29  Paolo Carlini  

PR c++/65977
* decl.c (grokfndecl): Allow constexpr declarations of friend
template specializations.

/testsuite
2015-06-29  Paolo Carlini  

PR c++/65977
* g++.dg/cpp0x/constexpr-friend-3.C: New.
* g++.dg/cpp0x/constexpr-friend-2.C: Adjust.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-friend-3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-friend-2.C

[Bug c++/65977] Constexpr should be allowed in declaration of friend template specialization

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org

--- Comment #3 from Paolo Carlini  ---
Fixed.

[Bug other/65732] stack overflow while demangling _ZNK7VectorTIfEmlIfvEES_IDTmlcvf_EcvT__EEERKS2_

[2bluesc at gmail dot com]

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

Kyle Manna <2bluesc at gmail dot com> changed:

   What|Removed |Added

 CC||2bluesc at gmail dot com

--- Comment #2 from Kyle Manna <2bluesc at gmail dot com> ---
This affects me too with binutils 2.25.0 on Arch Linux.

Added a two tests that also fail @ https://gist.github.com/9b701e4194c6c4e6cfb1

[Bug target/64833] [SH]: Error: pcrel too far when compiling imagemagick and graphicsmagick on Debian sh4

[kkojima at gcc dot gnu.org]

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

--- Comment #15 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #14)
> I was trying to understand what's happening there ... it's a bit confusing. 
> A cleaner way would probably be to add a function in final.c to update the
> cached length value for the INSN_UID in final.c.  Then, invoke that function
> for the insn in fixup_mova when the pattern rtx is changed from
> casesi_worker_1 to casesi_worker_2.  However, I guess that all the other
> insn length dependent values will have to be re-calculated to get a
> consistent state.

The usual way to re-compute insn length is shorten_branches.  I'm
not sure that new function is a good idea or not.  It looks a too
big hammer for this corner case on one specific target.
sh_reorg calls shorten_branches after the loop which includes
find_barrier call and get_attr_length will return correct value
after that.
It looks too costly to call shorten_branches for the rare case
in the loop.  I'll look for another point to call shorten_branches
which can fix the issue.

> Wouldn't it be easier/safer to just set the length of casesi_worker_1 to "8"?

It may be safest from the computational viewpoint, though it'll
affect almost existing pic codes, I'm afraid.  Perhaps it's OK
for trunk.  The above patch won't affect existing code except
very limited cases, though it's a bit tricky.

[Bug other/65732] stack overflow while demangling _ZNK7VectorTIfEmlIfvEES_IDTmlcvf_EcvT__EEERKS2_

[2bluesc at gmail dot com]

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

--- Comment #3 from Kyle Manna <2bluesc at gmail dot com> ---
I bisected this using the script @ https://gist.github.com/7d4007a2c18c62a1d84d 

It discovers the bad commit to be 492e19d098f4bf4f22bac22815e9cb117be55b33

This seems related to https://sourceware.org/bugzilla/show_bug.cgi?id=17066

[Bug fortran/55824] [OOP] ICE with ALLOCATE and SOURCE= TRANSPOSE/RESHAPE

[damian at sourceryinstitute dot org]

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

Damian Rouson  changed:

   What|Removed |Added

 CC||damian at sourceryinstitute 
dot or
   ||g

--- Comment #4 from Damian Rouson  ---
I'm guessing the code below is another manifestation of the this bug:

$ cat ice-on-pack-unlimited-polymorphic.f90 
contains
  subroutine array_to_vector(array)
class(*), allocatable :: vector(:),array(:,:)
allocate(vector,source=pack(array,.true.))
  end subroutine
end

$ gfortran ice-on-pack-unlimited-polymorphic.f90 
ice-on-pack-unlimited-polymorphic.f90:4:0:

 allocate(vector,source=pack(array,.true.))
1
internal compiler error: Segmentation fault: 11

ice-on-pack-unlimited-polymorphic.f90:4:0: internal compiler error: Abort trap:
6
gfortran: internal compiler error: Abort trap: 6 (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ gfortran --version
GNU Fortran (MacPorts gcc6 6-20150621_0) 6.0.0 20150621 (experimental)
...

$ sudo port select --set gcc mp-gcc5
Selecting 'mp-gcc5' for 'gcc' succeeded. 'mp-gcc5' is now active.

$ gfortran ice-on-pack-unlimited-polymorphic.f90 
ice-on-pack-unlimited-polymorphic.f90:4:13:

 allocate(vector,source=pack(array,.true.))
 1
Error: Array specification required in ALLOCATE statement at (1)

[Bug fortran/55824] [OOP] ICE with ALLOCATE and SOURCE= TRANSPOSE/RESHAPE

[damian at sourceryinstitute dot org]

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

--- Comment #5 from Damian Rouson  ---
I'm guessing the code below is another manifestation of the this bug:

$ cat ice-on-pack-unlimited-polymorphic.f90 
contains
  subroutine array_to_vector(array)
class(*), allocatable :: vector(:),array(:,:)
allocate(vector,source=pack(array,.true.))
  end subroutine
end

$ gfortran ice-on-pack-unlimited-polymorphic.f90 
ice-on-pack-unlimited-polymorphic.f90:4:0:

 allocate(vector,source=pack(array,.true.))
1
internal compiler error: Segmentation fault: 11

ice-on-pack-unlimited-polymorphic.f90:4:0: internal compiler error: Abort trap:
6
gfortran: internal compiler error: Abort trap: 6 (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ gfortran --version
GNU Fortran (MacPorts gcc6 6-20150621_0) 6.0.0 20150621 (experimental)
...

$ sudo port select --set gcc mp-gcc5
Selecting 'mp-gcc5' for 'gcc' succeeded. 'mp-gcc5' is now active.

$ gfortran ice-on-pack-unlimited-polymorphic.f90 
ice-on-pack-unlimited-polymorphic.f90:4:13:

 allocate(vector,source=pack(array,.true.))
 1
Error: Array specification required in ALLOCATE statement at (1)

[Bug target/64833] [SH]: Error: pcrel too far when compiling imagemagick and graphicsmagick on Debian sh4

[kkojima at gcc dot gnu.org]

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

--- Comment #16 from Kazumoto Kojima  ---
(In reply to Kazumoto Kojima from comment #15)
> I'll look for another point to call shorten_branches
> which can fix the issue.

OK, I'm giving up on this and now testing the patch below.

diff --git a/config/sh/sh.md b/config/sh/sh.md
index 35113c0..5c8d306 100644
--- a/config/sh/sh.md
+++ b/config/sh/sh.md
@@ -11344,6 +11344,8 @@ label:
 LABEL_NUSES (operands[2])++;
 })

+;; This may be replaced with casesi_worker_2 in sh_reorg for PIC.
+;; The insn length is set to 8 for that case.
 (define_insn "casesi_worker_1"
   [(set (match_operand:SI 0 "register_operand" "=r,r")
(unspec:SI [(reg:SI R0_REG)
@@ -11375,7 +11377,9 @@ label:
   gcc_unreachable ();
 }
 }
-  [(set_attr "length" "4")])
+  [(set_attr_alternative "length"
+ [(if_then_else (match_test "flag_pic") (const_int 8) (const_int 4))
+  (if_then_else (match_test "flag_pic") (const_int 8) (const_int 4))])])

 (define_insn "casesi_worker_2"
   [(set (match_operand:SI 0 "register_operand" "=r,r")

[Bug jit/66700] New: Bogus gimplification of jit code using ptrs to functions

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 66700
   Summary: Bogus gimplification of jit code using ptrs to
functions
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
Blocks: 66627
  Target Milestone: ---

https://gcc.gnu.org/ml/jit/2015-q2/msg00131.html noted a problem where a ptr to
a local was being passed as an argument in a function call built using
libgccjit, where the function was a prebuilt one that writes back through the
ptr to the local, but where the local wasn't changing.

The issue seems to be that during gimplification, the argument changes from
  &local
to:
  &local.0

and then "local" gets used later on in the caller, not "local.0".


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66627
[Bug 66627] Tracker bug for jit bugs affecting ravi

[Bug jit/66700] Bogus gimplification of jit code using ptrs to functions

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Created attachment 35875
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35875&action=edit
Minimal reproducer

This gimplifies to:

test_caller_of_write_back_through_ptr ()
{
   d.0;
   D.59;
   d;

  :
  d = 4.0e+0;
  d.0 = d;
  write_back_through_ptr (&d.0);
  D.59 = d;
  return D.59;
}

where write_back_through_ptr modifies "d.0", but the return value uses "d",
hence the result is "4.0", rather than the expected value of "5.60".

[Bug jit/66700] Bogus gimplification of jit code using ptrs to functions

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Created attachment 35876
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35876&action=edit
Dump of initial GENERIC form of function

[Bug target/66509] the new clang-based assembler in Xcode 7 on 10.11 fails on the libjava/java/lang/reflect/natArray.cc file from FSF gcc 5.1 at -m32

[mrs at gcc dot gnu.org]

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

--- Comment #19 from mrs at gcc dot gnu.org  ---
Author: mrs
Date: Tue Jun 30 02:10:43 2015
New Revision: 225158

URL: https://gcc.gnu.org/viewcvs?rev=225158&root=gcc&view=rev
Log:
PR target/66509
* configure.ac: Fix filds and fildq test for 64-bit.
* configure: Regenerated.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/configure
trunk/gcc/configure.ac

[Bug jit/66700] Bogus gimplification of jit code using ptrs to functions

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Looks like we're not setting
  TREE_ADDRESSABLE (x) = 1
when taking the address of something.

[Bug jit/66700] Bogus gimplification of jit code using ptrs to functions

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Created attachment 35877
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35877&action=edit
Crude patch that fixes the testcase

[Bug target/64833] [SH]: Error: pcrel too far when compiling imagemagick and graphicsmagick on Debian sh4

[olegendo at gcc dot gnu.org]

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

--- Comment #17 from Oleg Endo  ---
(In reply to Kazumoto Kojima from comment #15)
> sh_reorg calls shorten_branches after the loop which includes
> find_barrier call and get_attr_length will return correct value
> after that.

I see.  If I understand correctly, the computed and cached values in final.c
will not be used by anything else in this case and shorten_branches is always
invoked afterwards.  Now I understand the patch in c#12, thanks.

> > Wouldn't it be easier/safer to just set the length of casesi_worker_1 to 
> > "8"?
> 
> It may be safest from the computational viewpoint, though it'll
> affect almost existing pic codes, I'm afraid.  Perhaps it's OK
> for trunk.  The above patch won't affect existing code except
> very limited cases, though it's a bit tricky.

Increasing insn lengths unnecessarily might result in some unlucky constant
pool placements and far branches and some code might get worse.  On the other
hand, constant pool placement and far branch code generation is "a matter of
luck" anyway.  Reading through the sh_reorg code, there are already some
"CODE_FOR_casesi_worker_2" ifs and elses.  Adding one more special case as in
c#12 seems to fit in the picture nicely :)
However, I think the comment in c#12 should be expanded a bit ...

/* get_attr_length returns cached insn lengths which are computed
   once in shorten_branches.  When here, fixup_mova might have replaced
   the insn pattern casesi_worker_1 with casesi_worker_2 and the cached
   insn length will be wrong.  In this case, get the uncached length
   value directly from the insn attribute.  */

[Bug target/64833] [SH]: Error: pcrel too far when compiling imagemagick and graphicsmagick on Debian sh4

[olegendo at gcc dot gnu.org]

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

--- Comment #18 from Oleg Endo  ---
BTW, in sh_reorg there is...

  label_ref_list_d::pool.release ();
  for (insn = first; insn; insn = NEXT_INSN (insn))
PUT_MODE (insn, VOIDmode);

  mdep_reorg_phase = SH_SHORTEN_BRANCHES1;
  INSN_ADDRESSES_FREE ();
  split_branches (first);

Kaz, do you know why that PUT_MODE loop above is required?

[Bug libstdc++/66699] Incorrect order of destruction for std::tuple elements

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
Since the layout of std::pair members is fully specified, so is the order of
their initialization and destruction.  The output of the test case reflects
this order.

The order of initialization (and destruction) of std:stuple subobjects is less
clearly specified.  At least it's not immediately obvious from my reading of
the spec if any particular order is required.

The reason why the output for std::tuple with libstdc++ is the reverse of
std::pair is because the implementation, which relies on recursive inheritance,
 stores and constructs tuple elements in the reverse order: i.e., the base
class, which stores the last element, is stored and constructed first, followed
by each derived class (each of which stores the last - Nth element).

[Bug target/64833] [SH]: Error: pcrel too far when compiling imagemagick and graphicsmagick on Debian sh4

[kkojima at gcc dot gnu.org]

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

--- Comment #19 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #18)

I don't know how it works, though I've found
https://gcc.gnu.org/ml/gcc-patches/2006-03/msg01108.html

[Bug rtl-optimization/66552] Missed optimization when shift amount is result of signed modulus

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-06-30
 CC||segher at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Segher Boessenkool  ---
Please file a separate bug for that last problem (it seems to be a
combine problem; it has nothing to do with PR66217).  You can assign
it to me if you want.

Confirmed, btw.

[Bug libstdc++/66699] Incorrect order of destruction for std::tuple elements

[antoshkka at gmail dot com]

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

--- Comment #3 from Antony Polukhin  ---
(In reply to Martin Sebor from comment #2)
> Since the layout of std::pair members is fully specified, so is the order of
> their initialization and destruction.  The output of the test case reflects
> this order.
> 
> The order of initialization (and destruction) of std:stuple subobjects is
> less clearly specified.  At least it's not immediately obvious from my
> reading of the spec if any particular order is required.

I'm pointing out that according to Standard std::pair and
std::tuple must be similar. std::pair destruction order is fully
specified, so that order must be used by tuple too.

[Bug other/65732] stack overflow while demangling _ZNK7VectorTIfEmlIfvEES_IDTmlcvf_EcvT__EEERKS2_

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
492e19d098f4 in binutils is r205292 in gcc.