[Bug target/65341] New: [5 Regression] glibc build failure on ppc64le: setcontext.S:367: Error: junk at end of line: `1,0'

[trippels at gcc dot gnu.org]

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

Bug ID: 65341
   Summary: [5 Regression] glibc build failure on ppc64le:
setcontext.S:367: Error: junk at end of line: `1,0'
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: dje at gcc dot gnu.org, meissner at gcc dot gnu.org

glibc doesn't build anymore on ppc64le:

 % gcc ../sysdeps/unix/sysv/linux/powerpc/powerpc64/setcontext.S -c
-I../include -I/home/trippels/glibc_build/stdlib -I/home/trippels/glibc_build
-I../sysdeps/unix/sysv/linux/powerpc/powerpc64/fpu
-I../sysdeps/unix/sysv/linux/powerpc/powerpc64
-I../sysdeps/unix/sysv/linux/wordsize-64 -I../sysdeps/unix/sysv/linux/powerpc
-I../sysdeps/powerpc/nptl -I../sysdeps/unix/sysv/linux/include
-I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread
-I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv
-I../sysdeps/unix/powerpc -I../sysdeps/unix -I../sysdeps/posix
-I../sysdeps/powerpc/powerpc64/fpu -I../sysdeps/powerpc/powerpc64
-I../sysdeps/wordsize-64 -I../sysdeps/powerpc/fpu -I../sysdeps/powerpc
-I../sysdeps/ieee754/ldbl-128ibm -I../sysdeps/ieee754/ldbl-opt
-I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754
-I../sysdeps/generic -I.. -I../libio -I. -nostdinc -isystem
/home/trippels/gcc_test/usr/local/bin/../lib/gcc/powerpc64le-unknown-linux-gnu/5.0.0/include
-isystem
/home/trippels/gcc_test/usr/local/bin/../lib/gcc/powerpc64le-unknown-linux-gnu/5.0.0/include-fixed
-isystem /usr/include -D_LIBC_REENTRANT -include
/home/trippels/glibc_build/libc-modules.h -DMODULE_NAME=libc -include
../include/libc-symbols.h -DASSEMBLER -g -Werror=undef -Wa,--noexecstack -o
/home/trippels/glibc_build/stdlib/setcontext.o -MD -MP -MF
/home/trippels/glibc_build/stdlib/setcontext.o.dt -MT
/home/trippels/glibc_build/stdlib/setcontext.o 
../sysdeps/unix/sysv/linux/powerpc/powerpc64/setcontext.S: Assembler messages:
../sysdeps/unix/sysv/linux/powerpc/powerpc64/setcontext.S:367: Error: junk at
end of line: `1,0'

This happens because the _ARCH_PWR6 macro is now defined with gcc-5:

trippels@gcc2-power8 gcc % gcc -dM -E - < /dev/null | grep _ARCH_PWR6
#define _ARCH_PWR6 1

and sysdeps/unix/sysv/linux/powerpc/powerpc64/setcontext.S contains:

365 # ifdef _ARCH_PWR6
366   /* Use the extended four-operand version of the mtfsf insn.  */
367   mtfsf  0xff,fp0,1,0
368 # else
369   .machine push
370   .machine "power6"
371   /* Availability of DFP indicates a 64-bit FPSCR.  */
372   andi.  r6,r5,PPC_FEATURE_HAS_DFP
373   beq7f
374   /* Use the extended four-operand version of the mtfsf insn.  */
375   mtfsf  0xff,fp0,1,0
376   b  8f
377   /* Continue to operate on the FPSCR as if it were 32-bits.  */
378 7:
379   mtfsf  0xff,fp0
380 8:
381   .machine pop
382 # endif /* _ARCH_PWR6 */

trippels@gcc2-power8 stdlib % diff -u setcontext.s setcontext.s_bad
--- setcontext.s2015-03-07 08:20:19.902444301 +
+++ setcontext.s_bad2015-03-07 07:57:46.171055684 +
@@ -285,22 +285,8 @@



-
-
-  .machine push
-  .machine "power6"
-
-  andi. 6,5,0x0400
-  beq 7f
-
   mtfsf 0xff,0,1,0
-  b 8f
-
-7:
-  mtfsf 0xff,0
-8:
-  .machine pop
-
+# 383 "../sysdeps/unix/sysv/linux/powerpc/powerpc64/setcontext.S"
   lfd 29,(616 +(29*8))(31)
   lfd 28,(616 +(28*8))(31)
   lfd 27,(616 +(27*8))(31)

[Bug target/65342] New: [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[dominiq at lps dot ens.fr]

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

Bug ID: 65342
   Summary: [5 Regression] FAIL:
gfortran.dg/intrinsic_(un)?pack_1.f90   -O1  execution
test on powerpc-apple-darwin9 after r210201
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: amodra at gcc dot gnu.org, iains at gcc dot gnu.org
  Host: powerpc-apple-darwin9
Target: powerpc-apple-darwin9
 Build: powerpc-apple-darwin9

On powerpc-apple-darwin9 I see the following failures with -m64 after r210201

FAIL: gfortran.dg/intrinsic_pack_1.f90   -O1  execution test
FAIL: gfortran.dg/intrinsic_pack_1.f90   -O2  execution test
FAIL: gfortran.dg/intrinsic_unpack_1.f90   -O1  execution test
FAIL: gfortran.dg/intrinsic_unpack_1.f90   -O2  execution test
FAIL: gfortran.dg/intrinsic_unpack_1.f90   -O3 -fomit-frame-pointer  execution
test
FAIL: gfortran.dg/intrinsic_unpack_1.f90   -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: gfortran.dg/intrinsic_unpack_1.f90   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/intrinsic_unpack_1.f90   -O3 -g  execution test

The failures occur only in the following reduced codes

program intrinsic_unpack
   implicit none
   integer(kind=2), dimension(3, 3) :: a2, b2

   logical, dimension(3, 3) :: mask
   character(len=500) line1, line2
   integer i

   mask = reshape ((/.false.,.true.,.false.,.true.,.false.,.false.,&
&.false.,.false.,.true./), (/3, 3/));
   a2 = reshape ((/1, 0, 0, 0, 1, 0, 0, 0, 1/), (/3, 3/));
   b2 = unpack ((/2_2, 3_2, 4_2/), mask, a2)
   print *, b2
   if (any (b2 .ne. reshape ((/1, 2, 0, 3, 1, 0, 0, 0, 4/), (/3, 3/ &
  call abort

end program

program main
  implicit none
  integer :: i
  integer(kind=2), dimension(3,3) :: i2
  integer(kind=2), dimension(9) :: vi2
  integer(kind=2), dimension(9) :: ri2

  vi2 = (/(i+10,i=1,9)/)
  i2 = reshape((/1_2, -1_2, 2_2, -2_2, 3_2, -3_2, 4_2, -4_2, 5_2/), shape(i2))
  ri2 = pack(i2,i2>0,vi2)
  if (any(ri2 /= (/1_2, 2_2, 3_2, 4_2, 5_2, 16_2, 17_2, 18_2, 19_2/))) &
   & call abort

end program main

all the other checks in the original tests succeed.

The difference between the assembly generated by r210200 (-) and r210201 (+) is

--- intrinsic_unpack_1_red.s2015-03-07 10:11:12.0 +0100
+++ intrinsic_unpack_1_red_b.s2015-03-07 10:10:46.0 +0100
@@ -26,18 +26,14 @@ L1$pb:
 std r10,172(r1)
 lwz r2,32(r2)
 stw r2,180(r1)
-addis r9,r31,ha16(_A.1.1600-L1$pb)
-la r2,lo16(_A.1.1600-L1$pb)(r9)
-lwz r7,lo16(_A.1.1600-L1$pb)(r9)
-lwz r8,4(r2)
-lwz r10,8(r2)
-lwz r9,12(r2)
-stw r7,112(r1)
-stw r8,116(r1)
-stw r10,120(r1)
-stw r9,124(r1)
-lhz r2,16(r2)
-sth r2,128(r1)
+addis r2,r31,ha16(_A.1.1600-L1$pb)
+la r9,lo16(_A.1.1600-L1$pb)(r2)
+ld r2,lo16(_A.1.1600-L1$pb)(r2)
+ld r10,8(r9)
+lhz r9,16(r9)
+std r2,112(r1)
+std r10,120(r1)
+sth r9,128(r1)
 li r25,138
 std r25,752(r1)
 li r30,1

[Bug rtl-optimization/65321] [5 Regression] ICE on valid code at -O2 and -O3 with -g enabled in decompose, at rtl.h:2007

[rsandifo at gcc dot gnu.org]

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
(In reply to rguent...@suse.de from comment #5)
> On Thu, 5 Mar 2015, rsandifo at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321
> > 
> > --- Comment #4 from rsandifo at gcc dot gnu.org  > gnu.org> ---
> > (In reply to Richard Biener from comment #3)
> > > (gdb) p debug_rtx (x.first)
> > > (const_int 128 [0x80])
> > > (gdb) p x.second
> > > $2 = QImode
> > > (gdb) p precision 
> > > $3 = 8
> > > 
> > > the CONST_INT is not properly sign-extended.  This is from
> > > 
> > > #6  0x00d55381 in simplify_const_binary_operation (code=ASHIFT, 
> > > mode=QImode, op0=0x768d3490, op1=0x769e8b00)
> > > at /space/rguenther/src/svn/trunk2/gcc/simplify-rtx.c:4001
> > > ...
> > > 3997case LSHIFTRT:
> > > 3998case ASHIFTRT:
> > > 3999case ASHIFT:
> > > 4000  {
> > > 4001wide_int wop1 = pop1;
> > > 4002if (SHIFT_COUNT_TRUNCATED)
> > > 4003  wop1 = wi::umod_trunc (wop1, width);
> > > 
> > > but of course the shift amount need not be QImode as well.  128 is quite
> > > large,
> > > but well...
> > > 
> > > Fact is that we don't know the mode of op1 here.  From the fact that the
> > > const_int is not sign-extended we can conclude its mode is larger than
> > > QImode.
> > > And we will truncate it anyway (or return NULL_RTX) if it is too large, so
> > > it doesn't even matter.
> > 
> > I take your point, but at the same time, is it really worth supporting 
> > shifts
> > whose shift amount is wider than the shifted value?  ISTM that no .md 
> > pattern
> > would want such a thing, so in practice this would only ever happen with 
> > debug
> > exprs.
> 
> Well, simplifying such shift may occur in regular code as well.  We
> simply drop the extra bits (or fail to simplify), but that's done
> with wide-int stuff so we need to be able to convert the RTX to a
> wide-int first... (chicken and egg issue).

But shifts in regular code are going to be more sensible, since they're
ultimately constrained by .md patterns.  And when given a sensible shift
mode, the simplify-rtx.c routines should only produce sensible shift modes.
The problem case is coming from simplification routines local to
var-tracking.c.

> >  I think the safest fix would be to make use_narrower_mode{,_test}
> > narrow the shift amount if it is wider than the target mode.  Just tried 
> > that
> > locally and it seems to fix the test case.
> 
> No, that doesn't work.  It will change behavior for say
> a shift of a QImode value by 0x101 because you'd obtain one for the
> shift value and thus the path taken will be different. ISTR that
> the difference with respect to implementations is whether a
> shift by 0x101 will result in a shift by 1 (SHIFT_COUNT_TRUNCATED)
> or whether it will result in zero (shift by too large value).

No, !SHIFT_COUNT_TRUNCATED doesn't mean that the shifts are infinite
precision, it just means that they have a target-specific precision.
The result can be 0, 1 or even something else.  The target-independent
code simply doesn't know, which is why simplify-rtx.c bails out if the
shift amount is out of range on a !SHIFT_COUNT_TRUNCATED target.

AIUI this leeway isn't there for language-level behaviour.  It's there
so that if the target wants to split more complicated operations into
sequences involving shifts, it can take the behaviour of the shift
instructions into account without worrying about the target-independent
code misoptimising the result.  E.g. if you're implementing doubleword
64-bit shifts using 32-bit word shifts, you can save an instruction if
the 32-bit shift honours the low 6 bits of the shift amount.  32-bit ARM
is an example of this.  It's !SHIFT_COUNT_TRUNCATED, but pass a shift
amount of 0x101 to an ARM shift instruction and the result would be the
same as a shift of 1, just as it is for SHIFT_COUNT_TRUNCATED.

So !SHIFT_COUNT_TRUNCATED shifts are only "implementation-defined" for
shifts that the target could actually do.  If the shift has no
corresponding instruction, the behaviour is undefined rather than
implementation-defined.

> > > I think we can simply use
> > > 
> > >   wide_int wop1 = std::make_pair (op1, MAX_MODE_INT);
> > > 
> > > here (or SImode maybe).  Or have a "don't care" way to make a wide-int
> > > from a CONST_INT directly.
> > 
> > Certainly SImode would be dangerous, since there's nothing to stop the same 
> > bug
> > reappearing with DImode.  MAX_MODE_INT is a problem because it can be wider
> > than MAX_BITSIZE_MODE_ANY_INT on targets like x86_64 that explicitly 
> > override
> > the wide_int size.  And I'd be reluctant to relax the general CONST_INT
> > semantics for such an oddball case.
> 
> Well, the real fix is to pass down the mode - which may be not available,
> of course.

The real fix is to add modes to CONST_INT :-)  Have I c

[Bug c++/61362] g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2 does not compile lambda with template

[thibaut.lutz at googlemail dot com]

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

Thibaut LUTZ  changed:

   What|Removed |Added

 CC||thibaut.lutz at googlemail dot 
com

--- Comment #3 from Thibaut LUTZ  ---
This triggers the same internal error on HEAD 5.0.0 20150306.


>>
template 
struct S {
  int f{[this](){return 42;}()};
};

int main(){
  return S{}.f; // should be 42
}
<<

prog.cc: In instantiation of 'struct S::':
prog.cc:3:29:   required from here
prog.cc:3:10: internal compiler error: in tsubst_copy, at cp/pt.c:12872
  int f{[this](){return 42;}()};

[Bug middle-end/61207] [4.9 Regression] Win64 gcc 4.9.0: ICE in in expand_expr_addr_expr_1 at -Os compiling some C++ code

[mingw.android at gmail dot com]

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

Ray Donnelly  changed:

   What|Removed |Added

 CC||mingw.android at gmail dot com

--- Comment #8 from Ray Donnelly  ---
Regarding https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61207#c5

It's not a question of being able to get the source code, it's about reducing
the code to the minimum amount that exhibits the bug. In the old days (maybe
still now?) gccbug would be used, now-a-days, creduce works well. Here is the
testcase from Boost:

// reduced test case:

namespace std {
class basic_string typedef string;
class basic_string {
public:
  basic_string(char *, unsigned);
};
}
class A {
public:
  A(char);
  size();
  char *begin();
  *m_begin;
  *m_end;
};
enum output_format {};
namespace std {
class runtime_error {
public:
  runtime_error(string);
};
}
struct B : std::runtime_error {
  B(A m) : runtime_error(std::string(m.begin(), m.size())) {}
};
fn1(int, output_format) {
  B(0);
  B(0);
}

// elapsed time: 30405 seconds

Compiling with MSYS2's mingw64/mingw-w64-x86_64-gcc 4.9.2-4 package with:
/mingw64/bin/g++ -Os testcase.ii

Gives:
internal compiler error: in expand_expr_addr_expr_1, at expr.c:7669

[Bug target/64785] [5 Regression][SH] and|or|xor #imm not used

[olegendo at gcc dot gnu.org]

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

--- Comment #3 from Oleg Endo  ---
Created attachment 34982
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34982&action=edit
Add sh_pre_ra RTL pass

[Bug target/64785] [5 Regression][SH] and|or|xor #imm not used

[olegendo at gcc dot gnu.org]

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

--- Comment #4 from Oleg Endo  ---
(In reply to Oleg Endo from comment #3)
> Created attachment 34982 [details]
> Add sh_pre_ra RTL pass

Right now I can think of two alternatives for this PR:
- convert respective insns into insn_and_split and emit a pseudo + move in
split1

- catch imm8,r0 insns in sh_legitimate_combined_insn in the same way as it's
done by the sh_pre_ra pass above.


I think that an SH specific pre-RA RTL pass could be useful in the future, for
example to improve R0 utilization, even with LRA.

Kaz, do you have any opinions?

[Bug target/64785] [5 Regression][SH] and|or|xor #imm not used

[olegendo at gcc dot gnu.org]

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

--- Comment #5 from Oleg Endo  ---
(In reply to Oleg Endo from comment #3)
> Created attachment 34982 [details]
> Add sh_pre_ra RTL pass

+
+  flag_live_range_shrinkage = 1;

This hunk was not supposed to be in the patch.

[Bug target/65341] [5 Regression] glibc build failure on ppc64le: setcontext.S:367: Error: junk at end of line: `1,0'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I'd say that predefining this macro is not a bug.
So, the issue is more likely that some -m* option isn't passed to the
assembler, or that .machine isn't emitted in the assembly.

[Bug c++/65339] [5 Regression] C++ ICE with lambda and no capture list

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Started with r210292.

[Bug c++/65333] [5 Regression] error: incomplete type used in nested name specifier

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Started with r217250 aka DR 1558.

[Bug c++/65332] [5 Regression] error: expected template-name before ‘<’ token

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Started with r217250 aka DR 1558.

[Bug c/65331] C99 format macros doesn't accept bit fields for 64-bit integer types

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #3 from Jakub Jelinek  ---
Not a bug then.

[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-07
 CC||amodra at gmail dot com
 Ever confirmed|0   |1

--- Comment #1 from Alan Modra  ---
Confirmed.  The problem occurs in fwprop1 where instructions corresponding to
the following assembly
addis r2,r31,ha16(_A.1.1600-L1$pb)
la r9,lo16(_A.1.1600-L1$pb)(r2)
ld r2,0(r9)
are combined to
addis r2,r31,ha16(_A.1.1600-L1$pb)
la r9,lo16(_A.1.1600-L1$pb)(r2)
ld r2,lo16(_A.1.1600-L1$pb)(r2)
ie. the offset is propagated into the memory load.  This ought to give you an
error at assembly or link time.  If not, you have a bad assembler or linker..

movdi_low is the culprit, I think.  It should require a suitably aligned offset
(operand 2).

[Bug libstdc++/65343] New: unexpected exception thrown during destruction of static object in debug mode

[frankhb1989 at gmail dot com]

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

Bug ID: 65343
   Summary: unexpected exception thrown during destruction of
static object in debug mode
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frankhb1989 at gmail dot com

Recently I found one of my program unexpected aborted by unhandled exception.
The program is compliled with '-std=c++11 -D_GLIBCXX_DEBUG
-D_GLIBCXX_DEBUG_PEDANTIC'. The corresponding release build (i.e. "no
-D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC") does not behave like this.

GDB tells me there is something wrong happened during destruction of some
global container objects:

#2  0x00454b09 in __cxxabiv1::__terminate(void (*)()) ()
#3  0x00635d99 in __cxa_call_terminate ()
#4  0x006366df in __gxx_personality_v0 ()
#5  0x6e952cd2 in ?? () from F:\msys\mingw\bin\libgcc_s_dw2-1.dll
#6  0x6e95332b in ?? () from F:\msys\mingw\bin\libgcc_s_dw2-1.dll
#7  0x00636435 in __cxa_throw ()
#8  0x005021ea in __gnu_cxx::__throw_concurrence_lock_error ()
at F:/msys/mingw/include/c++/4.9.1/ext/concurrence.h:102
#9  0x00470a15 in __gnu_debug::_Safe_sequence_base::_M_detach_all() ()

I searched the source of libstdc++, then I found, in "C++11/debug.cc", there
were mutexes used by the debug mode containers, which was some static
__gnu_cxx::__mutex objects. This was probably the direct reason: the order
destruction of static objects among translation units are unspecified, so the
mutexes could be destroyed before the sequences contained by some other static
objects (certainly in different translation units). Then, during the
desturction of the sequence, "_M_detach_all" was called. In that function,
"__gnu_cxx::__scoped_lock sentry(_M_get_mutex());" tried using the (already
destroyed) mutex to lock the resources, which failed and threw.

Since the documentation says, "all functional and exception-handling guarantees
made by the normal library also hold for the debug mode library, with one
exception: performance guarantees made by the normal library may not hold in
the debug mode library", and ISO C++ effectively forbids destructors in
standard library to throw, this should be a bug.

[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
> Confirmed.  The problem occurs in fwprop1 where instructions corresponding to 
> the
> following assembly
>   addis r2,r31,ha16(_A.1.1600-L1$pb)
>   la r9,lo16(_A.1.1600-L1$pb)(r2)
>   ld r2,0(r9)
> are combined to
>   addis r2,r31,ha16(_A.1.1600-L1$pb)
>   la r9,lo16(_A.1.1600-L1$pb)(r2)
>   ld r2,lo16(_A.1.1600-L1$pb)(r2)
> ie. the offset is propagated into the memory load.  This ought to give you
> an error at assembly or link time.

No error at assembly or link time.

> If not, you have a bad assembler or linker..

Well, we'll have to live with them!-(EOL target).

> movdi_low is the culprit, I think.  It should require a suitably aligned
> offset (operand 2).

How?

[Bug libstdc++/65343] unexpected exception thrown during destruction of static object in debug mode

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Maybe we want to placement-new the mutexes into a buffer so they are never
destroyed, although on mingw that will show up as leaked resources at program
shutdown (and this is only really a problem on mingw as we don't need to run
any destructor on the mutexes for most targets).

[Bug target/65341] [5 Regression] glibc build failure on ppc64le: setcontext.S:367: Error: junk at end of line: `1,0'

[dje at gcc dot gnu.org]

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

--- Comment #2 from David Edelsohn  ---
When did this start?  GCC should be passing ".machine power8".  Was this before
or after Mike's change to processor default?

[Bug rtl-optimization/65321] [5 Regression] ICE on valid code at -O2 and -O3 with -g enabled in decompose, at rtl.h:2007

[law at redhat dot com]

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

--- Comment #7 from Jeffrey A. Law  ---
Richard S. is correct.  SHIFT_COUNT_TRUNCATED means that the target internally
truncates the shift count to the number of bits needed to represent the size of
the object being shift (which is actually more crisply defined than I
remember).

For a !SHIFT_COUNT_TRUNCATED target, the count is still constrained by the mode
of the shift count and it *may* still be internally truncated by the target. 
The x86 and m68k are good examples of this.  They truncate shifts, but not
things like variable bit test instructions.  But since they don't truncate
both, we do not define SHIFT_COUNT_TRUNCATED.

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[olegendo at gcc dot gnu.org]

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

--- Comment #16 from Oleg Endo  ---
Author: olegendo
Date: Sat Mar  7 16:12:41 2015
New Revision: 221256

URL: https://gcc.gnu.org/viewcvs?rev=221256&root=gcc&view=rev
Log:
gcc/testsuite/
PR target/65249
* g++.dg/torture/pr65249.C: New.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr65249.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #17 from Oleg Endo  ---
I think we can close this as fixed.

[Bug middle-end/61207] [4.9 Regression] Win64 gcc 4.9.0: ICE in in expand_expr_addr_expr_1 at -Os compiling some C++ code

[ktietz at gcc dot gnu.org]

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

--- Comment #9 from Kai Tietz  ---
well, it might be same issue, but on x64 target the testcase of comment #6
works without issues.
As SRA seems to be involved here, the changes on trunk for DOM might be the
solution.

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

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
Summary|[4.9/5 regression] FAIL:|[4.9 regression] FAIL:
   |gcc.dg/vect/costmodel/ppc/c |gcc.dg/vect/costmodel/ppc/c
   |ostmodel-bb-slp-9a.c|ostmodel-bb-slp-9a.c
   |scan-tree-dump-times slp2"  |scan-tree-dump-times slp2"
   |basic block vectorized  |basic block vectorized
   |using SLP" 1|using SLP" 1

--- Comment #35 from Jeffrey A. Law  ---
Performance regression fixed by Richi.  Testsuite improvements by Martin.  Both
on the trunk only.  Trunk regression marker removed.

[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[iains at gcc dot gnu.org]

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

--- Comment #3 from Iain Sandoe  ---
(In reply to Dominique d'Humieres from comment #2)
> > Confirmed.  The problem occurs in fwprop1 where instructions corresponding 
> > to the
> > following assembly
> > addis r2,r31,ha16(_A.1.1600-L1$pb)
> > la r9,lo16(_A.1.1600-L1$pb)(r2)
> > ld r2,0(r9)
> > are combined to
> > addis r2,r31,ha16(_A.1.1600-L1$pb)
> > la r9,lo16(_A.1.1600-L1$pb)(r2)
> > ld r2,lo16(_A.1.1600-L1$pb)(r2)
> > ie. the offset is propagated into the memory load.  This ought to give you
> > an error at assembly or link time.
> 
> No error at assembly or link time.

> > If not, you have a bad assembler or linker..
> 
> Well, we'll have to live with them!-(EOL target).

The system as is based on gas-1.38 and doesn't warn for this :-(
ld64 is slightly better and does catch a few more cases (where they resolve at
link-time).

.. there's some hope for my WIP GAS port and an updated ld64 (yeah, I know it's
taking a long time for these to appear) ..

> > movdi_low is the culprit, I think.  It should require a suitably aligned
> > offset (operand 2).
> 
> How?

In the mdynamic-no-pic case, the literal value should work the same as for
linux.

In the case of PIC, I suspect we need to look through the uspecs that wrap
mach-o PIC offsets and try to determine if the alignment of the referenced
symbol is guaranteed to be "enough".  The alignment of the picbase will always
be >= 4.

Some time ago I had a WIP patch to try and deal with this … but it's bit-rotted
so needs a significant re-visit.

[Bug target/65344] New: Exception is not catched on AIX - class with more ancestors, virtual method throws

[jezz at hkfree dot org]

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

Bug ID: 65344
   Summary: Exception is not catched on AIX - class with more
ancestors, virtual method throws
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jezz at hkfree dot org

Created attachment 34983
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34983&action=edit
Sources for reproducing

In my program exception is not catched, when it is compiled with gcc newer than
4.4 (4.2.4 & 4.4.7 works). I have created sample (sample with Makefile in in
attachment). I have tested the sample with 4.5.4 and 4.8.3 - both fails. All
compilers are from http://www.perzl.org/aix/index.php?n=Main.Gcc

This is output from sample compiled with 4.4.7:

./main 
Case 1:

Case 2:
(Class*)ThrowingClass=0x0x200013b8
(DoThrowIface*)this=0x0x200013bc
(DoThrowIface*)ThrowingClass=0x0x200013bc
Called doThrow.
Thrown && catched BaseException.
End.

This is output from sample compiled with 4.8.3:
 ./main 
Case 1:

Case 2:
(Class*)ThrowingClass=0x0x20001ab8
(DoThrowIface*)this=0x0x20001abc
(DoThrowIface*)ThrowingClass=0x0x20001abc
Called doThrow.
terminate called after throwing an instance of 'Exception'

(gdb) where
#0  0xd37bd440 in raise () from /usr/lib/libc.a(shr.o)
#1  0xd384bca8 in abort () from /usr/lib/libc.a(shr.o)
#2  0xd8055610 in __gnu_cxx::__verbose_terminate_handler () at  _start_ :95
#3  0xd80609ec in __cxxabiv1::__terminate (handler=)
at  _start_ :38
#4  0xd8055404 in std::terminate () at  _start_ :48
#5  0xd8060d7c in __cxa_throw (obj=, 
tinfo=, dest=) at  _start_ :87
#6  0x10001604 in ThrowingClass::doThrow (this=0x20001ab8)
at throwing_class.cc:24
#7  0x16a8 in main (argc=1, argv=0x2ff22af4) at main.cc:39

g++ -v:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/freeware/libexec/gcc/powerpc-ibm-aix6.1.0.0/4.8.3/lto-wrapper
Target: powerpc-ibm-aix6.1.0.0
Configured with: ../gcc-4.8.3/configure --with-as=/usr/bin/as
--with-ld=/usr/bin/ld --enable-languages=c,c++,fortran --prefix=/opt/freeware
--mandir=/opt/freeware/man --infodir=/opt/freeware/info
--enable-version-specific-runtime-libs --disable-nls --enable-decimal-float=dpd
--host=powerpc-ibm-aix6.1.0.0
Thread model: aix
gcc version 4.8.3 (GCC) 


Sample sources:

base.hh:
#ifndef BASE_HH
#define BASE_HH 1

class Exception
   {
   public:
  Exception() {}
   };

class Iface
   {
   public:
  virtual ~Iface() {}
   };

class Class
   {
   public:
  virtual ~Class() {}
  virtual Iface *getIface() = 0;
   };

class DoThrowIface
   : public Iface
   {
   public:
  virtual void doThrow() = 0;
   };

class Registrator
   {
   public:
  virtual Class* getClass() = 0;
   };

#endif /* BASE_HH */

throwing_class.hh:
#ifndef THROWING_CLASS_HH
#define THROWING_CLASS_HH 1

class ThrowingClass
   : public Class
   , public DoThrowIface
   {
   public:
  virtual void doThrow();
  virtual Iface *getIface();
   };

#endif /* THROWING_CLASS_HH */

throwing_class.cc:
#include 
#include "base.hh"
#include "throwing_class.hh"

extern Registrator *reg;

// This class must be in separate object file
class ThrowingClassRegistrator : public Registrator
   {
   public:
  ThrowingClassRegistrator()
 {
 reg = this;
 }
  virtual Class *getClass()
 {
 return new ThrowingClass();
 }
   } ThrowingClassRegistrator_I;

void ThrowingClass::doThrow()
   {
   std::cout << "Called doThrow." << std::endl;
   throw Exception();
   }

Iface *ThrowingClass::getIface()
   {
   std::cout << "(DoThrowIface*)this=0x" << (DoThrowIface*)this << std::endl;
   return static_cast(this);
   }


main.cc:
#include 
#include 
#include "base.hh"
#include "throwing_class.hh"

Registrator *reg;

int
main(int argc, char *argv[])
   {
   std::cout << "Case 1:" << std::endl;
   try
  {
  // This always works, but if I uncomment this, case 2 is also working.
  /*
  Class *throwingClass = new ThrowingClass();
  std::cout << "(Class*)ThrowingClass=0x" << throwingClass << std::endl;
  DoThrowIface *throwIface = (DoThrowIface *)throwingClass->getIface();
  std::cout << "(DoThrowIface*)ThrowingClass=0x" << throwIface <<
std::endl;
  throwIface->doThrow();
  //*/
  }
   catch (Exception const& e)
  {
  std::cout << "Thrown && catched BaseException." << std::endl;
  }
   catch (...)
  {
  std::cout << "General catch." << std::endl;
  }

   std::cout << std::endl << "Case 2:" << std::endl;
   try
  {
  Class *throwingClass = reg->getClass();
  std::cout << "(Class*)ThrowingClass=0x" << throwingClass << std::endl;
  DoThrowIface *throwIface = (DoThrowIface *)throwingClass->getIface();
  std::cout << "(DoThrowIface*)ThrowingClass=0x" << throwIface <<
std::endl;

[Bug target/65341] [5 Regression] glibc build failure on ppc64le: setcontext.S:367: Error: junk at end of line: `1,0'

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
(In reply to David Edelsohn from comment #2)
> When did this start?  GCC should be passing ".machine power8".  Was this
> before or after Mike's change to processor default?

It started with your r219854.

[Bug lto/65316] [5 Regression] LTO: Uninitialized memory / ICE with -g -fno-lto-odr-type-merging: in types_same_for_odr, at ipa-devirt.c:465

[hubicka at gcc dot gnu.org]

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

--- Comment #10 from Jan Hubicka  ---
Unfortunately the patch breaks firefox LTO in an interesting way - I am
investigating if it is a firefox bug or not.

[Bug ipa/64253] [5 Regression] IPA inline analysis processes a code transform operation

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-03-07
 CC||hubicka at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
   Target Milestone|5.0 |6.0
 Ever confirmed|0   |1

--- Comment #3 from Jan Hubicka  ---
I looked into making loop optimizer to be initialized before all analysis hooks
so inliner can use SCEV.  The issue is that the analysis is organized as a
series of passes over whole program (something I mean to change back, we used
to do it per function that is friendlier to caches). We have no way to
initiazlie SCEV on all functions at once and I do not htink we want to.
We can just do the initialization and rely on fact that another initialization
should not affect code, but it seems hackish.

In any case I think it is something for next stage1, not for GCC 5.

I am assigning myself and setting target milestone.

[Bug target/65341] [5 Regression] glibc build failure on ppc64le: setcontext.S:367: Error: junk at end of line: `1,0'

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
The four operand form of the mtfsf instruction was added in Power ISA 2.5 and
gas recognizes it when targeting power6 or later.  From the glibc snippet it
does look like the first block controlled by _ARCH_PWR6 is missing the .machine
"power6" directive.  Once it's added I would expect as to be happy again (it is
in my tests, though I didn't go as far as building all of glibc).

365 # ifdef _ARCH_PWR6
366   /* Use the extended four-operand version of the mtfsf insn.  */
367   mtfsf  0xff,fp0,1,0
368 # else
369   .machine push
370   .machine "power6"

[Bug target/65341] [5 Regression] glibc build failure on ppc64le: setcontext.S:367: Error: junk at end of line: `1,0'

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
I think the point is when _ARCH_PWR6 is defined, the assembler should be
already in power6 or later mode (either through .machine directive emitted by
the compiler earlier, or through some command line option passed to the
assembler), so glibc shouldn't need to do that.

[Bug pch/61250] Random pch failures on x86_64-apple-darwin1(3|4).

[howarth at bromo dot med.uc.edu]

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

howarth at bromo dot med.uc.edu changed:

   What|Removed |Added

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

--- Comment #4 from howarth at bromo dot med.uc.edu ---
I see the failure of...

FAIL: g++.dg/pch/pch.C  -O2 -I. -Dwith_PCH (internal compiler error)
FAIL: g++.dg/pch/pch.C  -O2 -I. -Dwith_PCH (test for excess errors)
Excess errors:
Internal compiler error: Error reporting routines re-entered.
xg++: internal compiler error: Abort trap: 6 (program cc1plus)

randomly with a serial...

make -k check RUNTESTFLAGS="pch.exp=pch.C --target_board=unix'{-m32,-m64}'"

on x86_64-apple-darwin14.

[Bug target/65341] [5 Regression] glibc build failure on ppc64le: setcontext.S:367: Error: junk at end of line: `1,0'

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
Ah, yes, I missed that the macro was defined by gcc rather than glibc.  It does
look like gcc defines the macro and then invokes as without telling it it's in
power6 mode.

[Bug target/65153] [SH][4.9 Regression] "insn does not satisfy its constraints" when compiling libmcrypt

[olegendo at gcc dot gnu.org]

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

--- Comment #16 from Oleg Endo  ---
Author: olegendo
Date: Sat Mar  7 19:35:22 2015
New Revision: 221257

URL: https://gcc.gnu.org/viewcvs?rev=221257&root=gcc&view=rev
Log:
gcc/testsuite/
PR target/65153
* gcc.c-torture/compile/pr65153.c: New.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr65153.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/65341] [5 Regression] glibc build failure on ppc64le: setcontext.S:367: Error: junk at end of line: `1,0'

[dje at gcc dot gnu.org]

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

--- Comment #7 from David Edelsohn  ---
Was this fixed after Mike's patch?  The logic in rs6000_override_options was
ignoring TARGET_DEFAULT.

[Bug c++/59832] [c++11] ICE in reshape_init_class with initializer list

[ppluzhnikov at google dot com]

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

--- Comment #7 from Paul Pluzhnikov  ---
Still broken on trunk @r221169.

Leaving known ICEs for >= 1 year untouched seems... suboptimal.
(Sorry I don't know enough GCC internals to take this on.)

[Bug lto/65316] [5 Regression] LTO: Uninitialized memory / ICE with -g -fno-lto-odr-type-merging: in types_same_for_odr, at ipa-devirt.c:465

[hubicka at gcc dot gnu.org]

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

--- Comment #11 from Jan Hubicka  ---
Author: hubicka
Date: Sat Mar  7 20:33:58 2015
New Revision: 221258

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

PR ipa/65316
* tree.c (free_lang_data_in_type): Be sure to keep BINFO_VTABLE
when outputting debug.

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

[Bug c/65345] New: ICE with _Generic selection on _Atomic int

[tijl at coosemans dot org]

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

Bug ID: 65345
   Summary: ICE with _Generic selection on _Atomic int
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tijl at coosemans dot org

gcc49 (FreeBSD Ports Collection) 4.9.3 20150218 (prerelease)

% cat test.c
_Atomic int i;  
int j = _Generic( i+1, int: 1, default: 0 );

% gcc49 -c test.c
tmp.c:2:1: internal compiler error: Segmentation fault
 int j = _Generic( i+1, int: 1, default: 0 );
 ^
no stack trace because unwind library not available
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


The error only happens when "i" is part of an expression, so _Generic(i,...)
works correctly (it returns 1).  Qualifiers like const and volatile instead of
_Atomic also work.

[Bug preprocessor/65238] [5 Regression] __has_attribute is not handled properly with -traditional-cpp.

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe  ---
well, I suppose, before digging deeper into fixing this, the question is
"should __has_attribute/__has_cpp_attribute be enabled for traditional"?

if not ..  (using the 'keep non-traditional cpp builtins at the end' from
init.c) then I suppose something like:

diff --git a/libcpp/init.c b/libcpp/init.c
index 45a4d13..3f6cd4d 100644
--- a/libcpp/init.c
+++ b/libcpp/init.c
@@ -455,7 +455,7 @@ cpp_init_special_builtins (cpp_reader *pfile)
   size_t n = ARRAY_SIZE (builtin_array);

   if (CPP_OPTION (pfile, traditional))
-n -= 2;
+n -= 4;
   else if (! CPP_OPTION (pfile, stdc_0_in_system_headers)
   || CPP_OPTION (pfile, std))
 n--;


.. would work.

[Bug c/65345] ICE with _Generic selection on _Atomic int

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-03-07
 CC||mpolacek at gcc dot gnu.org
Version|unknown |4.9.2
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Happens with trunk as well.  Taking.

[Bug preprocessor/65238] [5 Regression] __has_attribute is not handled properly with -traditional-cpp.

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
(In reply to Iain Sandoe from comment #4)
> well, I suppose, before digging deeper into fixing this, the question is
> "should __has_attribute/__has_cpp_attribute be enabled for traditional"?

I believe it should, e.g. __has_include works in traditional cpp.

[Bug c/65345] ICE with _Generic selection on _Atomic int

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Backtrace:

0xcbc8aa crash_signal
/home/marek/src/gcc/gcc/toplev.c:383
0x978b80 tree_check
/home/marek/src/gcc/gcc/tree.h:2845
0x978b80 gimple_body(tree_node*)
/home/marek/src/gcc/gcc/gimple-expr.c:328
0xa18d07 gimple_add_tmp_var(tree_node*)
/home/marek/src/gcc/gcc/gimplify.c:721
0x97949a create_tmp_var(tree_node*, char const*)
/home/marek/src/gcc/gcc/gimple-expr.c:522
0x68051f convert_lvalue_to_rvalue(unsigned int, c_expr, bool, bool)
/home/marek/src/gcc/gcc/c/c-typeck.c:2042
0x6bd29a c_parser_binary_expression
/home/marek/src/gcc/gcc/c/c-parser.c:6379
0x6bd7d8 c_parser_conditional_expression
/home/marek/src/gcc/gcc/c/c-parser.c:6031
0x6bdd80 c_parser_expr_no_commas
/home/marek/src/gcc/gcc/c/c-parser.c:5949
0x6b39e8 c_parser_generic_selection
/home/marek/src/gcc/gcc/c/c-parser.c:6856
0x6b39e8 c_parser_postfix_expression
/home/marek/src/gcc/gcc/c/c-parser.c:7665
0x6b5572 c_parser_unary_expression
/home/marek/src/gcc/gcc/c/c-parser.c:6602
0x6bcaaa c_parser_cast_expression
/home/marek/src/gcc/gcc/c/c-parser.c:6440
0x6bcc74 c_parser_binary_expression
/home/marek/src/gcc/gcc/c/c-parser.c:6255
0x6bd7d8 c_parser_conditional_expression
/home/marek/src/gcc/gcc/c/c-parser.c:6031
0x6bdd80 c_parser_expr_no_commas
/home/marek/src/gcc/gcc/c/c-parser.c:5949
0x6c7c0a c_parser_initializer
/home/marek/src/gcc/gcc/c/c-parser.c:4167
0x6cd107 c_parser_declaration_or_fndef
/home/marek/src/gcc/gcc/c/c-parser.c:1824
0x6d51c7 c_parser_external_declaration
/home/marek/src/gcc/gcc/c/c-parser.c:1452
0x6d5a49 c_parser_translation_unit
/home/marek/src/gcc/gcc/c/c-parser.c:1339
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/65345] ICE with _Generic selection on _Atomic int

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Seems to be unrelated to _Generic, the following ICEs as well:

_Atomic int i = 5;
int j = i;

[Bug target/65341] [5 Regression] glibc build failure on ppc64le: setcontext.S:367: Error: junk at end of line: `1,0'

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
(In reply to David Edelsohn from comment #7)

I assume the patch you are referring to is r221132 (pr65138).  It doesn't look
like that's fixed it.  The latest trunk exhibits the same problem:

$ cat t.s && /build/gcc-trunk-git/gcc/xgcc -B /build/gcc-trunk-git/gcc -dM -E
-xc - < /dev/null | grep PWR6 && /build/gcc-trunk-git/gcc/xgcc -B
/build/gcc-trunk-git/gcc -c -v t.s
.text
start:
mtfsf   6,10,0,0
#define _ARCH_PWR6 1
Reading specs from /build/gcc-trunk-git/gcc/specs
COLLECT_GCC=/build/gcc-trunk-git/gcc/xgcc
Target: powerpc64le-unknown-linux-gnu
Configured with: /src/gcc-trunk-git/configure --disable-bootstrap
--enable-languages=c,c++
Thread model: posix
gcc version 5.0.0 20150307 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-B' '/build/gcc-trunk-git/gcc' '-c' '-v'
 /build/gcc-trunk-git/gcc/as -v -a64 -mppc64 -many -mlittle -o t.o t.s
GNU assembler version 2.23.52.0.1 (ppc64le-redhat-linux) using BFD version
version 2.23.52.0.1-30.ael7b 20130226
t.s: Assembler messages:
t.s:3: Error: junk at end of line: `0,0'

[Bug target/64785] [5 Regression][SH] and|or|xor #imm not used

[kkojima at gcc dot gnu.org]

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

--- Comment #6 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #4)
> I think that an SH specific pre-RA RTL pass could be useful in the future,
> for example to improve R0 utilization, even with LRA.
> 
> Kaz, do you have any opinions?

I like your pre-RA pass even if it's a too big hammer for
this specific problem.  It should wait the next stage1, though.
Also it would be better to look for another use cases of that
pass as you suggested so as to justify the cost of scanning
all insns.

[Bug c++/43407] Specifying visibility attribute of C++0x enum class emits warning

[badams at gnarlie dot com]

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

--- Comment #3 from Brian Adams  ---
This bug is also in 4.9.0, and applies to /any/ attribute. Assuming a GCC
plugin that defines 'my_attr': 

   enum class __attribute__((my_attr)) MessageType : uint8_t  {}

will generate the warning

   Messages.h:37:1: warning: type attributes ignored after type is already
defined [-Wattributes]

As a work around, this code functions as desired:

   enum class MessageType : uint8_t  __attribute__((my_attr)) {}

Interestingly, putting the attribute *before* the enum keyword generates a
warning and note that are (currently) incorrect, given this bug:

   warning: attribute ignored in declaration of ‘enum class MessageType’
[-Wattributes]
__attribute__((my_attr)) enum class MessageType : uint8_t  {
 ^
   note: attribute for ‘enum class batsoe::MessageType’ must follow the ‘enum
class’ keyword

[Bug target/65341] [5 Regression] glibc build failure on ppc64le: setcontext.S:367: Error: junk at end of line: `1,0'

[dje at gcc dot gnu.org]

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

--- Comment #9 from David Edelsohn  ---
GCC is working correctly.  The file prologue generated by GCC for a C file now
includes

.machine power8

The example is a pre-processed assembly file.  Note the file actively pushes
and pops the machine type.

The assembly file incorrectly assumes that GCC will invoke the assembler with a
command-line option enabling a default ISA level sufficient for the
instructions in the file.  This is a bad assumption.  Even if we create a
kludge in GCC to invoke the assembler an arbitrary ISA level, this is bad
assumption.  The GLIBC file is buggy.

[Bug target/65341] [5 Regression] glibc build failure on ppc64le: setcontext.S:367: Error: junk at end of line: `1,0'

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Ah, indeed, I've totally missed it is a *.S file rather than *.c.  Thus this is
certainly a glibc bug, please file it there instead.

[Bug target/65341] [5 Regression] glibc build failure on ppc64le: setcontext.S:367: Error: junk at end of line: `1,0'

[trippels at gcc dot gnu.org]

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

--- Comment #11 from Markus Trippelsdorf  ---
So one has to use:
CC="gcc -Wa,-mpower8" CXX="g++ -Wa,-mpower8" ../glibc/configure 
to configure glibc on ppc64le? This looks odd to me.
Why not pass -mpower8 to the assembler by default?

[Bug other/55930] libatomic build failure if configured with --disable-dependency-tracking

[compnerd at compnerd dot org]

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

--- Comment #3 from Saleem Abdulrasool  ---
Still occurs with 4.9.2 (and the same patch still fixes it).