[Bug rtl-optimization/64688] [4.9 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
  Known to work||5.0
 Resolution|FIXED   |---
Summary|[4.9/5 Regression] internal |[4.9 Regression] internal
   |compiler error: Max. number |compiler error: Max. number
   |of generated reload insns   |of generated reload insns
   |per insn is achieved (90)   |per insn is achieved (90)
  Known to fail|5.0 |

--- Comment #16 from Jakub Jelinek  ---
Sure.  On the other side, RA changes are better backported with some delay, so
that they get more testing on the trunk.

[Bug rtl-optimization/64882] [5 Regression] ICE on valid code at -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5681

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-31
 CC||aoliva at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
   Target Milestone|--- |5.0
Summary|ICE on valid code at -O3|[5 Regression] ICE on valid
   |with -g enabled in  |code at -O3 with -g enabled
   |simplify_subreg, at |in simplify_subreg, at
   |simplify-rtx.c:5681 |simplify-rtx.c:5681
 Ever confirmed|0   |1

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

[Bug rtl-optimization/64882] [5 Regression] ICE on valid code at -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5681

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||uros at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I'd say the bug is either in postreload or in the backend.  At *.reload we
have:
(insn 32 197 59 3 (parallel [
(set (reg/v:DI 0 ax [orig:87 f ] [87])
(plus:DI (reg:DI 0 ax [106])
(reg:DI 1 dx [orig:104 D.1912 ] [104])))
(clobber (reg:CC 17 flags))
]) pr64882.c:13 221 {*adddi_1}
 (expr_list:REG_EQUAL (plus:DI (reg:DI 1 dx [orig:104 D.1912 ] [104])
(const_int 5278350700 [0x13a9d3d6c]))
(nil)))
...
(insn 60 59 61 3 (set (reg:SI 2 cx [orig:103 D.1909 ] [103])
(reg:SI 0 ax [orig:87 f ] [87])) pr64882.c:27 90 {*movsi_internal}
 (nil))

but in postreload

(insn 60 59 61 3 (set (reg:SI 2 cx [orig:103 D.1909 ] [103])
(plus:DI (reg:DI 0 ax [106])
(reg:DI 1 dx [orig:104 D.1912 ] [104]))) pr64882.c:27 213 {*leasi}
 (nil))

which is IMNSHO invalid RTL, because SET_DEST has different mode from SET_SRC.
But leasi pattern has the same modes in there:
(define_insn_and_split "*lea"
  [(set (match_operand:SWI48 0 "register_operand" "=r")
(match_operand:SWI48 1 "address_no_seg_operand" "Ts"))]
so either recog didn't check the modes, or postreload failed to validize this
instruction.

[Bug rtl-optimization/64882] [5 Regression] ICE on valid code at -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5681

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
And the problem seems to be that the mode argument to address_no_seg_operand
predicate is completely ignored.

The big question is where to fix this.
I've tried changing ix86_legitimate_address_p, but that ICEs pretty much
everywhere, on the other side doing it just in address_no_seg_operand might be
sufficient for this exact testcase, but what about others? 
config/i386/predicates.md has tons of predicates that check "address_operand"
and do something on top of that.

--- gcc/recog.c.jj2015-01-15 20:25:30.0 +0100
+++ gcc/recog.c2015-01-31 11:33:28.546090770 +0100
@@ -1122,6 +1122,8 @@ general_operand (rtx op, machine_mode mo
 int
 address_operand (rtx op, machine_mode mode)
 {
+  if (GET_MODE (op) != mode && mode != VOIDmode && GET_MODE (op) != VOIDmode)
+return 0;
   return memory_address_p (mode, op);
 }

seems to fix this testcase, can try to bootstrap/regtest that, but as it is a
generic change, there is a risk of breaking many other ports.

So, any thoughts on this?  Or should it be postreload's duty to verify that
modes match?

[Bug rtl-optimization/64882] [5 Regression] ICE on valid code at -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5681

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #3)
> And the problem seems to be that the mode argument to address_no_seg_operand
> predicate is completely ignored.
> 
> The big question is where to fix this.
> I've tried changing ix86_legitimate_address_p, but that ICEs pretty much
> everywhere, on the other side doing it just in address_no_seg_operand might
> be sufficient for this exact testcase, but what about others? 
> config/i386/predicates.md has tons of predicates that check
> "address_operand" and do something on top of that.
> 
> --- gcc/recog.c.jj2015-01-15 20:25:30.0 +0100
> +++ gcc/recog.c   2015-01-31 11:33:28.546090770 +0100
> @@ -1122,6 +1122,8 @@ general_operand (rtx op, machine_mode mo
>  int
>  address_operand (rtx op, machine_mode mode)
>  {
> +  if (GET_MODE (op) != mode && mode != VOIDmode && GET_MODE (op) !=
> VOIDmode)
> +return 0;
>return memory_address_p (mode, op);
>  }
>  
> seems to fix this testcase, can try to bootstrap/regtest that, but as it is
> a generic change, there is a risk of breaking many other ports.
> 
> So, any thoughts on this?  Or should it be postreload's duty to verify that
> modes match?

Ah, doing it in ix86_legitimate_address_p is of course wrong, since the mode
passed in that case isn't the desired mode of the address, but the mode of the
MEM containing the address.  But IMHO the mode passed to address_operand is the
mode of the address, rather than the mode of the MEM.

[Bug rtl-optimization/64882] [5 Regression] ICE on valid code at -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5681

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
This is target problem, address_no_seg_operand should check the mode for all
non-CONST_INT_P operands (please see the comment above the predicate).

So, we have to narrow the condition to:

--cut here--
Index: config/i386/predicates.md
===
--- config/i386/predicates.md   (revision 220302)
+++ config/i386/predicates.md   (working copy)
@@ -971,6 +971,11 @@
   struct ix86_address parts;
   int ok;

+  if (!CONST_INT_P (op)
+  && mode != VOIDmode
+  && GET_MODE (op) != mode)
+return false;
+
   ok = ix86_decompose_address (op, &parts);
   gcc_assert (ok);
   return parts.seg == SEG_DEFAULT;
--cut here--

[Bug target/64882] [5 Regression] ICE on valid code at -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5681

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|uros at gcc dot gnu.org|
  Component|rtl-optimization|target
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

--- Comment #6 from Uroš Bizjak  ---
Taking bug.

[Bug target/64882] [5 Regression] ICE on valid code at -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5681

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
But what about vsib_address_operand, address_mpx_no_base_operand,
address_mpx_no_index_operand?
Even address_operand is used directly:
  [(prefetch (match_operand:P 0 "address_operand" "p")
 (const_int 1)
 (const_int 2))]
The comment above address_operand is definitely confusing, because when it is
used directly in the *.md (various ports), then the mode of the address is
passed to it, the comment above address_operand is confusing:
"Return 1 if OP is a valid memory address for a memory reference of mode MODE."
and memory_address_p it calls wants address of the MEM, not the address.

[Bug target/64882] [5 Regression] ICE on valid code at -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5681

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
FYI, testcase tweaked to be 32-bit clean and still exhibit the issue with -m64:
--- gcc/testsuite/gcc.dg/pr64882.c.jj2015-01-31 11:40:35.492612235 +0100
+++ gcc/testsuite/gcc.dg/pr64882.c2015-01-31 11:40:20.0 +0100
@@ -0,0 +1,34 @@
+/* PR rtl-optimization/64882 */
+/* { dg-do compile } */
+/* { dg-options "-O3 -g" } */
+
+int a, d, e;
+long long b;
+static long long *c = &b;
+
+void
+fn1 (short p)
+{
+}
+
+long long
+fn2 (long long p1, long long p2)
+{
+  return (p1 && p1 > 26854775807LL - p2) || p1 < -p2 ? p1 : p1 + p2;
+}
+
+void
+fn3 ()
+{
+  long long f;
+  int g = 3;
+  int *h = &a;
+  for (e = 0; e < 2; e++)
+{
+  int *i = &g;
+  if (!fn2 (*c, 7 < d % (*i)--))
+f = fn2 ((*h <= 0) | b, 5278350700LL);
+  *h = f;
+  fn1 (*h);
+}
+}

[Bug target/64882] [5 Regression] ICE on valid code at -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5681

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #7)
> But what about vsib_address_operand, address_mpx_no_base_operand,
> address_mpx_no_index_operand?

These *do* check modes, the problematic predicate is defined as a special
predicate (AKA "define_special_predicate")

> Even address_operand is used directly:
>   [(prefetch (match_operand:P 0 "address_operand" "p")
>  (const_int 1)
>  (const_int 2))]

Hm... don't know the reason, but effectively address_operand is a special
predicate, too.

> The comment above address_operand is definitely confusing, because when it
> is used directly in the *.md (various ports), then the mode of the address
> is passed to it, the comment above address_operand is confusing:
> "Return 1 if OP is a valid memory address for a memory reference of mode
> MODE."
> and memory_address_p it calls wants address of the MEM, not the address.

FYI, testcase tweaked to be 32-bit clean and still exhibit the issue with -m64:

With the patch from Comment #5? It works for me with patched gcc (BTW: I think
this testcase should be put into torture directory).

[Bug c++/64791] Generic lambda fails to implicitly capture `const` variable

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  ---
Hi ville. With r220303 I don't see the warning, at any optimization level and
various combinations of other flags + -Wunused-but-set-variable of course. Can
you please double check / provide more information?

[Bug c++/64791] Generic lambda fails to implicitly capture `const` variable

[ville.voutilainen at gmail dot com]

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

--- Comment #6 from Ville Voutilainen  ---
I ran it with this thing:
http://melpon.org/wandbox/permlink/gAsh89NaSSFspYjq

[Bug libstdc++/61458] std::aligned_storage is bigger than expected

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  ---
Hi Jon. Frankly Are you 100% sure (in terms of middle-end/back-end details)
that the maximum alignment supported for a type of less than 4 bytes is 4? In
that case, your proposal of using  __aligned__((_Len)) certainly makes sense. I
wasn't sure at the time and picked a "safe" choice, probably should have
asked...

[Bug c++/64791] Generic lambda fails to implicitly capture `const` variable

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini  ---
I know that web page, but today, 20150131, I can't reproduce the issue with the
current tree on my machine.

[Bug target/64882] [5 Regression] ICE on valid code at -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5681

[ubizjak at gmail dot com]

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

--- Comment #10 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #7)
> But what about vsib_address_operand, address_mpx_no_base_operand,
> address_mpx_no_index_operand?

 (define_predicate "vsib_address_operand"
-  (match_operand 0 "address_operand")
+  (match_test "address_operand (op, VOIDmode)")

> Even address_operand is used directly:
>   [(prefetch (match_operand:P 0 "address_operand" "p")
>  (const_int 1)
>  (const_int 2))]

Ah, I see. Luckily, the mode is ignored in ix86_legitimate_address_p, so this
is more "cosmetic" issue.

I'm testing attached patch that solves all these issues and hopefully solves a
bunch of (harmless) thinkos.

[Bug target/64882] [5 Regression] ICE on valid code at -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5681

[ubizjak at gmail dot com]

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

--- Comment #11 from Uroš Bizjak  ---
Created attachment 34631
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34631&action=edit
Proposed patch

Patch in testing.

[Bug libstdc++/64883] New: FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[dominiq at lps dot ens.fr]

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

Bug ID: 64883
   Summary: FAIL: 17_intro/headers/c++*/all_attributes.cc (test
for excess errors) on x86_64-apple-darwin14
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: fxcoudert at gcc dot gnu.org, howarth at bromo dot 
med.uc.edu,
iains at gcc dot gnu.org, redi at gcc dot gnu.org
  Host: x86_64-apple-darwin14
Target: x86_64-apple-darwin14
 Build: x86_64-apple-darwin14

The tests 17_intro/headers/c++*/all_attributes.cc fail on x86_64-apple-darwin14

g++ -ffunction-sections -fdata-sections -DLOCALEDIR="." -nostdinc++
-I/opt/gcc/build_w/x86_64-apple-darwin14.1.0/i386/libstdc++-v3/include/x86_64-apple-darwin14.1.0
-I/opt/gcc/build_w/x86_64-apple-darwin14.1.0/i386/libstdc++-v3/include
-I/opt/gcc/work/libstdc++-v3/libsupc++
-I/opt/gcc/work/libstdc++-v3/testsuite/util
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc
-std=gnu++98 -S -m32
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:26:18:
error: expected ')' before numeric constant
 #define noreturn 1
  ^
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:26:18:
error: expected ')' before numeric constant
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:26:18:
error: expected ')' before numeric constant
 #define noreturn 1
  ^
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:26:18:
error: expected ')' before numeric constant
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:26:18:
error: expected ')' before numeric constant
 #define noreturn 1
  ^
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:26:18:
error: expected ')' before numeric constant
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:25:20:
error: expected ')' before numeric constant
 #define deprecated 1
^
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:25:20:
error: expected ')' before numeric constant
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:26:18:
error: expected ')' before numeric constant
 #define noreturn 1
  ^
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:26:18:
error: expected ')' before numeric constant
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:25:20:
error: expected ')' before numeric constant
 #define deprecated 1
^
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:25:20:
error: expected ')' before numeric constant
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:25:20:
error: expected ')' before numeric constant
 #define deprecated 1
^
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:25:20:
error: expected ')' before numeric constant
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:25:20:
error: expected ')' before numeric constant
 #define deprecated 1
^
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:25:20:
error: expected ')' before numeric constant
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:25:20:
error: expected ')' before numeric constant
 #define deprecated 1
^
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:25:20:
error: expected ')' before numeric constant
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:25:20:
error: expected ')' before numeric constant
 #define deprecated 1
^
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:25:20:
error: expected ')' before numeric constant
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:25:20:
error: expected ')' before numeric constant
 #define deprecated 1
^
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:25:20:
error: expected ')' before numeric constant
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:25:20:
error: expected ')' before numeric constant
 #define deprecated 1
^
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:25:20:
error: expected ')' before numeric constant
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:25:20:
erro

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  ---
Created attachment 34632
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34632&action=edit
compressed preprocessed file

See also https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg03581.html.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-31
 Ever confirmed|0   |1

[Bug testsuite/64775] FAIL: g++.dg/ipa/pr64612.C scan-assembler _ZN5QListI7QStringED1Ev on x86_64-apple-darwin14

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Dominique d'Humieres  ---
Fixed by r220198. Closing as FIXED.

[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||uros at gcc dot gnu.org

--- Comment #8 from Dominique d'Humieres  ---
The failures are gone after r220296. However I think the "fix" (skipping the
test on pic targets) does not answer

> So, it seems the r216154 patch introduces a performance degradation
> for -m32 -fpic for the fuse-caller-save example.

Any comment before closing the PR as FIXED?

[Bug testsuite/58321] FAIL: gcc.target/i386/memcpy-strategy-3.c scan-assembler-times memcpy 2 on x86_64-apple-darwin*

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
Still present at r220301 (see
https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg03581.html). Does the patch
in comment 2 makes sense or is there a better fix?

[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak  ---
(In reply to Dominique d'Humieres from comment #8)
> The failures are gone after r220296. However I think the "fix" (skipping the
> test on pic targets) does not answer
> 
> > So, it seems the r216154 patch introduces a performance degradation
> > for -m32 -fpic for the fuse-caller-save example.
> 
> Any comment before closing the PR as FIXED?

The test fails due to different and orthogonal issue: RA chooses %ebx for a
temporary when -fpic is used:

movl%eax, %ebx
callbar
addl%ebx, %eax

The push and pop insns are from prologue/epilogue since call-saved reg is used
(%ebx), not due to save/restore the reg around the call:

(note 3 4 19 2 NOTE_INSN_FUNCTION_BEG)
(insn/f:TI 19 3 20 2 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [0  S4 A8])
(reg:SI 3 bx)) fuse-caller-save.c:16 66 {*pushsi2}
 (expr_list:REG_DEAD (reg:SI 3 bx)
(nil)))
(note 20 19 2 2 NOTE_INSN_PROLOGUE_END)
...
(note 27 15 24 2 NOTE_INSN_EPILOGUE_BEG)
(insn/f:TI 24 27 25 2 (set (reg:SI 3 bx)
(mem:SI (post_inc:SI (reg/f:SI 7 sp)) [0  S4 A8]))
fuse-caller-save.c:18 74 {*popsi1}
 (expr_list:REG_CFA_ADJUST_CFA (set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int 4 [0x4])))
(expr_list:REG_CFA_RESTORE (reg:SI 3 bx)
(nil

So, please open a new PR due to RA issue: since %edx was allocated for PIC
register (but later removed), another call-used (%ecx) should be used here.

[Bug c++/64884] New: [5 Regression] FAIL: g++.dg/tm/pr47573.C -std=gnu++98 (test for excess errors) on x86_64-apple-darwin*

[dominiq at lps dot ens.fr]

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

Bug ID: 64884
   Summary: [5 Regression] FAIL: g++.dg/tm/pr47573.C  -std=gnu++98
(test for excess errors) on x86_64-apple-darwin*
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: fxcoudert at gcc dot gnu.org, howarth at bromo dot 
med.uc.edu,
hubicka at gcc dot gnu.org, iains at gcc dot gnu.org
  Host: x86_64-apple-darwin*
Target: x86_64-apple-darwin*
 Build: x86_64-apple-darwin*

The test g++.dg/tm/pr47573.C has started to fail on x86_64-apple-darwin*
between revisions r218633 (OK) and r218641 (fail), likely r218640. The error is

/opt/gcc/work/gcc/testsuite/g++.dg/tm/pr47573.C:17:39: error: unsafe function
call 'allocator<_Tp>::allocator() [with _Tp = char]' within 'transaction_safe'
function

[Bug c++/64884] [5 Regression] FAIL: g++.dg/tm/pr47573.C -std=gnu++98 (test for excess errors) on x86_64-apple-darwin*

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-31
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
See https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg03581.html.

[Bug target/64159] [5 Regression] FAIL: gcc.dg/tree-ssa/ssa-dom-cse-2.c scan-tree-dump optimized "return 28;"

[dje at gcc dot gnu.org]

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

--- Comment #5 from David Edelsohn  ---
Author: dje
Date: Sat Jan 31 14:57:43 2015
New Revision: 220305

URL: https://gcc.gnu.org/viewcvs?rev=220305&root=gcc&view=rev
Log:
PR target/64159
* gcc.dg/tree-ssa/ssa-dom-cse-2.c: Add XFAIL for powerpc*-*-* and
sparc*-*-*.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-2.c

[Bug target/64882] [5 Regression] ICE on valid code at -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5681

[uros at gcc dot gnu.org]

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

--- Comment #12 from uros at gcc dot gnu.org ---
Author: uros
Date: Sat Jan 31 15:30:30 2015
New Revision: 220306

URL: https://gcc.gnu.org/viewcvs?rev=220306&root=gcc&view=rev
Log:
2015-01-31  Uros Bizjak  

PR target/64882
* config/i386/predicates.md (address_no_seg_operand): Reject
non-CONST_INT_P operands in invalid mode.

2015-01-31  Uros Bizjak  

* config/i386/i386.md (*prefetch_prefetchw1): Remove mode of
address_operand 0.  Rename from *prefetch_prefetchwt1_.
* config/i386/predicates.md (address_no_seg_operand): Call
address_operand with VOIDmode.
(vsib_address_operand): Ditto.
(address_mpx_no_base_operand): Ditto.
(address_mpx_no_index_operand): Ditto.

testsuite/ChangeLog:

2015-01-31  Uros Bizjak  

PR target/64882
* gcc.dg/torture/pr64882.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/torture/pr64882.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/predicates.md
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/64885] New: libstdc++ all_attributes failure

[dje at gcc dot gnu.org]

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

Bug ID: 64885
   Summary: libstdc++ all_attributes failure
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org

The new all_attributes.cc libstdc++ testcases produce numerous excess errors on
AIX

/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:29:16:
error: expected ')' before numeric constant
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:29:16:
error: expected ')' before numeric constant
/tmp/20150130/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/powerpc-ibm-aix7.1.0.0/bits/gthr-single.h:222:1:
error: expected ',' or '...' before 'static'
/tmp/20150130/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/powerpc-ibm-aix7.1.0.0/bits/gthr.h:151:27:
error: expected ')' before end of line
/tmp/20150130/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/powerpc-ibm-aix7.1.0.0/bits/gthr.h:151:27:
error: expected initializer before end of line
/tmp/20150130/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/powerpc-ibm-aix7.1.0.0/bits/gthr.h:151:27:
error: expected declaration before end of line

[Bug testsuite/64885] libstdc++ all_attributes failure

[dje at gcc dot gnu.org]

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

--- Comment #1 from David Edelsohn  ---
Created attachment 34633
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34633&action=edit
gzipped pre-processed source of testcase

[Bug target/64882] ICE on valid code at -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5681

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Target Milestone|5.0 |4.8.5
Summary|[5 Regression] ICE on valid |ICE on valid code at -O3
   |code at -O3 with -g enabled |with -g enabled in
   |in simplify_subreg, at  |simplify_subreg, at
   |simplify-rtx.c:5681 |simplify-rtx.c:5681

--- Comment #13 from Uroš Bizjak  ---
Fixed on mainline sofar.

[Bug testsuite/64885] libstdc++ all_attributes failure

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Target||powerpc-ibm-aix
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-31
 CC||redi at gcc dot gnu.org
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

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

[Bug testsuite/64885] libstdc++ all_attributes failure

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
Related to (duplicate of) pr64883.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
See also pr64885.

[Bug target/11911] Aix 5.2 building sendmail fails with bug error

[LpSolit at netscape dot net]

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

--- Comment #9 from Frédéric Buclin  ---
(In reply to anthony from comment #4)
> That was I.  Any way to change the reporter to acq...@optonline.net?

Done (12 years later)!

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
This looks like a bug in darwin's system headers which should be using
__noreturn__ not noreturn and __deprecated__ not deprecate, but I'll change the
test to avoid it.

[Bug testsuite/64885] libstdc++ all_attributes failure

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
That's a bug in gthr-single.h

--- a/libgcc/gthr-single.h
+++ b/libgcc/gthr-single.h
@@ -38,7 +38,7 @@ typedef int __gthread_recursive_mutex_t;
 #define __GTHREAD_MUTEX_INIT_FUNCTION(mx)
 #define __GTHREAD_RECURSIVE_MUTEX_INIT 0

-#define UNUSED __attribute__((unused))
+#define UNUSED __attribute__((__unused__))

 #ifdef _LIBOBJC

[Bug testsuite/64885] libstdc++ all_attributes failure

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug c++/64877] strange warning message from -Waddress

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-31
 CC||paolo.carlini at oracle dot com
Version|unknown |5.0
 Ever confirmed|0   |1

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Tom Tromey from comment #3)
> Oops, had the wrong gcc in $PATH.
> That test case does warn:
> 
> pokyo. g++ -std=c++11 -c -Wall -Waddress -O2 x.cc
> x.cc: In instantiation of ‘S::S() [with Derived = T]’:
> x.cc:19:8:   required from here
> x.cc:9:29: warning: the address of ‘void S::Unwrap() [with Derived
> = T]’ will never be NULL [-Waddress]
>  if (&S::Unwrap != &Derived::Unwrap)
>  ^
> 
> 
> I think I would expect a warning on the second assert, but not the first.

We hit this code in cp/typeck.c

/* We generate:

   (op0.pfn == op1.pfn
   && (!op0.pfn || op0.delta == op1.delta))

   The reason for the `!op0.pfn' bit is that a NULL
   pointer-to-member is any member with a zero PFN; the
   DELTA field is unspecified.  */

e1 = cp_build_binary_op (location,
 EQ_EXPR, delta0, delta1, complain);
e2 = cp_build_binary_op (location,
 EQ_EXPR,
 pfn0,
 build_zero_cst (TREE_TYPE (pfn0)),
 complain);
e1 = cp_build_binary_op (location,
 TRUTH_ORIF_EXPR, e1, e2, complain);

thus, the !op0.pfn triggers the warning. It may be enough to pass tf_none
instead of complain for the two compiler-generated expressions. Alternatively,
since we know pfn0 cannot be NULL, do not generate this check. It seems quite
wasteful to go through the huge cp_build_binary_op just to build something that
will get optimized out.

Not working on this, but it seems feasible to fix. If it is a regression, you
may even convince someone to approve it for GCC 5.

[Bug c++/64877] strange warning message from -Waddress

[manu at gcc dot gnu.org]

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

--- Comment #5 from Manuel López-Ibáñez  ---
And just for the sake of completion, the warning we trigger is:

else if (((code0 == POINTER_TYPE || TYPE_PTRDATAMEM_P (type0))
  && null_ptr_cst_p (op1))
 /* Handle, eg, (void*)0 (c++/43906), and more.  */
 || (code0 == POINTER_TYPE
 && TYPE_PTR_P (type1) && integer_zerop (op1)))
  {
if (TYPE_PTR_P (type1))
  result_type = composite_pointer_type (type0, type1, op0, op1,
CPO_COMPARISON, complain);
else
  result_type = type0;

if (TREE_CODE (op0) == ADDR_EXPR
B =>&& decl_with_nonnull_addr_p (TREE_OPERAND (op0, 0)))
  {
if ((complain & tf_warning)
&& c_inhibit_evaluation_warnings == 0)
  warning (OPT_Waddress, "the address of %qD will never be
NULL",
   TREE_OPERAND (op0, 0));
  }
  }

It could be enough to test decl_with_nonnull_addr_p (TREE_OPERAND (op0, 0)) to
avoid building !op0.pfn when not needed.

[Bug c++/64791] Generic lambda fails to implicitly capture `const` variable

[paolo.carlini at oracle dot com]

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

--- Comment #8 from Paolo Carlini  ---
Weird, I tried on my machine yesterday's r220267 and same result, no warning
(with -std=gnu++1z -Wall -Wextra). I guess that before closing this bug we need
either to figure out what's special about that web page or another report that
things are actually fine.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe  ---
(In reply to Jonathan Wakely from comment #3)
> This looks like a bug in darwin's system headers which should be using
> __noreturn__ not noreturn and __deprecated__ not deprecate, but I'll change
> the test to avoid it.

hmm .. so cdefs.h does indeed use __attribute__((no return)) and
__attribute__((deprecated)).

(although both are still valid by GCC documentation)

What about a fixincludes? (not familiar with what level of stuff is feasible
there).

[Bug ipa/64813] [5 Regression] 23_containers/unordered_map/requirements/explicit_instantiation/[2,4].cc iCEs

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #13 from John David Anglin  ---
Also seen on hppa2.0w-hp-hpux11.11.

[Bug rtl-optimization/64756] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)

[mikpelinux at gmail dot com]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #1 from Mikael Pettersson  ---
Started with r210113, aka wide-int merge.  Still occurs with today's trunk.

[Bug rtl-optimization/64886] New: FAIL: gcc.dg/pr64434.c scan-rtl-dump-times expand "Swap operands" 1

[danglin at gcc dot gnu.org]

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

Bug ID: 64886
   Summary: FAIL: gcc.dg/pr64434.c scan-rtl-dump-times expand
"Swap operands" 1
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64434.c  -fno-diagnostics-show-caret
-fdiagnostics-color=never   -O1 -fdump-rtl-expand-details -S   -o pr64434.s   
(timeout = 300)
spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64434.c -fno-diagnostics-show-caret
-fdiagnostics-color=never -O1 -fdump-rtl-expand-details -S -o pr64434.s
PASS: gcc.dg/pr64434.c (test for excess errors)
FAIL: gcc.dg/pr64434.c scan-rtl-dump-times expand "Swap operands" 1

"Swap operands" is not present in dump.

[Bug c++/64887] New: Brace initialization of array members when move constructor is deleted or implicit.

[cth027 at yahoo dot de]

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

Bug ID: 64887
   Summary: Brace initialization of array members when move
constructor is deleted or implicit.
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cth027 at yahoo dot de

Created attachment 34634
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34634&action=edit
Test case 1: Failure to compile (move and copy ctors are deleted)

The initialisation of member arrays of type A fail to compile when move
constructor of A is deleted or implicitely defined and A has a member which is
not a base type.  

Testcase1 fails to compile because move constructor of A is deleted.  The same
code compiles, when the string member of A is removed (Testcase2) or if the
string member of A is replaced with an int member (Testcase3).

Testcase4 fails to compile because the copy constructor of A is deleted, the
move construcor being implicietly defined.  The same code compiles if the move
constructor is user defined (Testcase5).

The bug could be related to bug 63707, but it's broader (move and not only copy
constructor) and unrelated to user defined destructor.

[Bug c++/64887] Brace initialization of array members when move constructor is deleted or implicit.

[cth027 at yahoo dot de]

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

--- Comment #1 from Christophe  ---
Created attachment 34635
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34635&action=edit
Test case 2: same code compile if private member removed

[Bug c++/64887] Brace initialization of array members when move constructor is deleted or implicit.

[cth027 at yahoo dot de]

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

--- Comment #2 from Christophe  ---
Created attachment 34636
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34636&action=edit
Test case 2: same code compiles if private string member replace by int member

[Bug c++/64887] Brace initialization of array members when move constructor is deleted or implicit.

[cth027 at yahoo dot de]

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

--- Comment #3 from Christophe  ---
Created attachment 34637
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34637&action=edit
Test case 4: Failure to compile (copy ctor deleted, move implicit)

[Bug c++/64887] Brace initialization of array members when move constructor is deleted or implicit.

[cth027 at yahoo dot de]

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

--- Comment #4 from Christophe  ---
Created attachment 34638
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34638&action=edit
Test case 2: same code compile if user-defined move ctor

[Bug sanitizer/64888] New: ubsan doesn't work with openmp

[mikulas at artax dot karlin.mff.cuni.cz]

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

Bug ID: 64888
   Summary: ubsan doesn't work with openmp
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikulas at artax dot karlin.mff.cuni.cz
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

Undefined behavior sanitizer and openmp don't work together. Ubsan generates
some internal variables and openmp complains that shareability of these
variables haven't been defined. Try to compile this program with
gcc -fsanitize=undefined -fopenmp openmp-ubsan.c

#include 

int main(void)
{
unsigned a = 1;
unsigned b = 2;
unsigned c;
#pragma omp parallel default(none) shared(a,b) private(c)
{
c = a / b;
}
}

openmp-ubsan.c: In function ‘main’:
openmp-ubsan.c:10:9: error: ‘*.Lubsan_data0’ not specified in enclosing
parallel
   c = a / b;
 ^
openmp-ubsan.c:8:9: error: enclosing parallel
 #pragma omp parallel default(none) shared(a,b) private(c)
 ^

[Bug target/64889] New: [h8300] ICE maybe_record_trace_start, at dwarf2cfi.c:2318

[ysato at users dot sourceforge.jp]

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

Bug ID: 64889
   Summary: [h8300] ICE maybe_record_trace_start, at
dwarf2cfi.c:2318
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysato at users dot sourceforge.jp

Created attachment 34639
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34639&action=edit
reproduce on ICE

reporoduce code attached.

$ h8300-elf-gcc -mh -mint32 -Os -g -fomit-frame-pointer -c namei.c
namei.c: In function 'SYSC_mknodat':
namei.c:38:6: warning: implicit declaration of function 'new_decode_dev'
[-Wimplicit-function-declaration]
  new_decode_dev(dev));
  ^
../../linux/namei.c:42:1: internal compiler error: in maybe_record_trace_start,
at dwarf2cfi.c:2318
 }
 ^
0x6d1d87 maybe_record_trace_start
../../gcc/dwarf2cfi.c:2318
0x6d2640 scan_trace
../../gcc/dwarf2cfi.c:2496
0x6d2e4a create_cfi_notes
../../gcc/dwarf2cfi.c:2650
0x6d2e4a execute_dwarf2_frame
../../gcc/dwarf2cfi.c:3006
0x6d2e4a execute
../../gcc/dwarf2cfi.c:3486
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug sanitizer/64888] ubsan doesn't work with openmp

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-31
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug c++/64877] [5 Regression] strange warning message from -Waddress

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|strange warning message |[5 Regression] strange
   |from -Waddress  |warning message from
   ||-Waddress

--- Comment #6 from Paolo Carlini  ---
Thanks Manuel for the analysis. Indeed, now -Waddress is much more general, and
those internally generated expressions are causing problems. Thus, following
your suggestion, I would propose something like the below, which I'm finishing
testing. Does it look Ok to you?


Index: typeck.c
===
--- typeck.c(revision 220306)
+++ typeck.c(working copy)
@@ -4552,35 +4552,44 @@ cp_build_binary_op (location_t location,

  The reason for the `!op0.pfn' bit is that a NULL
  pointer-to-member is any member with a zero PFN and
- LSB of the DELTA field is 0.  */
+ LSB of the DELTA field is 0.  Note: avoid generating the
+ '|| (!op0.pfn && ...)' if !op0.pfn is known to be false.  */

-  e1 = cp_build_binary_op (location, BIT_AND_EXPR,
-   delta0, 
-   integer_one_node,
-   complain);
-  e1 = cp_build_binary_op (location,
-   EQ_EXPR, e1, integer_zero_node,
-   complain);
-  e2 = cp_build_binary_op (location, BIT_AND_EXPR,
-   delta1,
-   integer_one_node,
-   complain);
-  e2 = cp_build_binary_op (location,
-   EQ_EXPR, e2, integer_zero_node,
-   complain);
-  e1 = cp_build_binary_op (location,
-   TRUTH_ANDIF_EXPR, e2, e1,
-   complain);
-  e2 = cp_build_binary_op (location, EQ_EXPR,
-   pfn0,
-   build_zero_cst (TREE_TYPE (pfn0)),
-   complain);
-  e2 = cp_build_binary_op (location,
-   TRUTH_ANDIF_EXPR, e2, e1, complain);
-  e1 = cp_build_binary_op (location,
-   EQ_EXPR, delta0, delta1, complain);
-  e1 = cp_build_binary_op (location,
-   TRUTH_ORIF_EXPR, e1, e2, complain);
+  if (TREE_CODE (pfn0) != ADDR_EXPR
+  || !decl_with_nonnull_addr_p (TREE_OPERAND (pfn0, 0)))
+{
+  e1 = cp_build_binary_op (location, BIT_AND_EXPR,
+   delta0, 
+   integer_one_node,
+   complain);
+  e1 = cp_build_binary_op (location,
+   EQ_EXPR, e1, integer_zero_node,
+   complain);
+  e2 = cp_build_binary_op (location, BIT_AND_EXPR,
+   delta1,
+   integer_one_node,
+   complain);
+  e2 = cp_build_binary_op (location,
+   EQ_EXPR, e2, integer_zero_node,
+   complain);
+  e1 = cp_build_binary_op (location,
+   TRUTH_ANDIF_EXPR, e2, e1,
+   complain);
+  e2 = cp_build_binary_op (location, EQ_EXPR,
+   pfn0,
+   build_zero_cst (TREE_TYPE (pfn0)),
+   complain);
+  e2 = cp_build_binary_op (location,
+   TRUTH_ANDIF_EXPR, e2, e1, complain);
+  e1 = cp_build_binary_op (location,
+   EQ_EXPR, delta0, delta1, complain);
+  e1 = cp_build_binary_op (location,
+   TRUTH_ORIF_EXPR, e1, e2, complain);
+
+}
+  else
+e1 = cp_build_binary_op (location,
+ EQ_EXPR, delta0, delta1, complain);
 }
   else
 {
@@ -4591,17 +4600,22 @@ cp_build_binary_op (location_t location,

  The reason for the `!op0.pfn' bit is that a NULL
  pointer-to-member is any member with a zero PFN; the
- DELTA field is unspecified.  */
+ DELTA field is unspecified.  Note: avoid generating the
+ '!op0.pfn ||' if !op0.pfn is known to be false.  */

   e1 = cp_build_binary_op (location,
EQ_EXPR, delta0, delta1, complain);
-  e2 = cp_build_binary_op (location,
-   EQ_EXPR,
- pfn0,
-  build_zero_cst (TREE_TYPE (pfn0)),
-   complain);
-  e1 = cp_build_binary_op (location,
-   TRUTH_ORIF_EXPR, e1, e2, complain);
+  if (TREE_CODE (pfn0) != ADDR_EXPR
+  || !decl_with_nonnull_addr_p (TREE_OPERAND (pfn0, 0)))
+{
+  e2 = cp_build_binary_op (location,
+ 

[Bug rtl-optimization/64756] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)

[mikpelinux at gmail dot com]

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

--- Comment #2 from Mikael Pettersson  ---
Also fails on m68k, but not on powerpc64, sparc64, or ARMv5.

[Bug c/64890] New: FAIL: gcc.dg/pr64809.c (test for excess errors)

[danglin at gcc dot gnu.org]

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

Bug ID: 64890
   Summary: FAIL: gcc.dg/pr64809.c (test for excess errors)
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

FAIL: gcc.dg/pr64809.c (test for excess errors)
Excess errors:
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:4:1: warning: data definition
has no type or storage class
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:4:1: warning: type defaults to
'int' in declaration of 'memcpy' [-Wimplicit-int]
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:4:1: warning: conflicting
types for built-in function 'memcpy'
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:5:1: warning: data definition
has no type or storage class
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:5:1: warning: type defaults to
'int' in declaration of 'memccpy' [-Wimplicit-int]
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:7:1: warning: data definition
has no type or storage class
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:7:1: warning: type defaults to
'int' in declaration of 'strncpy' [-Wimplicit-int]
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:7:1: warning: conflicting
types for built-in function 'strncpy'
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:8:1: warning: data definition
has no type or storage class
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:8:1: warning: type defaults to
'int' in declaration of 'strcat' [-Wimplicit-int]
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:8:1: warning: conflicting
types
 for built-in function
'strcat'/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:11:14: warning: no
semicolon at
 end of struct or union/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:12:1:
warning: data definition 
has no type or storage
class/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:12:1: warning: type
defaults to
 'int' in declaration of 'strerror'
[-Wimplicit-int]/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:13:1: warning:
data definition 
has no type or storage
class/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:13:1: warning: type
defaults to
 'int' in declaration of 'strerror_r'
[-Wimplicit-int]/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:15:1: warning:
data definition 
has no type or storage
class/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:15:1: warning: type
defaults to
 'int' in declaration of 'strerror_l'
[-Wimplicit-int]/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:16:1: warning:
data definition 
has no type or storage
class/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:16:1: warning: type
defaults to
 'int' in declaration of '__bzero'
[-Wimplicit-int]/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:17:19:
warning: type defaults to 'int' in declaration of 'bzero' [-Wimplicit-int]
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:17:19: warning: conflicting
types for built-in function 'bzero'
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:20:1: warning: return type
defaults to 'int' [-Wimplicit-int]
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:24:1: warning: data definition
has no type or storage class
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:24:1: warning: type defaults
to 'int' in declaration of '__strcspn_c2' [-Wimplicit-int]
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:25:19: warning: return type
defaults to 'int' [-Wimplicit-int]
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:30:43: warning: type defaults
to 'int' in declaration of 'p1' [-Wimplicit-int]
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:30:19: warning: return type
defaults to 'int' [-Wimplicit-int]
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:32:12: warning: type defaults
to 'int' in declaration of '__result' [-Wimplicit-int]
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:37:1: warning: return type
defaults to 'int' [-Wimplicit-int]
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:39:12: warning: type defaults
to 'int' in declaration of '__result' [-Wimplicit-int]
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr64809.c:44:1: warning: data definition
has no type or storage class

etc.

[Bug testsuite/64891] New: FAIL: gcc.dg/ipa/pr64307.c (test for excess errors)

[danglin at gcc dot gnu.org]

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

Bug ID: 64891
   Summary: FAIL: gcc.dg/ipa/pr64307.c (test for excess errors)
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/test/gnu/gcc/gc
c/gcc/testsuite/gcc.dg/ipa/pr64307.c -fno-diagnostics-show-caret
-fdiagnostics-c
olor=never -O0 -fipa-icf -fdump-ipa-icf -S -o pr64307.s
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/ipa/pr64307.c:4:21: fatal error:
complex.
h: No such file or directory

Probably needs c99_runtime require.

[Bug c++/64884] [5 Regression] FAIL: g++.dg/tm/pr47573.C -std=gnu++98 (test for excess errors) on x86_64-apple-darwin*

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #2 from John David Anglin  ---
Also seen on hppa2.0w-hp-hpux11.11.

[Bug c/64890] FAIL: gcc.dg/pr64809.c (test for excess errors)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Markus Trippelsdorf  ---
The testcase was removed by r220241.

[Bug bootstrap/64256] [5.0 Regression] Pointer Bounds Checker builtins enum overflows stabstring length

[zoltan at hidvegi dot com]

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

Zoltan Hidvegi  changed:

   What|Removed |Added

 CC||zoltan at hidvegi dot com

--- Comment #5 from Zoltan Hidvegi  ---
I've also encountered this bug in a user source code, note on AIX for 32-bit
XCOFF32 objects, the stabstring length is limited to 64k, because length is
stored in a 2-byte field. Compiling with -maix64 works for these sources:
http://www-01.ibm.com/support/knowledgecenter/api/content/nl/en-us/ssw_aix_53/com.ibm.aix.files/doc/aixfiles/XCOFF.htm#x83wh24fshar

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Iain Sandoe from comment #4)
> hmm .. so cdefs.h does indeed use __attribute__((no return)) and
> __attribute__((deprecated)).
> 
> (although both are still valid by GCC documentation)

It's valid but the point is that "noreturn" is not a reserved name in any C or
POSIX standard, nor in any C++ standard before C++11, so users can reasonably
expect to be able to define a macro with that name and not get problems. In
order to support such valid usr code system headers should avoid using that
name, and should use the __noreturn__ form that is not a valid macro name for
users to define.

The point of the new test is to ensure libstdc++ itself doesn't contain this
kind of bug ... but it fails because darwin has the bug, even though the
libstdc++ headers no longer have it.

> What about a fixincludes? (not familiar with what level of stuff is feasible
> there).

I think this could be solved with fixincludes, but that seems like something
for stage 1. For now I might just adjust the test to stop it failing.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Perhaps unconditionally or conditionally for Darwin only include some C header
or headers before defining those macros, then include the STL headers?

[Bug rtl-optimization/63577] [4.8/4.9/5 Regression]: Huge compile time and memory usage with -O and not -fPIC

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool  ---
Also note that doing GC during the pass will not reduce the compile
time or the amount of garbage created at all, so won't fix the actual
problem; it does of course make it more bearable on smaller machines.

I'll have another look at what causes this; from what I remember last
time I looked there simply *are* very many opportunities to combine
some insns (most of which fail, maybe we could short-circuit some).

[Bug c++/64887] Brace initialization of array members when move constructor is deleted or implicit.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
I maintain what I said on stackoverflow, this is PR 63707. Just because there
are other ways to reproduce the bug doesn't make it a separate bug, that just
means there should be additional testcases on the original bug.

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

[Bug c++/63707] Brace initialization of array sometimes fails if no copy constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||cth027 at yahoo dot de

--- Comment #6 from Jonathan Wakely  ---
*** Bug 64887 has been marked as a duplicate of this bug. ***

[Bug c++/63707] Brace initialization of array sometimes fails if no copy constructor

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Reduced from PR 64887:

struct string
{
  string(const char*) { }
  ~string(); // make this type non-trivial
};

struct A
{
  string s;
  A() = delete;
  A(const A&) = delete;
  A(A&&) = delete;
  A(const char*);
};

A arr[2] = {{"a"}, {"b"}}; // ok

struct Aggr {
  A arr[2];
  Aggr() : arr{{"a"}, {"b"}} {} // error
};

The member of non-trivial type is required to trigger the error, presumably
because it makes the destructor non-trivial.

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[hubicka at ucw dot cz]

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

--- Comment #18 from Jan Hubicka  ---
Reducing firefox may be fun, ICE happen during fork, so perhaps adding fork to
your testcase? :)

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe  ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Iain Sandoe from comment #4)
> > hmm .. so cdefs.h does indeed use __attribute__((no return)) and
> > __attribute__((deprecated)).
> > 
> > (although both are still valid by GCC documentation)
> 
> It's valid but the point is that "noreturn" is not a reserved name in any C
> or POSIX standard, nor in any C++ standard before C++11, so users can
> reasonably expect to be able to define a macro with that name and not get
> problems. In order to support such valid usr code system headers should
> avoid using that name, and should use the __noreturn__ form that is not a
> valid macro name for users to define.
> 
> The point of the new test is to ensure libstdc++ itself doesn't contain this
> kind of bug ... but it fails because darwin has the bug, even though the
> libstdc++ headers no longer have it.

OK, thanks for clarifying.
Perhaps, 

(a) given that the __attribute__((xyzzy)) etc. versions are in pretty wide use
"in the wild".

(b) Section 6.33  of the current GCC manual doesn't really mention the ____
versions and the examples throughout the section use undecorated versions (the
only example with ____ seems to be __target__). This section specifically
states the attributes may be identifiers or reserved words.

... we might implement some compatibility warning (again in the future) - or
perhaps at least add a note to the manual.

As far as Darwin's system headers, I guess someone needs to file a radar
against the current edition (but that doesn't solve things for the systems
already out there).

> > What about a fixincludes? (not familiar with what level of stuff is feasible
> > there).
> 
> I think this could be solved with fixincludes, but that seems like something
> for stage 1. For now I might just adjust the test to stop it failing.

for my part, I'm happy with whatever solution you think is reasonable for
stage4 - and we can re-visit this in stage #1.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[howarth at bromo dot med.uc.edu]

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

--- Comment #8 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #7)

Certainly getting the current GCC manual in sync with this new restriction and
emitting a clear warning in the gcc 5.0 release compiler would get the issue
more traction with upstream developers.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Iain Sandoe from comment #7)
> (a) given that the __attribute__((xyzzy)) etc. versions are in pretty wide
> use "in the wild".
> 
> (b) Section 6.33  of the current GCC manual doesn't really mention the
> ____ versions and the examples throughout the section use undecorated
> versions (the only example with ____ seems to be __target__). This
> section specifically states the attributes may be identifiers or reserved
> words.

Right, I think it's only mentioned at
https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html

> ... we might implement some compatibility warning (again in the future) - or
> perhaps at least add a note to the manual.

I'm not sure a waning is appropriate. Users are welcome to use the non-uglified
attributes, it's their responsibility to ensure their own attributes don't
clash with their own macros. 


(In reply to howarth from comment #8)
> Certainly getting the current GCC manual in sync with this new restriction
> and emitting a clear warning in the gcc 5.0 release compiler would get the
> issue more traction with upstream developers.

There is no new restriction. 

The failing test is only intended to check that libstdc++ is consistent about
using the uglified attributes. Anything outside libstdc++ can do whatever it
wants. IMHO the C standard library headers should use the reserved names, but
the GCC manual is not the right place to document how to implement the C
standard library.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #6)
> Perhaps unconditionally or conditionally for Darwin only include some C
> header or headers before defining those macros, then include the STL headers?

Yes, something like this:

--- a/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc
+++ b/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc
@@ -18,6 +18,19 @@
 // { dg-options "-std=gnu++98" }
 // { dg-do compile }

+#ifdef __APPLE__
+// darwin headers use noreturn and deprecated, PR 64883
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#endif
+
+// gthr-single.h uses unused, PR 64885
+#include 
+
 // Ensure the library only uses the __name__ form for attributes.
 // Don't test 'const' because it is reserved anyway.
 #define abi_tag 1


But it's a bit fragile, as the list of C headers might vary between darwin
versions. This would be more reliable, and we still test that libstdc++ doesn't
use those names on all other targets:

--- a/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc
+++ b/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc
@@ -18,12 +18,18 @@
 // { dg-options "-std=gnu++98" }
 // { dg-do compile }

+// gthr-single.h uses unused, see PR 64885
+#include 
+
 // Ensure the library only uses the __name__ form for attributes.
 // Don't test 'const' because it is reserved anyway.
 #define abi_tag 1
 #define always_inline 1
-#define deprecated 1
-#define noreturn 1
+#ifndef __APPLE__
+// darwin headers use these, see PR 64883
+# define deprecated 1
+# define noreturn 1
+#endif
 #define packed 1
 #define pure 1
 #define unused 1

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[hubicka at ucw dot cz]

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

--- Comment #19 from Jan Hubicka  ---
I guess the problem is that with fork we invoke dumping by hand instead of
relying on dtors?

honza

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[howarth at bromo dot med.uc.edu]

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

--- Comment #11 from howarth at bromo dot med.uc.edu ---
What is so dangerous about just using...

Index: fixincludes/inclhack.def
===
--- fixincludes/inclhack.def(revision 220306)
+++ fixincludes/inclhack.def(working copy)
@@ -1266,6 +1266,18 @@ fix = {
 };

 /*
+ * sys/cdef.sh on Darwin should use reserved name __noreturn__
+ * rather than noreturn.
+ */
+fix = {
+  hackname  = darwin_noreturn;
+  mach  = "*-*-darwin*";
+  files = sys/cdefs.h;
+  sed   = "s/__attribute__((noreturn))/__attribute__((__noreturn__))/g";
+  test_text = "__attribute__((noreturn))";
+};
+
+/*
  *  __private_extern__ doesn't exist in FSF GCC.  Even if it did,
  *  why would you ever put it in a system header file?
  */

...instead? It seems a whole lot simpler.

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[nathan at acm dot org]

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

--- Comment #20 from Nathan Sidwell  ---
Adding a call to __gcov_fork doesn't cause breakage.  I'd much rather start
from a failing testcase than stab in the dark at various hypotheses.

[Bug target/53949] [SH] Add support for mac.w / mac.l instructions

[olegendo at gcc dot gnu.org]

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

--- Comment #13 from Oleg Endo  ---
A more interesting real-world example from libjpeg would be function
jpeg_idct_ifast (jidctint.c).

If we take the code as-is, there are few mac opportunities due to sharing of
the terms.  The expressions could be un-CSE'd which would result in longer mac
chains, but the overall result gets worse because the data layout is not in a
mac friendly way.

The first loop in jpeg_idct_ifast can be split into 8 independent loops for the
output value wsptr[8*n+i].
For n = 1,2,3,4,5,6 the loops look a bit complex, but for n = 0 and n = 7 we
get similar looking loops like:

for (int i = 0; i < 8; ++i)
{
  wsptr[8*7+i] = inptr[8*0 + i] * quantptr[8*0 + i]
 - inptr[8*1 + i] * quantptr[8*1 + i]
 + inptr[8*2 + i] * quantptr[8*2 + i]
 - inptr[8*3 + i] * quantptr[8*3 + i]
 + inptr[8*4 + i] * quantptr[8*4 + i]
 - inptr[8*5 + i] * quantptr[8*5 + i]
 + inptr[8*6 + i] * quantptr[8*6 + i]
 - inptr[8*7 + i] * quantptr[8*7 + i];
}

Still, due to the subtractions and memory access pattern, plain mac insns can't
be used.

The subtractions can be converted into additions by negating the operands. 
Since mac wants both operands in memory, those can be placed on the stack. 
Also, in this case the address registers can be pre-computed outside the loop,
since there are enough registers.
A possible outcome would be something like this:

// r4 = inptr[8*0+i]
// r5 = quantptr[8*0+i]
// r6 = wsptr[8*0+i]

  movr4,r3;add#32,r3// r3 = inptr[8*1+i]
  movr3,r7;add#32,r7// r7 = inptr[8*2+i]
  movr7,r8;add#32,r8// r8 = inptr[8*3+i]
  movr8,r9;add#32,r9// r9 = inptr[8*4+i]
  movr9,r10;   add#32,r10   // r10 = inptr[8*5+i]
  movr10,r11;  add#32,r11   // r11 = inptr[8*6+i]
  movr11,r12;  add#32,r12   // r12 = inptr[8*7+i]

  mov#8,r14
  add#126,r6;  add#102,r6   // r6 = wpstr + 8*7*4 + 4
  movr4,r0;subr5,r0 // r0 = quantptr - intptr

.Loop:
  mov.l  @(r0,r12),r1   // quantptr[8*7+i]
  mov.l  @(r0,r11),r2// quantptr[8*6+i]
  mov.l  @(r0,r10),r13// quantptr[8*5+i]
  negr1,r1
  mov.l  r1,@-r15
  mov.l  r2,@-r15
  negr13,r13
  mov.l  @(r0,r8),r1// quantptr[8*3+i]
  mov.l  @(r0,r9),r2// quantptr[8*4+i]
  mov.l  r13,@-r15
  negr1,r1
  mov.l  r2,@-r15
  mov.l  @(r0,r7),r2// quantptr[8*2+i]
  mov.l  @(r0,r3),r13   // quantptr[8*1+i]
  mov.l  r1,@-r15
  mov.l  r2,@-r15
  negr13,r13
  mov.l  r13,@-r15

  clrmac
  mac.l@r4+,@r5+
  mac.l@r3+,@r15+
  mac.l@r7+,@r15+
  mac.l@r8+,@r15+
  mac.l@r9+,@r15+
  mac.l@r10+,@r15+
  mac.l@r11+,@r15+
  mac.l@r12+,@r15+
  dtr14
  stsmacl,@-r6
  bf/s.Loop
  add#8,r6

which is 31 insns per loop and (almost) no pipeline stalls, vs. 53 insns per
loop + stalls on mul-sts sequences when the mac insn is not used.
The above loop can be optimized even further with partial unrolling to avoid
the latency of the last mac and sts.
Of course it'd be even better, if the application's data was in a mac friendly
layout.

[Bug c++/64892] New: C++1y: generic lambdas, decltype(auto), and rvalue references, oh my!

[eric.niebler at gmail dot com]

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

Bug ID: 64892
   Summary: C++1y: generic lambdas, decltype(auto), and rvalue
references, oh my!
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric.niebler at gmail dot com

In the following code, gcc seems to be getting the value category wrong for the
return type of the generic lambda:

#include 

int main()
{
using std::pair;
using std::declval;
using X = decltype(declval>().first);
auto f = [](auto && p) -> decltype(auto) //((decltype(p)&&)p).first)
{
return ((decltype(p)&&)p).first;
};
using Y = decltype(f(declval>()));
}

In this code, Y becomes an alias for int&. I believe it should be int&&. X is
an alias for int&&, and I think it's doing the same thing. Also, if I replace
the decltype(auto) with decltype(((decltype(p)&&)p).first) -- which is
*exactly* the return expression -- Y becomes an alias for int&&. Seems fishy to
me.

[Bug target/64893] [5 Regression] ICE while doing a bootstrap with the latest compiler

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug target/64893] New: [5 Regression] ICE while doing a bootstrap with the latest compiler

[pinskia at gcc dot gnu.org]

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

Bug ID: 64893
   Summary: [5 Regression] ICE while doing a bootstrap with the
latest compiler
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: build, ice-on-valid-code
  Severity: blocker
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
Target: aarch64*

Compile the following with -O0:
typedef __Uint32x2_t uint32x2_t;
__extension__ static __inline unsigned __attribute__
((__always_inline__))vget_lane_u32 (uint32x2_t __a, const int __b)
{
  return __extension__ ({ __builtin_aarch64_im_lane_boundsi ((sizeof (__a) /
sizeof (__a[0])), __b); __a[__b]; });
}
int
search_line_fast (uint32x2_t t)
{
  return vget_lane_u32 (t, 0);
}

-- CUT ---
With the C front-end, it works correctly but with the C++ front-end it fails
due to (int) (8 / 4) not being folded into just 2.

[Bug target/64893] [5 Regression] ICE while doing a bootstrap with the latest compiler

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
This was caused/exposed by revision 218532.

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[hubicka at gcc dot gnu.org]

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

--- Comment #21 from Jan Hubicka  ---
OK, I am currently on a trip with sporadic internet access but I can try to
build the shared libraries.  In meantime you can also just try out firefox
profiledbuild ;)

What happens IMO is that
1) fork calls __gcov_fork
2) __gcov_fork calls __gcov_dump_int
3) gcov_dump_int traverses the global master root and walks into objects from
other DSO and calls __gcov_dump_one
4) __gcov_dump_one eventaully calls dump_one_gcov that calls merge_one_data
5) merge_one_data uses pointer from other DSO to call merge function that calls
wrong copy of gcov-io

So unlike the atexit machinery, IMO the bug is that gcov_dump_int walks the
master_root without dispatching to a proper copy of the gcov_dump_one

Honza

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[howarth at bromo dot med.uc.edu]

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

--- Comment #12 from howarth at bromo dot med.uc.edu ---
(In reply to howarth from comment #11)

A fixincludes doesn't solve the problem as the libstdc++ test suite doesn't
seem to use those fixed headers.

[Bug target/64893] [5 Regression] ICE while doing a bootstrap with the latest compiler

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Ok, the problem is related to sizeof.
Let me see if I can make the gimplifier fold the statements or something
similar.  Note we might want to change the first argument of
__builtin_aarch64_im_lane_boundsi to size_t to get rid of the case so it is
easy to handle in fold.

[Bug target/58400] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ext4/mballoc.c: In function 'mb_free_blocks':

[ysato at users dot sourceforge.jp]

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

Yoshinori Sato  changed:

   What|Removed |Added

 CC||ysato at users dot 
sourceforge.jp

--- Comment #10 from Yoshinori Sato  ---
I verified fix problem in this patch.
(4.9.2 and 5.0)

[Bug c++/64892] C++1y: generic lambdas, decltype(auto), and rvalue references, oh my!

[eric.niebler at gmail dot com]

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

--- Comment #1 from Eric Niebler  ---
I think this is user error. I was confused between the difference between
decltype(x.y) and decltype((x.y)). It seems the decltype(auto) is semantically
the same as decltype((x.y)) in this case. From that perspective, gcc is begin
consistent.

As for why decltype((declval>().first)) is int& instead of
int&&, I'm guessing it's because of some subtlety of rvalue references that I
don't yet grasp. I'll leave this open on the off-chance that this really is a
bug, and on the off-change that someone will explain to me why it is the way it
is.

Sorry in advance if this is just noise.

[Bug tree-optimization/15596] [4.8/4.9/5 Regression] Missed optimization with bitfields with return value

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #25 from Segher Boessenkool  ---
If you initialise the return value to all zeroes, the good code comes
out again.  The problem is that currently GCC preserves all padding
bits.  The same is true for normal stores (instead of return value via
hidden pointer as in the example code).

For this case, for PowerPC, writing 0 to all padding bits is optimal.
That is because we write to field "d" which is adjacent to the padding
bits, and we do the access as a 32-bit word anyway.  For other cases
(and other targets, and other ABIs) things will be different.