[Bug ada/63725] Scalar_Storage_Order and nested string subtypes

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-06
 CC||ebotcazou at gcc dot gnu.org
Version|4.9.1   |5.0
Summary|Scalar_Storage_Order is |Scalar_Storage_Order and
   |required for nested string  |nested string subtypes
   |types, but cannot be added  |
   |to those types  |
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Eric Botcazou  ---
I agree this is annoying, but the workaround is trivial (use a derived type
instead of a subtype) so I'm not sure we want to do something here.

[Bug ipa/63696] Alloc-dealloc-mismatch in ipa-icf.c

[chefmax at gcc dot gnu.org]

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

Maxim Ostapenko  changed:

   What|Removed |Added

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

--- Comment #4 from Maxim Ostapenko  ---
Fixed by r216954.

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

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #20 from Igor Zamyatin  ---
This is mentioned here - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534#c9

Fix for this is under review, start of the discussion is here -
http://gcc.gnu.org/ml/gcc-patches/2014-10/msg01727.html

[Bug ada/63725] Scalar_Storage_Order and nested string subtypes

[daniel.merrill at psware dot com]

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

--- Comment #2 from Dan Merrill  ---
Is this what you are proposing?

   type string_type is new string (1..15);
   for string_type'Scalar_Storage_Order use System.High_Order_First;

   type string_array is array (1..2) of string_type;
   for string_array'Scalar_Storage_Order use System.High_Order_First;

   type BigEndianInt32Array is array (1..10) of int32;


   type bigEndianType is record
  ThirtyTwoBits : int32;
  SixteenBits   : int16;
  TestStrings   : string_array;
   end record;

   for bigEndianType use record
  ThirtyTwoBits at 0 range 0  .. 31;
  SixteenBits   at 0 range 32 .. 47;
  TestStrings   at 0 range 48 .. 287;
   end record;

   for bigEndianType'Bit_Order use System.High_Order_First;
   for bigEndianType'Scalar_Storage_Order use System.High_Order_First;

?

That seems to work, but in a non trivial case doesn't that make string_type non
inter operable with other string types? In reality I don't care what the scalar
storage order of the string is because they are just bytes and should work the
same across both platforms. It seems like string_type shouldn't even need a
scalar storage order applied to it.

[Bug target/63756] _mm_cvtepi16_epi32 with a memory operand produces either broken or slow asm

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #4 from Uroš Bizjak  ---
_mm_cvtepi16_epi32 accepts __m128i operand, and when this operand is loaded
from memory, it has to be located in 16byte location with 16byte natural
alignment.

The fact that "pmovsxd (%rax), %xmm0" is emitted is an implementation detail of
the intrinsic, but this fact does not relax the requirement for the pointer.
You are casting the pointer to __m128i, so you have to guarantee that the
pointer is suitably aligned and points to the correct memory location.

Please use assembly primitive, if you want to emit pmovsxwd that loads from
64bit memory location. There is no intrinsic with this functionality available.

Oh, and nobody will care about long (but otherwise correct) assembly when
optimization is switched off.

[Bug c/63760] New: Support __func__ in PROGMEM

[mojo at world3 dot net]

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

Bug ID: 63760
   Summary: Support __func__ in PROGMEM
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mojo at world3 dot net

The C99 __func__ magic variable is defined as:

static const char __func__[] = "function-name";

On architectures such as AVR where there is a distinction between program
memory and RAM this definition is not ideal. It will place the string in RAM,
even though it is constant. Devices using these Harvard style architectures
typically have very little RAM, a few kilobytes at most.

I suggest adding a __funcP__ magic variable that is defined as:

static const char __funcP__[] PROGMEM = "function-name";

That way the string will end up in program memory, which is almost always much
larger than available RAM and is commonly used for the storage of constant
strings.

[Bug other/63758] liblto_plugin.so has undefined reference to _environ on OSX

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-06
 Ever confirmed|0   |1

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

[Bug target/63749] [4.9/5 Regression] registers may not be the same

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.3

[Bug go/63269] libgo/math test failures in TestLog2

[vogt at linux dot vnet.ibm.com]

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

--- Comment #6 from Dominik Vogt  ---
(In reply to Ian Lance Taylor from comment #3)
> First, let me say that this code is in the Go master library and must be
> fixed there.  It might be more effective to discuss it on the Go issue
> tracker at http://golang.org/issue.

--> https://code.google.com/p/go/issues/detail?id=9066

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

[marxin at gcc dot gnu.org]

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

--- Comment #21 from Martin Liška  ---
(In reply to Igor Zamyatin from comment #20)
> This is mentioned here -
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534#c9
> 
> Fix for this is under review, start of the discussion is here -
> http://gcc.gnu.org/ml/gcc-patches/2014-10/msg01727.html

If you apply both my IPA ICF alias restriction patch and this mentioned patch,
can you bootstrap?

As I don't have a machine with darwin1, I cannot verify if bootstrap works and
there's no new regression?

Thanks,
Martin

[Bug c/63760] Support __func__ in PROGMEM

[sch...@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab  ---
Why aren't read-only data being placed in progmem by default?

[Bug c++/63736] gcc generated program with segfault on atomic exchange when the atomic variable is a member of a struct allocated with make_shared

[leandrosansilva at gmail dot com]

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

--- Comment #3 from Leandro Santiago  ---
I've just realized the gcc I am using is 4.8.1 instead of 4.8.1 as initially
reported.

[Bug c/63760] Support __func__ in PROGMEM

[mojo at world3 dot net]

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

--- Comment #2 from mojo at world3 dot net ---
On platforms with this kind of architecture the default is to place everything
in RAM, unless you specifically state otherwise.

With Harvard style architectures different instructions are used to access RAM
and program memory. GCC doesn't handle that natively, so you need to add things
like PROGMEM or __flash to tell it where to store and how to access the data.

[Bug middle-end/63761] New: [5 Regression] error: gimple_bb (stmt) is set to a wrong basic block

[trippels at gcc dot gnu.org]

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

Bug ID: 63761
   Summary: [5 Regression] error: gimple_bb (stmt) is set to a
wrong basic block
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org

On ppc64 I get the following binutils build failure:

trippels@gcc2-power8 gold % cat dynobj.ii
template  struct A;
template  struct A<_Tp *>
{
  typedef _Tp reference;
};
template  class B
{
public:
  typename A<_Iterator>::reference operator*();
};
template  class C
{
  typedef _Tp *const_pointer;
};
template  > class D
{
public:
  typedef B const_iterator;
};
struct F
{
  static int
  convert_host (int p1)
  {
return (
{
  p1 >> 8 & 255 | (p1 & 255) << 8;
});
  }
};
struct G
{
  static int
  convert_host (int p1)
  {
return F::convert_host (p1);
  }
};
struct H
{
  int vd_ndx;
};
class I
{
public:
  I (int);
  short set_vd_flags_a;
  void
  set_vd_flags (int)
  {
unsigned short v;
set_vd_flags_a = (
{
  v >> 8 | v << 8;
});
  }
  void
  set_vd_ndx (int p1)
  {
p_->vd_ndx = G::convert_host (p1);
  }
  H *p_;
};
typedef int Stringpool;
class J
{
public:
  template 
  unsigned char *write (const Stringpool *, bool, unsigned char *) const;
  int index_;
};
class Versions
{
  template 
  void def_section_contents (const Stringpool *, unsigned char **, unsigned *,
 unsigned *) const;
};
template 
void
Versions::def_section_contents (const Stringpool *, unsigned char **,
unsigned *, unsigned *) const
{
  D::const_iterator p;
  (*p)->write (0, 0, 0);
}
template void Versions::def_section_contents<32, false> (const Stringpool *,
 unsigned char **,
 unsigned *,
 unsigned *) const;
void fn1 (int, int, int) __attribute__ ((__noreturn__));
template 
unsigned char *
J::write (const Stringpool *, bool, unsigned char *) const
{
  I c (0);
  c.set_vd_flags (0);
  !index_ ? fn1 (0, 0, 0), 0 : 0;
  c.set_vd_ndx (index_);
}

trippels@gcc2-power8 gold % /home/trippels/gcc_test/usr/local/bin/g++ -c -O2
dynobj.ii
dynobj.ii: In member function ‘void Versions::def_section_contents(const
Stringpool*, unsigned char**, unsigned int*, unsigned int*) const [with int
 = 32; bool  = false; Stringpool = int]’:
dynobj.ii:80:1: error: gimple_bb (stmt) is set to a wrong basic block
 Versions::def_section_contents (const Stringpool *, unsigned char **,
 ^
_7 = v_6(D) r>> 8;
dynobj.ii:80:1: internal compiler error: verify_gimple failed
0x109c04df verify_gimple_in_cfg(function*, bool)
../../gcc/gcc/tree-cfg.c:5039
0x108830b7 execute_function_todo
../../gcc/gcc/passes.c:1868
0x10883fb3 do_per_function
../../gcc/gcc/passes.c:1595
0x10884287 execute_todo
../../gcc/gcc/passes.c:1925
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug ada/63725] Scalar_Storage_Order and nested string subtypes

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  ---
> That seems to work, but in a non trivial case doesn't that make string_type
> non inter operable with other string types?

Interoperability should be preserved modulo minor adjustments.

[Bug sanitizer/62132] [5 Regression] FAIL: c-c++-common/asan/misalign-[12].c after r213807 on x86_64-apple-darwin13 with -m32

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
Per comments 6 and 7 I have tried

--- ../_clean/gcc/testsuite/c-c++-common/asan/misalign-1.c2014-05-31
12:40:03.0 +0200
+++ gcc/testsuite/c-c++-common/asan/misalign-1.c2014-11-05
14:35:09.0 +0100
@@ -1,6 +1,7 @@
 /* { dg-do run { target { ilp32 || lp64 } } } */
 /* { dg-options "-O2" } */
 /* { dg-shouldfail "asan" } */
+/* { dg-additional-options "-funwind-tables" { target *-*-darwin* } } */

 struct S { int i; } __attribute__ ((packed));

but it does not fix the failures. What am I misunderstanding?

[Bug sanitizer/62132] [5 Regression] FAIL: c-c++-common/asan/misalign-[12].c after r213807 on x86_64-apple-darwin13 with -m32

[y.gribov at samsung dot com]

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

--- Comment #10 from Yury Gribov  ---
(In reply to Dominique d'Humieres from comment #9)
> Per comments 6 and 7 I have tried
> ...
> but it does not fix the failures. What am I misunderstanding?

That wouldn't help because libsanitizer does not use -funwind-tables even if
they are available.  I think the problem is in StackTrace::WillUseFastUnwind in
libsanitizer/sanitizer_common/sanitizer_stacktrace.h.

[Bug target/63756] _mm_cvtepi16_epi32 with a memory operand produces either broken or slow asm

[tterribe at xiph dot org]

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

--- Comment #5 from Timothy B. Terriberry  ---
(In reply to Uroš Bizjak from comment #4)
> Oh, and nobody will care about long (but otherwise correct) assembly when
> optimization is switched off.

I also don't care about this.

What I care about is the long (but otherwise correct) assembly when
optimization is switched ON.

[Bug target/63762] New: [ARM]GCC generates UNPREDICTABLE STR with Rn = Rt when hard-float abi is used

[renlin.li at arm dot com]

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

Bug ID: 63762
   Summary: [ARM]GCC generates UNPREDICTABLE STR with Rn = Rt when
hard-float abi is used
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: renlin.li at arm dot com
CC: marcus.shawcroft at arm dot com, ramana.radhakrishnan at 
arm dot com
Target: arm*

Created attachment 33910
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33910&action=edit
test case

This was reported on a public mailing list on 2014-10-25:
http://lists.debian.org/debian-arm/2014/10/msg00057.html

The problem is reproducible with a recent FSF compiler:

$arm-none-eabi-gcc -mfloat-abi=hard -O2 -c unpreditable-str.c

or

$arm-none-linux-gnueabihf-gcc -O2 -c unpreditable-str.c 


/tmp/ccWQsFwY.s: Assembler messages:
/tmp/ccWQsFwY.s:176: Warning: source register same as write-back base

In this case the assembler is giving a warning rather than an error but the
instruction ("str r2, [r2], #4" in this case) is UNPREDICTABLE.

[Bug target/63762] [ARM]GCC generates UNPREDICTABLE STR with Rn = Rt when hard-float abi is used

[renlin.li at arm dot com]

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

--- Comment #1 from Renlin Li  ---
I am starting to work on this issue.

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

[howarth at bromo dot med.uc.edu]

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

--- Comment #22 from howarth at bromo dot med.uc.edu ---
(In reply to Martin Liška from comment #21)
> (In reply to Igor Zamyatin from comment #20)
> > This is mentioned here -
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534#c9
> > 
> > Fix for this is under review, start of the discussion is here -
> > http://gcc.gnu.org/ml/gcc-patches/2014-10/msg01727.html
> 
> If you apply both my IPA ICF alias restriction patch and this mentioned
> patch, can you bootstrap?
> 
> As I don't have a machine with darwin1, I cannot verify if bootstrap works
> and there's no new regression?
> 
> Thanks,
> Martin

I already had https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534#c50
applied and https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01727.html
is already be committed. Perhaps a PR should be opened where the
accumulated patches required for darwin are listed. At the moment we
also need https://gcc.gnu.org/bugzilla/attachment.cgi?id=33897 and
https://gcc.gnu.org/bugzilla/attachment.cgi?id=33854 for Yosemite
as well.

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

[howarth at bromo dot med.uc.edu]

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

--- Comment #23 from howarth at bromo dot med.uc.edu ---
(In reply to Martin Liška from comment #21)
> (In reply to Igor Zamyatin from comment #20)
> > This is mentioned here -
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534#c9
> > 
> > Fix for this is under review, start of the discussion is here -
> > http://gcc.gnu.org/ml/gcc-patches/2014-10/msg01727.html
> 
> If you apply both my IPA ICF alias restriction patch and this mentioned
> patch, can you bootstrap?
> 
> As I don't have a machine with darwin1, I cannot verify if bootstrap works
> and there's no new regression?
> 
> Thanks,
> Martin

Martin,
Are you currently testing gcc trunk with the IPA ICF alias restriction
patch applied in your tree on linux? Is it possible that patch is regressed by
all of the recent ipa icf commits?
Jack

[Bug c++/63763] New: Crash (4) gcc 4.8.2 building cpp file

[adrien.courdavault at arturia dot com]

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

Bug ID: 63763
   Summary: Crash (4) gcc 4.8.2 building cpp file
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adrien.courdavault at arturia dot com

Created attachment 33911
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33911&action=edit
I attached as LZMA compresse cpp file result of the preprocessing of my
original cpp. (compressed because uncompressed is 6MB)

Version gcc 4.8.2 (ubuntu 4.8.2-19ubuntu1)

Target x86_64-linux-gnu

Problem description

I was building a project that I'm currently porting from Mac + Windows to
linux. (on mac I use Apple CLang 6.0)

This file made GCC crash with internal error code 4

I don't know why except maybe it's size..

Good Luck

And thank you for GCC

[Bug c/59708] clang-compatible checked arithmetic builtins

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #13 from Jakub Jelinek  ---
Created attachment 33912
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33912&action=edit
gcc5-pr59708-wip3.patch

After discussions with richi on IRC, I've revamped the patch so that it uses
the
internal calls for all cases through GIMPLE, and only does all the special
casing how to best emit code during expansion.  So, all the
{ADD,SUB,MUL}_OVERFLOW internal calls now can have arbitrary types in the
arguments (signed vs. unsigned, different precision) and the result type is the
type of __real__ of the result.  The advantage of doing that is that we don't
have to decide during gimplification about the best way to emit the more rare
sign/precision combination, and depending on propagation and VRP we can emit
better code.

In this version, I've recoded most of the code I had in builtins.c to be done
during expansion and finished up handling of the last few add/sub cases (signed
+- signed into unsigned and unsigned +- unsigned into signed).  From the
previous patch, what is missing right now is type promotion (i.e. when the
result type is narrower than that of the arguments and the computation needs to
be done in wider mode, then converted to the result mode, sign or zero extended
back and compared to the wider mode result and overflow set if it doesn't
compare equal) which I'll handle tomorrow, and the 4 different cases for
multiplication not handled yet (when multiplication arguments differ or when
they are the same, but result has different sign); plus of course more
testcases and documentation.

[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

[htl10 at users dot sourceforge.net]

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

--- Comment #14 from Hin-Tak Leung  ---
(In reply to howarth from comment #13)
>
> If we made any change, I would rather it be a check in FSF gcc's
> configure for the presence of /usr/include on darwin which provided the
> appropriate error message to the user that the Command Line Tools needs to
> be installed.

I don't think mandating Command Line Tools would be a good idea - I think in
that case you can have a reverse problem when your intention is to build stuff
for other people: you build x intended for others, you have /usr/include but
others don't, x made assumptions about the intended users having the same stuff
as yours, and it doesn't work on the intended user's machine, or have
mysterious errors.

[Bug middle-end/63764] New: nternal compiler error: in verify_ssa, at tree-ssa.c:939

[mkg at us dot ibm.com]

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

Bug ID: 63764
   Summary: nternal compiler error: in verify_ssa, at
tree-ssa.c:939
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mkg at us dot ibm.com

Created attachment 33913
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33913&action=edit
File performs several builtin operations in a loop.

mkg@genoa:~/tests/olivier$ /home/user/gcc/install/gcc-mainline-test/bin/g++ -O6
 -funroll-loops --save-temps  test2.c  -S
test2.c: In function ?void test(int, cfloat (*)[3], cfloat (**)[3])?:
test2.c:47:1: internal compiler error: in verify_ssa, at tree-ssa.c:939
 }
 ^
0x10c1b24f verify_ssa(bool, bool)
/home/user/gcc/gcc-mainline-test/gcc/tree-ssa.c:939
0x108d7c7b execute_function_todo
/home/user/gcc/gcc-mainline-test/gcc/passes.c:1875
0x108d8c03 do_per_function
/home/user/gcc/gcc-mainline-test/gcc/passes.c:1602
0x108d8daf execute_todo
/home/user/gcc/gcc-mainline-test/gcc/passes.c:1925
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

mkg@genoa:~/tests/olivier$ gcc -v 
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc64le-linux-gnu/4.8/lto-wrapper
Target: powerpc64le-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--disable-libsanitizer --disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-ppc64el/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-ppc64el
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-ppc64el
--with-arch-directory=ppc64el --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-secureplt --with-cpu=power7 --with-tune=power8
--disable-multilib --enable-multiarch --disable-werror --with-long-double-128
--enable-checking=release --build=powerpc64le-linux-gnu
--host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) 

This compiler was built from head in trunk, on Ubuntu 14.04 PowerPC LE

[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

[mrs at gcc dot gnu.org]

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

--- Comment #15 from mrs at gcc dot gnu.org  ---
Mandating commands line tools is fine.  Would be nice if everything worked
flawlessly if no optional package had to be installed, but I'm pragmatic.

[Bug libobjc/63765] New: [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

Bug ID: 63765
   Summary: [5.0 Regression] libobjc testsuite failures on AIX
caused by setting _XOPEN_SOURCE
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libobjc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org

The Objective C testsuite results have regressed from 1 failure to 180 failures
after the libobjc patch was applied.

[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

David Edelsohn  changed:

   What|Removed |Added

 Target||powerpc-ibm-aix*
 Status|UNCONFIRMED |NEW
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2014-11/msg00073.ht
   ||ml
   Last reconfirmed||2014-11-06
 CC||ro at gcc dot gnu.org
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

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

[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

Andrew Pinski  changed:

   What|Removed |Added

URL|https://gcc.gnu.org/ml/gcc- |
   |patches/2014-11/msg00073.ht |
   |ml  |
 CC||pinskia at gcc dot gnu.org

--- Comment #2 from Andrew Pinski  ---
Caused by:
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00073.html

Let's only define the new value for Solaris instead of for everyone.

[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #16 from Iain Sandoe  ---
(In reply to m...@gcc.gnu.org from comment #15)
> Mandating commands line tools is fine.  Would be nice if everything worked
> flawlessly if no optional package had to be installed, but I'm pragmatic.

I'd agree with pragmatism every time.
OTOH, 
(a) it would be nice to have a heads up on the thinking going forward (would
have been possible to ask filks last week).

(b) it is apparent that there's a move towards desiring a uniform interface
where the {native}host is considered "just another target" with its own SDK.

I kinda like the uniformity too.

[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

[howarth at bromo dot med.uc.edu]

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

--- Comment #17 from howarth at bromo dot med.uc.edu ---
(In reply to Hin-Tak Leung from comment #14)
> (In reply to howarth from comment #13)
> >
> > If we made any change, I would rather it be a check in FSF gcc's
> > configure for the presence of /usr/include on darwin which provided the
> > appropriate error message to the user that the Command Line Tools needs to
> > be installed.
> 
> I don't think mandating Command Line Tools would be a good idea - I think in
> that case you can have a reverse problem when your intention is to build
> stuff for other people: you build x intended for others, you have
> /usr/include but others don't, x made assumptions about the intended users
> having the same stuff as yours, and it doesn't work on the intended user's
> machine, or have mysterious errors.

You have to remember that Apple expects you to build everything from within the
Xcode projects while the Command Line Tools package exists to handle building
outside of that mechanism. The unfortunate fact is that far too much software
explicitly expects headers in /usr/include to avoid installing the Command Line
Tools. In the fink project, we get endless bug reports from users who fail to
install the Command Line Tools.

[Bug middle-end/63761] [5 Regression] error: gimple_bb (stmt) is set to a wrong basic block

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug middle-end/63766] New: [5 Regression] ICE: in gimple_predict_edge, at predict.c:578

[trippels at gcc dot gnu.org]

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

Bug ID: 63766
   Summary: [5 Regression] ICE: in gimple_predict_edge, at
predict.c:578
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org

trippels@gcc2-power8 AST % cat ASTDumper.ii
class A
{
public:
  void
  getValueType ()
  {
  }
  void getTypeClass ();
};
template  class B
{
public:
  void
  Visit (A *p1)
  {
p1->getTypeClass ();
static_cast (0)->VisitAtomicType (0);
  }
};
class C : B
{
  template 
  void
  dumpChild (Fn p1)
  {
p1 ();
  }

public:
  void dumpTypeAsChild (int);
  void
  VisitAtomicType (A *p1)
  {
p1->getValueType ();
dumpTypeAsChild (0);
  }
};
void
C::dumpTypeAsChild (int)
{
  dumpChild ([=]
 {
   Visit (0);
 });
}

trippels@gcc2-power8 AST % g++ -std=c++11 -O2 -c ASTDumper.ii
ASTDumper.ii: In function ‘C::dumpTypeAsChild(int)::’:
ASTDumper.ii:45:1: internal compiler error: in gimple_predict_edge, at
predict.c:578
 }
 ^
0x108a4513 gimple_predict_edge(edge_def*, br_predictor, int)
../../gcc/gcc/predict.c:578
0x104ea027 predict_edge(edge_def*, br_predictor, int)
../../gcc/gcc/cfghooks.c:737
0x108a37ab predict_edge_def
../../gcc/gcc/predict.c:664
0x108a37ab predict_loops
../../gcc/gcc/predict.c:1581
0x108a37ab tree_estimate_probability()
../../gcc/gcc/predict.c:2344
0x108a41e3 execute
../../gcc/gcc/predict.c:3056
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/63766] [5 Regression] ICE: in gimple_predict_edge, at predict.c:578

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
Started with r217125.

[Bug c/63767] New: Excessive memory usage/crash on compilation

[sasha.levin at oracle dot com]

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

Bug ID: 63767
   Summary: Excessive memory usage/crash on compilation
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sasha.levin at oracle dot com
CC: rguenther at suse dot de

On the trunk branch I'm seeing excessive memory usage (reaching 400GB) followed
by a crash:

  CC  net/core/sock.o
gcc: internal compiler error: Killed (program cc1)
0x40bf6c execute
../../gcc/gcc.c:2908
0x410477 driver::do_spec_on_infiles() const
../../gcc/gcc.c:7529
0x403223 driver::main(int, char**)
../../gcc/gcc.c:6796
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

It always happens when compiling the Linux Kernel net/core/sock.c . I've attach
the preprocessed source file.

This issue was bisected to the following commit:

commit d0eb9b3dcd3d5c6ff85aaff9753c187423aeb764  
Author: rguenth   
Date:   Thu Nov 6 09:07:39 2014 +  

2014-11-06  Richard Biener

* match.pd: Implement bitwise binary and unary simplifications  
from tree-ssa-forwprop.c.  
* fold-const.c (fold_unary_loc): Remove them here.  
(fold_binary_loc): Likewise.  
* tree-ssa-forwprop.c (simplify_not_neg_expr): Remove.  
(truth_valued_ssa_name): Likewise.  
(lookup_logical_inverted_value): Likewise.  
(simplify_bitwise_binary_1): Likewise.  
(hoist_conversion_for_bitop_p): Likewise.  
(simplify_bitwise_binary_boolean): Likewise.  
(simplify_bitwise_binary): Likewise.  
(pass_forwprop::execute): Remove calls to simplify_not_neg_expr  
and simplify_bitwise_binary.  
* genmatch.c (dt_node::append_true_op): Use safe_as_a for parent.  
(decision_tree::insert): Also insert non-expressions.  

* gcc.dg/tree-ssa/forwprop-28.c: Adjust scanning for the
desired transform.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@217178
138bc75d-0d04-0410-961f-82ee72b054a4

My gcc build was using this configuration:

../configure --prefix=/home/sasha/gcc-inst/ --with-arch=native
--with-tune=native --enable-languages=c --enable-lto --enable-gold
--enable-stage1-languages=c

[Bug c/63767] Excessive memory usage/crash on compilation

[sasha.levin at oracle dot com]

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

--- Comment #1 from Sasha Levin  ---
Created attachment 33914
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33914&action=edit
Preprocessed source

[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)

[jsm28 at gcc dot gnu.org]

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

--- Comment #49 from Joseph S. Myers  ---
Author: jsm28
Date: Thu Nov  6 21:08:52 2014
New Revision: 217202

URL: https://gcc.gnu.org/viewcvs?rev=217202&root=gcc&view=rev
Log:
Preserve original spellings of extended identifiers.

This patch makes cpplib track the original spellings of extended
identifiers, as well as the canonical UTF-8 version, in order to
follow standard semantics properly without needing a convoluted and
undocumented canonicalization in translation phase 1 (see bug 9449
comments 39-46 regarding such a canonicalization).

The spelling is tracked in cpp_identifier and cpp_macro_arg without
making cpp_token any larger.  The original spelling is used for checks
of duplicate macro definitions, stringizing (see the C++ tests added;
this case is only an issue for C++ not C because C makes it
implementation-defined whether a \ is inserted before the \ of a UCN
in a string or character constant when stringizing, while C++ does
not), pasting (relevant when the result is then stringized for C++)
and when macro definitions are output as text (e.g. for -d options).

Once a macro has been defined, only the original spelling of the
argument names needs keeping in the argument list.  While it is being
defined, however, both spellings are needed: the original one for
subsequent saving for checks of duplicate macro definitions, and the
canonical one which is the node marked specially to generate macro
argument tokens rather than normal identifier tokens.  The buffer that
is used to save the original values of the identifier tokens is
changed so that it stores both those original values and a pointer to
the canonical hash nodes, so that those canonical nodes can be found
when their values need restoring after the macro definition has been
parsed.

I believe this covers the known standards issues in extended
identifiers support (the remaining unimplemented C99 areas in GCC all
being floating-point-related), except for C++ translation of extended
characters to UCNs in phase 1 (which I have no plans to work on).
There are however probably issues left with handling of extended
identifiers in other places, as listed in
 (those
issues are generally the sort of thing that could be addressed as bugs
outside development stage 1).  (The bulk of the potential issues Zack
was concerned about in 2003-5, that resulted in extended identifiers
being disabled in the absence of -fextended-identifiers, were
effectively eliminated by the audit and fixes I did in 2009, however;
that todo list reflects what was left over after that audit.)

Bootstrapped with no regressions on x86_64-unknown-linux-gnu.

libcpp:
* include/cpp-id-data.h (struct cpp_macro): Update comment
regarding parameters.
* include/cpplib.h (struct cpp_macro_arg, struct cpp_identifier):
Add spelling fields.
(struct cpp_token): Update comment on macro_arg.
* internal.h (_cpp_save_parameter): Add extra argument.
(_cpp_spell_ident_ucns): New declaration.
* lex.c (lex_identifier): Add SPELLING argument.  Set *SPELLING to
original spelling of identifier.
(_cpp_lex_direct): Update calls to lex_identifier.
(_cpp_spell_ident_ucns): New function, factored out of
cpp_spell_token.
(cpp_spell_token): Adjust FORSTRING argument semantics to return
original spelling of identifiers.  Use _cpp_spell_ident_ucns in
!FORSTRING case.
(_cpp_equiv_tokens): Check spellings of identifiers and macro
arguments are identical.
* macro.c (macro_arg_saved_data): New structure.
(paste_tokens): Use original spellings of identifiers from
cpp_spell_token.
(_cpp_save_parameter): Add argument SPELLING.  Save both canonical
node and its value.
(parse_params): Update calls to _cpp_save_parameter.
(lex_expansion_token): Save spelling of macro argument tokens.
(_cpp_create_definition): Extract canonical node from saved data.
(cpp_macro_definition): Use UCNs in spelling of macro name.  Use
original spellings of macro argument tokens and identifiers.
* traditional.c (scan_parameters): Update call to
_cpp_save_parameter.

gcc:
* doc/invoke.texi (-std=c99, -std=c11): Don't refer to corner
cases of extended identifiers.

gcc/testsuite:
* g++.dg/cpp/ucnid-2.C, g++.dg/cpp/ucnid-3.C,
gcc.dg/cpp/ucnid-11.c, gcc.dg/cpp/ucnid-12.c,
gcc.dg/cpp/ucnid-13.c, gcc.dg/cpp/ucnid-14.c,
gcc.dg/cpp/ucnid-15.c: New tests.

Added:
trunk/gcc/testsuite/g++.dg/cpp/ucnid-2.C
trunk/gcc/testsuite/g++.dg/cpp/ucnid-3.C
trunk/gcc/testsuite/gcc.dg/cpp/ucnid-11.c
trunk/gcc/testsuite/gcc.dg/cpp/ucnid-12.c
trunk/gcc/testsuite/gcc.dg/cpp/ucnid-13.c
trunk/gcc/testsuite/gcc.dg/cpp/ucnid-14.c
trunk/gcc/testsuite/gcc.dg/cpp/ucnid-15.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/l

[Bug middle-end/63761] [5 Regression] error: gimple_bb (stmt) is set to a wrong basic block

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-06
 CC||thomas.preudhomme at arm dot 
com
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Started with r216971.

[Bug java/63768] New: double included .h file in libjava/.../natFileChannelPosix.cc

[dilyan.palauzov at aegee dot org]

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

Bug ID: 63768
   Summary: double included .h file in
libjava/.../natFileChannelPosix.cc
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dilyan.palauzov at aegee dot org

deheader (git://gitorious.org/deheader/deheader.git) states correctly, that
libjava/gnu/java/nio/channels/natFileChannelPosix.cc contains twice 

#include 

and one of them is unnecessary.

[Bug c++/62115] [5 Regression] ICE with invalid default argument

[roman.perepelitsa at gmail dot com]

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

Roman Perepelitsa  changed:

   What|Removed |Added

 CC||roman.perepelitsa at gmail dot 
com

--- Comment #4 from Roman Perepelitsa  ---
r216124 has also fixed another bug, which may result in valid code being
rejected and also in incorrect code generation for valid code.

#include 

struct Base { int value; };
struct Derived : Base {};

void Foo(int&&) {}

int main() {
  Derived d;
  Foo(std::move(d).value);
}

Before r216124 this program produced the following compile error:

   test.cc: In function 'int main()':
test.cc:10:25: error: cannot bind 'int' lvalue to 'int&&'
   Foo(std::move(d).value);
 ^
test.cc:6:6: error:   initializing argument 1 of 'void Foo(int&&)'
void Foo(int&&) {}

If function Foo() was overloaded for const int& and int&, or if it used perfect
forwarding, it would result in successful compilation and incorrect runtime
behaviour.

Would it be possible to backport the fix to gcc-4_9-branch?

[Bug c++/63757] nullptr conversion sequence fails to compile

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
Still broken for gcc 5.0.0 20141106 (experimental)

[Bug libgcj/63768] double included .h file in libjava/.../natFileChannelPosix.cc

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|java|libgcj
   Severity|normal  |trivial

[Bug tree-optimization/61515] [4.9/5 Regression] Extremely long compile time for generated code

[law at redhat dot com]

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

--- Comment #25 from Jeffrey A. Law  ---
So I think there's another approach.  invalidate_equivalences is passed in the
stack of temporary equivalences, which include those created by jump threading
as well as those created by DOM.

This means that in theory, we could walk that stack (in reverse order) to find
all the equivalences we need to invalidate.  If the stack has fewer entries
than we have SSA_NAMES, then we win.

For the stripped down testcase in this PR we go from ~40 seconds to ~1 second
in the relevant part of the compiler with a hack that does exactly what's
described above.

I need to do a bit more review/research, but it looks like a promising
alternative.

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

[howarth at bromo dot med.uc.edu]

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

--- Comment #24 from howarth at bromo dot med.uc.edu ---
The error seen in Comment 19 appears to be identical to that reported in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534#c9.

If I also add in the proposed patch
https://gcc.gnu.org/bugzilla/attachment.cgi?id=33736&action=diff from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534#c18 for disabling just
nonlocal_goto_receiver split in addition to the IPA ICF alias restriction
patch, the bootstrap on x86_64-apple-darwin14 continues further into stage2
when it hits...

/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./prev-gcc/xg++
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./prev-gcc/
-B/sw/lib/gcc5.0/x86_64-apple-darwin14.0.0/bin/ -nostdinc++
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/libsupc++/.libs

-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/include/x86_64-apple-darwin14.0.0

-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/include
 -I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/libstdc++-v3/libsupc++
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/libsupc++/.libs
-c   -g -O2  -gtoggle -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
 -DHAVE_CONFIG_H -I. -I. -I../../gcc-5.0-20141106/gcc
-I../../gcc-5.0-20141106/gcc/. -I../../gcc-5.0-20141106/gcc/../include
-I../../gcc-5.0-20141106/gcc/../libcpp/include -I/sw/include -I/sw/include 
-I../../gcc-5.0-20141106/gcc/../libdecnumber
-I../../gcc-5.0-20141106/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc-5.0-20141106/gcc/../libbacktrace -DCLOOG_INT_GMP -I/sw/include
-DCLOOG_INT_GMP -I/sw/include -I/sw/include -o tree-inline.o -MT tree-inline.o
-MMD -MP -MF ./.deps/tree-inline.TPo ../../gcc-5.0-20141106/gcc/tree-inline.c
../../gcc-5.0-20141106/gcc/tree-inline.c: In function 'int
estimate_num_insns_seq(gimple_seq, eni_weights*)':
../../gcc-5.0-20141106/gcc/tree-inline.c:5820:1: error: invalid argument to
gimple call
}
 ^
stmts
# .MEM_3 = VDEF <.MEM_1(D)>
retval.1677_4 = count_insns_seq (stmts, weights_2(D)); [tail call]
../../gcc-5.0-20141106/gcc/tree-inline.c:5820:1: internal compiler error:
verify_gimple failed

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[howarth at bromo dot med.uc.edu]

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

howarth at bromo dot med.uc.edu changed:

   What|Removed |Added

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

--- Comment #54 from howarth at bromo dot med.uc.edu ---
What is the status of this PR? I am finding that current gcc trunk requires
https://gcc.gnu.org/bugzilla/attachment.cgi?id=33843 in order to avoid the use
of alias  on darwin resulting in undefined symbols in libstdc++. However then
the error shifts to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622#c19
which is identical to that reported in Comment 9 here. If I use the patch from
https://gcc.gnu.org/bugzilla/attachment.cgi?id=33736&action=diff in this PR,
the bootstrap failure shifts to...

/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./prev-gcc/xg++
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./prev-gcc/
-B/sw/lib/gcc5.0/x86_64-apple-darwin14.0.0/bin/ -nostdinc++
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/libsupc++/.libs

-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/include/x86_64-apple-darwin14.0.0

-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/include
 -I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/libstdc++-v3/libsupc++
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/libsupc++/.libs
-c   -g -O2  -gtoggle -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
 -DHAVE_CONFIG_H -I. -I. -I../../gcc-5.0-20141106/gcc
-I../../gcc-5.0-20141106/gcc/. -I../../gcc-5.0-20141106/gcc/../include
-I../../gcc-5.0-20141106/gcc/../libcpp/include -I/sw/include -I/sw/include 
-I../../gcc-5.0-20141106/gcc/../libdecnumber
-I../../gcc-5.0-20141106/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc-5.0-20141106/gcc/../libbacktrace -DCLOOG_INT_GMP -I/sw/include
-DCLOOG_INT_GMP -I/sw/include -I/sw/include -o tree-inline.o -MT tree-inline.o
-MMD -MP -MF ./.deps/tree-inline.TPo ../../gcc-5.0-20141106/gcc/tree-inline.c
../../gcc-5.0-20141106/gcc/tree-inline.c: In function ‘int
estimate_num_insns_seq(gimple_seq, eni_weights*)’:
../../gcc-5.0-20141106/gcc/tree-inline.c:5820:1: error: invalid argument to
gimple call
 }
 ^
stmts
# .MEM_3 = VDEF <.MEM_1(D)>
retval.1677_4 = count_insns_seq (stmts, weights_2(D)); [tail call]
../../gcc-5.0-20141106/gcc/tree-inline.c:5820:1: internal compiler error:
verify_gimple failed

in stage2.

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

[dominiq at lps dot ens.fr]

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

--- Comment #25 from Dominique d'Humieres  ---
> The error seen in Comment 19 appears to be identical to that reported in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534#c9.

This is fixed by the patch at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63580#c4.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[evstupac at gmail dot com]

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

--- Comment #55 from Stupachenko Evgeny  ---
Created attachment 33915
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33915&action=edit
patch disabling nonlocal goto receiver and fixing setjmp receiver

(In reply to howarth from comment #54)
> What is the status of this PR? I am finding that current gcc trunk requires
> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33843 in order to avoid the
> use of alias  on darwin resulting in undefined symbols in libstdc++. However
> then the error shifts to
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622#c19 which is identical to
> that reported in Comment 9 here. If I use the patch from
> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33736&action=diff in this PR,
> the bootstrap failure shifts to...
> 
Please try attached patch instead of
"https://gcc.gnu.org/bugzilla/attachment.cgi?id=33736&action=diff";

[Bug target/47500] -G0 option not recognized by gnat1

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-06
   Target Milestone|--- |4.8.4
 Ever confirmed|0   |1

--- Comment #7 from Eric Botcazou  ---
We should fix this.

[Bug c++/63198] decltype in template function declaration yields spurious error

[thomas at famillebernardgouriou dot fr]

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

--- Comment #4 from Thomas Bernard  ---
I investigated a bit further and I come up to the same conclusion as Bob
Abeles.

Having an assignment operator inside the decltype makes gcc believe the type is
dependent. There are a couple of spots where the assignment operator is handled
specifically, most probably it isn't handled correctly inside the decltype.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[evstupac at gmail dot com]

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

--- Comment #56 from Stupachenko Evgeny  ---
If this does not help, then described issue is not related to this bug,
as darwin bootstrap passed with the patch applied on r216304 (along with
already committed to trunk patches from PR63618 and PR63620).

The patch is discussed here:
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00445.html

[Bug c++/63769] New: accepts-invalid multiple function definitions in extern "C"

[nlewycky at google dot com]

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

Bug ID: 63769
   Summary: accepts-invalid multiple function definitions in
extern "C"
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nlewycky at google dot com

"At most one function with a particular name can have C language linkage. Two
declarations for a function with C language linkage with the same function name
(ignoring the namespace names that qualify it) that appear in two different
namespace scopes refer to the same function." - (N4141) C++14 [dcl.link]
paragraph 6.

Testcase:
extern "C" {
  namespace ns1 {
void foo() {}
  }
  namespace ns2 {
void foo() {}
  }
}

GCC compiles this and emits assembly, if assembled the assembler will complain
about symbol 'foo' already being defined.

Clang complains about the redeclaration:
x.cc:6:10: error: redefinition of 'foo'
void foo() {}
 ^
x.cc:3:10: note: previous definition is here
void foo() {}
 ^
1 error generated.

This should apply all the way back to C++98, this isn't a C++14 change.

[Bug c++/63769] accepts-invalid multiple function definitions in extern "C"

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 25940.

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

[Bug c++/25940] multiple definitions of extern "C" functions

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||nlewycky at google dot com

--- Comment #4 from Andrew Pinski  ---
*** Bug 63769 has been marked as a duplicate of this bug. ***

[Bug c++/63769] accepts-invalid multiple function definitions in extern "C"

[nlewycky at google dot com]

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

--- Comment #2 from Nick Lewycky  ---
Oops. Thanks!

[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

[htl10 at users dot sourceforge.net]

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

--- Comment #18 from Hin-Tak Leung  ---
(In reply to m...@gcc.gnu.org from comment #15)
> Mandating commands line tools is fine.  Would be nice if everything worked
> flawlessly if no optional package had to be installed, but I'm pragmatic.

The current behavior is definitely wrong: without command line tools and
without --with-sysroot (i.e. just plain ./configure), ./configure returns
success, but only fail to 'make' towards the end of stage1 when the build
system tries to do the 'stage1-fixincludes' target.

./configure should either auto-add the --with-sysroot (as the reverted fix
did), or abort with an appropriate message, like the requirement for
gmp/mpfr/mpc. successful ./configure then failing part-way through make is bad.

(In reply to howarth from comment #17)
> You have to remember that Apple expects you to build everything from within
> the Xcode projects while the Command Line Tools package exists to handle
> building outside of that mechanism. The unfortunate fact is that far too
> much software explicitly expects headers in /usr/include to avoid installing
> the Command Line Tools. In the fink project, we get endless bug reports from
> users who fail to install the Command Line Tools.

Not really. Actually xcode 6.1 seem to ships all the command line tools. doing
'xcode-select --install' install a much older(?) command line tools plus
headers in /usr/include. I don't know if Apple is going to keep that in-sync,
but there might be a danger of the headers in /usr/include not really
describing the system.

Also, people who DIY are supposed to go through all the troubles... you still
haven't addressed the issue of new gcc (+ xcode building it with) may generate
stuff that have additional dependencies on /usr/include, if /usr/include is
around, and therefore not suitable when one is building things for others.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[howarth at bromo dot med.uc.edu]

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

--- Comment #57 from howarth at bromo dot med.uc.edu ---
(In reply to Stupachenko Evgeny from comment #55)
> Created attachment 33915 [details]
> patch disabling nonlocal goto receiver and fixing setjmp receiver
> 
> (In reply to howarth from comment #54)
> > What is the status of this PR? I am finding that current gcc trunk requires
> > https://gcc.gnu.org/bugzilla/attachment.cgi?id=33843 in order to avoid the
> > use of alias  on darwin resulting in undefined symbols in libstdc++. However
> > then the error shifts to
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622#c19 which is identical to
> > that reported in Comment 9 here. If I use the patch from
> > https://gcc.gnu.org/bugzilla/attachment.cgi?id=33736&action=diff in this PR,
> > the bootstrap failure shifts to...
> > 
> Please try attached patch instead of
> "https://gcc.gnu.org/bugzilla/attachment.cgi?id=33736&action=diff";

Using gcc trunk at r217202 with the patches from...

https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00541.html
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00555.html
https://gcc.gnu.org/bugzilla/attachment.cgi?id=33843 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622#c3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63580#c4

and your revised patch for disabling nonlocal goto receiver and fixing setjmp
receiver from Comment 55 applied allows x86_64-apple-darwin14 to completely
bootstrap when configured as...

../gcc-5.0-20141106/configure --prefix=/sw --prefix=/sw/lib/gcc5.0
--mandir=/sw/share/man --infodir=/sw/lib/gcc5.0/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--program-suffix=-fsf-5.0

Hopefully these patches can get pushed into gcc trunk to allow routine
regression testing on darwin again.

[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

[howarth at bromo dot med.uc.edu]

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

--- Comment #19 from howarth at bromo dot med.uc.edu ---
(In reply to Hin-Tak Leung from comment #18)
> (In reply to m...@gcc.gnu.org from comment #15)
> > Mandating commands line tools is fine.  Would be nice if everything worked
> > flawlessly if no optional package had to be installed, but I'm pragmatic.
> 
> The current behavior is definitely wrong: without command line tools and
> without --with-sysroot (i.e. just plain ./configure), ./configure returns
> success, but only fail to 'make' towards the end of stage1 when the build
> system tries to do the 'stage1-fixincludes' target.
> 
> ./configure should either auto-add the --with-sysroot (as the reverted fix
> did), or abort with an appropriate message, like the requirement for
> gmp/mpfr/mpc. successful ./configure then failing part-way through make is
> bad.
> 

The proper test to detect the missing Command Line Tools /usr/include files
should be added then.

> (In reply to howarth from comment #17)
> > You have to remember that Apple expects you to build everything from within
> > the Xcode projects while the Command Line Tools package exists to handle
> > building outside of that mechanism. The unfortunate fact is that far too
> > much software explicitly expects headers in /usr/include to avoid installing
> > the Command Line Tools. In the fink project, we get endless bug reports from
> > users who fail to install the Command Line Tools.
> 
> Not really. Actually xcode 6.1 seem to ships all the command line tools.
> doing 'xcode-select --install' install a much older(?) command line tools
> plus headers in /usr/include. I don't know if Apple is going to keep that
> in-sync, but there might be a danger of the headers in /usr/include not
> really describing the system.

You must have caught them before they synced. On my machine, I have synced
Xcode.app and Command Line Tools...

%
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
-v
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix

% /Library/Developer/CommandLineTools/usr/bin/clang -v
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix

from 'xcode-select --install'.

> 
> Also, people who DIY are supposed to go through all the troubles... you
> still haven't addressed the issue of new gcc (+ xcode building it with) may
> generate stuff that have additional dependencies on /usr/include, if
> /usr/include is around, and therefore not suitable when one is building
> things for others.

Are you assuming that folks are installing third-party stuff in /usr/include?
Since users should be installing only in /usr/local for that, that seems a bit
out of bounds here.

Kia Motors

[KIAUK MOTORS]

KIA MOTORS UK have awarded you £1,000.000.000GBP for claims contact
email:kiaukmot...@qualityservice.com
Call +27734751089

[Bug c/63770] New: ICE on valid code at all optimization levels on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 63770
   Summary: ICE on valid code at all optimization levels on
x86_64-linux-gnu
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

The following code causes an ICE when compiled with the current gcc trunk at
all the optimization levels on x86_64-linux-gnu in both 32-bit and 64-bit
modes. 

It is a regression from 4.9.x. 

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 5.0.0 20141106 (experimental) [trunk revision 217200] (GCC) 

$ 
$ gcc-4.9 -O0 -c small.c
$ 
$ gcc-trunk -O0 -c small.c
gcc-trunk: internal compiler error: Segmentation fault (program cc1)
0x40bccc execute
../../gcc-trunk/gcc/gcc.c:2908
0x40bfb9 do_spec_1
../../gcc-trunk/gcc/gcc.c:4724
0x40ea2b process_brace_body
../../gcc-trunk/gcc/gcc.c:6007
0x40ea2b handle_braces
../../gcc-trunk/gcc/gcc.c:5921
0x40cb17 do_spec_1
../../gcc-trunk/gcc/gcc.c:5378
0x40ea2b process_brace_body
../../gcc-trunk/gcc/gcc.c:6007
0x40ea2b handle_braces
../../gcc-trunk/gcc/gcc.c:5921
0x40cb17 do_spec_1
../../gcc-trunk/gcc/gcc.c:5378
0x40c443 do_spec_1
../../gcc-trunk/gcc/gcc.c:5493
0x40ea2b process_brace_body
../../gcc-trunk/gcc/gcc.c:6007
0x40ea2b handle_braces
../../gcc-trunk/gcc/gcc.c:5921
0x40cb17 do_spec_1
../../gcc-trunk/gcc/gcc.c:5378
0x40ea2b process_brace_body
../../gcc-trunk/gcc/gcc.c:6007
0x40ea2b handle_braces
../../gcc-trunk/gcc/gcc.c:5921
0x40cb17 do_spec_1
../../gcc-trunk/gcc/gcc.c:5378
0x40ea2b process_brace_body
../../gcc-trunk/gcc/gcc.c:6007
0x40ea2b handle_braces
../../gcc-trunk/gcc/gcc.c:5921
0x40cb17 do_spec_1
../../gcc-trunk/gcc/gcc.c:5378
0x40ea2b process_brace_body
../../gcc-trunk/gcc/gcc.c:6007
0x40ea2b handle_braces
../../gcc-trunk/gcc/gcc.c:5921
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


---


char a;

struct S
{
  int f0:9;
};

volatile struct S b;

int
fn1 ()
{
  return (1 & b.f0) < a;
}