[Bug c/63224] False Positive for -Wmaybe-uninitialized at -Os, not -O2

[sebastian.hu...@embedded-brains.de]

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

--- Comment #7 from Sebastian Huber  ---
I reduced the test case using the delta tool to:

void foo(void);

void bar(int s, int *a)
{
int i;
int c;

for (i = 0; s != 0 && (c = a[i]); ++i) {
}

if (s == 2 && c == 0) {
} else if (s != 0) {
foo();
}
}

cp test.c Os.c
cp test.c O2.c
arm-rtems4.11-gcc -Wfatal-errors -Wall -Os -S Os.c -o Os.s
-fdump-tree-all-all-lineno
Os.c: In function 'bar':
Os.c:11:25: warning: 'c' may be used uninitialized in this function
[-Wmaybe-uninitialized]
 if (s == 2 && c == 0) {
 ^
arm-rtems4.11-gcc -Wfatal-errors -Wall -O2 -S O2.c -o O2.s
-fdump-tree-all-all-lineno

diff -u O*c*uni*
--- O2.c.140t.uninit1   2014-09-12 09:20:47.983177990 +0200
+++ Os.c.140t.uninit1   2014-09-12 09:20:47.909178064 +0200
@@ -5,73 +5,138 @@
 Pass statistics:
 

+[WORKLIST]: add to initial list: c_2 = PHI 
+[CHECK]: examining phi: c_2 = PHI 
+
+[CHECK] Found def edge 1 in c_2 = PHI 
+[CHECK]: Found unguarded use: c_3 = PHI 
+[WORKLIST]: Update worklist with phi: c_3 = PHI 
+[CHECK]: examining phi: c_3 = PHI 
+[CHECK]: Found unguarded use: _15 = c_3 == 0;

 Pass statistics:
 

 bar (intD.3 sD.4075, intD.3 * aD.4076)
 {
-  unsigned int ivtmp.12D.4111;
+  unsigned int ivtmp.10D.4109;
   intD.3 cD.4080;
   intD.3 iD.4079;
+  _BoolD.1375 _14;
+  _BoolD.1375 _15;
+  _BoolD.1375 _16;
+  _BoolD.1375 _21;
+  intD.3 * _23;
+  voidD.63 * _24;

 ;;   basic block 2, loop depth 0, count 0, freq 880, maybe hot
-;;prev block 0, next block 6, flags: (NEW, REACHABLE)
+;;prev block 0, next block 3, flags: (NEW, REACHABLE)
 ;;pred:   ENTRY [100.0%]  (FALLTHRU,EXECUTABLE)
-;;   starting at line 8
-  [O2.c : 8:9] if (s_6(D) != 0)
-goto ;
+;;   starting at line -1
+  _23 = a_9(D) + 4294967292;
+  # RANGE [0, 4294967295]
+  ivtmp.10_22 = (unsigned int) _23;
+;;succ:   3 [100.0%]  (FALLTHRU,EXECUTABLE)
+
+;;   basic block 3, loop depth 1, count 0, freq 1, maybe hot
+;;prev block 2, next block 4, flags: (NEW, REACHABLE)
+;;pred:   2 [100.0%]  (FALLTHRU,EXECUTABLE)
+;;8 [100.0%]  (FALLTHRU,DFS_BACK)
+;;   starting at line 8, discriminator 1
+  # RANGE ~[0, 0]
+  # c_2 = PHI 
+  # ivtmp.10_19 = PHI 
+  [Os.c : 8:9] if (s_6(D) != 0)
+goto ;
   else
-goto ;
-;;succ:   3 [95.5%]  (TRUE_VALUE,EXECUTABLE)
-;;6 [4.5%]  (FALSE_VALUE,EXECUTABLE)
-
-;;   basic block 6, loop depth 0, count 0, freq 40, maybe hot
-;;prev block 2, next block 3, flags: (NEW)
-;;pred:   2 [4.5%]  (FALSE_VALUE,EXECUTABLE)
+goto ;
+;;succ:   4 [95.5%]  (TRUE_VALUE,EXECUTABLE)
+;;9 [4.5%]  (FALSE_VALUE,EXECUTABLE)
+
+;;   basic block 4, loop depth 1, count 0, freq 9550, maybe hot
+;;prev block 3, next block 10, flags: (NEW, REACHABLE)
+;;pred:   3 [95.5%]  (TRUE_VALUE,EXECUTABLE)
+;;   starting at line -1, discriminator 3
+  # RANGE [0, 4294967295]
+  ivtmp.10_18 = ivtmp.10_19 + 4;
+  # PT = nonlocal 
+  _24 = (voidD.63 *) ivtmp.10_18;
+  [Os.c : 8:34] # VUSE <.MEM_11(D)>
+  c_12 = MEM[base: _24, offset: 0B];
+  [Os.c : 8:28] if (c_12 != 0)
+goto ;
+  else
+goto ;
+;;succ:   8 [95.5%]  (TRUE_VALUE,EXECUTABLE)
+;;10 [4.5%]  (FALSE_VALUE,EXECUTABLE)
+
+;;   basic block 10, loop depth 0, count 0, freq 430, maybe hot
+;;prev block 4, next block 8, flags: (NEW)
+;;pred:   4 [4.5%]  (FALSE_VALUE,EXECUTABLE)
 ;; 
   goto ;
 ;;succ:   5 [100.0%]  (FALLTHRU)

-;;   basic block 3, loop depth 0, count 0, freq 430, maybe hot
-;;   Invalid sum of incoming frequencies 840, should be 430
-;;prev block 6, next block 7, flags: (NEW, REACHABLE)
-;;pred:   2 [95.5%]  (TRUE_VALUE,EXECUTABLE)
-;;   starting at line 11
-  [O2.c : 11:12] if (s_6(D) == 2)
-goto ;
-  else
-goto ;
-;;succ:   7 [79.8%]  (TRUE_VALUE,EXECUTABLE)
-;;4 [20.2%]  (FALSE_VALUE,EXECUTABLE)
+;;   basic block 8, loop depth 1, count 0, freq 9120, maybe hot
+;;prev block 10, next block 9, flags: (NEW)
+;;pred:   4 [95.5%]  (TRUE_VALUE,EXECUTABLE)
+;; 
+  goto ;
+;;succ:   3 [100.0%]  (FALLTHRU,DFS_BACK)

-;;   basic block 7, loop depth 0, count 0, freq 343, maybe hot
-;;prev block 3, next block 4, flags: (NEW)
-;;pred:   3 [79.8%]  (TRUE_VALUE,EXECUTABLE)
+;;   basic block 9, loop depth 0, count 0, freq 450, maybe hot
+;;prev block 8, next block 5, flags: (NEW)
+;;pred:   3 [4.5%]  (FALSE_VALUE,EXECUTABLE)
 ;; 
-  goto ;
 ;;succ:   5 [100.0%]  (FALLTHRU)

-;;   basic block 4, loop depth 0, count 0, freq 209, maybe hot
-;;   Invalid sum of incoming frequencies 87, should be 209
-;;prev block 7, next block 5, flags: (NEW, REACHABLE)
-;;pred:   3 [20.2%]  (FALSE_VALUE,EXECUTABLE)
+;;   basic block 5, loop depth 0, count 0, freq 880, maybe ho

[Bug middle-end/63237] New: [5 Regression] error: invalid operand in unary operation

[trippels at gcc dot gnu.org]

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

Bug ID: 63237
   Summary: [5 Regression] error: invalid operand in unary
operation
   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

markus@x4 llvm_build % < RewriteMacros.ii
extern "C" unsigned long strlen(const char *);
class A {
  int Length;

 public:
  A(const char *p1) { Length = strlen(p1); }
};
class B {
 public:
  void m_fn1(int, A);
};
class C {
 public:
  B &m_fn2();
};
int a;
void RewriteMacrosInInput() {
  C b;
  B &c = b.m_fn2();
  c.m_fn1(0, &""[a]);
}

markus@x4 llvm_build % g++ -c -O2 RewriteMacros.ii
RewriteMacros.ii: In function ‘void RewriteMacrosInInput()’:
RewriteMacros.ii:21:1: error: invalid operand in unary operation
 }
 ^
RewriteMacros.ii:21:1: error: invalid operand to unary operator
(ssizetype) a.0_6
RewriteMacros.ii:6:41: note: in statement
   A(const char *p1) { Length = strlen(p1); }
 ^
_14 = (long unsigned int) -(ssizetype) a.0_6;
RewriteMacros.ii:21:1: internal compiler error: verify_gimple failed
 }
 ^
0xc04b7a verify_gimple_in_cfg(function*, bool)
../../gcc/gcc/tree-cfg.c:5003
0xb12cd2 execute_function_todo
../../gcc/gcc/passes.c:1751
0xb136e3 execute_todo
../../gcc/gcc/passes.c:1808
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/63224] False Positive for -Wmaybe-uninitialized at -Os, not -O2

[sebastian.hu...@embedded-brains.de]

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

--- Comment #8 from Sebastian Huber  ---
Actually the for loop is not necessary.

int bar(int s, int *a)
{
int c;
int r;

r = s != 0 && (c = a[s]);

if (s == 2 && c == 0) {
} else if (s != 0) {
return 0;
}

return r;
}

cp test.c Os.c
cp test.c O2.c
arm-rtems4.11-gcc -Wfatal-errors -Wall -Os -S Os.c -o Os.s
-fdump-tree-all-all-lineno
Os.c: In function 'bar':
Os.c:8:18: warning: 'c' may be used uninitialized in this function
[-Wmaybe-uninitialized]
  if (s == 2 && c == 0) {
  ^
arm-rtems4.11-gcc -Wfatal-errors -Wall -O2 -S O2.c -o O2.s
-fdump-tree-all-all-lineno

diff -u O*c*uni*
--- O2.c.140t.uninit1   2014-09-12 09:29:10.627991057 +0200
+++ Os.c.140t.uninit1   2014-09-12 09:29:10.574991191 +0200
@@ -5,6 +5,9 @@
 Pass statistics:
 

+[WORKLIST]: add to initial list: c_1 = PHI 
+[CHECK]: examining phi: c_1 = PHI 
+[CHECK]: Found unguarded use: _13 = c_1 == 0;

 Pass statistics:
 
@@ -13,13 +16,97 @@
 {
   intD.3 rD.4078;
   intD.3 cD.4077;
+  intD.3 _3;
+  unsigned intD.6 s.1_6;
+  unsigned intD.6 _7;
+  intD.3 * _9;
+  _BoolD.1375 _12;
+  _BoolD.1375 _13;
+  _BoolD.1375 _14;
+  _BoolD.1375 _16;
+  _BoolD.1375 _18;

 ;;   basic block 2, loop depth 0, count 0, freq 1, maybe hot
-;;prev block 0, next block 1, flags: (NEW, REACHABLE)
+;;prev block 0, next block 7, flags: (NEW, REACHABLE)
 ;;pred:   ENTRY [100.0%]  (FALLTHRU,EXECUTABLE)
+;;   starting at line 6
+  [Os.c : 6:13] if (s_4(D) != 0)
+goto ;
+  else
+goto ;
+;;succ:   3 [50.0%]  (TRUE_VALUE,EXECUTABLE)
+;;7 [50.0%]  (FALSE_VALUE,EXECUTABLE)
+
+;;   basic block 7, loop depth 0, count 0, freq 5000, maybe hot
+;;prev block 2, next block 3, flags: (NEW)
+;;pred:   2 [50.0%]  (FALSE_VALUE,EXECUTABLE)
+;; 
+  goto ;
+;;succ:   4 [100.0%]  (FALLTHRU)
+
+;;   basic block 3, loop depth 0, count 0, freq 5000, maybe hot
+;;prev block 7, next block 4, flags: (NEW, REACHABLE)
+;;pred:   2 [50.0%]  (TRUE_VALUE,EXECUTABLE)
+;;   starting at line 6, discriminator 1
+  [Os.c : 6:22] # RANGE [1, 4294967295]
+  s.1_6 = (unsigned intD.6) s_4(D);
+  [Os.c : 6:22] # RANGE [0, 4294967295] NONZERO 0x0fffc
+  _7 = s.1_6 * 4;
+  [Os.c : 6:22] # PT = nonlocal 
+  _9 = a_8(D) + _7;
+  [Os.c : 6:19] # VUSE <.MEM_10(D)>
+  c_11 = [Os.c : 6] *_9;
+  [Os.c : 6:13] # RANGE [0, 1]
+  _16 = c_11 != 0;
+  [Os.c : 6:13] # RANGE [0, 1] NONZERO 0x1
+  r_19 = (intD.3) _16;
+;;succ:   4 [100.0%]  (FALLTHRU,EXECUTABLE)
+
+;;   basic block 4, loop depth 0, count 0, freq 1, maybe hot
+;;prev block 3, next block 8, flags: (NEW, REACHABLE)
+;;pred:   7 [100.0%]  (FALLTHRU)
+;;3 [100.0%]  (FALLTHRU,EXECUTABLE)
+;;   starting at line 8, discriminator 6
+  # c_1 = PHI 
+  # RANGE [0, 1] NONZERO 0x1
+  # r_2 = PHI <[Os.c : 6:13] 0(7), [Os.c : 6:13] r_19(3)>
+  [Os.c : 8:8] # RANGE [0, 1]
+  _12 = s_4(D) == 2;
+  [Os.c : 8:18] # RANGE [0, 1]
+  _13 = c_1 == 0;
+  [Os.c : 8:13] # RANGE [0, 1]
+  _14 = _13 & _12;
+  [Os.c : 9:12] # RANGE [0, 1]
+  _18 = s_4(D) != 0;
+  [Os.c : 9:12] if (_14 < _18)
+goto ;
+  else
+goto ;
+;;succ:   5 [39.0%]  (TRUE_VALUE,EXECUTABLE)
+;;8 [61.0%]  (FALSE_VALUE,EXECUTABLE)
+
+;;   basic block 8, loop depth 0, count 0, freq 6100, maybe hot
+;;prev block 4, next block 5, flags: (NEW)
+;;pred:   4 [61.0%]  (FALSE_VALUE,EXECUTABLE)
+;; 
+  goto ;
+;;succ:   6 [100.0%]  (FALLTHRU)
+
+;;   basic block 5, loop depth 0, count 0, freq 3900, maybe hot
+;;prev block 8, next block 6, flags: (NEW)
+;;pred:   4 [39.0%]  (TRUE_VALUE,EXECUTABLE)
+;; 
+;;succ:   6 [100.0%]  (FALLTHRU,EXECUTABLE)
+
+;;   basic block 6, loop depth 0, count 0, freq 1, maybe hot
+;;prev block 5, next block 1, flags: (NEW, REACHABLE)
+;;pred:   5 [100.0%]  (FALLTHRU,EXECUTABLE)
+;;8 [100.0%]  (FALLTHRU)
 ;;   starting at line -1
+  # RANGE [0, 1] NONZERO 0x1
+  # _3 = PHI <[Os.c : 10:3] 0(5), [Os.c : 13:2] r_2(8)>
   # VUSE <.MEM_10(D)>
-  return 0;
+  return _3;
 ;;succ:   EXIT [100.0%] 

 }

[Bug middle-end/63237] [5 Regression] error: invalid operand in unary operation

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-09-12
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug middle-end/63237] [5 Regression] error: invalid operand in unary operation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug pch/63229] [5.0 Regression] FAIL: ./except-1.h -O0 (internal compiler error)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug middle-end/63220] error: inlining failed in call to always_inline

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to davidxl from comment #2)
> (In reply to Richard Biener from comment #1)
> > First of all you should mark the functions 'inline' as well.
> 
> This does not help.
> 
>   Then the issue
> > is that 'eq' is called indirectly which isn't allowed for always_inline
> > functions:
> 
> 
> Is this documented somewhere? A function can be called indirectly and
> directly. What is the right way to force inlining the direct calls?
> 
> A warning is already emitted about always_inline might not be inlinable, why
> the error?

@item always_inline
@cindex @code{always_inline} function attribute
Generally, functions are not inlined unless optimization is specified.
For functions declared inline, this attribute inlines the function
independent of any restrictions that otherwise apply to inlining.
Failure to inline such a function is diagnosed as an error.
Note that if such a function is called indirectly the compiler may
or may not inline it depending on optimization level and a failure
to inline an indirect call may or may not be diagnosed.

always_inline is _not_ an optimization hint!  always_inline was meant
to mark functions that won't work correctly if not inlined.

There is no way to "force" only inlining of direct calls.

> > 
> > t.C:81:66: error: inlining failed in call to always_inline 'static constexpr
> > bool std::__1::char_traits::eq(std::__1::char_traits::char_type,
> > std::__1::char_traits::char_type)': indirect function call with a yet
> > undetermined callee
> >__attribute__ (( __always_inline__)) static constexpr bool
> > eq(char_type __c1, char_type __c2)  {
> >   ^
> > t.C:75:37: error: called from here
> >  if (!__pred(*__m1, *__m2)) { } 
> >  ^
> > 
> > which means this is a missed-optimization only.  The error is your fault.
> > 
> > Note that getting the error is unreliable so -O0 simply doesn't discover the
> > failed inlining.
> 
> -O2 works fine -- I have not debugged the problem -- but it seems to be some
> newly cloned cgraph edge to be in inconsistent state.
> 
> David

[Bug go/63172] gccgo testcase cplx2.go execution provides incorrect answers on trunk for powerpc64, powerpc64le

[vogt at linux dot vnet.ibm.com]

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

--- Comment #4 from Dominik Vogt  ---
On s390x, the option -fcx-limited-range "fixes" the deviation in the C test
program (tried with -O0 and -O3), but it has no effect for the Go test program.

[Bug debug/56974] c++ ref qualifiers not represented in DWARF

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-09-12
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

--- Comment #4 from Marek Polacek  ---
Confirmed.

[Bug debug/63238] New: DWARF does not represent _Alignas

[mpolacek at gcc dot gnu.org]

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

Bug ID: 63238
   Summary: DWARF does not represent _Alignas
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org

C11 has the _Alignas specifier, but it isn't emitted
in DWARF.

The proposal is here:
https://www.mail-archive.com/dwarf-discuss@lists.dwarfstd.org/msg00159.html

[Bug tree-optimization/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #8 from Eric Botcazou  ---
>> I think that's easiest for Eric to say.
>
> Not really, I guess you want to debug the function and replay the computation
> since the cost is synthetized and doesn't come directly from the back-end.

I've found what's going on:

* In expmed.c (init_expmed_one_mode), l.194

  set_shiftadd_cost (speed, mode, m, set_src_cost (all->shift_add, speed));

  with all->shift_add something like

(plus:QI (mult:QI (reg:QI 109 [0])
(const_int 8 [0x8]))
(reg:QI 109 [0]))

* For the mult part, rtx_code calls sparc_rtx_cost, which has

case MULT:
  if (float_mode_p)
*total = sparc_costs->float_mul;
  else if (! TARGET_HARD_MUL)
*total = COSTS_N_INSNS (25);

  On SPARCv9/-m64, TARGET_HARD_MUL is false, so we get the 25*4 = 100 part,
  unlike v8, which explains why the test only fails for 64-bit.

Rainer

[Bug debug/63239] New: DWARF does not represent C++ deleted methods

[mpolacek at gcc dot gnu.org]

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

Bug ID: 63239
   Summary: DWARF does not represent C++ deleted methods
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org

C++11 has implicitly deleted functions.  These are declared with the = delete
specifier, and their usage in the program is forbidden.

struct A
{ 
  int i;
  A() = delete;
};
A a = { 42 };

However, it seems that currently the deleted functions are emitted like any
other.

[Bug middle-end/63237] [5 Regression] error: invalid operand in unary operation

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Fri Sep 12 11:06:49 2014
New Revision: 215212

URL: https://gcc.gnu.org/viewcvs?rev=215212&root=gcc&view=rev
Log:
2014-09-12  Richard Biener  

PR middle-end/63237
* gimple-fold.c (get_maxval_strlen): Gimplify string length.

* g++.dg/torture/pr63237.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr63237.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/63237] [5 Regression] error: invalid operand in unary operation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug debug/63240] New: DWARF does not represent C++ defaulted methods

[mpolacek at gcc dot gnu.org]

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

Bug ID: 63240
   Summary: DWARF does not represent C++ defaulted methods
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org

Similarly to PR63239, DWARF does not seem to represent C++ defaulted methods.

struct A
{ 
  int i;
  A() = default;
};

Not sure whether that is really an issue, might be just an implementation
detail.

[Bug debug/16063] Debuggers need more information about enum types in C++

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #9 from Marek Polacek  ---
So, is this fixed?

[Bug libstdc++/59603] std::random_shuffle tries to swap element with itself

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Jörg Richter from comment #2)
> Seems like we have hit this bug too.  It happens not only in debug mode.  We
> have a testcase that triggers valgrind errors in non-debug mode while
> calling random_shuffle.  I can try to reduce this testcase if it would help.

Would you be able to provide such a test? self-move in non-debug mode should
not cause valgrind errors, it should just cause the vector to be left empty (so
the valgrind errors might come later if you assume the vector still contains
data and try to access it).

[Bug debug/16063] Debuggers need more information about enum types in C++

[mark at gcc dot gnu.org]

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

Mark Wielaard  changed:

   What|Removed |Added

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

--- Comment #10 from Mark Wielaard  ---
(In reply to Marek Polacek from comment #9)
> So, is this fixed?

Yes, I do believe so, in gcc trunk. Sorry for not closing earlier.

[Bug c++/63241] New: Internal error in gimplify_init_constructor when using constexr and multidimensional arrays

[thibaut.lutz at googlemail dot com]

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

Bug ID: 63241
   Summary: Internal error in gimplify_init_constructor when using
constexr and multidimensional arrays
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thibaut.lutz at googlemail dot com

I stumbled upon a weird regression bug. The test case below is working fine
with GCC 4.8 and 4.9.0 but triggers an internal error on 4.9.1. I haven't
tested 4.9.2.

Any of these modifications would remove the error:
- removing `constexpr` from the constructor at line 2
- using `0` instead of `i` in the second array element constructor at line 8
- using `const int i` instead of `int i` at line 6
- using a 1D array instead of a 2D array at line 7
So I believe the example below cannot be reduced further.

However somehow the combination of `constexpr` constructor and multidimensional
array is causing the compiler to crash.

Details:

* GCC version: 4.9.1 built with default config

* System: x86_64 GNU/Linux

* Command line: c++ -std=c++11 bug.cpp

* Minimal example:

struct A {
  constexpr A(int){}
};

int main() {
  int i = 1;
  A array[2][2] =
{{{0}, {i}},
 {{0}, {0}}};
}


* Output:
>>>
bug.cpp: In function ‘int main()’:
bug.cpp:9:16: internal compiler error: in gimplify_init_constructor, at
gimplify.c:4007
  {{0}, {0}}};
^
0x7f6213 gimplify_init_constructor
../.././gcc/gimplify.c:4007
0x7f6dee gimplify_modify_expr_rhs
../.././gcc/gimplify.c:4167
0x7f6ec4 gimplify_modify_expr
../.././gcc/gimplify.c:4486
0x7f7dda gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../.././gcc/gimplify.c:7627
0x7facd6 gimplify_stmt(tree_node**, gimple_statement_base**)
../.././gcc/gimplify.c:5373
0x7f806a gimplify_cleanup_point_expr
../.././gcc/gimplify.c:5149
0x7f806a gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../.././gcc/gimplify.c:7990
0x7facd6 gimplify_stmt(tree_node**, gimple_statement_base**)
../.././gcc/gimplify.c:5373
0x7f8d3b gimplify_statement_list
../.././gcc/gimplify.c:1432
0x7f8d3b gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../.././gcc/gimplify.c:8042
0x7facd6 gimplify_stmt(tree_node**, gimple_statement_base**)
../.././gcc/gimplify.c:5373
0x7f806a gimplify_cleanup_point_expr
../.././gcc/gimplify.c:5149
0x7f806a gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../.././gcc/gimplify.c:7990
0x7facd6 gimplify_stmt(tree_node**, gimple_statement_base**)
../.././gcc/gimplify.c:5373
0x7f8d3b gimplify_statement_list
../.././gcc/gimplify.c:1432
0x7f8d3b gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../.././gcc/gimplify.c:8042
0x7facd6 gimplify_stmt(tree_node**, gimple_statement_base**)
../.././gcc/gimplify.c:5373
0x7fb56b gimplify_bind_expr
../.././gcc/gimplify.c:1099
0x7f7fc0 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../.././gcc/gimplify.c:7824
0x7facd6 gimplify_stmt(tree_node**, gimple_statement_base**)
../.././gcc/gimplify.c:5373
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
<<

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|tree-optimization   |target
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org

--- Comment #10 from Eric Botcazou  ---
> * For the mult part, rtx_code calls sparc_rtx_cost, which has
> 
> case MULT:
>   if (float_mode_p)
>   *total = sparc_costs->float_mul;
>   else if (! TARGET_HARD_MUL)
>   *total = COSTS_N_INSNS (25);
> 
>   On SPARCv9/-m64, TARGET_HARD_MUL is false, so we get the 25*4 = 100 part,
>   unlike v8, which explains why the test only fails for 64-bit.

Ugh, thanks for spotting it, this looks like an annoying oversight.

[Bug lto/63242] New: memory starvation caused by flatten attribute

[wbrana at gmail dot com]

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

Bug ID: 63242
   Summary: memory starvation caused by flatten attribute
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wbrana at gmail dot com

forwarded from https://bugs.freedesktop.org/show_bug.cgi?id=77580

Hello,
I've been testing GCC 4.9 for a virtual gentoo machine and I noticed that
you us flatten attribute in source code. In case of src/sna/sna_glyphs.c
flatten functions, inliner inlines about 3.3M functions and crashes because of
no free memory (I have 8GB memory).

Please notice that LTO has ability to optimize whole program. As a result, it
sees almost all function bodies and that leads to enormous inlining.

Suggested patch removes these flatten attributes for selected functions.

Thank you,
MArtin

[Bug libstdc++/59603] std::random_shuffle tries to swap element with itself

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Author: redi
Date: Fri Sep 12 13:30:35 2014
New Revision: 215219

URL: https://gcc.gnu.org/viewcvs?rev=215219&root=gcc&view=rev
Log:
PR libstdc++/59603
* include/bits/stl_algo.h (random_shuffle): Prevent self-swapping.
* testsuite/25_algorithms/random_shuffle/59603.cc: New.

Added:
trunk/libstdc++-v3/testsuite/25_algorithms/random_shuffle/59603.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_algo.h

[Bug libstdc++/59603] std::random_shuffle tries to swap element with itself

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug debug/63243] New: [meta-bug] RH GDB project tracker

[mpolacek at gcc dot gnu.org]

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

Bug ID: 63243
   Summary: [meta-bug] RH GDB project tracker
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org

This bug tracks various GCC bugs that are blocking or hindering GDB progress.

gcc-bugs@gcc.gnu.org

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-09-12
  Component|c   |middle-end
 Blocks||24639
Summary|False Positive for  |false positive for
   |-Wmaybe-uninitialized at|-Wmaybe-uninitialized at
   |-Os, not -O2|-Os (not -O2) with &&
   ||transformed to &
 Ever confirmed|0   |1

--- Comment #9 from Manuel López-Ibáñez  ---
(In reply to Manuel López-Ibáñez from comment #6)
> I think this is PR56574, but we need to check the dumps to be sure. The dump
> should be something like: test.c.NNNt.uninit1, you can get it with
> -fdump-tree-all-all-lineno.

According to this:

+  [Os.c : 8:8] # RANGE [0, 1]
+  _12 = s_4(D) == 2;
+  [Os.c : 8:18] # RANGE [0, 1]
+  _13 = c_1 == 0;
+  [Os.c : 8:13] # RANGE [0, 1]
+  _14 = _13 & _12;

the same bug is involved, but this one is a bit more complicated because it is
not clear that the uninit pass realizes that the c_5(D)(7) edge is guarded by
s==0, so in that case _12==0 and c_1 doesn't matter.

[Bug tree-optimization/56654] uninit warning behaves erratically

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-09-12
 Ever confirmed|0   |1

--- Comment #3 from Manuel López-Ibáñez  ---
Anyway, it is at least one bug, perhaps more.

[Bug c++/59500] Bogus maybe-uninitialized warning due to optimizations

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
Could you remove the stdbool.h header (just use char or int, it should not
change the bug)? Also could you compile with -fdump-tree-all-all-lineno and
paste/attach the dump file that looks similar to test.c.XXXt.uninitX? It should
show clearly whether it is a duplicate or a different issue.

[Bug middle-end/57832] compiling sha-256 code (xz 5.0.5) generates false warnings when using -march=native on Atom CPU

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to Olivier Langlois from comment #1)
> Created attachment 30466 [details]
> original c file
> 
> very macro heavy loop unrolling sha-256 code hand optimized code (I have
> peaked into the resulting intermediate code, yuck!) but the code seems ok:

If you want someone to look at this code, you need to reduce it further:
https://gcc.gnu.org/bugs/minimize.html

You can also check what the uninit pass is doing by using
-fdump-tree-all-all-lineno, which will create a test.c.XXXt,uninitX file.

[Bug debug/63239] DWARF does not represent C++ deleted methods

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Perhaps we need some DWARF extension for this?

[Bug middle-end/62084] [avr] ICE: in convert_debug_memory_address

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||addr-space,
   ||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-09-12
 CC||law at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Georg-Johann Lay  ---
CC'ing Jeff as he also fixed PR52472...

ICE with Jörg's code for 4.9.2and 5.0 (from 2014-09-12 SVN 215212)

[Bug c++/63201] Full specialization of a member variable template of a class template does not work

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Fri Sep 12 14:39:25 2014
New Revision: 215226

URL: https://gcc.gnu.org/viewcvs?rev=215226&root=gcc&view=rev
Log:
PR c++/63201
* decl.c (start_decl): Handle specialization of member variable
template.
* pt.c (check_explicit_specialization): Adjust error.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ11.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/g++.old-deja/g++.robertl/eb103.C

[Bug lto/63226] ICE with -flto-odr-type-merging

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  ---
Created attachment 33478
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33478&action=edit
Second test file pair (1/2): one37.ii

 namespace std {
   template struct unary_function 
   {
   };
 }
   namespace mpl_ {
 }
   namespace mpl_ {
 template< bool C_ > struct bool_ {
  };
template< typename T, T N > struct integral_c;
}
   namespace boost {
namespace mpl {
   using ::mpl_::integral_c;
   }
}
   namespace mpl_ {
 template< typename T, T N > struct integral_c {
  static const T value = N;
  };
 }
   namespace boost{
 template  struct integral_constant : public
mpl::integral_c {
   };
 namespace detail {
  template  struct cv_traits_imp {
typedef T unqualified_type;
};
  };
 template< typename T > struct is_void :
::boost::integral_constant {
   };
 template< typename T > struct is_integral :
::boost::integral_constant {
   };
 namespace type_traits {
  template  struct is_mem_fun_pointer_impl {
  static const bool value = false;
  };
  }
 template< typename T > struct remove_cv {
  typedef typename boost::detail::cv_traits_imp::unqualified_type type;
  };
 template< typename T > struct is_member_function_pointer :
::boost::integral_constant::type>::value> {
   };
 template< typename T > struct is_member_pointer :
::boost::integral_constant::value>
{
   };
 namespace type_traits {
  template  struct ice_and;
  template 
struct ice_and {
static const bool value = false;
};
  template  struct ice_not {
  static const bool value = true;
  };
  }
 namespace detail {
  template< typename T > struct is_pointer_helper {
  static const bool value = false;
  };
  template< typename T > struct is_pointer_impl {
  static const bool value = (::boost::type_traits::ice_and<
::boost::detail::is_pointer_helper::type>::value ,
::boost::type_traits::ice_not< ::boost::is_member_pointer::value >::value
>::value)  ;
  };
  }
 template< typename T > struct is_pointer :
::boost::integral_constant::value> {
   };
 namespace mpl {
  template<   bool C , typename T1 , typename T2 > struct
if_c {
};
  template<   typename T1 , typename T2 > struct
if_c {
typedef T2 type;
};
  }
   templatestruct enable_if_c {
  typedef T type;
};
   template class function;
   namespace detail {
  namespace function {
  union function_buffer   {   mutable void (*func_ptr)();  
  };
  struct function_ptr_tag {  };
  template   class get_function_tag   {  
typedef typename mpl::if_c<(is_pointer::value), 
  function_ptr_tag,   
function_ptr_tag>::type ptr_or_obj_tag; public: typedef
ptr_or_obj_tag type; };
  template   struct functor_manager   {  
  public: static inline void manage(const function_buffer&
in_buffer, function_buffer& out_buffer) {  } };
  struct vtable_base   {   void (*manager)(const
function_buffer& in_buffer, function_buffer&
out_buffer); };
}
}
 class function_base {
  };
   namespace detail {
  namespace function {
  template< typename FunctionObj, typename R ,
typename T0   >   struct function_obj_invoker1   {   static
R invoke(function_buffer& function_obj_ptr , T0 a0)
{   } };
  template< typename FunctionObj, typename R ,
typename T0   >   struct void_function_obj_invoker1   { };
  template< typename FunctionObj, typename R ,
typename T0>   struct get_function_obj_invoker1   {  
typedef typename mpl::if_c<(is_void::value),
void_function_obj_invoker1< FunctionObj,   
 R , T0  
>,   function_obj_invoker1<
FunctionObj, R , T0
  >>::type type; };
  template   struct get_invoker1 {  
template  
  struct apply { typedef typename
get_function_obj_invoker1<  FunctionObj,   
  R ,  T0 

[Bug lto/63226] ICE with -flto-odr-type-merging

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus  ---
Created attachment 33479
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33479&action=edit
Second test file pair (1/2): two22.ii

[Bug middle-end/61848] [5 Regression] a previous declaration causes the section attribute to be lost

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #10 from Alan Modra  ---
Created attachment 33480
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33480&action=edit
A different approach to fixing this bug

I was playing with this one today, before I found your bugzilla Andrew.  It has
been regression tested on x86_64, fixes the loss of section attributes, and
builds a 3.16 x86_64 defconfig kernel - haven't checked if it boots yet..

Adds a fix for C++ which has the same problem as C.  (The s/olddecl/newdecl/
lines are because "if (TREE_CODE (newdecl) == FUNCTION_DECL) ... else switch
(TREE_CODE (olddecl))" looks horrible.  Cosmetic really since we exit the
function before this code if TREE_CODE (newdecl) != TREE_CODE (olddecl).)

[Bug c++/63201] Full specialization of a member variable template of a class template does not work

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC|jason at redhat dot com|jason at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|--- |5.0

--- Comment #3 from Jason Merrill  ---
Fixed.

[Bug lto/63226] ICE with -flto-odr-type-merging

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #5)
> Created attachment 33478 [details]
> Second test file pair (1/2): one37.ii

Mixed up the fields ... That should have been the attachment - and the
attachment should have been the comment.

Still, if you take the code of comment 5 together with attachment 33479, one
can still reproduce it.

Here what I actually wanted to write (and is in the attachment):


(In reply to Jan Hubicka from comment #4)
> this is patch I am testing.  It fixes few issues in the ODR comparsions code
> and seems to handle this testcase sanely.

Thanks. Works for the two files (also for the two files of the big program).
However, the big program (as a whole) still fails with the ICE:
internal compiler error: in odr_types_equivalent_p, at ipa-devirt.c:1125

g++ -O0 -w -c -std=c++11 -flto one37.ii two22.ii; g++ -flto one37.o two22.o

[Bug lto/63242] memory starvation caused by flatten attribute

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-09-12
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
It would nice if you attach a testcase which uses large amount of memory.

[Bug lto/63242] memory starvation caused by flatten attribute

[wbrana at gmail dot com]

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

--- Comment #2 from wbrana  ---
How I can create such testcase?

I can reproduce it on Gentoo by adding -flto to /etc/portage/make.conf
and running: emerge xf86-video-intel
but can't reproduce from command-line
gcc  -std=gnu99 -O3 -shared -fPIC -flto sna_glyphs.i -o test.so

[Bug rtl-optimization/62265] [4.8/4.9/5 regression] FAIL: gcc.dg/20111227-2.c scan-rtl-dump ree "Elimination opportunities = 3 realized = 3"

[tejohnson at google dot com]

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

Teresa Johnson  changed:

   What|Removed |Added

 CC||tejohnson at google dot com

--- Comment #3 from Teresa Johnson  ---
I believe this was fixed by the following commit:

r214848 | uros | 2014-09-03 00:58:17 -0700 (Wed, 03 Sep 2014) | 4 lines
Changed paths:
   M /trunk/gcc/testsuite/ChangeLog
   M /trunk/gcc/testsuite/gcc.dg/20111227-2.c
   M /trunk/gcc/testsuite/gcc.dg/20111227-3.c

* gcc.dg/20111227-2.c: Compile only for x86 targets.
* gcc.dg/20111227-3.c: Ditto.

[Bug debug/63243] [meta-bug] RH GDB project tracker

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-09-12
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
Confirmed so it doesn't show up in the list of unconfirmed bugs.

[Bug fortran/63205] [OOP] Wrongly rejects type = class (for identical declared type)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-09-12
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
I see two issues with the test assign_11.f90:

(1) an ICE, reduced test

program test
  implicit none
  type t
integer :: ii
  end type t
  type(t) :: y(3)

  y = func2()
contains
  function func2() result(res)
class(t), allocatable :: res(:)
  end function func2
end program test

[Book15] f90/bug% gfc49 pr63205_red.f90
pr63205_red.f90: In function 'test':
pr63205_red.f90:8:0: internal compiler error: in gfc_trans_arrayfunc_assign, at
fortran/trans-expr.c:7369
   y = func2()
 ^

(2) a wrong code, reduced test

module m
  implicit none
  type t
integer :: ii = 55
  end type t
contains
  subroutine sub (from, from2)
class(t) :: from, from2(:)
type(t) :: to, to2(3)

if (from%ii /= 43) call abort()
if (size (from2) /= 3) call abort()
if (any (from2(:)%ii /= [11,22,33])) call abort()

to = from  ! TYPE = CLASS
to2 = from2  ! TYPE = CLASS

print *, to%ii
!if (to%ii /= 43) call abort()
if (any (to2(:)%ii /= [11,22,33])) call abort()
  end subroutine sub
end module m

program test
  use m
  implicit none
  type(t), target :: x
  type(t), target :: y(3)

  x%ii = 43
  y(:)%ii = [11,22,33]
  call sub(x,y)
  x = func1()
  print *, x
!  if (x%ii /= 123) call abort()
  y = func1()
  print *, y
!  if (any (y(:)%ii /= 123)) call abort()
contains
  function func1()
class(t), allocatable :: func1
allocate(func1)
func1%ii = 123
  end function func1
end program test

[Book15] f90/bug% gfc49 pr63205_red_1.f90
[Book15] f90/bug% a.out 
   167182484
   586153984
   586154000   586154000   586154000

Any objection that I open a new PR for the ICE?

> However, only "type => class" is handled. Still missing is "type = class",
> where CLASS is a (coarray) scalar or (coarray) array variable, function or
> an array constructor. See also PR 57530 comment 3.

AFAICT the assignment works for array variable, at least in the to2 context.

[Bug c++/63244] New: x86_64-pc-linux-gnu-g++: internal compiler error: Segmentation fault (program cc1plus)

[nheghathivhistha at gmail dot com]

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

Bug ID: 63244
   Summary: x86_64-pc-linux-gnu-g++: internal compiler error:
Segmentation fault (program cc1plus)
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nheghathivhistha at gmail dot com

Created attachment 33481
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33481&action=edit
Preprocessed un-reduced file

Part of media-libs/mesa-10.2.7 Gentoo package segfaults cc1plus:
x86_64-pc-linux-gnu-g++ -m32 -DPACKAGE_NAME=\"Mesa\" -DPACKAGE_TARNAME=\"mesa\"
-DPACKAGE_VERSION=\"10.2.7\" "-DPACKAGE_STRING=\"Mesa 10.2.7\""
"-DPACKAGE_BUGREPORT=\"https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\"";
-DPACKAGE_URL=\"\" -DPACKAGE=\"mesa\" -DVERSION=\"10.2.7\" -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\"
-DHAVE___BUILTIN_BSWAP32=1 -DHAVE___BUILTIN_BSWAP64=1 -DHAVE_DLADDR=1
-DHAVE_CLOCK_GETTIME=1 -DHAVE_PTHREAD=1 -I. -DHAVE_PIPE_LOADER_XLIB
-DHAVE_PIPE_LOADER_DRI -DHAVE_PIPE_LOADER_DRM
-DPIPE_SEARCH_DIR=\"/usr/lib32/gallium-pipe\" -I../../../../include
-I../../../../src/gallium/include -I../../../../src/gallium/drivers
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/winsys -I.
-std=c++11 -fvisibility=hidden -flto=4 -fuse-linker-plugin -O2 -ggdb -pipe
-march=core2 -mtune=core2 -mno-3dnow -mno-sse4.2 -mno-avx -mno-xop -mno-fma4
-mno-sse4a -Wall -fno-strict-aliasing -fno-builtin-memcmp -c core/context.cpp 
-fPIC -DPIC -o core/.libs/libclover_la-context.o -save-temps
x86_64-pc-linux-gnu-g++: warning: -pipe ignored because -save-temps specified
x86_64-pc-linux-gnu-g++: internal compiler error: Segmentation fault (program
cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

When LTO is not enabled it not happens. It crashes the same way in 64 bit mode.

[Bug c++/63244] x86_64-pc-linux-gnu-g++: internal compiler error: Segmentation fault (program cc1plus)

[nheghathivhistha at gmail dot com]

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

--- Comment #1 from David Kredba  ---
gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.2-alpha20140911/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.2-alpha20140911/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.9.2_alpha20140911/work/gcc-4.9-20140911/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.2-alpha20140911
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2-alpha20140911/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.2-alpha20140911
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.2-alpha20140911/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.2-alpha20140911/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2-alpha20140911/include/g++-v4
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.9.2-alpha20140911/python
--enable-languages=c,c++,go,objc,obj-c++,fortran,ada --enable-obsolete
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.9.2_alpha20140911' --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --disable-altivec --disable-fixed-point
--enable-targets=all --enable-libgomp --enable-lto --with-cloog
--disable-isl-version-check
Thread model: posix
gcc version 4.9.2-alpha20140911 20140912 (prerelease) [gcc-4_9-branch revision
215199] (Gentoo 4.9.2_alpha20140911)

[Bug c++/63244] x86_64-pc-linux-gnu-g++: internal compiler error: Segmentation fault (program cc1plus)

[nheghathivhistha at gmail dot com]

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

--- Comment #2 from David Kredba  ---
x86_64-pc-linux-gnu-g++ -m32 -std=c++11 -fvisibility=hidden -flto=4
-fuse-linker-plugin -O2 -ggdb -pipe -march=core2 -mtune=core2 -mno-3dnow
-mno-sse4.2 -mno-avx -mno-xop -mno-fma4 -mno-sse4a -Wall -fno-strict-aliasing
-fno-builtin-memcmp -c context.ii  -fPIC -DPIC -o context.o reproduces it from
my home folder.

[Bug sanitizer/63245] New: renderMemorySnippet shouldn't show more bytes than the underlying type

[hjl.tools at gmail dot com]

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

Bug ID: 63245
   Summary: renderMemorySnippet shouldn't show more bytes than the
underlying type
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

c-c++-common/ubsan/align-4.c fails at random for -m32 on Linux/x86:

/export/gnu/import/git/gcc/gcc/testsuite/c-c++-common/ubsan/align-2.c:37:11:
runtime error: load of misaligned address 0x08049ff1 for type 'long long int',
which requires 4 byte alignment
0x08049ff1: note: pointer points here
 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
Program received signal SIGSEGV, Segmentation fault.
0xf79f0e98 in renderMemorySnippet (Args=, 
NumRanges=, Ranges=, Loc=, 
Decor=...)
at /export/gnu/import/git/gcc/libsanitizer/ubsan/ubsan_diag.cc:208
208Printf("%s%02x", (P % 8 == 0) ? "  " : " ", C);
(gdb) 

The program has

08048000-08049000 r-xp  08:11 39853233  
/export/build/gnu/gcc-x32-mx32/build-x86_64-linux/gcc/testsuite/g++/align-4.exe
08049000-0804a000 rw-p  08:11 39853233  
/export/build/gnu/gcc-x32-mx32/build-x86_64-linux/gcc/testsuite/g++/align-4.exe

There is a long long int at 0x08049ff1.  But renderMemorySnippet tries
to show 32 bytes even though long long int only has 8 bytes.

[Bug middle-end/61654] [4.9/5 Regression] ICE in release_function_body, at cgraph.c:1699

[jamborm at gcc dot gnu.org]

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

--- Comment #14 from Martin Jambor  ---
Author: jamborm
Date: Fri Sep 12 16:52:24 2014
New Revision: 215228

URL: https://gcc.gnu.org/viewcvs?rev=215228&root=gcc&view=rev
Log:
2014-09-12  Martin Jambor  

PR ipa/61654
* cgraph.h (cgraph_analyze_function): Declare.
* cgraphunit.c: (analyze_function): Remove forward declaration,
rename to cgraph_analyze_function, made external.
* cgraphclones.c (duplicate_thunk_for_node): Copy arguments of the
new decl properly.  Analyze the new thunk if it is expanded.

gcc/testsuite/
* g++.dg/ipa/pr61654.C: New test.


Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ipa/pr61654.C
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/cgraph.h
branches/gcc-4_9-branch/gcc/cgraphclones.c
branches/gcc-4_9-branch/gcc/cgraphunit.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug middle-end/61654] [4.9/5 Regression] ICE in release_function_body, at cgraph.c:1699

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #15 from Martin Jambor  ---
Fixed.

[Bug c++/63244] x86_64-pc-linux-gnu-g++: internal compiler error: Segmentation fault (program cc1plus)

[nheghathivhistha at gmail dot com]

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

--- Comment #3 from David Kredba  ---
C-Reduce in progress.

[Bug target/61142] [SH] QImode/HImode @(R0,Rm),Rn does not load to Rn = R0

[olegendo at gcc dot gnu.org]

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

--- Comment #2 from Oleg Endo  ---
I've tried the above test case with LRA on (sh-lra branch, not fully working
yet) and it produces the following code:

mov r5,r0
mov.b   @(r0,r4),r0
cmp/eq  #92,r0
bt  .L3
mov r7,r0
rts
nop
.align 1
.L3:
rts
mov r6,r0

i.e. the problem is gone.

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

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.7.3, 5.0
   Last reconfirmed||2014-09-12
  Component|c++ |middle-end
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|x86_64-pc-linux-gnu-g++:|[4.9 regression] internal
   |internal compiler error:|compiler error:
   |Segmentation fault (program |Segmentation fault (program
   |cc1plus)|cc1plus)
   Target Milestone|--- |4.9.3
  Known to fail||4.9.2

--- Comment #4 from Markus Trippelsdorf  ---
markus@x4 tmp % cat context.ii
namespace std {
template 
void declval();
class A;
}
namespace detail {
template 
class iterator_adaptor;
template 
class basic_range;
template 
using preferred_iterator_type = decltype(std::declval);
}
template 
class adaptor_range
: detail::basic_range<
  adaptor_range,
  detail::iterator_adaptor...>,
  detail::iterator_adaptor...>> {};
template 
using property_list = std::A;
class B {
  B(const property_list& p1, const adaptor_range& p2);
};
B::B(const ::property_list& p1, const adaptor_range& p2) {}

markus@x4 tmp % gdb --args g++ -std=c++11 -c context.ii
Reading symbols from g++...done.
(gdb) run
Starting program: /usr/bin/g++ -std=c++11 -c context.ii
process 30304 is executing new program:
/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.2/g++
[New process 30308]
process 30308 is executing new program:
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.2/cc1plus

Program received signal SIGSEGV, Segmentation fault.
[Switching to process 30308]
0x00c2ffd6 in analyze_functions() ()
(gdb) bt
#0  0x00c2ffd6 in analyze_functions() ()
#1  0x00c2ed95 in finalize_compilation_unit() ()
#2  0x00d2a2d4 in cp_write_global_declarations() ()
#3  0x00c29020 in compile_file() [clone .lto_priv.2474] ()
#4  0x00b6ccd7 in toplev_main(int, char**) ()
#5  0x77741fd0 in __libc_start_main () from /lib/libc.so.6
#6  0x00b66a93 in _start ()
(gdb)

[Bug middle-end/63246] New: OpenMP target: gimplifier produces unsuitable implicit map clauses if inside a data region

[tschwinge at gcc dot gnu.org]

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

Bug ID: 63246
   Summary: OpenMP target: gimplifier produces unsuitable implicit
map clauses if inside a data region
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org

Consider:

int
main(int argc, char **argv)
{
#define N 4
short a[N];

#pragma omp target data map(a[1:N-1])
{
#pragma omp target
  {
a[1] = 51;
  }
}

return 0;
}

..., which results in the following gimple:

[...]
  #pragma omp target data map(tofrom:a[1] [len: 6]) map(alloc:a
[pointer assign, bias: 2])
{
  try
{
  {
#pragma omp target map(tofrom:a [len: 8])
  {
{
  a[1] = 51;
[...]

The outer data region sets up an expicit mapping for a subset of the array, and
the inner target construct then again gets an implicit map clause added for
*the whole* region.  A suitably equipped libgomp (for example, gomp-4_0-branch
with the non-shared memory host plugin) doesn't like this:

libgomp: Trying to map into device [0x7fff6f513410..0x7fff6f513418) object
when[0x7fff6f513412..0x7fff6f513418) is already mapped

[Bug bootstrap/63235] building fails with --disable-bootstrap

[andi-gcc at firstfloor dot org]

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

--- Comment #5 from Andi Kleen  ---
Created attachment 33482
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33482&action=edit
use ifdef instead of builtin_cpu_supports

This patch fixes the problem for me.

Just use an ifdef instead of builtin_cpu_supports.

[Bug fortran/63247] New: fortran array alignment in omp target map

[cesar at codesourcery dot com]

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

Bug ID: 63247
   Summary: fortran array alignment in omp target map
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cesar at codesourcery dot com

I've noticed that lower_omp_target is not passing the proper pointer alignment
to libgomp for fortran array maps. While this isn't a problem for trunk, it
does affect our nvptx target. Here is a test case:

program test
  implicit none

  integer a(5)

  a = 10;

  write (*, '(a,Z16)') 'address of a = ', loc(a)

  !$omp target map(a(1:5))  
  a(1) = 5
  a(2) = 5
  a(3) = 5
  a(4) = 5
  a(5) = 5
  !$omp end target  

end program test

Here's my gdb session:

Breakpoint 5, lower_omp_target (gsi_p=, ctx=) at
../../../gcc/gcc/omp-low.c:10191
10191CONSTRUCTOR_APPEND_ELT (vkind, purpose,
(gdb) p talign
$10 = 2
(gdb) p ovar
$11 = (tree) 
(gdb) pt
warning: Expression is not an assignment (and might have no effect)
 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x76303690
precision 32 min  max 
pointer_to_this >
type_2 BLK
size 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x7643e3f0
domain 
DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x7643e738
precision 64 min  max >
pointer_to_this >
addressable used decl_0 BLK file
/home/cphilipp/tools/nvidia/demos/fortran-tests/pointer-align-2.f90 line 4 col
0 size  unit size 
align 32 context >
(gdb) p talign
$12 = 2

How should this issue be resolved? I think the fortran FE behavior is correct.
Should lower_omp_target have something like this

if (tkind == OMP_CLAUSE_MAP_POINTER)
  talign = POINTER_SIZE / BITS_PER_UNIT;

or should libgomp correct the alignment for OMP_CLAUSE_MAP_POINTER? It should
be noted the C FE doesn't have this problem with arrays.

Thanks,
Cesar

[Bug target/50751] SH Target: Displacement addressing does not work for QImode and HImode

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Depends on||55212

--- Comment #36 from Oleg Endo  ---
(In reply to Oleg Endo from comment #35)
> (In reply to Oleg Endo from comment #34)
> > 
> Compiling with -Os -m4 -ml -matomic-model=soft-gusa, I get:
> 
> 
> Probably we really should try switching to LRA (PR 55212).

I've tried compiling the problematic test case with the sh-lra branch (LRA
enabled) and '-Os -m4 -ml -matomic-model=soft-gusa' and '-Os -m4 -mb
-matomic-model=soft-gusa'.  The problem seems to be gone for those parameters,
but when compiling for '-O2 -m4 -ml -matomic-model=soft-gusa' it crashes:

internal compiler error: in check_rtl, at lra.c:1928
 TEST_FUNCS (complex_float_add, _Complex float, , += 1, 0, 2)
 ^
0x8523d00 check_rtl
../../gcc-sh-lra/gcc/lra.c:1928
0x85273f7 lra(_IO_FILE*)
../../gcc-sh-lra/gcc/lra.c:2318
0x84e6823 do_reload
../../gcc-sh-lra/gcc/ira.c:5306
0x84e6823 execute
../../gcc-sh-lra/gcc/ira.c:5465

[Bug bootstrap/63235] building fails with --disable-bootstrap

[andi-gcc at firstfloor dot org]

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

--- Comment #6 from Andi Kleen  ---
Created attachment 33483
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33483&action=edit
Preprocessed file from the cilk runtime library

I'm not sure it'll help you because you would likely need a compiler
miscompiled in the same way as mine?

[Bug target/59400] [SH] gcc.c-torture/compile/pr55921.c fails with -O0 on big endian with FPU

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Depends on||55212

--- Comment #1 from Oleg Endo  ---
I've tried the problematic case with the sh-lra branch and the problem seems to
be gone.

[Bug c++/63248] New: Crash when OpenMP target's array section handling is used with templates

[tschwinge at gcc dot gnu.org]

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

Bug ID: 63248
   Summary: Crash when OpenMP target's array section handling is
used with templates
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org

Consider:

template 
void f(T A, T B)
{
  extern int *v;
  T a = 2;
  T b = 4;

#pragma omp target map(to: v[a:b])
  v[a] = 0;

#pragma omp target map(to: v[A:B])
  v[a] = 0;
}

void g()
{
  f(1, 5);
}

GCC doesn't like that template usage:

../../openacc/T.C: In function 'void f(T, T)':
../../openacc/T.C:8:35: internal compiler error: Segmentation fault
0xc1833f crash_signal
../../source/gcc/toplev.c:339
0x697f0d tree_class_check
../../source/gcc/tree.h:2851
0x697f0d cp_omp_mappable_type(tree_node*)
../../source/gcc/cp/decl2.c:1393
0x764777 finish_omp_clauses(tree_node*)
../../source/gcc/cp/semantics.c:5671
0x6d3d39 cp_parser_omp_all_clauses
../../source/gcc/cp/parser.c:28680
0x6c6265 cp_parser_omp_target
../../source/gcc/cp/parser.c:30649
[...]

Discussion in
.

[Bug c++/60894] [4.8/4.9/5 Regression] Use of redundant struct keyword in function prototype combined with using statement causes compilation error

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

  Known to fail|4.10.0  |5.0

--- Comment #8 from Jason Merrill  ---
(In reply to fabien from comment #6)
> I looked into it but did not manage to get it fixed. I will have another try
> this week. Thanks for the reminder.

Ping?

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

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
(gdb) bt
#0  analyze_functions () at ../../gcc/gcc/cgraphunit.c:1042
#1  0x006e03f0 in finalize_compilation_unit () at
../../gcc/gcc/cgraphunit.c:2326
#2  0x00594dd4 in cp_write_global_declarations () at
../../gcc/gcc/cp/decl2.c:4643
#3  0x00951a4d in compile_file () at ../../gcc/gcc/toplev.c:562
#4  0x00953620 in do_compile () at ../../gcc/gcc/toplev.c:1917
#5  toplev_main (argc=15, argv=0x7fffdfb8) at ../../gcc/gcc/toplev.c:1993
#6  0x775fcfd0 in __libc_start_main () from /lib/libc.so.6
#7  0x0052cf61 in _start ()
(gdb) l
1037  will be later needed to output debug info.  */
1038  if (DECL_ABSTRACT_ORIGIN (decl))
1039{
1040  struct cgraph_node *origin_node
1041  = cgraph_get_node (DECL_ABSTRACT_ORIGIN (decl));
1042  origin_node->used_as_abstract_origin = true;
1043}
1044}
1045  else
1046{

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

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Target Milestone|4.9.3   |4.9.2

[Bug target/34777] uClibc-0.9.29 compilation error for sh4 arch with gcc-4.x

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Depends on||55212

--- Comment #12 from Oleg Endo  ---
(In reply to Oleg Endo from comment #11)
> 
> seems to fix the test case of PR 34807.  However, I've not tested it any
> further and probably the fix is incomplete and works only for mem loads and
> not stores.
> In fact it can be broken again quite easily by inserting another insn that
> requires R0 (tst #imm,r0 in this case):
> 
> int glob, glob1;
> 
> static int _dl_mmap (int xx)
>  {
>register int __sc0 __asm__ ("r0") = glob1;
>register int __sc1 __asm__ ("r1") = glob;
> 
>if (xx & 3)
>  __asm__  ("trapa %1 " : "=z" (__sc0) : "i" (0x10), "0" (__sc0), "r"
> (__sc1));
> 
>return (__sc0);
>  }
>  
>  void _start(int xx)
>  {
>static int buf;
>buf = _dl_mmap(xx);
>  }

I've tried that test case with the sh-lra branch and the problems seem to be
gone.

[Bug c++/63249] New: [OpenMP] Spurious »set but not used« warnings when actually used in OpenMP target's array section's lower-bound and length

[tschwinge at gcc dot gnu.org]

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

Bug ID: 63249
   Summary: [OpenMP] Spurious »set but not used« warnings when
actually used in OpenMP target's array section's
lower-bound and length
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Depends on: 63248

This is similar to what has previously been addressed in
,
:

int f(int A, int B)
{
  int r = 0;
  extern int *v;
  int a = 2;
  int b = 4;
  int n = 3;

  v[n] = 0;

#pragma omp target map(to: v[a:b])
  r |= v[n];

#pragma omp target map(to: v[A:B])
  r |= v[n];

  return r;
}

../../openacc/w.c: In function 'f':
../../openacc/w.c:6:7: warning: variable 'b' set but not used
[-Wunused-but-set-variable]
   int b = 4;
   ^
../../openacc/w.c:5:7: warning: variable 'a' set but not used
[-Wunused-but-set-variable]
   int a = 2;
   ^
../../openacc/w.c:1:11: warning: parameter 'A' set but not used
[-Wunused-but-set-parameter]
 int f(int A, int B)
   ^
../../openacc/w.c:1:18: warning: parameter 'B' set but not used
[-Wunused-but-set-parameter]
 int f(int A, int B)
  ^
Patch (for C) submitted in
,
C++ blocked on PR63248.

[Bug bootstrap/63235] building fails with --disable-bootstrap

[trippels at gcc dot gnu.org]

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

--- Comment #7 from Markus Trippelsdorf  ---
(In reply to Andi Kleen from comment #6)
> Created attachment 33483 [details]
> Preprocessed file from the cilk runtime library
> 
> I'm not sure it'll help you because you would likely need a compiler
> miscompiled in the same way as mine?

There were surly a number of wrong-code bugs fixed between 
your version 4.8.1 20130909 and the 4.8.3 release.

I cannot reproduce the issue with 4.8.3.

[Bug fortran/63247] fortran array alignment in omp target map

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||openmp
 CC||tschwinge at gcc dot gnu.org
Version|unknown |5.0

--- Comment #1 from Thomas Schwinge  ---
Actually, here is a C test case that exhibits the problem on x86 (which has a
flag to switch on alignment checking), with OpenMP using the non-shared memory
host plugin.  Need to build with -O, as otherwise there will be other alignment
errors.  This is probably too fragile for any test suite usage, though.

#include 

int
main(int argc, char **argv)
{
#define N 4
short a[N];

a[0] = 10;
a[1] = 10;
a[2] = 10;
a[3] = 10;

#pragma omp target map(a[1:N-1])
{
__asm__("pushf\norl $(1<<18),(%rsp)\npopf");
a[1] = 51;
a[2] = 52;
a[3] = 53;
__asm__("pushf\nandl $(~(1<<18)),(%rsp)\npopf");
}

if (a[0] != 10)
  abort ();
if (a[1] != 51)
  abort ();
if (a[2] != 52)
  abort ();
if (a[3] != 53)
  abort ();

return 0;
}

$ gdb -q ./a.out 
Reading symbols from ./a.out...done.
(gdb) r
Starting program: [...]/a.out 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGBUS, Bus error.
0x0040080e in main._omp_fn.0 (.omp_data_i=0x6020c0) at
source-gcc/libgomp/testsuite/libgomp.c/pointer-align-1.c:19
19  a[1] = 51;
(gdb) disassemble 
Dump of assembler code for function main._omp_fn.0:
   0x00400801 <+0>: pushfq 
   0x00400802 <+1>: orl$0x4,(%rsp)
   0x00400809 <+8>: popfq  
   0x0040080a <+9>: mov0x8(%rdi),%rax
=> 0x0040080e <+13>:mov(%rax),%rax
   0x00400811 <+16>:movw   $0x33,0x2(%rax)
   0x00400817 <+22>:mov0x8(%rdi),%rax
   0x0040081b <+26>:mov(%rax),%rax
   0x0040081e <+29>:movw   $0x34,0x4(%rax)
   0x00400824 <+35>:mov0x8(%rdi),%rax
   0x00400828 <+39>:mov(%rax),%rax
   0x0040082b <+42>:movw   $0x35,0x6(%rax)
   0x00400831 <+48>:pushfq 
   0x00400832 <+49>:andl   $0xfffb,(%rsp)
   0x00400839 <+56>:popfq  
   0x0040083a <+57>:retq   
End of assembler dump.
(gdb) info registers rax
rax0x6020d6 6299862

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

[nheghathivhistha at gmail dot com]

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

--- Comment #6 from David Kredba  ---
For the record only, git version of c-reduce returned

namespace std {
template  struct less;
template  struct add_rvalue_reference;
template  typename add_rvalue_reference<_Tp>::type declval();
template  struct __add_rvalue_reference_helper {
  typedef _Tp type;
};
template 
struct add_rvalue_reference : __add_rvalue_reference_helper<_Tp> {};
}
typedef int intptr_t;
namespace std {
template  class allocator;
template  > class vector {};
}

typedef intptr_t cl_context_properties;
namespace clover {
class device;
}
namespace std {
template  > class map;
}
namespace clover {
template  class intrusive_ref;
struct derefs;
namespace detail {
template  class iterator_adaptor;
template  class basic_range {
public:
  template  operator V() const {}
};
template  using preferred_iterator_type =
decltype(std::declval);
}
template 
class adaptor_range : public detail::basic_range<
  adaptor_range, detail::iterator_adaptor,
  detail::iterator_adaptor<
  F, detail::preferred_iterator_type...> > {};
template 
class ref_vector : public adaptor_range > {};
template  class property_element;
template  using property_list = std::map >;
class context {
  typedef clover::property_list property_list;
  context(const property_list &, const ref_vector &);
  std::vector > devs;
};
}

using namespace clover;
context::context(const property_list &, const ref_vector &devs)
: devs(devs) {}

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

[trippels at gcc dot gnu.org]

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

--- Comment #7 from Markus Trippelsdorf  ---
When one uses a naive test script one arrives at the testcase
from comment 4. Using a differential script (-O2 vs. -flto -O2 -g)
one gets:

markus@x4 /tmp % cat context2.ii
namespace std {
template 
_Tp declval();
}
class A {};
namespace std {
template 
using __allocator_base = A;
template 
class H : __allocator_base {};
template >
class I {};
}

template 
class D;
struct F;
namespace detail {
template 
class iterator_adaptor;
template 
class basic_range {
 public:
  template 
  using store_traits = int;
  template 
  operator V() const {}
};
template 
using preferred_iterator_type = decltype(std::declval);
}

template 
class adaptor_range
: public detail::basic_range<
  adaptor_range,
  detail::iterator_adaptor...>,
  detail::iterator_adaptor<
  F, detail::preferred_iterator_type...>> {};
class J : public adaptor_range> {};
template 
using property_list = int;
class G {
  G(const property_list &props, const J &);
  std::I> devs;
};
G::G(const property_list &props, const J &devs) : devs(devs) {}

markus@x4 /tmp % g++ -std=c++11 -flto -O2 -g -c context2.ii
g++: internal compiler error: Segmentation fault (program cc1plus)
0x40c96c execute
../../gcc/gcc/gcc.c:2855
0x40cd34 do_spec_1
../../gcc/gcc/gcc.c:4659
0x40f5f6 process_brace_body
../../gcc/gcc/gcc.c:5942
0x40f5f6 handle_braces
../../gcc/gcc/gcc.c:5856
0x40dba9 do_spec_1
../../gcc/gcc/gcc.c:5313
0x40f5f6 process_brace_body
../../gcc/gcc/gcc.c:5942
0x40f5f6 handle_braces
../../gcc/gcc/gcc.c:5856
0x40dba9 do_spec_1
../../gcc/gcc/gcc.c:5313
0x40d913 do_spec_1
../../gcc/gcc/gcc.c:5428
0x40f5f6 process_brace_body
../../gcc/gcc/gcc.c:5942
0x40f5f6 handle_braces
../../gcc/gcc/gcc.c:5856
0x40dba9 do_spec_1
../../gcc/gcc/gcc.c:5313
0x40f5f6 process_brace_body
../../gcc/gcc/gcc.c:5942
0x40f5f6 handle_braces
../../gcc/gcc/gcc.c:5856
0x40dba9 do_spec_1
../../gcc/gcc/gcc.c:5313
0x40f5f6 process_brace_body
../../gcc/gcc/gcc.c:5942
0x40f5f6 handle_braces
../../gcc/gcc/gcc.c:5856
0x40dba9 do_spec_1
../../gcc/gcc/gcc.c:5313
0x40f5f6 process_brace_body
../../gcc/gcc/gcc.c:5942
0x40f5f6 handle_braces
../../gcc/gcc/gcc.c:5856
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Looks like a stack overflow.

(-g and -flto alone are fine)
markus@x4 /tmp % g++ -std=c++11 -O2 -g -c context2.ii
markus@x4 /tmp % g++ -std=c++11 -flto -O2 -c context2.ii
markus@x4 /tmp %

[Bug c++/59500] Bogus maybe-uninitialized warning due to optimizations

[luto at mit dot edu]

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

--- Comment #3 from Andy Lutomirski  ---
Created attachment 33484
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33484&action=edit
Headerless reproducer (c++ only)

[Bug c++/59500] Bogus maybe-uninitialized warning due to optimizations

[luto at mit dot edu]

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

--- Comment #4 from Andy Lutomirski  ---
Created attachment 33485
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33485&action=edit
Output from g++ -O2 -Wall -fdump-tree-all-all-lineno pr59500.cc

[Bug middle-end/63246] OpenMP target: gimplifier produces unsuitable implicit map clauses if inside a data region

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
IMNSHO this is just a buggy testcase, whether something is present in map
clauses on target data region matters only for the actual allocations, but not
for what map clauses are explicit or implicit on the target region.  I've
already earlier today commented on the IMHO invalid textcase from OpenMP 4.0.1
examples 56.3[cf] in the ticket discussing bugs in the Examples document.
If you don't want the implicit map(a) clause, you should provide the
map(a[1:N-1]) there (which will not map anything, because it is already mapped,
but will DTRT wrt. pointer translation).

[Bug libstdc++/61909] Small function optimization not applied to small objects

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-09-12
 Ever confirmed|0   |1

--- Comment #6 from Jonathan Wakely  ---
The right fix requires std::is_trivially_copyable, so fixing this properly this
will have to wait until someone implements that.

[Bug libstdc++/54316] [C++11] move constructor for stringstream

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug libstdc++/56193] ios_base should replace operator void* with explicit operator bool in C++11 onwards.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug c++/62052] function parameter has wrong address in lambda converted to pointer-to-function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-09-12
 Ever confirmed|0   |1
  Known to fail|4.10.0  |5.0

[Bug bootstrap/63235] building fails with --disable-bootstrap

[andi-gcc at firstfloor dot org]

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

--- Comment #8 from Andi Kleen  ---
Yes it doesn't happen when compiling with 4.8 branch tip. So has been fixed.

Anyways i'm still going to submit the patch to make the opensuse 13.1 build
work again. I don't think it should hurt anything here to use ifdef.

[Bug bootstrap/63235] building fails with --disable-bootstrap

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  ---
(In reply to Andi Kleen from comment #8)
> Yes it doesn't happen when compiling with 4.8 branch tip. So has been fixed.
> 
> Anyways i'm still going to submit the patch to make the opensuse 13.1 build
> work again. I don't think it should hurt anything here to use ifdef.

The difference is run-time check vs compile-time check.

[Bug bootstrap/63235] building fails with --disable-bootstrap

[andi-gcc at firstfloor dot org]

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

--- Comment #10 from Andi Kleen  ---
Ok fair enough.

Can do the runtime check in the else of the ifdef then.

Then at least x86_64 or 32bit with SSE would work.

[Bug target/63250] New: Complex fp16 arithmetic uses nonexistent libgcc functions

[jsm28 at gcc dot gnu.org]

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

Bug ID: 63250
   Summary: Complex fp16 arithmetic uses nonexistent libgcc
functions
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
Target: arm*-*-*

If on ARM you declare complex __fp16 values using __attribute__((mode(HC)))
(because you can't use _Complex __fp16 directly, the ARM analogue of bug
32187), this is accepted, but multiplication and division of those values
produces references to libgcc functions __mulhc3 and __divhc3 that don't exist.
 E.g., compiled with -O2 -mfp16-format=ieee:

typedef _Complex float fp16c __attribute__((mode(HC)));
fp16c a, b;
fp16c f (void) { return a * b; }

Just as __fp16 values are promoted to float for arithmetic, so should complex
fp16 values probably be promoted to complex float.  (Were TS 18661-3
implemented, there would be various differences from the existing __fp16 and
__float128 support in GCC, but there would still be no need for HCmode
operations as distinct from promoting to SCmode then converting results back to
HCmode at some point, whether you define FLT_EVAL_METHOD to 32, which would be
the closest equivalent to the existing promotion, or treat the promotion as an
implementation detail and truncate after every operation.)

[Bug c++/59500] Bogus maybe-uninitialized (|| converted to nested-if)

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-09-12
 Blocks||24639
Summary|Bogus maybe-uninitialized   |Bogus maybe-uninitialized
   |warning due to  |(|| converted to nested-if)
   |optimizations   |
 Ever confirmed|0   |1

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to Andy Lutomirski from comment #1)
> This might be a duplicate of PR56574

I think not. In this case the problem is that

# value = PHI
if (!valid || intval() < value)

is converted to

# value = PHI 
if(!valid)
else if (intval() < value)

and I think the uninit pass is not smart enough to realize that the use is
guarded by valid != 0 but the default definition implies valid == 0.

Perhaps it is also a missed-optimization, since "if(cond())" could jump
directly to "if (intval() < value)".

[Bug sanitizer/63251] New: tsan: corrupted shadow stack

[dvyukov at google dot com]

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

Bug ID: 63251
   Summary: tsan: corrupted shadow stack
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dvyukov at google dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

Created attachment 33486
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33486&action=edit
reproducer

Reported in the ThreadSanitizer bug tracker, but it looks like gcc
instrumentation issue:
https://code.google.com/p/thread-sanitizer/issues/detail?id=76

gcc version 5.0.0 20140830 (experimental) (GCC)

$ g++ -fsanitize=thread /tmp/stack.cc -pie -fPIE -g
$ ./a.out 
==
WARNING: ThreadSanitizer: data race (pid=27898)
...
  Thread T2 (tid=27901, running) created by main thread at:
#0 pthread_create ../../.././libsanitizer/tsan/tsan_interceptors.cc:853
(libtsan.so.0+0x00026eb4)
#1 main /tmp/stack.cc:28 (a.out+0x1017)
#2 void std::__introsort_loop<__gnu_cxx::__normal_iterator > >, long,
__gnu_cxx::__ops::_Iter_less_iter>(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, long,
__gnu_cxx::__ops::_Iter_less_iter)
/ssd/src/gcc_trunk/install/include/c++/5.0.0/bits/stl_algo.h:1952
(a.out+0x1d60)
#3 void std::__sort<__gnu_cxx::__normal_iterator > >,
__gnu_cxx::__ops::_Iter_less_iter>(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, __gnu_cxx::__ops::_Iter_less_iter)
/ssd/src/gcc_trunk/install/include/c++/5.0.0/bits/stl_algo.h:1967
(a.out+0x182c)
#4 void std::sort<__gnu_cxx::__normal_iterator > > >(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >)
/ssd/src/gcc_trunk/install/include/c++/5.0.0/bits/stl_algo.h:4676
(a.out+0x130a)
#5 main /tmp/stack.cc:24 (a.out+0x0fd9)


Frames #1-4 are bogus and must not be present in the thread creation stack.

Clang produces a correct stack, which is:
  Thread T2 (tid=12121, running) created by main thread at:
#0 pthread_create
/ssd/src/llvm/build/../projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:847
(a.out+0x00048403)
#1 main /tmp/stack.cc:28:3 (a.out+0x00095bcf)


Looking at the symptoms I think that the sort-related functions do not call
__tsan_func_exit and so they are left on the shadow stack.

It's not only about report quality. If it happens enough times, then it will
overflow and blow up tsan shadow stack.

[Bug fortran/63252] New: [5 Regression] tree_class_check_failed

[hjl.tools at gmail dot com]

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

Bug ID: 63252
   Summary: [5 Regression] tree_class_check_failed
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: bur...@net-b.de

On Linux/x32, r213979 caused

[hjl@gnu-mic-2 gcc]$ ./xgcc -B./ 
/export/gnu/import/git/gcc/gcc/testsuite/gfortran.dg/coarray_32.f90 
-fcoarray=lib -S   
f951: internal compiler error: Segmentation fault
0xa5499f crash_signal
/export/gnu/import/git/gcc/gcc/toplev.c:337
0xca11be tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/export/gnu/import/git/gcc/gcc/tree.c:9203
0xca56d0 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/export/gnu/import/git/gcc/gcc/tree.h:2852
0xca56d0 type_hash_list
/export/gnu/import/git/gcc/gcc/tree.c:6639
0xca5acd build_function_type(tree_node*, tree_node*)
/export/gnu/import/git/gcc/gcc/tree.c:7994
0x60b989 build_library_function_decl_1
/export/gnu/import/git/gcc/gcc/fortran/trans-decl.c:2784
0x60bc8f gfc_build_library_function_decl_with_spec(tree_node*, char const*,
tree_node*, int, ...)
/export/gnu/import/git/gcc/gcc/fortran/trans-decl.c:2835
0x60d9e6 gfc_build_builtin_function_decls()
/export/gnu/import/git/gcc/gcc/fortran/trans-decl.c:3422
0x5e4377 gfc_create_decls
/export/gnu/import/git/gcc/gcc/fortran/f95-lang.c:196
0x5e4377 gfc_be_parse_file
/export/gnu/import/git/gcc/gcc/fortran/f95-lang.c:211
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[hjl@gnu-mic-2 gcc]$ 

for stage2 and stage3 f951.

[Bug bootstrap/63253] New: boot strap failure due to ODR warnings

[andi-gcc at firstfloor dot org]

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

Bug ID: 63253
   Summary: boot strap failure due to ODR warnings
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andi-gcc at firstfloor dot org

I suppose it's Honza's commit

commit b99d67c130c18dc99bc123dcf3fb9b06784892db
Author: gccadmin 
Date:   Fri Sep 12 00:16:51 2014 +

Daily bump.

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

commit d585ba22a6b4250b0d819d3d7da72f7dd37e2981
Author: hubicka 
Date:   Thu Sep 11 23:16:42 2014 +


../../gcc/gcc/tlink.c:62:16: error: type 'struct file_hash_entry' violates one
definition rule [-Werror=odr]
 typedef struct file_hash_entry
^
../../gcc/libcpp/files.c:143:8: note: a different type is defined in another
translation unit
 struct file_hash_entry
^
../../gcc/gcc/tlink.c:64:15: note: the first difference of corresponding
definitions is field 'key'
   const char *key;
   ^
../../gcc/libcpp/files.c:145:27: note: a field with different name is defined
in another translation unit
   struct file_hash_entry *next;
   ^
lto1: all warnings being treated as errors

[Bug bootstrap/63253] boot strap failure due to ODR warnings

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/ml/gcc/2014-09/msg00161.html

[Bug middle-end/61848] [5 Regression] a previous declaration causes the section attribute to be lost

[amodra at gmail dot com]

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

--- Comment #11 from Alan Modra  ---
It boots
Linux version 3.17.0-rc4-00222-gc73f6fd-dirty (anton@tul181p1) (gcc version
5.0.0 20140912 (experimental) (GCC) ) #23 SMP Fri Sep 12 21:19:06 UTC 2014

[Bug c++/63254] New: elfos.h missing space between literal and identifier.

[scott.clark at itron dot com]

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

Bug ID: 63254
   Summary: elfos.h missing space between literal and identifier.
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: scott.clark at itron dot com

Created attachment 33487
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33487&action=edit
Zip file of the output (which shows the command line) and .ii file.

On lines 102 and 170 of elfos.h, the compiler throws the following warning:

invalid suffix on literal; C++11 requires a space between literal and
identifier [-Wliteral-suffix]

[Bug middle-end/61848] [5 Regression] a previous declaration causes the section attribute to be lost

[amodra at gmail dot com]

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

--- Comment #12 from Alan Modra  ---
extern char foo;
char foo __attribute__ ((__section__(".machine.desc")));
char foo __attribute__ ((__section__(".mymachine.desc")));

It looks like we should take out the DECL_SECTION_NAME (olddecl) == NULL
checks.
The above gives no diagnostic with older compilers, and results in section
.mymachine.desc being used.  trunk+patch results in section .machine.desc.

[Bug c++/63254] elfos.h missing space between literal and identifier.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-09-13
 Ever confirmed|0   |1

[Bug fortran/63252] [5 Regression] tree_class_check_failed

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  ---
Patch:

--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -3423,3 +3423,3 @@ gfc_build_builtin_function_decls (void)
get_identifier (PREFIX("caf_unlock")), "R..WW",
-   void_type_node, 7, pvoid_type_node, size_type_node, integer_type_node,
+   void_type_node, 6, pvoid_type_node, size_type_node, integer_type_node,
pint_type, pchar_type_node, integer_type_node);