[Bug sanitizer/63813] New: [5 Regression][UBSAN] ICE in ubsan_type_descriptor, at ubsan.c:346

[burnus at gcc dot gnu.org]

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

Bug ID: 63813
   Summary: [5 Regression][UBSAN] ICE in ubsan_type_descriptor, at
ubsan.c:346
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org,
mpolacek at gcc dot gnu.org

With yesterdays's GCC, compiling our big code fails with:

$ g++ -S -w -fsanitize=undefined -O1 poly21.ii

poly21.ii: In member function ‘void
sfm::PolygonBuilder::ProcessSingleExternalTopRight(const
sfm::PolygonSingleEvent&)’:
poly21.ii:23:8: internal compiler error: in ubsan_type_descriptor, at
ubsan.c:346
   void PolygonBuilder::ProcessSingleExternalTopRight (
^
0xcaaebc ubsan_type_descriptor(tree_node*, ubsan_print_style)
../../gcc/ubsan.c:346
0xcac58c ubsan_expand_null_ifn(gimple_stmt_iterator*)
../../gcc/ubsan.c:766


It was working on 7 November.


namespace sfm
{
  class PolygonFragment { };
  typedef long AttributeValue;
  class CrossingEvent {
   public:
inline AttributeValue GetValue () const;
  };
  class SingleCrossingEvent : public CrossingEvent { };
  class PolygonSingleEvent : public SingleCrossingEvent {
   public:
inline PolygonFragment &GetFragment () const;
  };
  PolygonFragment &PolygonSingleEvent::GetFragment () const {
return *reinterpret_cast (GetValue ());
  }
  class PolygonBuilder {
void ProcessSingleExternalTopRight (const PolygonSingleEvent &inEvent);
inline void CloseExternal (PolygonFragment &ioLeft,
   PolygonFragment &ioRight);
PolygonFragment *mCarryBelow;
  };
  void PolygonBuilder::ProcessSingleExternalTopRight (
  const PolygonSingleEvent &inEvent)
  {
CloseExternal (*mCarryBelow, inEvent.GetFragment ());
  }
}

[Bug target/63810] gcc sets incorrect macro for OS X deployment targets

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Target||*-*-darwin*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-11
  Component|driver  |target
   Host||*-*-darwin*
Version|unknown |5.0
 Ever confirmed|0   |1
  Build||*-*-darwin*

[Bug tree-optimization/63569] [5.0 Regression] Wrong code with volatile and ICF

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||trippels at gcc dot gnu.org

[Bug ipa/63671] [5 Regression] 21% tramp3d-v4 performance hit due to -fdevirtualize

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  ---
There is also code size differnce. I tried to track it down and with
-fno-devirtualize I need to disable all places devirtualization happens:
Index: gimple-fold.c
===
--- gimple-fold.c   (revision 217304)
+++ gimple-fold.c   (working copy)
@@ -331,7 +331,7 @@ fold_gimple_assign (gimple_stmt_iterator
tree val = OBJ_TYPE_REF_EXPR (rhs);
if (is_gimple_min_invariant (val))
  return val;
-   else if (flag_devirtualize && virtual_method_call_p (rhs))
+   else if (flag_devirtualize && virtual_method_call_p (rhs) && 0)
  {
bool final;
vec targets
@@ -2633,7 +2633,7 @@ gimple_fold_call (gimple_stmt_iterator *
  gimple_call_set_fn (stmt, OBJ_TYPE_REF_EXPR (callee));
  changed = true;
}
-  else if (flag_devirtualize && !inplace && virtual_method_call_p
(callee))
+  else if (flag_devirtualize && !inplace && virtual_method_call_p (callee)
&& 0)
{
  bool final;
  vec targets
Index: ipa.c
===
--- ipa.c   (revision 217304)
+++ ipa.c   (working copy)
@@ -198,7 +198,7 @@ walk_polymorphic_call_targets (hash_set<
  final or anonymous (so we know all its derivation)
  and there is only one possible virtual call target,
  make the edge direct.  */
-  if (final)
+  if (final && 0)
 {
   if (targets.length () <= 1 && dbg_cnt (devirt))
{
Index: tree-ssa-pre.c
===
--- tree-ssa-pre.c  (revision 217304)
+++ tree-ssa-pre.c  (working copy)
@@ -4320,7 +4320,7 @@ eliminate_dom_walker::before_dom_childre
{
  tree fn = gimple_call_fn (stmt);
  if (fn
- && flag_devirtualize
+ && flag_devirtualize && 0
  && virtual_method_call_p (fn))
{
  tree otr_type = obj_type_ref_class (fn);

So apparently it is not the unit growth nor reachability code. It is simply
presence of direct calls instead of polymorphic calls that seems to make
inliner to do bad decisions...

[Bug tree-optimization/63748] [4.9/5 Regression] wrong may be used uninitialized warning (abnormal edges)

[amodra at gmail dot com]

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

--- Comment #8 from Alan Modra  ---
Thanks!  Fix confirmed with gdb sources prior to the workaround Uli committed. 
Is the fix appropriate for gcc-4.9?  If not, I'll be happy to adjust the target
milestone and close the bug.

[Bug c/60804] Another CilkPlus ICE in gimplify_expr, at gimplify.c:8335

[ak at gcc dot gnu.org]

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

--- Comment #11 from ak at gcc dot gnu.org ---
Author: ak
Date: Tue Nov 11 05:10:58 2014
New Revision: 217336

URL: https://gcc.gnu.org/viewcvs?rev=217336&root=gcc&view=rev
Log:
Error out for Cilk_spawn or array expression in forbidden places

_Cilk_spawn or Cilk array expressions are only allowed on their own,
but not in for(), if(), switch, do, while, goto, etc.
The C parser didn't always check for that, which lead to ICEs earlier
for invalid code.

Add a generic helper that checks this and call it where needed
in the C frontend.

I chose to allow spawn/array for for init and increment expressions.
While the Cilk spec could be interpreted to forbid it there too
there didn't seem any reason to not allow it.

One dark corner is spawn, array in statement expressions not at
the end. Right now that's forbidden too.

gcc/c-family/:

2014-11-10  Andi Kleen  

PR c/60804
* c-common.h (check_no_cilk): Declare.
* cilk.c (get_error_location): New function.
(check_no_cilk): Dito.

gcc/c/:

2014-11-10  Andi Kleen  

PR c/60804
* c-parser.c (c_parser_statement_after_labels): Call
check_no_cilk.
(c_parser_if_statement): Dito.
(c_parser_switch_statement): Dito.
(c_parser_while_statement): Dito.
(c_parser_do_statement): Dito.
(c_parser_for_statement): Dito.
* c-typeck.c (c_finish_loop): Dito.

Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.h
trunk/gcc/c-family/cilk.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/c/c-typeck.c

[Bug go/63812] Compilation error due to a large floating point constant truncated to integer

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
This might be an issue in mpfr and not GCC if I read GCC's code correctly. 
Depending on how 2.22 is read in as a floating point value.

[Bug bootstrap/63811] r217322 breaks bootstrap

[howarth at bromo dot med.uc.edu]

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

--- Comment #1 from howarth at bromo dot med.uc.edu ---
The change...

Index: libstdc++-v3/include/bits/stl_deque.h
===
--- libstdc++-v3/include/bits/stl_deque.h(revision 217331)
+++ libstdc++-v3/include/bits/stl_deque.h(working copy)
@@ -642,7 +642,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 // Create a copy of the current allocator.
 _Tp_alloc_type __alloc{_M_get_Tp_allocator()};
 // Put that copy in a moved-from state.
-_Tp_alloc_type __unused __attribute((__unused__)) {std::move(__alloc)};
+_Tp_alloc_type __unused__ __attribute((__unused__)) {std::move(__alloc)};
 // Create an empty map that allocates using the moved-from allocator.
 _Deque_base __empty{__alloc};
 // Now safe to modify current allocator and perform non-throwing swaps.

eliminates the bootstrap error

[Bug go/63812] New: Compilation error due to a large floating point constant truncated to integer

[e29253 at jp dot ibm.com]

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

Bug ID: 63812
   Summary: Compilation error due to a large floating point
constant truncated to integer
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: e29253 at jp dot ibm.com
CC: cmang at google dot com

GCCGO cannot compile the following program, while GC can compile and run the
same program. This program is derived from a unit test of Docker
(https://github.com/docker/docker/blob/master/pkg/units/size_test.go#L28):

inagaki@black3:~/size_test$ cat example.go
package main

import "fmt"

func main() {
  fmt.Println(int64(2.22*1000))
}
inagaki@black3:~/size_test$ gccgo example.go
example.go:6:15: error: floating point constant truncated to integer
   fmt.Println(int64(2.22*1000))
   ^
inagaki@black3:~/size_test$ /usr/bin/go build example.go
inagaki@black3:~/size_test$ ./example
2220
inagaki@black3:~/size_test$ gccgo --version
gccgo.bin (GCC) 5.0.0 20141029 (experimental)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

inagaki@black3:~/size_test$

The example can be successfully compiled if the constant value is smaller, for
example, 2.22*10^12.

[Bug bootstrap/63811] New: r217322 breaks bootstrap

[howarth at bromo dot med.uc.edu]

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

Bug ID: 63811
   Summary: r217322 breaks bootstrap
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: howarth at bromo dot med.uc.edu

On x86_64-apple-darwin14, at r217330, the bootstrap now fails at...

make[5]: Entering directory
'/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/include'
mkdir -p ./x86_64-apple-darwin13.4.0/bits/stdc++.h.gch
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc/xgcc -shared-libgcc
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc -nostdinc++
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/src
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/libsupc++/.libs
-B/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/bin/
-B/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/lib/ -isystem
/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/include -isystem
/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/sys-include-x c++-header
-nostdinc++ -g -O2 
-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/include/x86_64-apple-darwin13.4.0
-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/include
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20141110/libstdc++-v3/libsupc++ -O2
-g -std=gnu++0x
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20141110/libstdc++-v3/include/precompiled/stdc++.h
\
-o x86_64-apple-darwin13.4.0/bits/stdc++.h.gch/O2ggnu++0x.gch
In file included from /usr/include/assert.h:42:0,
 from
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/include/cassert:43,
 from
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20141110/libstdc++-v3/include/precompiled/stdc++.h:33:
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/include/bits/stl_deque.h:
In member function ‘std::_Deque_base<_Tp, _Alloc>::_Deque_impl
std::_Deque_base<_Tp, _Alloc>::_M_move_impl()’:
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/include/bits/stl_deque.h:645:17:
error: expected primary-expression before ‘__attribute__’
  _Tp_alloc_type __unused __attribute((__unused__)) {std::move(__alloc)};
 ^
Makefile:1615: recipe for target
'x86_64-apple-darwin13.4.0/bits/stdc++.h.gch/O2ggnu++0x.gch' failed
make[5]: *** [x86_64-apple-darwin13.4.0/bits/stdc++.h.gch/O2ggnu++0x.gch] Error
1
make[5]: Leaving directory
'/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/include'
Makefile:485: recipe for target 'all-recursive' failed
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory
'/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3'
Makefile:391: recipe for target 'all' failed
make[3]: *** [all] Error 2
make[3]: Leaving directory
'/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3'
Makefile:12208: recipe for target 'all-stage1-target-libstdc++-v3' failed
make[2]: *** [all-stage1-target-libstdc++-v3] Error 2
make[2]: Leaving directory '/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir'
Makefile:20568: recipe for target 'stage1-bubble' failed
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory '/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir'
Makefile:912: recipe for target 'all' failed
make: *** [all] Error 2

Suspect this is due to...

r217322 | redi | 2014-11-10 17:44:07 -0500 (Mon, 10 Nov 2014) | 13 lines

Fix std::deque move construction with non-equal allocators.

* include/bits/stl_deque.h (_Deque_base::_Deque_base(_Deque_base&&)):
Dispatch according to whether allocators are always equal.
(_Deque_base::_M_move_impl()): Implement move-from state.
* testsuite/23_containers/deque/requirements/dr438/assign_neg.cc: Fix
dg-error line number.
* testsuite/23_containers/deque/requirements/dr438/
constructor_1_neg.cc: Likewise.
* testsuite/23_containers/deque/requirements/dr438/
constructor_2_neg.cc: Likewise.
* testsuite/23_containers/deque/requirements/dr438/insert_neg.cc:
Likewise.

[Bug driver/63810] gcc sets incorrect macro for OS X deployment targets

[jeremyhu at macports dot org]

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

--- Comment #1 from Jeremy Huddleston Sequoia  ---
Larry said that he's working on a patch to fix this for gcc trunk, and I
suspect he's pretty close to having something since that was about a week ago.

The algorithm for determining what the macro should be is quite simple:

Split the string by "."
Use implicit "0" if there are less than three elements.
if (first field is >10) or (first field is 10 and second field >= 10), use
"%02d%02d%02d" as the format
else use "%02d%01d%01d" as the format

I had to do this in bash for some unrelated reason, and here it is in case it
is helpful to you:

BUILD_MAJOR=$(echo ${PRODUCT_VERSION} | cut -f1 -d.)
BUILD_MINOR=$(echo ${PRODUCT_VERSION} | cut -f2 -d.)
BUILD_TINY=$(echo ${PRODUCT_VERSION} | cut -f3 -d.)

[[ -z "${BUILD_MINOR}" ]] && BUILD_MINOR="0"
[[ -z "${BUILD_TINY}" ]] && BUILD_TINY="0"

if ((BUILD_MAJOR > 10 || (BUILD_MAJOR == 10 && BUILD_MINOR >= 10))) ; then
  VERSION_ENCODED=$(printf "%02d%02d%02d" ${BUILD_MAJOR} ${BUILD_MINOR}
${BUILD_TINY})
else
  VERSION_ENCODED=$(printf "%02d%01d%01d" ${BUILD_MAJOR} ${BUILD_MINOR}
${BUILD_TINY})
fi

For clang, I did this (slightly less clean):

-char Str[5];
-Str[0] = '0' + (Maj / 10);
-Str[1] = '0' + (Maj % 10);
-Str[2] = '0' + std::min(Min, 9U);
-Str[3] = '0' + std::min(Rev, 9U);
-Str[4] = '\0';
+char Str[7];
+if (Maj < 10 || Maj == 10 && Min < 10) {
+  Str[0] = '0' + (Maj / 10);
+  Str[1] = '0' + (Maj % 10);
+  Str[2] = '0' + std::min(Min, 9U);
+  Str[3] = '0' + std::min(Rev, 9U);
+  Str[4] = '\0';
+} else {
+  Str[0] = '0' + (Maj / 10);
+  Str[1] = '0' + (Maj % 10);
+  Str[2] = '0' + (Min / 10);
+  Str[3] = '0' + (Min % 10);
+  Str[4] = '0' + (Rev / 10);
+  Str[5] = '0' + (Rev % 10);
+  Str[6] = '\0';
+}

[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3

[jeremyhu at macports dot org]

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

--- Comment #50 from Jeremy Huddleston Sequoia  
---
As this bug is now marked as resolved, I've filed #63810 to address the
remaining issues.  Lawrence Velázquez  is working on a
patch to address the issue.

[Bug driver/63810] New: gcc sets incorrect macro for OS X deployment targets

[jeremyhu at macports dot org]

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

Bug ID: 63810
   Summary: gcc sets incorrect macro for OS X deployment targets
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeremyhu at macports dot org

Even after the change for bug #61407, gcc is not setting up the deployment
target macro correctly.  gcc always sets the tiny version to 0 which is not
always the case.  For example:

$ echo | clang-mp-3.5 -E -dM - -mmacosx-version-min=10.09.04 | grep
__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__
#define __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ 1094

[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3

[jeremyhu at macports dot org]

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

--- Comment #49 from Jeremy Huddleston Sequoia  
---
(In reply to Francois-Xavier Coudert from comment #45)
> (In reply to Jeremy Huddleston Sequoia from comment #42)
> > The committed patch is incorrect.  It makes an invalid assumption which
> > breaks the usage of deployment targets such as 10.9.3.
> 
> All Apple doc I can find has deployment targets of the form 10.x or 10.x.0
> (where x is integer, but not only one digit).

That is not the case.  Do not make that assumption.

(In reply to howarth from comment #46)
> (In reply to Francois-Xavier Coudert from comment #45)
> > (In reply to Jeremy Huddleston Sequoia from comment #42)
> > > The committed patch is incorrect.  It makes an invalid assumption which
> > > breaks the usage of deployment targets such as 10.9.3.
> > 
> > All Apple doc I can find has deployment targets of the form 10.x or 10.x.0
> > (where x is integer, but not only one digit).
> 
> If Jeremy really disagreed on that change, he hasn't acted on it in the
> gcc49 MacPorts packaging that he maintains (which still uses the original
> proposed patch from
> https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02428.html). FYI, as far as
> llvm-gcc 4.2.1 is concerned, in my fink legacy package for Apple's llvm-gcc
> 4.2.1, I used a back port of our patch,
> http://fink.cvs.sourceforge.net/viewvc/fink/dists/10.7/stable/main/finkinfo/
> languages/llvm-gcc42-yosemite.patch. Neither gcc 4.9.2 nor the patched
> llvm-gcc 4.2.1 has shown any problems on OS X 10.9.5.

I have not fixed the GPL3 ports in MacPorts because I do not read GPL-3 code
and thus am not able to fix it.  Another MacPorts developer is making the fix
for newer versions of gcc.

[Bug rtl-optimization/63799] [5 Regression] r217265 caused libjava failures

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target||x86
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Uroš Bizjak  ---
Fixed.

[Bug rtl-optimization/63620] RELOAD lost SET_GOT dependency on Darwin

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #31 from Uroš Bizjak  ---
Fixed.

[Bug rtl-optimization/63620] RELOAD lost SET_GOT dependency on Darwin

[uros at gcc dot gnu.org]

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

--- Comment #30 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Nov 10 23:29:59 2014
New Revision: 217325

URL: https://gcc.gnu.org/viewcvs?rev=217325&root=gcc&view=rev
Log:
2014-11-11  Uros Bizjak  

Revert:
2014-10-31  Uros Bizjak  

PR target/63620
* config/i386/i386-protos.h (ix86_use_pseudo_pic_reg): Declare.
* config/i386/i386.c (ix86_use_pseudo_pic_reg): Export.
* config/i386/i386.md (*pushtf): Allow only CONST_DOUBLEs that won't
be reloaded through memory.
(*pushxf): Ditto.
(*pushdf): Ditto.

testsuite/ChangeLog:

2014-11-11  Uros Bizjak  
Ilya Enkovich  

PR target/63620
* gcc.target/i386/pr63620.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr63620.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-protos.h
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug target/63527] [5 Regression] -fPIC uses 2 registers for GOT

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Keywords||ra
 CC||vmakarov at gcc dot gnu.org

--- Comment #2 from Uroš Bizjak  ---
RA issue with PIC register, adding CC.

[Bug rtl-optimization/63620] RELOAD lost SET_GOT dependency on Darwin

[vmakarov at gcc dot gnu.org]

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

--- Comment #29 from Vladimir Makarov  ---
Author: vmakarov
Date: Mon Nov 10 21:33:06 2014
New Revision: 217320

URL: https://gcc.gnu.org/viewcvs?rev=217320&root=gcc&view=rev
Log:
2014-11-10  Vladimir Makarov  

PR rtl-optimization/63620
PR rtl-optimization/63799
* lra-lives.c (process_bb_lives): Do not delete EH_REGION, trapped
and setting PIC pseudo insns.
(lra_create_live_ranges): Fix the typo.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-lives.c

[Bug rtl-optimization/63799] [5 Regression] r217265 caused libjava failures

[vmakarov at gcc dot gnu.org]

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

--- Comment #2 from Vladimir Makarov  ---
Author: vmakarov
Date: Mon Nov 10 21:33:06 2014
New Revision: 217320

URL: https://gcc.gnu.org/viewcvs?rev=217320&root=gcc&view=rev
Log:
2014-11-10  Vladimir Makarov  

PR rtl-optimization/63620
PR rtl-optimization/63799
* lra-lives.c (process_bb_lives): Do not delete EH_REGION, trapped
and setting PIC pseudo insns.
(lra_create_live_ranges): Fix the typo.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-lives.c

[Bug bootstrap/63622] [5.0 Regression] Bootstrap fails on x86_64-apple-darwin1[34] after revision r216305

[iains at gcc dot gnu.org]

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

--- Comment #26 from Iain Sandoe  ---
OK - so two more data points.

( i)
With the alias patch, I can bootstrap x86_64-darwin12
However, there are lots of new fails in Ada (for example) that go away when I
force ipa-icf off.

(ii) 
The patch is NOT sufficient to restore bootstrap on powerpc-darwin9 (accepting
that few people care about that platform).

-

So what this tells us is that the alias patch is necessary, but not sufficient
to fix all the issues.

My latest round of testing was carried out on 217269 - it takes time to spin
the permutations - if there's new stuff in since then - then I should try it.

[Bug tree-optimization/63748] [4.9/5 Regression] wrong may be used uninitialized warning (abnormal edges)

[ppalka at gcc dot gnu.org]

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

--- Comment #7 from ppalka at gcc dot gnu.org ---
Author: ppalka
Date: Mon Nov 10 20:43:40 2014
New Revision: 217317

URL: https://gcc.gnu.org/viewcvs?rev=217317&root=gcc&view=rev
Log:
2014-11-10  Patrick Palka  

gcc/
PR middle-end/63748
* tree-ssa-propagate.c (may_propagate_copy): Allow propagating
SSA copies whose source and destination names both occur in
abnormal PHIs.

gcc/testsuite/
PR middle-end/63748
* gcc.dg/pr63748.c: New testcase.


Added:
trunk/gcc/testsuite/gcc.dg/pr63748.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-propagate.c

Re: Suggestions welcomed to get bootstrap to work

[Michael Felt]

I have it all working now. Still need to run the test suite, but I
have been able to build perl-5.20.1 and the blead (5.21.6).

The key was to define CONFIG_SHELL before running the configure
script. The second element was getting the compare phase to pass.
Since I did not have GNU cmp installed (but did have GNU tail
(coreutils) the compare command "tail +16c" was not working (that
would have worked with AIX tail, but did not with GNU tail). After I
installed diffutils (and with it GNU cmp) the compare command used GNU
cmp and the make, make install, etc. completed normally.

Now I just need to automate the mkheaders command after the install
and it should be ready for everyone else
(http://dl.aixtools.net/gnu/gcc).

Compared to what is available from Michael Perlz or BULL it is an
install that has fewer dependencies (i.e. more self-contained) and
does not step on anything already installed (prefix is /opt).

Thanks for your suggestion!

Michael

On Wed, Nov 5, 2014 at 6:37 PM, Richard Earnshaw  wrote:
> You would probably be better of discussing this on gcc-help.  gcc-bugs
> is rather full of bugzilla traffic and normal mails are easily missed.
>
> Have you tried setting CONFIG_SHELL in the environment?  Also, when
> running the build use something like
>
> make SHELL=/bin/bash
>
> R.
>
> On 03/11/14 20:22, Michael Felt wrote:
>> What I have not yet found is how to get the SHELL variable to not use
>> /bin/sh because this is causing a failure immediately at the start of
>> make:
>>
>> root@x064:[/data/prj/gnu/gcc/objdir/gcc-4.7.4]make
>> [ -f stage_final ] || echo stage3 > stage_final
>> /bin/sh[3]: 0403-057 Syntax error at line 1 : `-qlanglvl=extc89' is
>> not expected.
>> make: *** [all] Error 2
>>
>> Setting a link from /bin/sh to "bash" is just a way of breaking the
>> host. I hope there is be a normal way to resolve this.
>>
>> regards,
>> Michael
>>
>> p.s. 4.5.4 fails elsewhere - it does not come as far as 4.7.4 or 4.6.4
>>
>> On Mon, Nov 3, 2014 at 9:19 PM, Michael Felt  wrote:
>>> I fear that after being set to "wontfix" an entry such as
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63714 will be completely
>>> ignored.
>>>
>>>
>>> That is not what I was expecting having spent nearly 8 hours yesterday
>>> looking for something I may have missed.
>>>
>>> I do not understand how to move forward from: Don't bootstrap GCC with
>>> IBM XLC. - considering that is the compiler I have.
>>>
>>> As I commented in the "bug" above, there are issues I have run into
>>> with gcc from other sources. If it turns out there is no other way,
>>> then that shall be the path forced upon me - but I prefer to research
>>> and package my own so that the demands on the host finally get
>>> documented - rather than libraries that step on each other and damage
>>> existing programs.
>>>
>>> That my submission is on the "bug-list" is because that is what seemed
>>> to be the correct path to submit a question. That gcc decides to never
>>> include any result in the source tree is of course your choice.
>>>
>>> I merely wish to express my hope for some sort of assistance in moving
>>> forward versus a stonewall of "don't care".
>>>
>>> FYI: I am trying 4.5.4 now as well, but I fear the same result.
>>>
>>> Maybe it is just a shell thing (e.g. needs a specific bash behavior)
>>>
>>> I shall continue to post, suggestions welcome.
>>>
>>> Michael
>
>

[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3

[fxcoudert at gcc dot gnu.org]

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

--- Comment #48 from Francois-Xavier Coudert  ---
Created attachment 33932
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33932&action=edit
Patch for gcc 4.8 branch (based on gcc 4.8.3)

This is the patch for GCC 4.8 branch (here based on 4.8.3) that allows to build
it on Yosemite.

[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Target||x86_64-apple-darwin14
 Status|NEW |RESOLVED
   Host||x86_64-apple-darwin14
 Resolution|--- |FIXED
  Build||x86_64-apple-darwin14

--- Comment #47 from Francois-Xavier Coudert  ---
Current status for Yosemite:

 - trunk has new failures on darwin, not specific to Yosemite ("end of stage 1"
syndrome)
 - gcc 4.9.2, and the 4.9 branch, both build fine.
 - gcc 4.8.3 builds fine with a similar patch to those I committed to 4.9 and
trunk

Thus closing this one as fixed.

[Bug bootstrap/63573] [5 Regression] libgo: ICE building libgo on powerpc-linux-gnu

[hubicka at gcc dot gnu.org]

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

--- Comment #18 from Jan Hubicka  ---
OK, in the new testcase we produce thunk that is subsetquently inlined. 
Inlining does not drop from_thunk_p flag and thus the call is expanded as
in-thunk call, but after inlining of course the parameters no longer correspond
to the parameters of outer function - and this is what from_thunk_p flag
promises.

I think correct fix is to clear the flag:
Index: tree-inline.c
===
--- tree-inline.c   (revision 217307)
+++ tree-inline.c   (working copy)
@@ -1567,9 +1567,13 @@ remap_gimple_stmt (gimple stmt, copy_bod
   copy = gimple_copy (stmt);

   /* Clear flags that need revisiting.  */
-  if (is_gimple_call (copy)
- && gimple_call_tail_p (copy))
-   gimple_call_set_tail (copy, false);
+  if (is_gimple_call (copy))
+   {
+ if (gimple_call_tail_p (copy))
+   gimple_call_set_tail (copy, false);
+ if (gimple_call_from_thunk_p (copy))
+   gimple_call_set_from_thunk (copy, false);
+   }

   /* Remap the region numbers for __builtin_eh_{pointer,filter},
 RESX and EH_DISPATCH.  */

Now however we have extra copies born in the inlined sequences. I wonder if
this is harmful (i.e. can it trigger for non-PODs that require copy
constructors?) and if we can avoid them (since they consume memory).

I think when inlining *into* the thunk call, the inliner should avoid producing
extra copies in setup_one_parameter, but it does not solve problem in question
where we are inlining the thunk.

I am testing the above patch.

[Bug bootstrap/63784] [5 Regression] profiledbootstrap failure with bootstrap-lto

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
Created attachment 33931
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33931&action=edit
A testcase

[hjl@gnu-6 pr63784]$ make
./libtool --tag=CXX   --mode=compile
/export/build/gnu/gcc/release/usr/gcc-5.0.0/bin/g++   -g -O2 -c -o foo.lo
foo.cc
libtool: compile:  /export/build/gnu/gcc/release/usr/gcc-5.0.0/bin/g++ -g -O2
-c foo.cc  -fPIC -DPIC -o .libs/foo.o
/export/build/gnu/gcc/release/usr/gcc-5.0.0/bin/gcc -flto -fPIC -g -O2 -c -o
bar.o bar.c
/export/build/gnu/gcc/release/usr/gcc-5.0.0/bin/gcc-ar rv libiberty.a bar.o
/usr/local/bin/ar: creating libiberty.a
a - bar.o
CXX=/export/build/gnu/gcc/release/usr/gcc-5.0.0/bin/g++ \
./libtool --tag=CXX   --mode=link
/export/build/gnu/gcc/release/usr/gcc-5.0.0/bin/g++  -g -O2 -rpath
/export/home/hjl/bugs/gcc/pr63784  -o libcc1.la  foo.lo libiberty.a 

*** Warning: Linking the shared library libcc1.la against the
*** static library libiberty.a is not portable!
libtool: link: /export/build/gnu/gcc/release/usr/gcc-5.0.0/bin/g++ -shared
-nostdlib /usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/crtbeginS.o  .libs/foo.o   libiberty.a
-L/usr/lib/gcc/x86_64-redhat-linux/4.8.3
-L/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../.. -lstdc++
-lm -lc -lgcc_s /usr/lib/gcc/x86_64-redhat-linux/4.8.3/crtendS.o
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/crtn.o-Wl,-soname
-Wl,libcc1.so.0 -o .libs/libcc1.so.0.0.0
/usr/local/bin/ld: /tmp/ccEkQEhc.ltrans0.ltrans.o: relocation R_X86_64_32S
against `i' can not be used when making a shared object; recompile with -fPIC
/tmp/ccEkQEhc.ltrans0.ltrans.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
make: *** [libcc1.la] Error 1
[hjl@gnu-6 pr63784]$

[Bug other/61321] demangler crash on casts in template parameters

[ccoutant at gcc dot gnu.org]

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

Cary Coutant  changed:

   What|Removed |Added

 CC||nheghathivhistha at gmail dot 
com

--- Comment #5 from Cary Coutant  ---
*** Bug 63244 has been marked as a duplicate of this bug. ***

[Bug middle-end/63244] [4.9/5 regression] internal compiler error: Segmentation fault (program cc1plus)

[ccoutant at gcc dot gnu.org]

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

Cary Coutant  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #21 from Cary Coutant  ---
Duplicate of PR 61321.

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

[Bug middle-end/63244] [4.9/5 regression] internal compiler error: Segmentation fault (program cc1plus)

[ccoutant at gcc dot gnu.org]

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

Cary Coutant  changed:

   What|Removed |Added

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

--- Comment #20 from Cary Coutant  ---
Duplicate of PR 61321.

[Bug bootstrap/63573] [5 Regression] libgo: ICE building libgo on powerpc-linux-gnu

[hubicka at gcc dot gnu.org]

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

--- Comment #17 from Jan Hubicka  ---
Author: hubicka
Date: Mon Nov 10 19:14:17 2014
New Revision: 217307

URL: https://gcc.gnu.org/viewcvs?rev=217307&root=gcc&view=rev
Log:

PR bootstrap/63573
* calls.c (initialize_argument_information): When emitting thunk call
use original memory placement of the argument.

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

[Bug other/63425] Demangler crash

[ccoutant at gcc dot gnu.org]

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

Cary Coutant  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ccoutant at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Cary Coutant  ---
This is like a dup of PR 61321.

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

[Bug other/61321] demangler crash on casts in template parameters

[ccoutant at gcc dot gnu.org]

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

Cary Coutant  changed:

   What|Removed |Added

 CC||riku at multitaction dot com

--- Comment #4 from Cary Coutant  ---
*** Bug 63425 has been marked as a duplicate of this bug. ***

[Bug libstdc++/63776] [C++11] Regex collate matching not working

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Tom Straub from comment #2)
> Hi Tim,
> 
> Okay, a program very similar to this using the Boost REGEX library and ICU
> 4.55 works just fine with this.
> 
> According to my understanding, the "char" data type and "std::string"
> classes were specifically set up in C++11 to handle UTF-8 sequences.

Nothing was done to char or std::string because they can already hold UTF-8
data. The new u8 literal prefix was added to produce UTF8-encoded string
literals.

> The "sequence of bytes" are actually valid UNICODE characters.

Right, and if your source character set wasn't UTF-8 you could still initialize
the std::string correctly with e.g.

  std::string s = u8"Jo\u00e3o M\u00e9ro\u00e7o";

> It is acting as if it is still in POSIX or C locale, since it doesn't
> recognize the accented characters as "[:alpha:]" class.

Yes, I don't know how it's supposed to work in  but I agree there seems
to be a bug.

(In reply to Tim Shen from comment #1)
> I don't know much about unicode support status in the standard library.
> @Jon, can you put a comment?

We're missing the facilities for converting between different unicode encodings
which would allow us to convert multibyte char strings to wchar_t so that we
can use the ctype::is(ctype_base::mask, wchar_t) function to match
non-ASCII characters.

Maybe a workaround for now would be to detect when we reach the first byte of a
UTF-8 character, read the rest of the multibyte character into a wchar_t and
use ctype for that.

Or just wait for the rest of the ctype and codecvt features to be implemented.

[Bug ada/39336] libgnat.dylib, libgnarl.dylib don't contain full paths

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |4.5.0

--- Comment #4 from Francois-Xavier Coudert  ---
(In reply to simon from comment #3)
> Fixed in 4.5.0 (only checked on *-apple-darwin10, but no reason to suppose
> isn't fixed on other OS releases).

Thus closing.

[Bug tree-optimization/63778] [5 Regression] Segfault with r217178 building 416.gamess from cpu2006

[hjl at gcc dot gnu.org]

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

--- Comment #9 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Mon Nov 10 18:08:00 2014
New Revision: 217304

URL: https://gcc.gnu.org/viewcvs?rev=217304&root=gcc&view=rev
Log:
Add a testcase for PR tree-optimization/63778

PR tree-optimization/63778
* gfortran.dg/pr63778.f: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr63778.f
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/61529] [5 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:953

[jiwang at gcc dot gnu.org]

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

--- Comment #11 from Jiong Wang  ---
Author: jiwang
Date: Mon Nov 10 17:53:21 2014
New Revision: 217303

URL: https://gcc.gnu.org/viewcvs?rev=217303&root=gcc&view=rev
Log:
[PATCH] Partially fix PR61529, bound basic block frequency

  2014-11-10  Renlin Li 

  PR middle-end/61529

  gcc/
* tree-ssa-threadupdate.c (compute_path_counts): Bound path_in_freq.

  gcc/testsuite/
* gcc.dg/pr61529.c: New.


Added:
trunk/gcc/testsuite/gcc.dg/pr61529.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-threadupdate.c

[Bug ada/42978] gnatmake doesn't report the options it actually provides to ranlib

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||charlet at gcc dot gnu.org

--- Comment #3 from Francois-Xavier Coudert  ---
I'm adding Arnaud to the CC list, so he can commit if the patch still makes
sense.

[Bug tree-optimization/63778] [5 Regression] Segfault with r217178 building 416.gamess from cpu2006

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  ---
[hjl@gnu-mic-2 delta-fortran]$ cat foo.f
  SUBROUTINE ZUNG2L( M, N, K, A, LDA, TAU, WORK, INFO )
  COMPLEX*16 A( LDA, * ), TAU( * ), WORK( * )
  IF( M.LT.0 ) THEN
  END IF
 CALL ZLARF( 'LEFT', M-N+II, II-1, A( 1, II ), 1, TAU( I ), A,
 $   LDA, WORK )
 CALL ZSCAL( M-N+II-1, -TAU( I ), A( 1, II ), 1 )
 A( M-N+II, II ) = ONE - TAU( I )
  END
  SUBROUTINE ZLARF( SIDE, M, N, V, INCV, TAU, C, LDC, WORK )
  CHARACTER SIDE(*)
  LOGICALLSAME
  COMPLEX*16 C( LDC, * ), V(*), WORK(*), TAU
  IF( LSAME( SIDE, 'L' ) ) THEN
 IF( TAU.NE.ZERO ) THEN
CALL ZGEMV( 'CONJUGATE TRANSPOSE', M, N, ONE, C, LDC, V,
 $  INCV, ZERO, WORK, 1 )
 END IF
  END IF
  END
  LOGICAL  FUNCTION LSAME( CA, CB )
  CHARACTER CA(*), CB(*)
  END
  SUBROUTINE ZGEMV ( TRANS, M, N, ALPHA, A, LDA, X, INCX,
 $   BETA, Y, INCY )
  COMPLEX*16 A( LDA, * ), X( * ), Y( * )
  CHARACTER TRANS(*)
  LOGICALLSAME
  IF( LSAME( TRANS, 'N' ) )THEN
 IF( INCY.EQ.1 )THEN
   IF( X( JX ).NE.ZERO )THEN
 Y( I ) = Y( I ) + TEMP*A( I, J )
   END IF
 END IF
  END IF
  END
  SUBROUTINE  ZSCAL(N,ZA,ZX,INCX)
  COMPLEX*16 ZA,ZX(1)
  IF( N.LE.0 .OR. INCX.LE.0 )RETURN
   20 DO 30 I = 1,N
ZX(I) = ZA*ZX(I)
   30 CONTINUE
  END
[hjl@gnu-mic-2 delta-fortran]$
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -S -O3 -ffast-math foo.f
f951: internal compiler error: Segmentation fault
0xd34f3a crash_signal
/export/gnu/import/git/gcc/gcc/toplev.c:358
0xa7b28f gimple_code
/export/gnu/import/git/gcc/gcc/gimple.h:1412
0xa7b46c is_gimple_assign
/export/gnu/import/git/gcc/gcc/gimple.h:2124
0xa7f816 gimple_simplify
/export/build/gnu/gcc/build-x86_64-linux/gcc/gimple-match.c:493
0xa7bcbe gimple_resimplify1
/export/gnu/import/git/gcc/gcc/gimple-match-head.c:125
0xa7d6f0 gimple_simplify(gimple_statement_base*, code_helper*, tree_node**,
gimple_statement_base**, tree_node* (*)(tree_node*))
/export/gnu/import/git/gcc/gcc/gimple-match-head.c:651
0xa711c4 fold_stmt_1
/export/gnu/import/git/gcc/gcc/gimple-fold.c:3074
0xa71ad0 fold_stmt(gimple_stmt_iterator*)
/export/gnu/import/git/gcc/gcc/gimple-fold.c:3253
0xaaa65c maybe_fold_stmt
/export/gnu/import/git/gcc/gcc/gimplify.c:2258
0xab3f64 gimplify_modify_expr
/export/gnu/import/git/gcc/gcc/gimplify.c:4682
0xac0d43 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
/export/gnu/import/git/gcc/gcc/gimplify.c:7693
0xab68ae gimplify_stmt(tree_node**, gimple_statement_base**)
/export/gnu/import/git/gcc/gcc/gimplify.c:5434
0xaa4a03 gimplify_and_add(tree_node*, gimple_statement_base**)
/export/gnu/import/git/gcc/gcc/gimplify.c:397
0xaa5104 internal_get_tmp_var
/export/gnu/import/git/gcc/gcc/gimplify.c:542
0xaa5145 get_formal_tmp_var(tree_node*, gimple_statement_base**)
/export/gnu/import/git/gcc/gcc/gimplify.c:563
0xac3e4d gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
/export/gnu/import/git/gcc/gcc/gimplify.c:8592
0xac7613 force_gimple_operand_1(tree_node*, gimple_statement_base**, bool
(*)(tree_node*), tree_node*)
/export/gnu/import/git/gcc/gcc/gimplify-me.c:93
0xac76cc force_gimple_operand_gsi_1(gimple_stmt_iterator*, tree_node*, bool
(*)(tree_node*), tree_node*, bool, gsi_iterator_update)
/export/gnu/import/git/gcc/gcc/gimplify-me.c:130
0xac force_gimple_operand_gsi(gimple_stmt_iterator*, tree_node*, bool,
tree_node*, bool, gsi_iterator_update)
/export/gnu/import/git/gcc/gcc/gimplify-me.c:159
0xd7da7a gimplify_build2(gimple_stmt_iterator*, tree_code, tree_node*,
tree_node*, tree_node*)
/export/gnu/import/git/gcc/gcc/tree-cfg.c:8223
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[hjl@gnu-mic-2 delta-fortran]$

[Bug ada/42978] gnatmake doesn't report the options it actually provides to ranlib

[simon at pushface dot org]

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

--- Comment #2 from simon at pushface dot org ---
I posted a patch for this in
https://gcc.gnu.org/ml/gcc-patches/2010-02/msg00325.html, and Arnaud approved
it in the followup message, but it never got applied.

[Bug rtl-optimization/63375] [4.8/4.9/5 Regression] reordering of reads across fences

[bobby.prani at gmail dot com]

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

--- Comment #11 from Pranith Kumar  ---
Is there any work around for this in the mean time? Thanks!

[Bug c++/63265] [4.9/5 Regression] Constexpr variables can trigger spurious compiler warnings

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org

[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3

[howarth at bromo dot med.uc.edu]

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

howarth at bromo dot med.uc.edu changed:

   What|Removed |Added

 CC||howarth at bromo dot med.uc.edu

--- Comment #46 from howarth at bromo dot med.uc.edu ---
(In reply to Francois-Xavier Coudert from comment #45)
> (In reply to Jeremy Huddleston Sequoia from comment #42)
> > The committed patch is incorrect.  It makes an invalid assumption which
> > breaks the usage of deployment targets such as 10.9.3.
> 
> All Apple doc I can find has deployment targets of the form 10.x or 10.x.0
> (where x is integer, but not only one digit).

If Jeremy really disagreed on that change, he hasn't acted on it in the gcc49
MacPorts packaging that he maintains (which still uses the original proposed
patch from https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02428.html). FYI, as
far as llvm-gcc 4.2.1 is concerned, in my fink legacy package for Apple's
llvm-gcc 4.2.1, I used a back port of our patch,
http://fink.cvs.sourceforge.net/viewvc/fink/dists/10.7/stable/main/finkinfo/languages/llvm-gcc42-yosemite.patch.
Neither gcc 4.9.2 nor the patched llvm-gcc 4.2.1 has shown any problems on OS X
10.9.5.

[Bug c++/61018] [5 Regression] -Wvarargs does not print warning for member functions

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org
   Target Milestone|--- |5.0
Summary|-Wvarargs does not print|[5 Regression] -Wvarargs
   |warning for member  |does not print warning for
   |functions   |member functions

--- Comment #1 from Manuel López-Ibáñez  ---
It seems a regression, because GCC 4.4.5 did warn.

[Bug libobjc/63765] [5.0 Regression] libobjc testsuite failures on AIX caused by setting _XOPEN_SOURCE

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski  ---
Let's go with the one defining _XOPEN_SOURCE only for Solaris until someone
programs David's suggestion of the host-specific configure file.

[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org

--- Comment #45 from Francois-Xavier Coudert  ---
(In reply to Jeremy Huddleston Sequoia from comment #42)
> The committed patch is incorrect.  It makes an invalid assumption which
> breaks the usage of deployment targets such as 10.9.3.

All Apple doc I can find has deployment targets of the form 10.x or 10.x.0
(where x is integer, but not only one digit).

[Bug libobjc/63765] [5.0 Regression] libobjc testsuite failures on AIX caused by setting _XOPEN_SOURCE

[dje at gcc dot gnu.org]

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

--- Comment #9 from David Edelsohn  ---
I would have expected _XOPEN_SOURCE=500 to be defined in a host-specific
configure file (like libstdc++-v3/config/os/.../os_defines.h) or added to the
compile line in configure.

[Bug target/63685] kern.osversion bug shows up with GFORTRAN as well as GCC

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org

--- Comment #2 from Francois-Xavier Coudert  ---
(In reply to Michael Clover from comment #0)
> I used the fortran compiler, 4.9.0, with the new Mac OS (Yosemite, 10.10),
> and got the same error message others got from the gcc compiler:
> 
> gfortran: warning: couldn’t understand kern.osversion ‘14.0.0
> 
> There doesn't seem to be a way to work around this, so my laptop is
> currently useless for compiling my code.

There are gfortran builds available for Yosemite on my webpage:
http://coudert.name

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[howarth at bromo dot med.uc.edu]

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

--- Comment #24 from howarth at bromo dot med.uc.edu ---
I always thought the major reorganization would be forced whenever Apple
finally fully deprecated the libgcc_s.10.5.dylib stub, the associated
libgcc_s.10.4.dylib symlink pointing at libgcc_s.10.5.dylib and the
libgcc_s.1.dylib symlink pointing at libSystem.B.dylib. I would imagine that
will happen whenever Apple decides to completely remove the legacy libstdc++
support from OS X (which I would imagine is still a few OS releases away).

[Bug libobjc/63765] [5.0 Regression] libobjc testsuite failures on AIX caused by setting _XOPEN_SOURCE

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #7 from David Edelsohn  ---
> Yes, the single objc failure existed before the patch. But I don't know if
> *other* targets need _XOPEN_SOURCE=500.

True, but now (end of stage1) is the time to find out.  In most
compilation environments, defining no feature test macros gives you the
superset of everything available.

Ultimately, it's Andrew's call.

Rainer

[Bug libobjc/63765] [5.0 Regression] libobjc testsuite failures on AIX caused by setting _XOPEN_SOURCE

[dje at gcc dot gnu.org]

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

--- Comment #7 from David Edelsohn  ---
Yes, the single objc failure existed before the patch. But I don't know if
*other* targets need _XOPEN_SOURCE=500.

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[iains at gcc dot gnu.org]

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

--- Comment #23 from Iain Sandoe  ---
My take is:

1. It's good we have an upstream patch - if it percolates through that's one
less thing to worry about - although (of course) that will never realistically
be available historically.

2. we have so many versions, different layouts and version-specific issues,
that I think it's time to reorganise our GCC extensions library to meet these
different requirements than to limp along with kludge after kludge.

(temporary fixes might be needed, of course, while we figure out a better
layout for the general case).

[Bug libobjc/63765] [5.0 Regression] libobjc testsuite failures on AIX caused by setting _XOPEN_SOURCE

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #5 from David Edelsohn  ---
> If _XOPEN_SOURCE is removed from thr.c completely, the testsuite results 
> revert
> to 1 failure.

Did this failure already exist before my patch?  If so, such a change is
certainly better than arch-specific _XOPEN_SOURCE values.  Andrew, what
do you thing?

Thanks.
Rainer

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[howarth at bromo dot med.uc.edu]

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

--- Comment #22 from howarth at bromo dot med.uc.edu ---
(In reply to Francois-Xavier Coudert from comment #21)
> True, we could also follow this approach again
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333#c55), but it's more of a
> hack really.

There isn't any notations upstream that indicate that original problem with
inaccurate results from ___divdc3 was fixed in compiler-rt...

http://llvm.org/bugs/show_bug.cgi?id=9150

[Bug tree-optimization/63796] [5.0 regression] FAIL: g++.dg/ipa/devirt-42.C -std=gnu++11 scan-tree-dump-times optimized "return 2" 2

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Jan Hubicka  ---
I looked into this testcase, not sure why I did not commit the change. The
problem is that we do not eliminate the dead function body (because we
devirtualize late) and therefore we end up with 3 "return 2" statements.  I
guess it is not kind of optimization we can easily implement in 5.0 so I will
update the template count.

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[fxcoudert at gcc dot gnu.org]

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

--- Comment #21 from Francois-Xavier Coudert  ---
True, we could also follow this approach again
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333#c55), but it's more of a
hack really.

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[howarth at bromo dot med.uc.edu]

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

howarth at bromo dot med.uc.edu changed:

   What|Removed |Added

 CC||howarth at bromo dot med.uc.edu

--- Comment #20 from howarth at bromo dot med.uc.edu ---
Don't forget, for the historical record, that the original attempt to work
around such broken compiler-rt calls was discussed in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333.

[Bug c++/63265] [4.9/5 Regression] Constexpr variables can trigger spurious compiler warnings

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

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

[Bug tree-optimization/63778] [5 Regression] Segfault with r217178 building 416.gamess from cpu2006

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On Mon, 10 Nov 2014, hjl.tools at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63778
> 
> --- Comment #5 from H.J. Lu  ---
> (In reply to Richard Biener from comment #3)
> > I can't reproduce it on x86_64-linux, neither with unreduced zheev.F
> > -DSPEC_CPU
> > nor with -march=native added.  Trying a cross to ppc64-linux (BE).
> > 
> > HJ, please provide more detailed instructions (I'm on r217281 now).
> 
> It is fixed by r217260.  Should we add a testcase for this?

Probably - can you reduce sth?  It's fixed by the hunk

Index: genmatch.c
===
--- genmatch.c  (revision 217259)
+++ genmatch.c  (revision 217260)
@@ -1726,6 +1726,7 @@ dt_node::gen_kids (FILE *f, bool gimple)
   if (exprs_len || fns_len)
 {
   fprintf (f, "case SSA_NAME:\n");
+  fprintf (f, "if (do_valueize (valueize, %s) != NULL_TREE)\n", 
kid_opname)
;
   fprintf (f, "{\n");
   fprintf (f, "gimple def_stmt = SSA_NAME_DEF_STMT (%s);\n", 
kid_opname);

[Bug tree-optimization/63778] [5 Regression] Segfault with r217178 building 416.gamess from cpu2006

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[fxcoudert at gcc dot gnu.org]

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

--- Comment #19 from Francois-Xavier Coudert  ---
(In reply to Iain Sandoe from comment #17)
> if it's part of compiler-rt we can just post a patch on llvm-commits and
> that will eventually percolate through to the system.

I've opened an LLVM PR and attached a patch here:
http://llvm.org/bugs/show_bug.cgi?id=21518

[Bug c++/63809] New: Missing warning on extra template

[glisse at gcc dot gnu.org]

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

Bug ID: 63809
   Summary: Missing warning on extra template
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org

wide-int.h contains code like:

  template <>
  template 
  struct binary_traits 
  {
typedef widest_int result_type;
  };

g++ fails to warn about the extra parameter list. clang does warn, see PR63750.

[Bug target/63808] New: [arm] Invalid register saving in FIQ handler causes register corruption

[Sergey.Belyashov at gmail dot com]

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

Bug ID: 63808
   Summary: [arm] Invalid register saving in FIQ handler causes
register corruption
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Sergey.Belyashov at gmail dot com

I have found strange bug which causes USR-mode register damage after FIQ
processing. Fiq handler stores R8 to the stack and loads it to USR-mode
registers at return instruction:
fiq:
sub lr, lr, #4
stmfd   sp!, {r0, r1, r2, r3, r4, r5, r6, r7, r8, lr}

ldmfd   sp!, {r0, r1, r2, r3, r4, r5, r6, r7, r8, pc}^

To reproduce use this code:

unsigned char a[8][5];
int func1(unsigned port);
unsigned func2(unsigned,void*);

__attribute__((optimize("Os"),interrupt("FIQ")))
void fiq(void)
{
static unsigned char b[8];
unsigned char *p = a[0];
for(int i = 0; i < 8; ++i) {
unsigned s = func1(i + 0x1);
func2(s,  &b[i]);

do {
if (s & 1)
++*p;
++p;
s >>= 1;
} while (s != 0x01);
}
}

Compile it using:
$ arm-none-eabi-gcc -c -S -std=c99 test_fiq.c

I try to create dummy FIQ handler with one instruction, which clobbes R8:
__asm__ volatile ("bl 0x12345" : : : "r8");
But compiler creates valid entry/exit code (ignoring R8 in save/restore).

$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/bin/../lib/gcc/arm-none-eabi/4.8.4/lto-wrapper
Target: arm-none-eabi
Configured with: /build/buildd/gcc-arm-none-eabi-4.8.4.2014q3/src/gcc/configure
--target=arm-none-eabi
--prefix=/build/buildd/gcc-arm-none-eabi-4.8.4.2014q3/install-native
--libexecdir=/build/buildd/gcc-arm-none-eabi-4.8.4.2014q3/install-native/lib
--infodir=/build/buildd/gcc-arm-none-eabi-4.8.4.2014q3/install-native/share/doc/gcc-arm-none-eabi/info
--mandir=/build/buildd/gcc-arm-none-eabi-4.8.4.2014q3/install-native/share/doc/gcc-arm-none-eabi/man
--htmldir=/build/buildd/gcc-arm-none-eabi-4.8.4.2014q3/install-native/share/doc/gcc-arm-none-eabi/html
--pdfdir=/build/buildd/gcc-arm-none-eabi-4.8.4.2014q3/install-native/share/doc/gcc-arm-none-eabi/pdf
--enable-languages=c,c++ --enable-plugins --disable-decimal-float
--disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath
--disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared
--disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib
--with-headers=yes --with-python-dir=share/gcc-arm-none-eabi
--with-sysroot=/build/buildd/gcc-arm-none-eabi-4.8.4.2014q3/install-native/arm-none-eabi
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-pkgversion='GNU Tools for ARM Embedded Processors'
--with-multilib-list=armv6-m,armv7-m,armv7e-m,armv7-r
Thread model: single
gcc version 4.8.4 20140725 (release) [ARM/embedded-4_8-branch revision 213147]
(GNU Tools for ARM Embedded Processors)

[Bug tree-optimization/63778] [5 Regression] Segfault with r217178 building 416.gamess from cpu2006

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
(In reply to Richard Biener from comment #3)
> I can't reproduce it on x86_64-linux, neither with unreduced zheev.F
> -DSPEC_CPU
> nor with -march=native added.  Trying a cross to ppc64-linux (BE).
> 
> HJ, please provide more detailed instructions (I'm on r217281 now).

It is fixed by r217260.  Should we add a testcase for this?

[Bug tree-optimization/63800] [5 Regression] ICE on valid code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Mon Nov 10 14:31:31 2014
New Revision: 217288

URL: https://gcc.gnu.org/viewcvs?rev=217288&root=gcc&view=rev
Log:
2014-11-10  Richard Biener  

PR tree-optimization/63800
* tree-ssa-pre.c (eliminate_push_avail): Push in a way so
we can restore the previous availability in after_dom_children.
(eliminate_dom_walker::after_dom_children): Restore
previous availability.

* gcc.dg/torture/pr63800.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr63800.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-pre.c

[Bug sanitizer/63806] #UBSAN ignores signed char possible overflow

[y.gribov at samsung dot com]

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

--- Comment #4 from Yury Gribov  ---
Looks like some compilers check integer demotions (e.g. MS checks with their
/RTCc flag).  I wonder if it makes sense to add an optional flag for this
(obviously not enabled under normal -fsanitize=undefined).

[Bug ada/48293] Legal program rejected, empty discriminant blocks object allocation with built-in-place

[charlet at gcc dot gnu.org]

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

Arnaud Charlet  changed:

   What|Removed |Added

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

--- Comment #3 from Arnaud Charlet  ---
Closing.

[Bug ada/48012] The executable file hangs up by combination of controlled-type, generic, renames and Inline_Always

[charlet at gcc dot gnu.org]

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

Arnaud Charlet  changed:

   What|Removed |Added

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

--- Comment #2 from Arnaud Charlet  ---
Closing.

[Bug ada/48002] internal error on calling inherited, overloaded and abstract subprograms with string literal

[charlet at gcc dot gnu.org]

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

Arnaud Charlet  changed:

   What|Removed |Added

 CC||charlet at gcc dot gnu.org
   Target Milestone|--- |5.0

--- Comment #2 from Arnaud Charlet  ---
Closing then, thanks for checking

[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|4.8.5   |---

[Bug rtl-optimization/63799] [5 Regression] r217265 caused libjava failures

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-10
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

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

[Bug tree-optimization/63796] [5.0 regression] FAIL: g++.dg/ipa/devirt-42.C -std=gnu++11 scan-tree-dump-times optimized "return 2" 2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-10
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

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

[Bug tree-optimization/63798] [5.0 regression] FAIL: gcc.target/powerpc/ppc-fmadd-1.c scan-assembler-not f(add|sub|mul|neg)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/63798] [5.0 regression] FAIL: gcc.target/powerpc/ppc-fmadd-1.c scan-assembler-not f(add|sub|mul|neg)

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Mon Nov 10 14:06:56 2014
New Revision: 217287

URL: https://gcc.gnu.org/viewcvs?rev=217287&root=gcc&view=rev
Log:
2014-11-10  Richard Biener  

PR middle-end/63798
* expr.c (expand_expr_real_2): When expanding FMA_EXPRs
properly treat the embedded multiplication as commutative
when looking for feeding negates.

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

[Bug sanitizer/55479] gfortran.dg/coarray/registering_1.f90 -fcoarray=lib -O2 -lcaf_single execution test fails with -fsanitize=address

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-11-10
 CC||fxcoudert at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Francois-Xavier Coudert  ---
I can't reproduce that on x86_64-apple-darwin14 (Yosemite), neither with trunk,
nor 4.9.2, nor 4.8.0. Can anyone test darwin12 or darwin13 to see if it's
OS-dependent? Or was it fixed throughout?

[Bug c++/63807] New: -Wvarargs doesn't warn when last argument has type that causes undefined behaviour

[redi at gcc dot gnu.org]

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

Bug ID: 63807
   Summary: -Wvarargs doesn't warn when last argument has type
that causes undefined behaviour
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org

The standard says in 18.10 [support.runtime]:

  If the parameter parmN is of a reference type, or of a type that is not
  compatible with the type that results when passing an argument for which
  there is no parameter, the behavior is undefined.

Testcase:

#include 

void f(int& i, ...)
{
  va_list a;
  va_start(a, i);
  va_end(a);
}

int main()
{
  int i=0;
  f(i, 1);
}

G++ produces no diagnostic.


Compiling with EDG says:

"va.cc", line 6: error: incorrect use of va_start

Compiling with Clang says:

va.cc:6:15: warning: 'va_start' has undefined behavior with reference types
[-Wvarargs]

There is no error from ubsan using either G++ or Clang.

[Bug bootstrap/63573] [5 Regression] libgo: ICE building libgo on powerpc-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #16 from Martin Liška  ---
(In reply to Jan Hubicka from comment #15)
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63573
> > 
> > --- Comment #14 from Martin Liška  ---
> > (In reply to Andreas Schwab from comment #12)
> > > This also breaks g++.dg/ipa/pr63587-2.C on powerpc -m32, but the patches 
> > > in
> > > #c6 and #c8 don't fix that.
> > > 
> > > $ gcc/xg++ -Bgcc/ ../gcc/testsuite/g++.dg/ipa/pr63587-2.C -nostdinc++
> > > -Ipowerpc64-linux/32/libstdc++-v3/include/powerpc64-linux
> > > -Ipowerpc64-linux/32/libstdc++-v3/include -I../libstdc++-v3/libsupc++
> > > -I../libstdc++-v3/include/backward -I../libstdc++-v3/testsuite/util
> > > -std=gnu++11 -O2 -S -m32 -o pr63587-2.s
> > > ../gcc/testsuite/g++.dg/ipa/pr63587-2.C: In static member function 
> > > ???static
> > > int
> > > boost::function_obj_invoker0::invoke(boost::function_buffer&)
> > > [with FunctionObj =
> > > boost::test_case_template_invoker]???:
> > > ../gcc/testsuite/g++.dg/ipa/pr63587-2.C:21:3: internal compiler error: in
> > > expand_expr_addr_expr_1, at expr.c:7725
> > 
> > There's really problem that both suggested patches can fix just cases where
> > DECL_INCOMING_RTL is defined. In following situation:
> > 
> > static boost::log::make_output_actor, RightT, 
> > ValueT>::type
> > boost::log::make_output_actor, RightT,
> > ValueT>::make(ActorT, RightT&) [with ActorT = boost::actor;
> > LeftExprT =
> > boost::log::attribute_output_terminal,
> > boost::log::to_log_fun> >, boost::log::to_log_fun>; RightT =
> > boost::log::attribute_actor > boost::actor>; ValueT = int; 
> > boost::log::make_output_actor,
> > RightT, ValueT>::type =
> > boost::actor,
> > boost::log::to_log_fun> >, boost::log::to_log_fun> >, 
> > boost::log::to_log_fun>
> > >] (struct actor left, struct attribute_actor & right)
> > {
> >   struct type D.4892;
> >   struct attribute_name D.4891;
> >   struct to_log_fun D.4890;
> >   struct actor left;
> > 
> >   :
> >   left = left;
> 
> The reason here is that thunk expansion introduce extra temporary.  
>   if (nargs)
> for (i = 1, arg = DECL_CHAIN (a); i < nargs; i++, arg = DECL_CHAIN
> (arg))
>   {  
> tree tmp = arg;
> if (!is_gimple_val (arg))
>   {
> tmp = create_tmp_reg (TYPE_MAIN_VARIANT
>   (TREE_TYPE (arg)), "arg");
> gimple stmt = gimple_build_assign (tmp, arg);
> gsi_insert_after (&bsi, stmt, GSI_NEW_STMT);
>   }
> vargs.quick_push (tmp); 
>   }
> 
> the temporary obviously is not linked with the original memory expression.

Ok, that makes sense.

> 
> I supose we may want to simply drop the tailcall flag in cases copy is
> necessary, but I do not really see why a copy is desirable here: IMO whatever
> can be RHS of assignment can also be passed to function.  What makes
> left to be !is_gimple_val here?

The loops iterates from 1..(nargs-1), where 'left' is first argument and is put
to vargs here:

  if (this_adjusting)
vargs.quick_push (thunk_adjust (&bsi, a, 1, fixed_offset,
virtual_offset));
  else if (nargs)
vargs.quick_push (a);

---^

  if (nargs)
for (i = 1, arg = DECL_CHAIN (a); i < nargs; i++, arg = DECL_CHAIN
(arg))

Martin

> 
> Honza

[Bug c++/61018] -Wvarargs does not print warning for member functions

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-10
 Ever confirmed|0   |1

[Bug sanitizer/63806] #UBSAN ignores signed char possible overflow

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
No, narrowing conversion is implementation defined, and gcc defines that to the
modulo 2^N wrapping, so this is not undefined behavior, and furthermore,
something you'd complain about in pretty much all the code (there is no
difference between implicit and explicit narrowing cast).

[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-10
   Target Milestone|--- |4.8.5
Summary|[4.9/4.8/5 Regression] ICE: |ICE: in extract_insn, at
   |in extract_insn, at |recog.c:2327 with
   |recog.c:2154 with   |-mcpu=power8
   |-mcpu=power8|
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Not a regression, because it apparently never worked.

[Bug sanitizer/63806] #UBSAN ignores signed char possible overflow

[y.gribov at samsung dot com]

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

--- Comment #2 from Yury Gribov  ---
I think Marat meant that narrowing cast from int to char can be undefined and
it makes sense to emit some check for it as well.

[Bug bootstrap/63771] internal compiler error: in lra_create_copy, at lra.c:1532

[aaro.koskinen at iki dot fi]

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

Aaro Koskinen  changed:

   What|Removed |Added

 CC||aaro.koskinen at iki dot fi

--- Comment #3 from Aaro Koskinen  ---
This is same as Bug 63740.

[Bug sanitizer/63806] #UBSAN ignores signed char possible overflow

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
?  That is the correct thing to do, there is no undefined behavior in C/C++ in
that testcase, for any a/b values.
a + b in C is computed on promoted arguments, so (signed char) ((int) a + (int)
b) in this case, so as long as signed char is narrower than int, it is fine.

[Bug sanitizer/62141] [GCC-4.10.0][ASAN] ICE: Segmentation fault: 11

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target|x86_64-apple-darwin11.4.2   |x86_64-apple-darwin14
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-10
 CC||fxcoudert at gcc dot gnu.org
Version|unknown |5.0
 Ever confirmed|0   |1

--- Comment #5 from Francois-Xavier Coudert  ---
Confirmed with trunk on x86_64-apple-darwin14 (with pending patches from
PR63773). Minimal reproducer:


void f1 (void *x)
{
  char a;
  __builtin_memcpy (x, &a, 1);
}

void f4 (void)
{
  char s[] = "";
}


compiled with "gcc -S -fsanitize=address -m32 a.c" gives ICE. Disappears
without -m32, and also at any optimization level other than -O0 (-O1, -O2, -O3,
-Os).
The backtrace is:

Process 49629 stopped
* thread #1: tid = 0x7e1f7, 0x00010053d2ff
cc1`df_install_ref(this_ref=0x000142091ff0, reg_info=0x00020006,
ref_info=0x000141e1e930, add_to_table=false) + 15 at df-scan.c:2328, queue
= 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1,
address=0x20006)
frame #0: 0x00010053d2ff
cc1`df_install_ref(this_ref=0x000142091ff0, reg_info=0x00020006,
ref_info=0x000141e1e930, add_to_table=false) + 15 at df-scan.c:2328
   2325{
   2326  unsigned int regno = DF_REF_REGNO (this_ref);
   2327  /* Add the ref to the reg_{def,use,eq_use} chain.  */
-> 2328  df_ref head = reg_info->reg_chain;
   2329
   2330  reg_info->reg_chain = this_ref;
   2331  reg_info->n_refs++;
(lldb) bt
* thread #1: tid = 0x7e1f7, 0x00010053d2ff
cc1`df_install_ref(this_ref=0x000142091ff0, reg_info=0x00020006,
ref_info=0x000141e1e930, add_to_table=false) + 15 at df-scan.c:2328, queue
= 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1,
address=0x20006)
  * frame #0: 0x00010053d2ff
cc1`df_install_ref(this_ref=0x000142091ff0, reg_info=0x00020006,
ref_info=0x000141e1e930, add_to_table=false) + 15 at df-scan.c:2328
frame #1: 0x000100540f2e cc1`df_install_refs(bb=,
old_vec=0x7fff5fbff250, reg_info=0x000141e20410,
ref_info=0x000141e1e930, is_notes=) + 110 at df-scan.c:2413
frame #2: 0x00010054155a
cc1`df_refs_add_to_chains(collection_rec=0x7fff5fbfee40,
bb=0x000142c0c820, insn=, flags=15) + 170 at df-scan.c:2466
frame #3: 0x000100543910 cc1`df_bb_refs_record(bb_index=,
scan_insns=) + 672 at df-scan.c:3399
frame #4: 0x000100543abd cc1`df_scan_blocks() + 253 at df-scan.c:629
frame #5: 0x00010052fb17 cc1`rest_of_handle_df_initialize + 311 at
df-core.c:746
frame #6: 0x00010089950b cc1`execute_one_pass(pass=0x000141e13210)
+ 395 at passes.c:2269
frame #7: 0x000100899abe
cc1`execute_pass_list_1(pass=0x000141e13210) + 30 at passes.c:2321
frame #8: 0x000100899ad0
cc1`execute_pass_list_1(pass=0x000141e12490) + 48 at passes.c:2322
frame #9: 0x000100899b19 cc1`execute_pass_list(fn=0x000142d65150,
pass=0x000141e0f310) + 25 at passes.c:2332
frame #10: 0x0001004d6da4
cc1`cgraph_node::expand(this=0x000142c12620) + 260 at cgraphunit.c:1773
frame #11: 0x0001004d7ccf cc1`output_in_order(no_reorder=)
+ 559 at cgraphunit.c:2011
frame #12: 0x0001004d821a
cc1`symbol_table::compile(this=0x000142c05000) + 890 at cgraphunit.c:2242
frame #13: 0x0001004da27e
cc1`symbol_table::finalize_compilation_unit(this=0x000142c05000) + 110 at
cgraphunit.c:2325
frame #14: 0x0001000205c9 cc1`c_write_global_declarations() + 601 at
c-decl.c:10779
frame #15: 0x0001009745ff cc1`compile_file + 143 at toplev.c:583
frame #16: 0x000100e8c014 cc1`toplev::main(this=, argc=20,
argv=0x7fff5fbff8f0) + 3764 at toplev.c:2013
frame #17: 0x000100e8c63c cc1`main(argc=20, argv=0x7fff5fbff8f0) +
44 at main.c:38
frame #18: 0x7fff880bd5c9 libdyld.dylib`start + 1

[Bug bootstrap/63573] [5 Regression] libgo: ICE building libgo on powerpc-linux-gnu

[hubicka at ucw dot cz]

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

--- Comment #15 from Jan Hubicka  ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63573
> 
> --- Comment #14 from Martin Liška  ---
> (In reply to Andreas Schwab from comment #12)
> > This also breaks g++.dg/ipa/pr63587-2.C on powerpc -m32, but the patches in
> > #c6 and #c8 don't fix that.
> > 
> > $ gcc/xg++ -Bgcc/ ../gcc/testsuite/g++.dg/ipa/pr63587-2.C -nostdinc++
> > -Ipowerpc64-linux/32/libstdc++-v3/include/powerpc64-linux
> > -Ipowerpc64-linux/32/libstdc++-v3/include -I../libstdc++-v3/libsupc++
> > -I../libstdc++-v3/include/backward -I../libstdc++-v3/testsuite/util
> > -std=gnu++11 -O2 -S -m32 -o pr63587-2.s
> > ../gcc/testsuite/g++.dg/ipa/pr63587-2.C: In static member function ???static
> > int
> > boost::function_obj_invoker0::invoke(boost::function_buffer&)
> > [with FunctionObj =
> > boost::test_case_template_invoker]???:
> > ../gcc/testsuite/g++.dg/ipa/pr63587-2.C:21:3: internal compiler error: in
> > expand_expr_addr_expr_1, at expr.c:7725
> 
> There's really problem that both suggested patches can fix just cases where
> DECL_INCOMING_RTL is defined. In following situation:
> 
> static boost::log::make_output_actor, RightT, ValueT>::type
> boost::log::make_output_actor, RightT,
> ValueT>::make(ActorT, RightT&) [with ActorT = boost::actor;
> LeftExprT =
> boost::log::attribute_output_terminal,
> boost::log::to_log_fun> >, boost::log::to_log_fun>; RightT =
> boost::log::attribute_actor boost::actor>; ValueT = int; boost::log::make_output_actor,
> RightT, ValueT>::type =
> boost::actor,
> boost::log::to_log_fun> >, boost::log::to_log_fun> >, boost::log::to_log_fun>
> >] (struct actor left, struct attribute_actor & right)
> {
>   struct type D.4892;
>   struct attribute_name D.4891;
>   struct to_log_fun D.4890;
>   struct actor left;
> 
>   :
>   left = left;

The reason here is that thunk expansion introduce extra temporary.  
  if (nargs)
for (i = 1, arg = DECL_CHAIN (a); i < nargs; i++, arg = DECL_CHAIN
(arg))
  {  
tree tmp = arg;
if (!is_gimple_val (arg))
  {
tmp = create_tmp_reg (TYPE_MAIN_VARIANT
  (TREE_TYPE (arg)), "arg");
gimple stmt = gimple_build_assign (tmp, arg);
gsi_insert_after (&bsi, stmt, GSI_NEW_STMT);
  }
vargs.quick_push (tmp); 
  }

the temporary obviously is not linked with the original memory expression.

I supose we may want to simply drop the tailcall flag in cases copy is
necessary, but I do not really see why a copy is desirable here: IMO whatever
can be RHS of assignment can also be passed to function.  What makes
left to be !is_gimple_val here?

Honza

[Bug sanitizer/63806] New: #UBSAN ignores signed char possible overflow

[m.zakirov at samsung dot com]

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

Bug ID: 63806
   Summary: #UBSAN ignores signed char possible overflow
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.zakirov at samsung dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

For the following example GCC with ubsan do not constructs UBSAN_ADD_CHECK for
signed char return value.

signed char a;
signed char b;

signed char foo ()
{
   return a + b;
}

Dump after ubsan

foo ()
{
  signed char a.0_2;
  unsigned char a.1_3;
  signed char b.2_4;
  unsigned char b.3_5;
  unsigned char _6;
  signed char _7;

  :
  a.0_2 = a;
  a.1_3 = (unsigned char) a.0_2;
  b.2_4 = b;
  b.3_5 = (unsigned char) b.2_4;
  _6 = a.1_3 + b.3_5;
  _7 = (signed char) _6;
  return _7;

}

Command line to reproduce

gcc -O3 t.c -fsanitize=signed-integer-overflow -fdump-tree-ubsan -S

[Bug rtl-optimization/63804] [5 Regression] ice in find_oldest_value_reg with -g -O2

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
Please ignore comment 4.

Testcase without implicit functions:

markus@x4 tmp % cat bug169.c
struct brw_context
{
  int gen;
} e;
int a, d;
long b;
enum brw_reg_type
{
  BRW_REGISTER_TYPE_Q
};
struct brw_reg
{
  enum brw_reg_type type : 1;
  int nr : 1;
  struct
  {
unsigned ud;
  } dw1;
};
enum brw_reg_type c;
void
fn1 (int p1)
{
  b = p1 & a;
}

int fn2 ();
void fn3 ();
void
fn4 (struct brw_reg p1, unsigned p2, int p3)
{
  struct brw_reg f, g, h, j = p1, l, m = l;
  struct brw_context i = e;
  if (i.gen)
p2 = 0;
  j.type = c;
  g = j;
  p1 = g;
  fn3 ();
  int k = p2, v = p1.nr, p = v;
  m.dw1.ud = k;
  f = m;
  h = f;
  struct brw_reg n = h;
  fn3 (n);
  {
d = fn2 ();
int o = d;
fn1 (o);
  }
  if (i.gen)
fn3 (p1);
  b = p & a;
  fn3 (p3);
}

[Bug rtl-optimization/63804] [5 Regression] ice in find_oldest_value_reg with -g -O2

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
trippels@gcc2-power8 status % cat freelist_test.ii
template  struct A
{ 
  _Tp _M_i;
  void
  load ()
  { 
_Tp a;
__atomic_load (&_M_i, &a, 0);
  }
};
class B
{ 
  int *ptr;
  int tag;
};
class C
{
public:
  template  C (Allocator, int);
  template 
  void
  construct ()
  { 
pool_.load ();
  }
  A pool_;
};
class D
{ 
  int *px;
  int pn;
};
class F
{
public:
  F (int);
};
class G
{
public:
  G (int) : p_predicate_value (0) {}
  class readonly_property61 : F
  {
  public:
readonly_property61 (int) : F (0) {}
  } p_predicate_value;
  D m_message;
};
void report_assertion (G);
template 
void
run_test ()
{ 
  C b (0, 0);
  b.construct ();
  report_assertion (0);
}
template 
void
run_tests ()
{ 
  run_test ();
}
void
freelist_teststest_method ()
{ 
  run_tests ();
}

[Bug ada/48039] Legal program rejected, a formal function is not visible in generic

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Target|i686-apple-darwin9  |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-10
 CC||fxcoudert at gcc dot gnu.org
   Host|i686-apple-darwin9  |
 Ever confirmed|0   |1
  Known to fail||5.0
  Build|i686-apple-darwin9  |

--- Comment #1 from Francois-Xavier Coudert  ---
Confirmed with trunk on x86_64-linux.

[Bug ada/48012] The executable file hangs up by combination of controlled-type, generic, renames and Inline_Always

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Target|i686-apple-darwin9  |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-10
  Known to work||5.0
   Host|i686-apple-darwin9  |
 Ever confirmed|0   |1
  Known to fail||4.5.2
  Build|i686-apple-darwin9  |

--- Comment #1 from Francois-Xavier Coudert  ---
Confirmed with GNATMAKE 4.4.7 20120313 (Red Hat 4.4.7-11) on x86_64-linux. Does
not occur anymore on trunk.

[Bug ada/48293] Legal program rejected, empty discriminant blocks object allocation with built-in-place

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Target|i686-apple-darwin9  |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-10
 CC||fxcoudert at gcc dot gnu.org
  Known to work||5.0
   Host|i686-apple-darwin9  |
 Ever confirmed|0   |1
  Build|i686-apple-darwin9  |

--- Comment #2 from Francois-Xavier Coudert  ---
Confirmed with GNATMAKE 4.4.7 20120313 on x86_64-linux.
Does not occur with trunk.

[Bug ada/48013] generic instantiation breaks the restriction of No_Elaboration_Code

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Target|i686-apple-darwin9  |
   Host|i686-apple-darwin9  |
  Build|i686-apple-darwin9  |

--- Comment #1 from Francois-Xavier Coudert  ---
Confirmed with trunk on x86_64-linux.

[Bug tree-optimization/63748] [4.9/5 Regression] wrong may be used uninitialized warning (abnormal edges)

[uweigand at gcc dot gnu.org]

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

--- Comment #6 from Ulrich Weigand  ---
I guess I can see why there might be an abnormal edge starting at bb 3, or at
least, that the compiler might not be easily able to deduce that it isn't
necessary.

However, I do not understand why any of the abnormal edges *target* bb5
*before* the setjmp call.  Shouldn't an abnormal edge due to a longjmp end up
*after* the setjmp?  After all, the setjmp itself (including the preparation of
its arguments) is *not* executed twice; the effect of the longjmp is simply to
make the setjmp *return* twice.

[Bug ada/48002] internal error on calling inherited, overloaded and abstract subprograms with string literal

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Target|i686-apple-darwin9  |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-10
 CC||fxcoudert at gcc dot gnu.org
   Host|i686-apple-darwin9  |
 Ever confirmed|0   |1
  Build|i686-apple-darwin9  |

--- Comment #1 from Francois-Xavier Coudert  ---
Confirmed on x86_64-linux with GNATMAKE 4.4.7 20120313.
Fixed on trunk, for both linux and darwin.

[Bug ada/61127] GNAT incorrectly accepts <> as a second association of a generic formal package

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Target|x86_64-apple-darwin13.1.0   |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-10
   Host|x86_64-apple-darwin13.1.0   |
 Ever confirmed|0   |1

--- Comment #1 from Francois-Xavier Coudert  ---
Confirmed with current trunk on x86_64-linux, not darwin-specific.

[Bug target/63805] New: [4.9/4.8/5 Regression] ICE: in extract_insn, at recog.c:2154 with -mcpu=power8

[trippels at gcc dot gnu.org]

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

Bug ID: 63805
   Summary: [4.9/4.8/5 Regression] ICE: in extract_insn, at
recog.c:2154 with -mcpu=power8
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu

trippels@gcc2-power8 status % cat freelist_test.ii
template  struct A
{
  _Tp _M_i;
  void
  load ()
  {
_Tp a;
__atomic_load (&_M_i, &a, 0);
  }
};
class B
{
  int *ptr;
  int tag;
};
class C
{
public:
  template  C (Allocator, int);
  template 
  void
  construct ()
  {
pool_.load ();
  }
  A pool_;
};
class D
{
  int *px;
  int pn;
};
class F
{
public:
  F (int);
};
class G
{
public:
  G (int) : p_predicate_value (0) {}
  class readonly_property61 : F
  {
  public:
readonly_property61 (int) : F (0) {}
  } p_predicate_value;
  D m_message;
};
void report_assertion (G);
template 
void
run_test ()
{
  C b (0, 0);
  b.construct ();
  report_assertion (0);
}
template 
void
run_tests ()
{
  run_test ();
}
void
freelist_teststest_method ()
{
  run_tests ();
}


trippels@gcc2-power8 status % /home/trippels/gcc_test/usr/local/bin/g++ -c
-mcpu=power8 -O2 freelist_test.ii
freelist_test.ii: In function ‘void freelist_teststest_method()’:
freelist_test.ii:68:1: error: unrecognizable insn:
 }
 ^
(insn 10 9 11 2 (set (reg:PTI 157)
(unspec:PTI [
(mem/v:TI (plus:DI (reg/f:DI 150 virtual-stack-vars)
(const_int 24 [0x18])) [-1  S16 A128])
] UNSPEC_LSQ)) freelist_test.ii:8 -1
 (nil))
freelist_test.ii:68:1: internal compiler error: in extract_insn, at
recog.c:2327
0x1094384b _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:110
0x1094389f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:118
0x1090a587 extract_insn(rtx_insn*)
../../gcc/gcc/recog.c:2327
0x106d9a3b instantiate_virtual_regs_in_insn
../../gcc/gcc/function.c:1574
0x106d9a3b instantiate_virtual_regs
../../gcc/gcc/function.c:1942
0x106d9a3b execute
../../gcc/gcc/function.c:1991
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/63803] When GCC 4.9.2 compile with option -O2, the target is error.

[airbak.li at huawei dot com]

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

Airbak  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #7 from Airbak  ---
Thank you for all reply, it could be closed.

[Bug rtl-optimization/63804] [5 Regression] ice in find_oldest_value_reg with -g -O2

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #3 from Markus Trippelsdorf  ---
Somewhat reduced:

markus@x4 tmp % cat bug169.c
struct brw_context
{
  int gen;
} e;
enum brw_reg_type
{
  B
};
struct brw_reg
{
  enum brw_reg_type type : 1;
  int nr : 1;
  struct
  {
unsigned ud;
  } dw1;
} fn1 ();
struct brw_reg a, c;
long b, d;
int
fn2 (struct brw_reg p2, unsigned p3)
{
  struct brw_reg f, g, h, l = g = p2, m, n = m;
  struct brw_context i = e;
  unsigned j;
  int k;
  if (i.gen)
p3 = 0;
  p2 = g;
  if (b)
j = k = 0;
  else
j = k = 2;
  fn3 ();
  l.type = 0;
  c = a;
  fn4 (p2, 0);
  m = fn1 (0, 0, 0, 0, 0, 0);
  n.dw1.ud = p3;
  f = n;
  h = f;
  d = fn5 (p2.nr);
  fn4 (0, 0, f);
  if (i.gen)
fn6 (p2, j, k);
}

[Bug c/63803] When GCC 4.9.2 compile with option -O2, the target is error.

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse  ---
If dereferencing 0 is ok on your platform, you need at least
-fno-delete-null-pointer-checks. I don't know if the isolate pass checks that
flag though (it probably should).

[Bug rtl-optimization/63804] [5 Regression] ice in find_oldest_value_reg with -g -O2

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with r217265.