[Bug c++/65851] ice in set_lattice_value at tree-ssa-cc p.c:535

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Tue Apr 28 07:26:41 2015
New Revision: 222510

URL: https://gcc.gnu.org/viewcvs?rev=222510&root=gcc&view=rev
Log:
2015-04-28  Richard Biener  

PR tree-optimization/65851
* tree-ssa-ccp.c (set_lattice_value): Perform a meet when
changing CONSTANT to CONSTANT non-copy.  Get new_val by reference.
(ccp_lattice_meet): Remove stray argument.  Use operand_equal_p
rather than simple_cst_equal as the latter doesn't handle COMPLEX_CST.
(ccp_visit_phi_node): Adjust.
(evaluate_stmt): For simplifications to SSA names return its
lattice value if that isn't VARYING.  Return immediately when
simplified to a constant.
(visit_assignment): Adjust.
(ccp_visit_stmt): Likewise.

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

Added:
trunk/gcc/testsuite/g++.dg/torture/pr65851.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c

[Bug c++/65851] ice in set_lattice_value at tree-ssa-cc p.c:535

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #4)
> For h we get into the loop PHI handling code which drops to INF-1 if it
> iterates
> "too much".  The rest probably ripples down from that.
> 
> I can't see where that [1, 0x7ff] issue happens.

Current trunk, -O2 -fdump-tree-vrp-details on the testcase has in vrp1 dump:
  :
  g.0_9 = g;
  if (g.0_9 < 0)
goto ;
  else
goto ;

  :
  _12 = -g.0_9;
  i_13 = (long int) _12;
  goto ;

and

Visiting statement:
_12 = -g.0_25;
Found new range for _12: [1, +INF(OVF)]
marking stmt to be not simulated again

Visiting statement:
i_13 = (long int) _12;
Found new range for i_13: [1, +INF(OVF)]
marking stmt to be not simulated again

The point was that the cast from 32-bit signed to 64-bit signed also should
imply that the value is not bigger than INT_MAX, and that is what we would do
if range for _12 was say [1, 0x7fff].

And for h, the point was that if only constants are assigned to the variable in
a loop, then no matter how many iterations the loop has, the resulting value
will only be one of the constants (thus smallest range covering those).
Or in this particular case, as the h = 1 assignments is only in endless loop,
we could have computed just [0, 0] (but that is probably too rare to care
about).

[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations

[thopre01 at gcc dot gnu.org]

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

--- Comment #25 from Thomas Preud'homme  ---
Author: thopre01
Date: Tue Apr 28 08:10:44 2015
New Revision: 222512

URL: https://gcc.gnu.org/viewcvs?rev=222512&root=gcc&view=rev
Log:
2015-04-28  Thomas Preud'homme  

gcc/
PR target/63503
* config.gcc: Add cortex-a57-fma-steering.o to extra_objs for
aarch64-*-*.
* config/aarch64/t-aarch64: Add a rule for cortex-a57-fma-steering.o.
* config/aarch64/aarch64.h (AARCH64_FL_USE_FMA_STEERING_PASS): Define.
(AARCH64_TUNE_FMA_STEERING): Likewise.
* config/aarch64/aarch64-cores.def: Set
AARCH64_FL_USE_FMA_STEERING_PASS for cores with dynamic steering of
FMUL/FMADD instructions.
* config/aarch64/aarch64.c (aarch64_register_fma_steering): Declare.
(aarch64_override_options): Include cortex-a57-fma-steering.h. Call
aarch64_register_fma_steering () if AARCH64_TUNE_FMA_STEERING is true.
* config/aarch64/cortex-a57-fma-steering.h: New file.
* config/aarch64/cortex-a57-fma-steering.c: Likewise.

Added:
trunk/gcc/config/aarch64/cortex-a57-fma-steering.c
trunk/gcc/config/aarch64/cortex-a57-fma-steering.h
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.gcc
trunk/gcc/config/aarch64/aarch64-cores.def
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/config/aarch64/aarch64.h
trunk/gcc/config/aarch64/t-aarch64

[Bug ipa/65908] [5/6 Regression] ICE: in expand_thunk, at cgraphunit.c:1700

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |5.2

[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de  ---
On Tue, 28 Apr 2015, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65875
> 
> --- Comment #8 from Jakub Jelinek  ---
> (In reply to Richard Biener from comment #4)
> > For h we get into the loop PHI handling code which drops to INF-1 if it
> > iterates
> > "too much".  The rest probably ripples down from that.
> > 
> > I can't see where that [1, 0x7ff] issue happens.
> 
> Current trunk, -O2 -fdump-tree-vrp-details on the testcase has in vrp1 dump:
>   :
>   g.0_9 = g;
>   if (g.0_9 < 0)
> goto ;
>   else
> goto ;
> 
>   :
>   _12 = -g.0_9;
>   i_13 = (long int) _12;
>   goto ;
> 
> and
> 
> Visiting statement:
> _12 = -g.0_25;
> Found new range for _12: [1, +INF(OVF)]
> marking stmt to be not simulated again
> 
> Visiting statement:
> i_13 = (long int) _12;
> Found new range for i_13: [1, +INF(OVF)]
> marking stmt to be not simulated again
> 
> The point was that the cast from 32-bit signed to 64-bit signed also should
> imply that the value is not bigger than INT_MAX, and that is what we would do
> if range for _12 was say [1, 0x7fff].

Yeah, but we _explicitely_ special-case the +INF(OVF) case in the source
range assuming "arbitrary" overflow and thus use +INF(OVF) in the 
destination range as well.  Probably for warnings or whatever (I don't
like that OVF stuff anyway).

> And for h, the point was that if only constants are assigned to the 
> variable in a loop, then no matter how many iterations the loop has, the 
> resulting value will only be one of the constants (thus smallest range 
> covering those). Or in this particular case, as the h = 1 assignments is 
> only in endless loop, we could have computed just [0, 0] (but that is 
> probably too rare to care about).

But h also gets subtracted 1 as well.  It is the PHI node

h_2 = PHI <0(7), h_21(19)>

that causes the "issue" via the

  /* To prevent infinite iterations in the algorithm, derive ranges
 when the new value is slightly bigger or smaller than the
 previous one.  We don't do this if we have seen a new executable
 edge; this helps us avoid an overflow infinity for conditionals
 which are not in a loop.  If the old value-range was VR_UNDEFINED
 use the updated range and iterate one more time.  */
  if (edges > 0
  && gimple_phi_num_args (phi) > 1
  && edges == old_edges
  && lhs_vr->type != VR_UNDEFINED)

code as we go from

Visiting PHI node: h_2 = PHI <0(7), h_21(19)>
Argument #0 (7 -> 8 executable)
0: [0, 0]
Argument #1 (19 -> 8 executable)
h_21: [0, 0]
Meeting
  [0, 0]
and
  [0, 0]
to
  [0, 0]

to

Simulating statement (from ssa_edges): h_2 = PHI <0(7), h_21(19)>

Visiting PHI node: h_2 = PHI <0(7), h_21(19)>
Argument #0 (7 -> 8 executable)
0: [0, 0]
Argument #1 (19 -> 8 executable)
h_21: [0, 1]
Meeting
  [0, 0]
and
  [0, 1]
to
  [0, 1]
Intersecting
  [0, 9223372036854775806]
and
  [-INF, +INF]
to
  [0, 9223372036854775806]
Found new range for h_2: [0, 9223372036854775806]

as the range grows we "drop" to +INF - 1 (to give the next iteration
the chance to compute wheter it will overflow - previously we dropped
to +INF(OVF) immediately).

Yes, we can do some more iterating or instead of dropping right away
to +INF - 1 we could go towards +INF in log (+INF) steps.  It's all
a question about compile-time vs. accuracy in rare(?) cases.

Yes, if we have a way to statically compute a good range estimate
(like we try with adjust_range_with_scev) then that's of course
even better.  I don't see anything obvious here though.

[Bug c++/65905] Building eCos fails with clist.hxx:304:1: error: template with C linkage

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

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

--- Comment #1 from Bernd Edlinger  ---
Oh, my fault.

Accidentally I left a sym-link from arm-eabi/sys-include
to ecos-test_install/include that is necessary for boot-strap,
but is known to not work for building the eCos library.

Although previously the error message was less cryptic.

[Bug other/65911] New: [6 Regression] r222508 breaks clang-tblgen

[trippels at gcc dot gnu.org]

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

Bug ID: 65911
   Summary: [6 Regression] r222508 breaks clang-tblgen
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: tbsaunde at gcc dot gnu.org
  Target Milestone: ---

Starting with r222508 LLVM doesn't build anymore on ppc64le:

trippels@gcc2-power8 llvm_build % ./bin/clang-tblgen -gen-clang-attr-impl -I
/home/trippels/llvm/tools/clang/include/clang/AST/../../ -I
/home/trippels/llvm/tools/clang/include/clang/AST -I
/home/trippels/llvm/lib/Target -I /home/trippels/llvm/include
/home/trippels/llvm/tools/clang/include/clang/AST/../Basic/Attr.td -o
/home/trippels/llvm_build/tools/clang/include/clang/AST/AttrImpl.inc.tmp
Program received signal SIGSEGV, Segmentation fault.
0x3fffb79d1ee4 in __strcmp_power7 () from /lib64/libc.so.6
(gdb) bt
#0  0x3fffb79d1ee4 in __strcmp_power7 () from /lib64/libc.so.6
#1  0x1005c504 in llvm::cl::generic_parser_base::findOption(char
const*) ()
#2  0x10004f9c in _GLOBAL__sub_I_TableGen.cpp ()

[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
I meant in the first loop.
But we handle:
int b, c, e;

long
foo (int x, int y)
{
  long h = 0;
  for (b = 0; b < x; b++)
for (c = 0; c < y; c++)
  if (e)
h = 1;
  return h + 4;
}
correctly, it is only as soon as one of those loops turns into endless loop:
int b, c, e;

long
foo (int x, int y)
{
  long h = 0;
  for (b = 0; b < x; b++)
for (c = 0; c < y;)
  if (e)
h = 1;
  return h + 4;
}
that we lose track.  But, if it is only for endless loops, probably nothing to
worry about, the finite loops are much more important.

[Bug fortran/62283] basic-block vectorization fails

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Biener  ---
Author: rguenth
Date: Tue Apr 28 08:30:44 2015
New Revision: 222514

URL: https://gcc.gnu.org/viewcvs?rev=222514&root=gcc&view=rev
Log:
2015-04-28  Richard Biener  

PR tree-optimization/62283
* tree-vect-slp.c (vect_build_slp_tree): When the SLP build
fails fatally and we are vectorizing a basic-block simply
cause the child to be constructed piecewise.
(vect_analyze_slp_cost_1): Adjust.
(vect_detect_hybrid_slp_stmts): Likewise.
(vect_bb_slp_scalar_cost): Likewise.
(vect_get_constant_vectors): For piecewise constructed
constants place them after the last def.
(vect_get_slp_defs): Adjust.
* tree-vect-stmts.c (vect_is_simple_use): Detect in-BB
externals for basic-block vectorization.

* gfortran.dg/vect/pr62283-2.f: New testcase.
* gcc.dg/vect/bb-slp-14.c: Adjust.

Added:
trunk/gcc/testsuite/gfortran.dg/vect/pr62283-2.f
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/bb-slp-14.c
trunk/gcc/tree-vect-slp.c
trunk/gcc/tree-vect-stmts.c

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 62283, which changed state.

Bug 62283 Summary: basic-block vectorization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62283

   What|Removed |Added

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

[Bug fortran/62283] basic-block vectorization fails

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #22 from Richard Biener  ---
Fixed for GCC 6.

[Bug c/65901] no warning or error for va_arg (ap, void)

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Tue Apr 28 08:36:50 2015
New Revision: 222515

URL: https://gcc.gnu.org/viewcvs?rev=222515&root=gcc&view=rev
Log:
PR c/65901
* c-typeck.c (c_build_va_arg): Require TYPE be a complete type.

* gcc.c-torture/compile/pr48767.c (foo): Add dg-error.
* gcc.dg/pr65901.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr65901.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/compile/pr48767.c

[Bug c/65901] no warning or error for va_arg (ap, void)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed for GCC 6.

[Bug target/65832] Inefficient vector construction

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Another example where the vectorizer thinks vectorization is profitable:

#define N 16

unsigned int out[N];
unsigned int in[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};

__attribute__ ((noinline)) int
main1 (unsigned int x, unsigned int y)
{
  int i;
  unsigned int a0, a1, a2, a3;

  a0 = in[0];
  a1 = in[1];
  a2 = in[2];
  a3 = in[3];

  out[0] = a0 * x;
  out[1] = a1 * y;
  out[2] = a2 * x;
  out[3] = a3 * y;
}

generates

main1:
.LFB0:
.cfi_startproc
movl%edi, -12(%rsp)
movd-12(%rsp), %xmm0
movl%esi, -12(%rsp)
movd-12(%rsp), %xmm3
movdqa  in(%rip), %xmm2
punpckldq   %xmm3, %xmm0
psrlq   $32, %xmm2
punpcklqdq  %xmm0, %xmm0
movdqa  %xmm0, %xmm1
psrlq   $32, %xmm0
pmuludq %xmm2, %xmm0
pshufd  $8, %xmm0, %xmm0
pmuludq in(%rip), %xmm1
pshufd  $8, %xmm1, %xmm1
punpckldq   %xmm0, %xmm1
movaps  %xmm1, out(%rip)
ret

slightly less obfuscated when we allow gpr xmm moves with -mtune=intel:

main1:
.LFB0:
.cfi_startproc
movd%edi, %xmm0
movd%esi, %xmm3
movdqa  in(%rip), %xmm2
punpckldq   %xmm3, %xmm0
punpcklqdq  %xmm0, %xmm0
psrlq   $32, %xmm2
movdqa  %xmm0, %xmm1
psrlq   $32, %xmm0
pmuludq in(%rip), %xmm1
pmuludq %xmm2, %xmm0
pshufd  $8, %xmm1, %xmm1
pshufd  $8, %xmm0, %xmm0
punpckldq   %xmm0, %xmm1
movdqa  %xmm1, out(%rip)
ret

so for { x, y, x, y } construction we generate

movd%edi, %xmm0
movd%esi, %xmm3
punpckldq   %xmm3, %xmm0
punpcklqdq  %xmm0, %xmm0

no f*** idea where all the shifting and shuffling comes from...

This is just

  vect_cst_.7_18 = {x_6(D), y_9(D), x_6(D), y_9(D)};
  vect_a0_2.5_17 = MEM[(unsigned int *)&in];
  vect__7.6_19 = vect_a0_2.5_17 * vect_cst_.7_18;
  MEM[(unsigned int *)&out] = vect__7.6_19;

[Bug target/65832] Inefficient vector construction

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||uros at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
Somehow we get into very weird initial RTL generated by expand...

(insn 12 11 13 (set (reg:V2DI 101)
(mult:V2DI (zero_extend:V2DI (vec_select:V2SI (reg:V4SI 95 [
vect_cst_.7 ])
(parallel [
(const_int 0 [0])
(const_int 2 [0x2])
])))
(zero_extend:V2DI (vec_select:V2SI (mem/c:V4SI (reg/f:DI 94) [1
MEM[(unsigned int *)&in]+0 S16 A256])
(parallel [
(const_int 0 [0])
(const_int 2 [0x2])
]) t.c:17 -1
 (nil))

(WTF!?  As if there were no integer vector multiply with SSE2 but only DImode
ones?!)

[Bug c++/42033] libstdc++ seems to miss std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
(In reply to Manoj from comment #12)
> I am facing a similar issue. Following is the error that I am facing at run
> time:

This is not similar at all. This bug was about a failure to link, if you are
getting an error at run-time then you have successfully linked and it is not
the same issue.

Instead of commenting here please try emailing the gcc-h...@gcc.gnu.org mailing
list, including a more complete description of your problem (you didn't say
what's wrong, just showed a stack trace).

[Bug other/65911] [6 Regression] r222508 breaks clang-tblgen

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-04-28
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
It's the ternary operator that causes the issue. 
The following patch works fine:

diff --git a/gcc/function.c b/gcc/function.c
index d1a2c0a..0930bb0 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -4195,9 +4195,9 @@ pad_to_arg_alignment (struct args_size *offset_ptr, int
boundary,
   else
{
  offset_ptr->constant = -sp_offset +
-   ARGS_GROW_DOWNWARD ?
+   (ARGS_GROW_DOWNWARD ?
FLOOR_ROUND (offset_ptr->constant + sp_offset, boundary_in_bytes) :
-   CEIL_ROUND (offset_ptr->constant + sp_offset, boundary_in_bytes);
+   CEIL_ROUND (offset_ptr->constant + sp_offset, boundary_in_bytes));

if (boundary > PARM_BOUNDARY)
  alignment_pad->constant = offset_ptr->constant - save_constant;

[Bug other/65911] [6 Regression] r222508 breaks clang-tblgen

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

--- Comment #2 from Richard Biener  ---
pre-approved.

[Bug bootstrap/65910] r222473 breaks x86_64 darwin bootstrap

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Looks obvious to me.

[Bug other/65911] [6 Regression] r222508 breaks clang-tblgen

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
The formatting is also wrong, both ? and : shouldn't be at the end of lines,
but at the start.  Patch with the formatting fixes included preapproved for
trunk.

[Bug rtl-optimization/65912] New: x_rtl.x_frame_offset not updated after frame related insn deleted

[jiwang at gcc dot gnu.org]

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

Bug ID: 65912
   Summary: x_rtl.x_frame_offset not updated after frame related
insn deleted
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jiwang at gcc dot gnu.org
  Target Milestone: ---

given the following simple test.c

typedef unsigned long int uint64_t;
typedef __Uint8x8_t uint8x8_t;

typedef struct uint8x8x4_t
{
  uint8x8_t val[4];
} uint8x8x4_t;

__inline uint8x8_t
bar (uint64_t __a)
{
  return (uint8x8_t) __a;
}

uint8x8x4_t foo(uint8x8x4_t v1, uint8x8x4_t v2)
{
  return (uint8x8x4_t){{bar(0), bar(0), bar(0), bar(0)}};
}

on aarch64, compile it with "./cc1-aarch64 -std=c99 -Wall -O3
-ftree-vectorizer-verbose=3"

foo:
moviv0.2s, 0
sub sp, sp, #128  <== useless stack adjustment
add sp, sp, 128   <== useless stack adjustment
...

There are useless stack adjustment. A quick investigation shows it's caued by
we first decide to put the return value on stack, then later optimized them
into registers, and all those store to stack are deleted by dse1, but stack
space required kept in x_rtl->x_frame_offset is not updated accordingly.

Although I run into this issue on AArch64, I highly suspect it's a generic
issue when the type of return value is very complex.

Has anyone run into this issue on other architecture like MIPS, PPC?

[Bug libstdc++/65913] New: Linking failure without -latomic

[yan12125 at gmail dot com]

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

Bug ID: 65913
   Summary: Linking failure without -latomic
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yan12125 at gmail dot com
  Target Milestone: ---

#include 
#include 

struct Simple1 { int i; };

int main()
{
std::atomic s1;
std::cout << std::boolalpha << s1.is_lock_free() << '\n';
return 0;
}

On GCC 5.1.0, the following program can't be compiled without -latomic:

g++ -v test.cpp -std=c++11
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc-multilib/src/gcc-5.1.0/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --with-default-libstdcxx-abi=c++98
Thread model: posix
gcc version 5.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/cc1plus -quiet -v -D_GNU_SOURCE
test.cpp -quiet -dumpbase test.cpp -mtune=generic -march=x86-64 -auxbase test
-std=c++11 -version -o /tmp/ccrpKTDe.s
GNU C++11 (GCC) version 5.1.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.1.0, GMP version 6.0.0, MPFR version
3.1.2-p11, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0

/usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0/x86_64-unknown-linux-gnu

/usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0/backward
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/include
 /usr/local/include
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/include-fixed
 /usr/include
End of search list.
GNU C++11 (GCC) version 5.1.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.1.0, GMP version 6.0.0, MPFR version
3.1.2-p11, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 13af7a32108dcf1445ef29e0b81ed4a1
COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 as -v --64 -o /tmp/ccb54wZN.o /tmp/ccrpKTDe.s
GNU assembler version 2.25.0 (x86_64-unknown-linux-gnu) using BFD version (GNU
Binutils) 2.25.0
COMPILER_PATH=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/:/usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/:/usr/lib/gcc/x86_64-unknown-linux-gnu/:/usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/:/usr/lib/gcc/x86_64-unknown-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/:/usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/collect2 -plugin
/usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccoH7Vln.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --build-id
--eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2
/usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../lib/crt1.o
/usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../lib/crti.o
/usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/crtbegin.o
-L/usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0
-L/usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../..
/tmp/ccb54wZN.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/crtend.o
/usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../lib/crtn.o
/tmp/ccb54wZN.o: In function `std::atomic::is_lock_free() const':
test.cpp:(.text._ZNKSt6atomicI7Simple1E12is_lock_freeEv[_ZNKSt6atomicI7Simple1E12is_lock_freeEv]+

[Bug other/65911] [6 Regression] r222508 breaks clang-tblgen

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
Author: trippels
Date: Tue Apr 28 10:09:43 2015
New Revision: 222521

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

2015-04-28  Markus Trippelsdorf  

PR other/65911
* function.c (pad_to_arg_alignment): Add parentheses.

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

[Bug other/65911] [6 Regression] r222508 breaks clang-tblgen

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #5 from Markus Trippelsdorf  ---
Fixed.

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[prathamesh3492 at gcc dot gnu.org]

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

prathamesh3492 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||mkuvyrkov at gcc dot gnu.org

--- Comment #14 from prathamesh3492 at gcc dot gnu.org ---
Hi,
Following Maxim's suggestion I tried to build with x86_64-gcc passing -mtune=k8
at compile-time but not at link time and the same thing happens.

gcc -flto -mtune=k8 foo.c -v:

Without passing -mtune=k8 at link-time, -mtune=generic overrides -mtune=k8
gcc -flto foo.o -v:

COLLECT_GCC_OPTIONS='-c' '-fmath-errno' '-fsigned-zeros' '-ftrapping-math'
'-fno-trapv' '-fno-strict-overflow' '-fno-openmp' '-fno-openacc' '-mtune=k8'
'-march=x86-64' '-v' '-mtune=generic' '-march=x86-64'
'-fltrans-output-list=/tmp/cc415lAT.ltrans.out' '-fwpa'
'-fresolution=/tmp/ccuL4EuS.res'

/home/prathamesh.kulkarni/fsf-toolchain/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto1
-quiet -dumpbase foo.o -mtune=k8 -march=x86-64 -mtune=generic -march=x86-64
-auxbase foo -version -fmath-errno -fsigned-zeros -ftrapping-math -fno-trapv
-fno-strict-overflow -fno-openmp -fno-openacc
-fltrans-output-list=/tmp/cc415lAT.ltrans.out -fwpa
-fresolution=/tmp/ccuL4EuS.res @/tmp/ccXLZx2S

Passing -mtune=k8 at link-time, passes only -mtune=k8 to lto1 
gcc -flto -mtune=k8 foo.o -v:

COLLECT_GCC_OPTIONS='-c' '-fmath-errno' '-fsigned-zeros' '-ftrapping-math'
'-fno-trapv' '-fno-strict-overflow' '-fno-openmp' '-fno-openacc' '-mtune=k8'
'-march=x86-64' '-mtune=k8' '-v' '-march=x86-64'
'-fltrans-output-list=/tmp/ccK0THy1.ltrans.out' '-fwpa'
'-fresolution=/tmp/ccqMHR7Y.res'

/home/prathamesh.kulkarni/fsf-toolchain/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto1
-quiet -dumpbase foo.o -mtune=k8 -march=x86-64 -mtune=k8 -march=x86-64 -auxbase
foo -version -fmath-errno -fsigned-zeros -ftrapping-math -fno-trapv
-fno-strict-overflow -fno-openmp -fno-openacc
-fltrans-output-list=/tmp/ccK0THy1.ltrans.out -fwpa
-fresolution=/tmp/ccqMHR7Y.res @/tmp/ccxcdoB1

So this looks like a target independent bug ? I am continuing to investigate
it.

Thank you,
Prathamesh

[Bug spam/9353] 20010525035601.4254.qmail,this would be for youwe could enter that

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Component|pending |spam
 Resolution|FIXED   |INVALID

[Bug spam/9360] 20010525035601.4254.qmail,this would be for youwe could enter that

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Component|pending |spam
 Resolution|FIXED   |INVALID

[Bug spam/10531] denoxe barth

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Component|pending |spam
 Resolution|FIXED   |INVALID

[Bug target/65914] New: [6 Regression] error: unrecognizable insn

[trippels at gcc dot gnu.org]

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

Bug ID: 65914
   Summary: [6 Regression] error: unrecognizable insn
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64le-unknown-linux-gnu
Target: powerpc64le-unknown-linux-gnu
 Build: powerpc64le-unknown-linux-gnu

Running the Boost testsuite on ppc64le shows:

trippels@gcc2-power8 status % g++ -O3 -c -std=c++14 unordered_set_test.ii
../libs/intrusive/test/unordered_set_test.cpp: In static member function
‘static void test_unordered_set::test_rehash(std::vector&,
boost::move_detail::true_) [with ValueTraits =
boost::intrusive::mhtraits, false>,
boost::intrusive::unordered_set_member_hook,
boost::intrusive::optimize_multikey, void, void>,
&boost::intrusive::testvalue, false>::node_>; bool CacheBegin =
false; bool CompareHash = false; bool Incremental = true; typename
ValueTraits::value_type = boost::intrusive::testvalue, false>;
boost::move_detail::true_ = boost::move_detail::bool_]’:
../libs/intrusive/test/unordered_set_test.cpp:448:1: error: unrecognizable
insn:
 }
 ^
(insn 72 71 73 2 (set (reg:V2DI 540 [ vect_cst_.26426 ])
(vec_concat:V2DI (reg/f:DI 150 virtual-stack-vars [ D.668853 ])
(reg:DI 541 [ D.668853 ])))
../boost/intrusive/detail/slist_node.hpp:55 -1
 (nil))
../libs/intrusive/test/unordered_set_test.cpp:448:1: internal compiler error:
in extract_insn, at recog.c:2341
0x109a7e33 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:110
0x109a7eaf _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:118
0x1096d767 extract_insn(rtx_insn*)
../../gcc/gcc/recog.c:2341
0x106c98bb instantiate_virtual_regs_in_insn
../../gcc/gcc/function.c:1598
0x106c98bb instantiate_virtual_regs
../../gcc/gcc/function.c:1966
0x106c98bb execute
../../gcc/gcc/function.c:2015
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Reducing...

[Bug target/65915] New: [6 Regression] FAIL: gcc.target/i386/avx512f-vrndscalepd-2.c (internal compiler error)

[hjl.tools at gmail dot com]

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

Bug ID: 65915
   Summary: [6 Regression] FAIL:
gcc.target/i386/avx512f-vrndscalepd-2.c (internal
compiler error)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: tocarip.intel at gmail dot com
  Target Milestone: ---

On x86-64, r222470 caused:

[hjl@gnu-ivb-1 gcc]$ ./xgcc -B./
/export/gnu/import/git/gcc-regression/gcc/gcc/testsuite/gcc.target/i386/avx512f-vrndscalepd-2.c
 -fpic -mcmodel=medium   -fno-diagnostics-show-caret -fdiagnostics-color=never 
 -O2 -mavx512f  -S
/export/gnu/import/git/gcc-regression/gcc/gcc/testsuite/gcc.target/i386/avx512f-vrndscalepd-2.c:
In function \u2018test_512\u2019:
/export/gnu/import/git/gcc-regression/gcc/gcc/testsuite/gcc.target/i386/avx512f-vrndscalepd-2.c:101:1:
error: insn does not satisfy its constraints:
(insn 367 366 319 9 (set (reg:V2DF 53 xmm16 [ D.29386 ])
(vec_merge:V2DF (vec_duplicate:V2DF (float:DF (reg:SI 2 cx [orig:96
D.29385 ] [96])))
(reg:V2DF 53 xmm16 [ D.29386 ])
(const_int 1 [0x1]))) 2191 {sse2_cvtsi2sd}
 (expr_list:REG_DEAD (reg:SI 2 cx [orig:96 D.29385 ] [96])
(nil)))
/export/gnu/import/git/gcc-regression/gcc/gcc/testsuite/gcc.target/i386/avx512f-vrndscalepd-2.c:101:1:
internal compiler error: in extract_constrain_insn, at recog.c:2244
0xcf4a34 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../../../gcc/gcc/rtl-error.c:110
0xcf4a94 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../../../gcc/gcc/rtl-error.c:121
0xca7059 extract_constrain_insn(rtx_insn*)
../../../../gcc/gcc/recog.c:2244
0xcb5847 copyprop_hardreg_forward_1
../../../../gcc/gcc/regcprop.c:793
0xcb704b execute
../../../../gcc/gcc/regcprop.c:1289
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-ivb-1 gcc]$

[Bug target/65915] [6 Regression] FAIL: gcc.target/i386/avx512f-vrndscalepd-2.c (internal compiler error)

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

--- Comment #1 from H.J. Lu  ---
Total regressions with -fpic -mcmodel=medium are:

FAIL: gcc.target/i386/avx512f-vrndscalepd-2.c (internal compiler error)
FAIL: gcc.target/i386/avx512f-vrndscalepd-2.c (test for excess errors)
FAIL: gcc.target/i386/avx512f-vrndscaleps-2.c (internal compiler error)
FAIL: gcc.target/i386/avx512f-vrndscaleps-2.c (test for excess errors)
FAIL: gcc.target/i386/avx512vl-vrndscaleps-2.c (internal compiler error)
FAIL: gcc.target/i386/avx512vl-vrndscaleps-2.c (test for excess errors)

[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0

[juergen.reuter at desy dot de]

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

--- Comment #10 from Jürgen Reuter  ---
(In reply to Dominique d'Humieres from comment #9)
> > With the attached patch your small test case and the test suite runs
> > w/o segfault now. Furthermore does gcc6 bootstrap and regtest ok
> > with the patch.
> 
> Confirmed. The bigger test in comment 2 runs without segfault also. However
> I get an ICE when compiling the full package at
> http://whizard.hepforge.org/versions/unofficial/whizard-2.2.6_alpha-20150426.
> tar.gz
> 
> libtool: compile:  gfc -I../basics -I../utilities -I../testing -I../system
> -I../combinatorics -I../expr_base -I../physics -g -O2 -c evaluators.f90 
> -fno-common -o .libs/evaluators.o
> evaluators.f90:897:0:
> 
>   .or. qn_mask_rest
>  1
> internal compiler error: in gfc_trans_assignment_1, at
> fortran/trans-expr.c:9203


I confirm this ICE with the patch and will provide a smaller test case soon.

[Bug libgcc/62097] mipsel-sde-elf build fails on OS X 10.7 host

[paul at xk7 dot net]

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

Paul Waring  changed:

   What|Removed |Added

 CC||paul at xk7 dot net

--- Comment #3 from Paul Waring  ---
I can confirm the same issue occurs for me on OS X  10.10 (Yosemite) and the
following:

GCC: 4.9.2
binutils: 2.25
MPFR: 3.1.2
MPC: 1.0.3
GMP: 6.0.0a
Newlib: 2.2.0-1

clang --version
Apple LLVM version 6.1.0 (clang-602.0.49) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.3.0
Thread model: posix

Is there anything I can do to help fix this bug?

[Bug libstdc++/65631] seed_seq should not be copyable

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #2 from Jonathan Wakely  ---
done

[Bug libstdc++/65631] seed_seq should not be copyable

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Tue Apr 28 12:35:30 2015
New Revision: 222524

URL: https://gcc.gnu.org/viewcvs?rev=222524&root=gcc&view=rev
Log:
PR libstdc++/65631
* include/bits/random.h (seed_seq) Define copy constructor and copy
assignment as deleted.
* testsuite/26_numerics/random/seed_seq/cons/65631.cc: New.

Added:
trunk/libstdc++-v3/testsuite/26_numerics/random/seed_seq/cons/65631.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/random.h

[Bug target/65871] bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com

--- Comment #2 from Uroš Bizjak  ---
Created attachment 35411
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35411&action=edit
Prototype patch for bextr and bzhi

Prototype patch that removes flag checks for bextr and bzhi insns.

[Bug libstdc++/61645] forward_list::splice_after shall not throw exceptions

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Tue Apr 28 13:05:33 2015
New Revision: 222525

URL: https://gcc.gnu.org/viewcvs?rev=222525&root=gcc&view=rev
Log:
PR libstdc++/61645
* include/bits/forward_list.h (forward_list::splice_after): Add
noexcept.
* include/bits/forward_list.tcc (forward_list::splice_after):
Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/forward_list.h
trunk/libstdc++-v3/include/bits/forward_list.tcc

[Bug libstdc++/61645] forward_list::splice_after shall not throw exceptions

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
done

[Bug target/65871] bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-04-28
 Ever confirmed|0   |1

--- Comment #3 from Uroš Bizjak  ---
(In reply to James Almer from comment #1)
> The same apparently happens with bextr, blsi, blsr, and most (if not all) of
> AMD's tbm instructions. They set the ZF flag but gcc still generates a test
> instruction.

Please see the patch, attached in Comment #2.

While I can see the use (and benefit) to model the patterns that also set CC
register internally for BEXTR and BZHI instructions, I don't think other listed
instructions have clear usage scenarios to warrant additional patterns.

Can you perhaps show the benefit to have more insns modelled this way?

[Bug c/65916] New: Unnecessary floating-point instruction causes runtime exception on PowerPC

[nikolay.pakulin at gmail dot com]

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

Bug ID: 65916
   Summary: Unnecessary floating-point instruction causes runtime
exception on PowerPC
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nikolay.pakulin at gmail dot com
  Target Milestone: ---

Created attachment 35412
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35412&action=edit
Test case to reproduce the issue

Writing 64-bit integers to memory on 32-bit PPC involves floating point
register FP0.  When floating-point support is disabled (bit FP is cleared in
MSR register) the generated code leads to exception "FP unavailable interrupt".

The test case compiled by GCC cross compiler running on x86_64 Linux.

powerpc-elf-gcc -S -m32 -mcpu=e500mc uint64.c


-- uint64.c --
typedef unsigned long long u64;

u64 globvar;

void f(u64 arg) { 
  globvar = arg;
}
-- /uint64.c --

-- Generated ASM --
f:
stwu 1,-32(1)
stw 31,28(1)
mr 31,1
stw 3,8(31) # Copies 'arg' to the temporary on the stack
stw 4,12(31)# 
lis 9,globvar@ha
la 9,globvar@l(9)
lfd 0,8(31) # Loads the temporary to FP0 -- exception!
stfd 0,0(9) # Store FP0 to memory
addi 11,31,32
lwz 31,-4(11)
mr 1,11
blr
-- End of Generated ASM --

== GCC specs ==
Using built-in specs.
COLLECT_GCC=powerpc-elf-gcc
COLLECT_LTO_WRAPPER=/opt/crosstools/powerpc-elf-4.9.1-Linux-x86_64/bin/../libexec/gcc/powerpc-elf/4.9.1/lto-wrapper
Target: powerpc-elf
Configured with: ../gcc-4.9.1/configure --target=powerpc-elf
--prefix=/home/geist/svn/toolchains/powerpc-elf-4.9.1-Linux-x86_64
--enable-languages=c,c++ --disable-werror
Thread model: single
gcc version 4.9.1 (GCC) 
== End of GCC specs ==

The workaround is to compile with optimization turned on. With -O switch GCC
produces ASM without FP0:

powerpc-elf-gcc -S -m32 -mcpu=e500mc -O uint64.c
-- Generated optimized ASM --
f:
lis 9,globvar@ha
la 9,globvar@l(9)
stw 3,0(9)# direct write to the destination
stw 4,4(9)# 
blr
-- End of generated optimized ASM --

[Bug libstdc++/65913] Linking failure without -latomic

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
This is due to the changes for Bug 65033

[Bug libstdc++/60333] type_traits make_signed, make_unsigned missing support for long long enumerations

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Tue Apr 28 13:21:54 2015
New Revision: 222526

URL: https://gcc.gnu.org/viewcvs?rev=222526&root=gcc&view=rev
Log:
PR libstdc++/60333
* include/std/type_traits (__make_unsigned_selector<_Tp, false, true>):
Handle enumeration types larger than sizeof(long).
(__make_signed_selector<_Tp, false, true>): Find unsigned type then
make it signed.
* testsuite/20_util/declval/requirements/1_neg.cc: Adjust dg-error.
* testsuite/20_util/make_signed/requirements/typedefs_neg.cc:
Likewise.
* testsuite/20_util/make_signed/requirements/typedefs-3.cc: New.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc: Adjust
dg-error.
* testsuite/20_util/make_unsigned/requirements/typedefs-3.cc: New.

Added:
trunk/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-3.cc
   
trunk/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-3.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/type_traits
trunk/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc
   
trunk/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc
   
trunk/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc

[Bug libstdc++/60333] type_traits make_signed, make_unsigned missing support for long long enumerations

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #3 from Jonathan Wakely  ---
Fixed on trunk

[Bug libgcc/65902] GCC-5.1 fails to bootstrap for eCos/arm-eabi

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Target||arm-eabi

--- Comment #2 from Richard Earnshaw  ---
The standard headers should only be defining bool if stdbool.h has been
included.  So this looks more like a build environment error than a bug in GCC.

[Bug tree-optimization/65917] New: [6.0 regression] FAIL: gcc.dg/tree-ssa/20030922-2.c scan-tree-dump-times dom1 "if " 2

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

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

Bug ID: 65917
   Summary: [6.0 regression] FAIL: gcc.dg/tree-ssa/20030922-2.c
scan-tree-dump-times dom1 "if " 2
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: m68k-*-*

$ gcc/xgcc -B gcc/ -O1 -fdump-tree-dom1 -S
../gcc/testsuite/gcc.dg/tree-ssa/20030922-2.c && grep -c "if " 20030922-2.c.*
3

83617aa2bed0a6ac21010ba3b960d087bcb66f9b is the first bad commit
commit 83617aa2bed0a6ac21010ba3b960d087bcb66f9b
Author: rguenth 
Date:   Mon Apr 27 12:46:58 2015 +

2015-04-27  Richard Biener  

* tree-ssa-dom.c (record_equivalences_from_phis): Valueize PHI arg.
(record_equivalences_from_stmt): Valueize rhs.
(record_equality): Canonicalize x and y order via
tree_swap_operands_p.  Do not swap operands for same loop depth.

* gcc.target/i386/pr65217.c: XFAIL.

[Bug tree-optimization/65917] [6.0 regression] FAIL: gcc.dg/tree-ssa/20030922-2.c scan-tree-dump-times dom1 "if " 2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-04-28
 CC||law at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Fixed by Jeffs later patch?

[Bug target/65914] [6 Regression] error: unrecognizable insn

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #15 from prathamesh3492 at gcc dot gnu.org ---
Hi,
I am not entirely sure, the issue seems to be in lto-wrapper.
In lto-wrapper.c:run_gcc():
fdecoded_options, which are compiler options contains "-mfpu=neon"
decoded_options, which are linker options contains "-mfpu=vfpv3-d16".
decoded_options are populated by 
lto-wrapper.c:get_options_from_collect_gcc_options() from environment
variable COLLECT_GCC_OPTIONS.

fdecoded_options are appended after decoded_options in run_gcc():

  append_linker_options (&argv_obstack, decoded_options,
decoded_options_count);
  append_compiler_options (&argv_obstack, fdecoded_options,
   fdecoded_options_count);

which is why -mfpu=vfpv3-d16 overrides -mfpu=neon.

Reversing the order of above function calls works fine for me
for the above test-case.

However I am not sure if this is the right approach,
It now passes -mfpu=vfpv3-d16 and then it's overriden by -mfpu=neon
since we reversed the order.
Ideally we don't want -mfpu=vfpv3-d16 to appear ?

I am not understanding why vfpv3-d16 appears in collect_gcc_options in
run_gcc().
While writing COLLECT_GCC_OPTIONS in
lto-opts.c:append_to_collect_gcc_options(), -mfpu=vfpv3-d16 is not present,
Only -mfpu=neon is present, which is correct since it was passed as a command
line option.

I am not sure what modifies COLLECT_GCC_OPTIONS before it is read by run_gcc()
in lto-wrapper.

Thank you,
Prathamesh

[Bug tree-optimization/65918] New: Optimized code (> -O0) on 2-dim array iteration incorrect

[habanero_pizza at yahoo dot com]

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

Bug ID: 65918
   Summary: Optimized code (> -O0) on 2-dim array iteration
incorrect
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: habanero_pizza at yahoo dot com
  Target Milestone: ---
  Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
 Build: i686-pc-linux-gnu

Created attachment 35413
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35413&action=edit
Test case source:  execution fails if OKAY is not defined...

When the following function is compiled with gcc 4.8.3, 4.9.2, or 5.1.0, it
only executes properly when no optimization is specified (-O0):

int f(int value, int type)
{
static const int limits[2][3] = {
{ 400, 480, 512 },
{ 460, 492, 500 }
};

int retval = 0;

while ((value > limits[type][retval]) && (retval < 3)) {
retval++;
}

return retval;
}

The problem is in the case where retval should be 3; for example, if value is
550 and type is 0, the retval should be 3, but the function will return 2.  For
cases where the function is supposed to return 0, 1, or 2, it does work
correctly.

However, if gcc 4.6.4 or gcc 4.7.2 is used, it works correctly with and without
optimization.

If the loop is changed to use an array of a single dimension, the problem is
also eliminated (4.8, 4.9, 5.1):

const int *limit = limits[type];

while ((value > limit[retval]) && (retval < 3)) {
retval++;
}

I have also confirmed that the problem appears for x86_64 and ARM
architectures.

See attached file (test-opt-2-dim-array-iter.c) for further information.

Compilation details:

Using built-in specs.
COLLECT_GCC=i386-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/local/i386-eabi-5.1.0/libexec/gcc/i686-pc-linux-gnu/5.1.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../../gcc-5.1.0/configure --prefix=/usr/local/i386-eabi-5.1.0
--program-prefix=i386-eabi- --enable-languages=c,c++
--with-gmp=/usr/local/i386-eabi-5.1.0 --with-mpfr=/usr/local/i386-eabi-5.1.0
--with-mpc=/usr/local/i386-eabi-5.1.0 --with-isl=/usr/local/i386-eabi-5.1.0
--with-zlib=/usr/local --enable-lto --enable-gold
Thread model: posix
gcc version 5.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-O1' '-v' '-save-temps' '-o' 'test-opt-2-dim-array-iter'
'-mtune=generic' '-march=pentiumpro'
 /usr/local/i386-eabi-5.1.0/libexec/gcc/i686-pc-linux-gnu/5.1.0/cc1 -E -quiet
-v test-opt-2-dim-array-iter.c -mtune=generic -march=pentiumpro -O1
-fpch-preprocess -o test-opt-2-dim-array-iter.i
ignoring nonexistent directory
"/usr/local/i386-eabi-5.1.0/lib/gcc/i686-pc-linux-gnu/5.1.0/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/i386-eabi-5.1.0/lib/gcc/i686-pc-linux-gnu/5.1.0/include
 /usr/local/include
 /usr/local/i386-eabi-5.1.0/include
 /usr/local/i386-eabi-5.1.0/lib/gcc/i686-pc-linux-gnu/5.1.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-O1' '-v' '-save-temps' '-o' 'test-opt-2-dim-array-iter'
'-mtune=generic' '-march=pentiumpro'
 /usr/local/i386-eabi-5.1.0/libexec/gcc/i686-pc-linux-gnu/5.1.0/cc1
-fpreprocessed test-opt-2-dim-array-iter.i -quiet -dumpbase
test-opt-2-dim-array-iter.c -mtune=generic -march=pentiumpro -auxbase
test-opt-2-dim-array-iter -O1 -version -o test-opt-2-dim-array-iter.s
GNU C11 (GCC) version 5.1.0 (i686-pc-linux-gnu)
compiled by GNU C version 5.1.0, GMP version 5.1.3, MPFR version 3.1.2,
MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (GCC) version 5.1.0 (i686-pc-linux-gnu)
compiled by GNU C version 5.1.0, GMP version 5.1.3, MPFR version 3.1.2,
MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: d06407f4e6fff3c174315d9bcdf98d85
COLLECT_GCC_OPTIONS='-O1' '-v' '-save-temps' '-o' 'test-opt-2-dim-array-iter'
'-mtune=generic' '-march=pentiumpro'

/usr/local/i386-eabi-5.1.0/lib/gcc/i686-pc-linux-gnu/5.1.0/../../../../i686-pc-linux-gnu/bin/as
-v --32 -o test-opt-2-dim-array-iter.o test-opt-2-dim-array-iter.s
GNU assembler version 2.25 (i686-pc-linux-gnu) using BFD version (GNU Binutils)
2.25
COMPILER_PATH=/usr/local/i386-eabi-5.1.0/libexec/gcc/i686-pc-linux-gnu/5.1.0/:/usr/local/i386-eabi-5.1.0/libexec/gcc/i686-pc-linux-gnu/5.1.0/:/usr/local/i386-eabi-5.1.0/libexec/gcc/i686-pc-linux-gnu/:/usr/local/i386-eabi-5.1.0/lib/gcc/i686-pc-linux-gnu/5.1.0/:/usr/local/i386-eabi-5.1.0/lib/gcc/i686-pc-linux-gnu/:/usr/local/i386-eabi-5.1.0/lib/gcc/i686-pc-linux-gnu/5.1.0/../../../../i686-pc-linux-gnu/bin/
LIBRARY_PATH=/usr/local/i386-eabi-5.1.0/lib/gcc/i686-pc-linux-gnu/5.1.0/:/usr/local/i386-eabi-5.1.0/lib/gcc/i686-pc-linux-gnu/5.1.0/../../../:/lib/:/usr/lib/
COLLE

[Bug libgcc/65902] GCC-5.1 fails to bootstrap for eCos/arm-eabi

[bernd.edlinger at hotmail dot de]

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

--- Comment #3 from Bernd Edlinger  ---
(In reply to Richard Earnshaw from comment #2)
> The standard headers should only be defining bool if stdbool.h has been
> included.  So this looks more like a build environment error than a bug in
> GCC.

yes. that is not too smart to define bool in the wrong header...

but somehow we are also defining that in the wrong place?

[Bug tree-optimization/65918] Optimized code (> -O0) on 2-dim array iteration incorrect

[habanero_pizza at yahoo dot com]

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

J. W. Mitchell  changed:

   What|Removed |Added

 CC||habanero_pizza at yahoo dot com

--- Comment #1 from J. W. Mitchell  ---
Created attachment 35414
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35414&action=edit
Preprocessed test case.

[Bug tree-optimization/65217] __builtin_unreachable in if statement causes bad assembly generation

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #5 from Jeffrey A. Law  ---
Resolved again :-)

[Bug target/65914] [6 Regression] error: unrecognizable insn

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
Created attachment 35415
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35415&action=edit
Somewhat reduced testcase

[Bug other/65911] [6 Regression] r222508 breaks clang-tblgen

[tbsaunde at tbsaunde dot org]

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

--- Comment #6 from tbsaunde at tbsaunde dot org ---
On Tue, Apr 28, 2015 at 03:59:05AM +, trippels at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65911
> 
> Markus Trippelsdorf  changed:
> 
>What|Removed |Added
> 
>  Status|UNCONFIRMED |NEW
>Last reconfirmed||2015-04-28
>  Ever confirmed|0   |1
> 
> --- Comment #1 from Markus Trippelsdorf  ---
> It's the ternary operator that causes the issue. 
> The following patch works fine:

huh, thanks for figuring it out!

Trev

[Bug c++/65734] Yet another case of lost alignment by stor_layout

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Tue Apr 28 14:43:48 2015
New Revision: 222529

URL: https://gcc.gnu.org/viewcvs?rev=222529&root=gcc&view=rev
Log:
PR c++/65734
gcc/
* stor-layout.c (layout_type): Layout the TYPE_MAIN_VARIANT.
(finalize_type_size): Respect TYPE_USER_ALIGN.
(layout_type) [ARRAY_TYPE]: Likewise.
gcc/cp/
* class.c (fixup_attribute_variants): Respect TYPE_USER_ALIGN.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/alignas1.C
trunk/gcc/testsuite/g++.dg/cpp0x/alignas2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/stor-layout.c

[Bug c++/50800] Internal compiler error in finish_member_declarations, possibly related to may_alias attribute

[jason at gcc dot gnu.org]

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

--- Comment #16 from Jason Merrill  ---
Author: jason
Date: Tue Apr 28 14:43:54 2015
New Revision: 222530

URL: https://gcc.gnu.org/viewcvs?rev=222530&root=gcc&view=rev
Log:
PR c++/50800
* tree.c (strip_typedefs): Add remove_attributes parm.
(strip_typedefs_expr): Likewise.
(apply_identity_attributes): New subroutine of strip_typedefs.
* pt.c (canonicalize_type_argument): Let strip_typedefs handle attrs.
(convert_nontype_argument, unify): Likewise.
* cp-tree.h: Adjust.

Added:
trunk/gcc/testsuite/g++.dg/ext/attrib50.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/g++.dg/abi/mangle40.C
trunk/gcc/testsuite/g++.dg/ext/alias-mangle.C

[Bug c++/65656] __builtin_constant_p should always be constexpr

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Tue Apr 28 14:43:59 2015
New Revision: 222531

URL: https://gcc.gnu.org/viewcvs?rev=222531&root=gcc&view=rev
Log:
PR c++/65656
* constexpr.c (cxx_eval_builtin_function_call): Fix
__builtin_constant_p.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-builtin3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c

[Bug tree-optimization/65918] Optimized code (> -O0) on 2-dim array iteration incorrect

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
while ((value > limits[type][retval]) && (retval < 3))

well, the index gets out of bound. Check (retval < 3) first.

[Bug libgcc/65902] GCC-5.1 fails to bootstrap for eCos/arm-eabi

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
But that is not in a header other packages use, it is in the source, and we
aren't including stdbool.h.
So this really looks like an eCos bug.

[Bug tree-optimization/65917] [6.0 regression] FAIL: gcc.dg/tree-ssa/20030922-2.c scan-tree-dump-times dom1 "if " 2

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #2 from Andreas Schwab  ---
r222492 is still failing.

[Bug target/65914] [6 Regression] error: unrecognizable insn

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
Started with r222514 so possibly a latent issue.

[Bug tree-optimization/65917] [6.0 regression] FAIL: gcc.dg/tree-ssa/20030922-2.c scan-tree-dump-times dom1 "if " 2

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #3 from Jeffrey A. Law  ---
 if (_8 != _14)
goto ;
  else
goto ;

  :
  target_bb.1_15 = target_bb;
  if (_14 == target_bb.1_15)
goto ;
  else
goto ;

  :
  if (_8 != target_bb.1_15)
goto ;
  else
goto ;


Presumably depending on the ordering in the conditionals, we should discover
that in bb4 _8 and _15 are equal and eliminate the test.

[Bug c++/65734] Yet another case of lost alignment by stor_layout

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

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

[Bug bootstrap/11660] libffi only builds when java is selected as language

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #11 from Eric Gallager  ---
Doesn't libffi also get built if go is selected as a language? I can't verify
it for myself due to bug 46986, but based on my reading of Makefile.def, it
seems like building libgo should cause libffi to be built, as well...

[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #43 from James Greenhalgh  ---
(In reply to torvald from comment #37)
> (In reply to James Greenhalgh from comment #35)
> > (In reply to torvald from comment #32)
> > > (In reply to James Greenhalgh from comment #28)
> > > > This also gives us an easier route to fixing any issues with the
> > > > acquire/release __sync primitives (__sync_lock_test_and_set and
> > > > __sync_lock_release) if we decide that these also need to be stronger 
> > > > than
> > > > their C++11 equivalents.
> > > 
> > > I don't think we have another case of different __sync vs. __atomics
> > > semantics in case of __sync_lock_test_and_set.  The current specification
> > > makes it clear that this is an acquire barrier, and how it describes the
> > > semantics (ie, loads and stores that are program-order before the acquire 
> > > op
> > > can move to after it) , this seems to be consistent with the effects C11
> > > specifies for acquire MO (with perhaps the distinction that C11 is clear
> > > that acquire needs to be paired with some release op to create an ordering
> > > constraint).
> > 
> > I think that the question is which parts of a RMW operation with
> > MEMMODEL_ACQUIRE semantics is ordered. My understanding is that in C++11
> > MEMMODEL_ACQUIRE only applies to the "load" half of the operation. So an
> > observer to:
> > 
> >   atomic_flag_test_and_set_explicit(foo, memory_order_acquire)
> >   atomic_store_exlicit (bar, 1, memory_model_relaxed)
>  
> That depends on your observer.  When reasoning about C11, please let's use
> complete examples (and ideally, run them through cppmem).  For example, if
> the observation is done by a pair of relaxed-MO loads, bar==1 && foo==0 can
> be observed:
> 
> int main() {
>   atomic_int foo = 0; 
>   atomic_int bar = 0; 
>   {{{ {
> r1 = cas_strong(foo, 0, 1);
> bar.store(1, memory_order_relaxed);
>   } ||| {
> r2 = bar.load(memory_order_relaxed).readsvalue(1); 
> r3 = foo.load(memory_order_relaxed).readsvalue(0); 
>   } }}};
>   return 0; }

Thanks for that, and sorry again for my sloppy terminology. I did try to write
a
cppmem example, but I couldn't find the syntax for a CAS. If I could have, this
is
what I would have written, and gets the results I had expected and was trying
to express.

> 
> > Is permitted to observe a write to bar before a write to foo (but not before
> > the read from foo).
> 
> How does one observe a load in C11 (ie, so that "before the read from foo"
> is defined)?  You can constrain the reads-from of a load, but the load
> itself is not observable as an effect.

Sorry, this is ARM memory model terminology leaking across to my C11 examples,
but
even then what I was saying doesn't make sense. To observe a load in the ARM
model:

"A read of a location in memory is said to be observed by an observer when a
 subsequent write to the location by the same observer has no effect on the
value
 returned by the read."

But you are right, this is not interesting to model.


> I think I get what you're trying to say regarding the "load half" but I
> would phrase it differently: If there could be another release store to foo
> that the CAS/TAS reads-from, then moving the store to bar before the load
> would risk creating a cycle between inter-thread happens-before and
> sequenced-before-created intra-thread happens-before.  (Note that the later
> isn't visible to other threads though, except through additional
> inter-thread synchronization.)
> 
> Perhaps one could also say that moving the store to bar before the store to
> foo could result in the CAS/TAS not being atomic -- but this is just
> reliably observable if the foo observation is a CAS/TAS by itself (so it's
> totally ordered with the other CAS), or if there is a inter-thread
> happens-before between the observation of bar and the store to bar (which
> means using a release store for bar).
> 
> I'm discussing these aspects because I think it matters which observations
> are actually possible in a reliable way.  It matters for C11, and it may
> matter for the __sync semantics as well because while the __sync functions
> promise TSO, we don't really do so for all (nonatomic) loads or stores
> anywhere else in the program...
> 
> IOW, can we actually come up with reliable and correct counter-examples
> (either using the C11 or __sync interfaces) for the guarantees we think ARM
> might not provide?
> 
> > My reading of the Itanium ABI is that the acquire barrier applies to the
> > entire operation (Andrew, I think you copied these over exactly backwards in
> > comment 34 ;) ):
> > 
> >   "Disallows the movement of memory references to visible data from
> >after the intrinsic (in program order) to before the intrinsic (this
> >behavior is desirable at lock-acquire operations, hence the name)."
> > 
> > The definition of __sync_lock_test_and_set is:
> > 
> >   "Behavior:
> >• Atomically store the supplied value in *ptr and return t

[Bug tree-optimization/65918] Optimized code (> -O0) on 2-dim array iteration incorrect

[habanero_pizza at yahoo dot com]

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

--- Comment #3 from J. W. Mitchell  ---
Indeed.  Apologies for the submission

[Bug libstdc++/65913] Linking failure without -latomic

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org

--- Comment #2 from Richard Henderson  ---
Created attachment 35416
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35416&action=edit
proposed patch

jwakely suggested on irc reverting the -alignment fake pointer
for the integral type template.  

Note that there are weird targets that have non-power-of-two
integral types:

config/avr/avr-modes.def:FRACTIONAL_INT_MODE (PSI, 24, 3);

Thankfully, avr doesn't also have atomic operations on this type,
so the second part of fold_builtin_atomic_always_lock_free would fail.

But I think we can also do better for non-integral types, so it's
probably better to attack this inside the compiler.

[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0

[juergen.reuter at desy dot de]

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

--- Comment #11 from Jürgen Reuter  ---
Here is the small test case for the ICE with the patch provided Andre
Vehreschild:

gfortran -c evaluators.f90
evaluators.f90:40:0:

 .or. qn_mask_rest
 1
internal compiler error: in gfc_trans_assignment_1, at
fortran/trans-expr.c:9187

evaluators.f90:40:0: internal compiler error: Abort trap: 6
gfortran: internal compiler error: Abort trap: 6 (program f951)

This is the code:

module evaluators
  implicit none
  private
  type :: quantum_numbers_mask_t
   contains
 generic :: operator(.or.) => quantum_numbers_mask_or
 procedure, private :: quantum_numbers_mask_or
  end type quantum_numbers_mask_t

  type :: index_map_t
 integer, dimension(:), allocatable :: entry
  end type index_map_t
  type :: prt_mask_t
 logical, dimension(:), allocatable :: entry
  end type prt_mask_t
  type :: qn_mask_array_t
 type(quantum_numbers_mask_t), dimension(:), allocatable :: mask
  end type qn_mask_array_t

contains
  elemental function quantum_numbers_mask_or (mask1, mask2) result (mask)
type(quantum_numbers_mask_t) :: mask
class(quantum_numbers_mask_t), intent(in) :: mask1, mask2
  end function quantum_numbers_mask_or

  subroutine make_product_interaction &
  (prt_is_connected, qn_mask_in, qn_mask_rest)
type(prt_mask_t), dimension(2), intent(in) :: prt_is_connected
type(qn_mask_array_t), dimension(2), intent(in) :: qn_mask_in
type(quantum_numbers_mask_t), intent(in) :: qn_mask_rest
type(index_map_t), dimension(2) :: prt_index_in
integer :: i
type(quantum_numbers_mask_t), dimension(:), allocatable :: qn_mask
allocate (qn_mask (2))
do i = 1, 2
   qn_mask(prt_index_in(i)%entry) = &
pack (qn_mask_in(i)%mask, prt_is_connected(i)%entry) &
.or. qn_mask_rest
end do
  end subroutine make_product_interaction
end module evaluators

[Bug web/64968] Upgrade GCC Bugzilla to 5.0

[trippels at gcc dot gnu.org]

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

--- Comment #18 from Markus Trippelsdorf  ---
One thing I've noticed is that the emails to gcc-bugs now use the local time
of the user. So the sorting isn't correct anymore if people from different
time zones comment.
(The same issue also happens on sourceware.org/bugzilla/)

[Bug tree-optimization/65917] [6.0 regression] FAIL: gcc.dg/tree-ssa/20030922-2.c scan-tree-dump-times dom1 "if " 2

[law at redhat dot com]

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

--- Comment #4 from Jeffrey A. Law  ---
We'll probably need to XFAIL this for now.

This is definitely a case where we were just getting lucky before and the new
code to canonicalize the comparison arguments causes us not to get lucky.

The single use heuristic doesn't help here, because both operands have multiple
uses.

I'd pondered walking up the use-def chains to guess which operand is more
expensive to compute and use that as a heuristic as well, but in this case it'd
do the opposite of what we want.

I don't see other obvious heuristics that would resolve this issue.

The "right" way to fix this would be to unify cprop and simplification -- ie,
when we have a statement that references an SSA_NAME with one of these
equivalences, we need to try both SSA_NAMEs and see if it simplifies.  I've
avoided doing that simply because it hasn't seemed worth the effort and
compile-time cost.

[Bug rtl-optimization/65912] x_rtl.x_frame_offset not updated after frame related insn deleted

[pinskia at gmail dot com]

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

--- Comment #1 from pinskia at gmail dot com  ---
> On Apr 27, 2015, at 9:10 PM, jiwang at gcc dot gnu.org 
>  wrote:
> 
> Has anyone run into this issue on other architecture like MIPS, PPC?

Yes on both.

Re: [Bug rtl-optimization/65912] New: x_rtl.x_frame_offset not updated after frame related insn deleted

[pinskia]

> On Apr 27, 2015, at 9:10 PM, jiwang at gcc dot gnu.org 
>  wrote:
> 
> Has anyone run into this issue on other architecture like MIPS, PPC?

Yes on both. 

[Bug web/64968] Upgrade GCC Bugzilla to 5.0

[trippels at gcc dot gnu.org]

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

--- Comment #19 from Markus Trippelsdorf  ---
See for example:
http://thread.gmane.org/gmane.comp.gnu.binutils.bugs/19841/focus=19855
When this thread is displayed in mutt the highlighted messages appears
in the wrong place.

[Bug target/65871] bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag

[jamrial at gmail dot com]

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

--- Comment #4 from James Almer  ---
(In reply to Uroš Bizjak from comment #3)
> Please see the patch, attached in Comment #2.
> 
> While I can see the use (and benefit) to model the patterns that also set CC
> register internally for BEXTR and BZHI instructions, I don't think other
> listed instructions have clear usage scenarios to warrant additional
> patterns.
> 
> Can you perhaps show the benefit to have more insns modelled this way?

Not really, i simply assumed that taking into consideration what flags these
instructions affected in every case was the intended behavior, so figured it
was worth pointing them out.
I'm mainly interested in bzhi (and by extension bextr).

[Bug bootstrap/65910] r222473 breaks x86_64 darwin bootstrap

[cmtice at google dot com]

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

--- Comment #4 from Caroline Tice  ---
Has anyone actually committed this fix?  I'm not seeing it in my tree yet

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[joseph at codesourcery dot com]

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

--- Comment #9 from joseph at codesourcery dot com  ---
The rule certainly has nothing to do with whether the struct types are 
defined inside the union definition, or defined outside and then used 
inside via a tag or typedef.

The "it is permitted" wording is poorly defined, and the C99 changes 
confused this through failing to realise how it's poorly defined.  In C90, 
the paragraph starts "With one exception, if a member of a union object is 
accessed after a value has been stored in a different member of the 
object, the behavior is implementation-defined.[41]  One special guarantee 
is made ... it is permitted ...".  This reads to me like "it is permitted" 
was intended as an exception to the general rule of behavior being 
implementation-defined (that is, it was defining one case of type punning, 
which was more generally defined non-normatively in the footnote added in 
C99 TC3).

The difficulty with "it is permitted" is there are any number of cases 
where other wording indicates something is not permitted that it could be 
interpreted as overriding - just saying "it is permitted" fails to say 
which are or are not overridden.  (As a C11 example, something might not 
be permitted because it's a data race, for example, but accessing a common 
initial sequence can hardly be intended to override the normal rules about 
data races.)  So the authors of N685 read "it is permitted" as relating 
not to the previous sentence in the same paragraph about accessing 
different union members, but as relating to completely separate rules 
about aliasing.  The visible union rule was then inserted for C99, thereby 
serving to confuse things further by supporting the suggestion that "it is 
permitted" relates to aliasing.

DR#236 then considered a different case of aliasing through pointers to 
union members.  However, the response never decided the question of 
whether the accesses must visibly be through the union, or whether it's 
sufficient for the declaration of the union to be visible.

Basing things on whether a union is visible in the translation unit is 
clearly a bad rule because of action-at-a-distance effects (the visible 
union might be in a header included for some completely unrelated purpose, 
but would still inhibit optimization).

(Note that the exact example given in this bug is invalid as the union has 
active member s1, but is modified via member s2; you can only "inspect" 
common members of non-active union members, not modify them.  But 
presumably using .s2 in the initializer would still show the issue.)

Thus, "it is permitted" needs reworking to describe what it's an exception 
to.  To the extent that it's an exception to aliasing rules, I think that 
should only be where the union is actually used for the accesses in 
question (in which case no exception is actually needed beyond defining 
the layout requirements and making the type punning rules normative), and 
DR#236 should be clarified accordingly.

[Bug bootstrap/65910] r222473 breaks x86_64 darwin bootstrap

[dje at gcc dot gnu.org]

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

--- Comment #5 from David Edelsohn  ---
Author: dje
Date: Tue Apr 28 17:16:19 2015
New Revision: 222535

URL: https://gcc.gnu.org/viewcvs?rev=222535&root=gcc&view=rev
Log:
2015-04-28  Dominique d'Humieres  

PR bootstrap/65910
* varasm.c (assemble_end_function): Guard ASM_DECLARE_FUNCTION_SIZE.


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

[Bug bootstrap/65910] r222473 breaks x86_64 darwin bootstrap

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Target|x86_64-apple-darwin14   |x86_64-apple-darwin14,
   ||powerpc-ibm-aix*
 Status|NEW |RESOLVED
 CC||dje at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #6 from David Edelsohn  ---
Patch committed.

[Bug libstdc++/65913] Linking failure without -latomic

[yan12125 at gmail dot com]

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

--- Comment #3 from yan12125 at gmail dot com ---
Sorry, but I don't quite understand. Does that mean for all the future versions
(5.2, 6.0, etc.) -latomic flag is necessary if atomic::is_lock_free() is
used in my program?

[Bug libquadmath/65757] gfortran gives incorrect result for anint with real*16 argument

[joseph at codesourcery dot com]

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

--- Comment #9 from joseph at codesourcery dot com  ---
Fixed in glibc (commit 7d0b2575416aec2717e8665287d0ab77826a0ade).  I'd 
advise merging to trunk GCC libquadmath all relevant glibc changes since 
the last merges in 2012, rather than cherry-picking just this fix 
(although if you wish to fix things on release branches, cherry-picking 
just the critical fixes would be appropriate there).

[Bug libstdc++/65704] Provide portable versions of std::timed_mutex and std::recursive_timed_mutex

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Making this work requires splitting  into smaller pieces so that
std::timed_mutex can depend on std::condition_variable, which depends on
std::mutex.

I'll come back to it.

[Bug c++/65919] New: Regression - GCC 5.1 with options "-g -std=c++14" fails to compile multiple lambdas used as default function parameters

[drew.dormann at gmail dot com]

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

Bug ID: 65919
   Summary: Regression - GCC 5.1 with options "-g -std=c++14"
fails to compile multiple lambdas used as default
function parameters
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: drew.dormann at gmail dot com
  Target Milestone: ---

The following program compiles with GCC 4.9, but will not compile using GCC 5.1

Command:

g++ -std=c++14 -g TEST.cpp

Source:

#include 

struct TestClass
{
static void do_things( std::function first = []{},
   std::function second = []{} );
};

int main()
{
TestClass::do_things();
}

Output:

TEST.cpp:12:1: error: ‘static void
std::_Function_base::_Base_manager<_Functor>::_M_init_functor(std::_Any_data&,
_Functor&&, std::false_type) [with _Functor = TestClass::;
std::false_type = std::integral_constant]’ conflicts with a
previous declaration
 }
 ^
In file included from TEST.cpp:1:0:
/usr/include/c++/5/functional:1786:2: note: previous declaration ‘static void
std::_Function_base::_Base_manager<_Functor>::_M_init_functor(std::_Any_data&,
_Functor&&, std::false_type) [with _Functor = TestClass::;
std::false_type = std::integral_constant]’
  _M_init_functor(_Any_data& __functor, _Functor&& __f, false_type)
  ^
/usr/include/c++/5/functional:1786:2: note: a later -fabi-version= (or =0)
avoids this error with a change in mangling
TEST.cpp:12:1: error: ‘static void
std::_Function_base::_Base_manager<_Functor>::_M_destroy(std::_Any_data&,
std::false_type) [with _Functor = TestClass::; std::false_type =
std::integral_constant]’ conflicts with a previous declaration
 }
 ^
In file included from TEST.cpp:1:0:
/usr/include/c++/5/functional:1724:2: note: previous declaration ‘static void
std::_Function_base::_Base_manager<_Functor>::_M_destroy(std::_Any_data&,
std::false_type) [with _Functor = TestClass::; std::false_type =
std::integral_constant]’
  _M_destroy(_Any_data& __victim, false_type)
  ^
/usr/include/c++/5/functional:1724:2: note: a later -fabi-version= (or =0)
avoids this error with a change in mangling
TEST.cpp:12:1: error: ‘static void
std::_Function_base::_Base_manager<_Functor>::_M_clone(std::_Any_data&, const
std::_Any_data&, std::false_type) [with _Functor = TestClass::;
std::false_type = std::integral_constant]’ conflicts with a
previous declaration
 }
 ^
In file included from TEST.cpp:1:0:
/usr/include/c++/5/functional:1708:2: note: previous declaration ‘static void
std::_Function_base::_Base_manager<_Functor>::_M_clone(std::_Any_data&, const
std::_Any_data&, std::false_type) [with _Functor = TestClass::;
std::false_type = std::integral_constant]’
  _M_clone(_Any_data& __dest, const _Any_data& __source, false_type)
  ^
/usr/include/c++/5/functional:1708:2: note: a later -fabi-version= (or =0)
avoids this error with a change in mangling

Version:

g++ -v
Using built-in specs.
COLLECT_GCC=g++-5
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.1.0-0ubuntu11~14.04.1' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=c++98 --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.1.0 (Ubuntu 5.1.0-0ubuntu11~14.04.1) 

Observations:

The code will compile if any one of the following changes are made.

- Use g++-4.9
- Compile without the "-g" option
- Remove either parameter from "do_things" prototype
- Make "do_things" prototype a global function instead of a static member
funtion.
- Change the default parameters from a "do nothing" lambda to a "do nothing"
function name.

[Bug web/64968] Upgrade GCC Bugzilla to 5.0

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

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

--- Comment #20 from Andreas Schwab  ---
I don't think this has anything to do with the timezone of the commenter.  For
example the mail for comment #19 has the date "Tue, 28 Apr 2015 16:28:19 +"
(which is correct), but comment #18 was sent with the date "Tue, 28 Apr 2015
10:44:58 +" (which is 5:30(!) hours off).  Both mails were sent immediately
after the comment was entered, and I assume that both were entered from the
same local timezone.

[Bug libgcc/65902] GCC-5.1 fails to bootstrap for eCos/arm-eabi

[bernd.edlinger at hotmail dot de]

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

--- Comment #5 from Bernd Edlinger  ---
Well, I thought maybe it would not hurt to be more permissive...

At least math.h and stdlib.h include 
which contains something like this:

#ifndef __cplusplus

typedef cyg_halbool bool;

# ifndef false
#  define false 0
# endif

# ifndef true
#  define true (!false)
# endif

#endif

[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared

[orion at cora dot nwra.com]

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

Orion Poplawski  changed:

   What|Removed |Added

 CC||orion at cora dot nwra.com

--- Comment #4 from Orion Poplawski  ---
A recent issue triggered by this:
https://bugzilla.redhat.com/show_bug.cgi?id=1127544

[Bug web/64968] Upgrade GCC Bugzilla to 5.0

[LpSolit at netscape dot net]

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

--- Comment #21 from Frédéric Buclin  ---
Markus, did you change your timezone preference between comments 18 and 19? If
yes, which ones did you select?

[Bug web/64968] Upgrade GCC Bugzilla to 5.0

[trippels at gcc dot gnu.org]

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

--- Comment #22 from Markus Trippelsdorf  ---
(In reply to Frédéric Buclin from comment #21)
> Markus, did you change your timezone preference between comments 18 and 19?
> If yes, which ones did you select?

No. But the question makes no sense, because we're talking about mails that
bugzilla automatically sends to the bug mailing lists on every new comment.
And I have no control over these.

[Bug web/64968] Upgrade GCC Bugzilla to 5.0

[LpSolit at netscape dot net]

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

--- Comment #23 from Frédéric Buclin  ---
(In reply to Markus Trippelsdorf from comment #22)
> No. But the question makes no sense, because we're talking about mails that
> bugzilla automatically sends to the bug mailing lists on every new comment.
> And I have no control over these.

The question makes total sense as I wanted to excluse a possible interaction
between your timezone and the timezone used by Bugzilla to send bugmails. :)

[Bug web/64968] Upgrade GCC Bugzilla to 5.0

[trippels at gcc dot gnu.org]

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

--- Comment #24 from Markus Trippelsdorf  ---
(In reply to Frédéric Buclin from comment #23)
> (In reply to Markus Trippelsdorf from comment #22)
> > No. But the question makes no sense, because we're talking about mails that
> > bugzilla automatically sends to the bug mailing lists on every new comment.
> > And I have no control over these.
> 
> The question makes total sense as I wanted to excluse a possible interaction
> between your timezone and the timezone used by Bugzilla to send bugmails. :)

Yeah, sorry. I though you were talking about the Sourceware binutils thread...

Here are the headers of comment18 as seen by Gmane:

Path: news.gmane.org!not-for-mail   
From: "trippels at gcc dot gnu.org"   
Newsgroups: gmane.comp.gcc.bugs 
Subject: [Bug web/6496Here are the headers from comment 18 as seem by gmane:
8] Upgrade GCC Bugzilla to 5.0  
Date: Tue, 28 Apr 2015 10:44:58 +   
Lines: 8
Approved: n...@gmane.org
Message-ID:  
References: 
NNTP-Posting-Host: plane.gmane.org  
Mime-Version: 1.0   
Content-Type: text/plain; charset="UTF-8"   
Content-Transfer-Encoding: 7bit 
X-Trace: ger.gmane.org 1430237721 11722 80.91.229.3 (28 Apr 2015 16:15:21 GMT)  
X-Complaints-To: use...@ger.gmane.org   
NNTP-Posting-Date: Tue, 28 Apr 2015 16:15:21 + (UTC)
To: gcc-bugs@gcc.gnu.org
Original-X-From: gcc-bugs-return-484874-gcgb-bugs-2=m.gmane@gcc.gnu.org Tue 
Apr 28 18:15:06 2015
Return-path:
Envelope-to: gcgb-bug...@plane.gmane.org
Original-Received: from server1.sourceware.org ([209.132.180.131]   
helo=sourceware.org)
by plane.gmane.org with esmtp (Exim 4.69)   
(envelope-from  
)   
id 1Yn8A5-7b-65 
for gcgb-bug...@plane.gmane.org; Tue, 28 Apr 2015 18:15:05 +0200
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id  
:list-unsubscribe:list-archive:list-post:list-help:sender:from  
:to:subject:date:message-id:in-reply-to:references:content-type 
:content-transfer-encoding:mime-version; q=dns; s=default; b=eu7
6Jpj++BEoByfYK1WkSgKWYsgqRvq1b0M/KeNitV7ycQgl4ohrGf06aE1Y/832wKH
y/NHq6WvFLytj6vGFKekJhnAeux6xZObH0Enc4lmiW47TFMB7WFG/bhBbk40mNFH
jz4WVwxa05bFqSFaPPVrl7Ym8EqWwrBYwxOOEPzM=   
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id
:list-unsubscribe:list-archive:list-post:list-help:sender:from  
:to:subject:date:message-id:in-reply-to:references:content-type 
:content-transfer-encoding:mime-version; s=default; bh=zsFudk2X+
ANEPRr/cJWaH3SAEF8=; b=jastBc1aGdhM4s2RoZnruY7ZX/FcmBeRB0JEflRMT
68TkmxuDrRvnETjdLSGVZ28Kf18TbSc4ZdK4AYzsQFM5GBTHoRDeehXarAzcwHLq
S1VHzdFA3sOjoz89NpDigZ2MYsn0aX3cj9Y4e783mPOPSRRSqsac1nV1hx7khXPE
4A= 
Original-Received: (qmail 122022 invoked by alias); 28 Apr 2015 16:15:03 -  
Mailing-List: contact gcc-bugs-h...@gcc.gnu.org; run by ezmlm   
Precedence: bulk
List-Id:  
List-Unsubscribe:   
   
List-Archive:  
List-Post: 
List-Help:    
Original-Sender: gcc-bugs-ow...@gcc.gnu.org 
Delivered-To: mailing list gcc-bugs@gcc.gnu.org 
Original-Received: (qmail 121912 invoked by uid 48); 28 Apr 2015 16:14:59 - 
X-Bugzilla-Reason: CC  

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[clyon at gcc dot gnu.org]

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

--- Comment #16 from clyon at gcc dot gnu.org ---
(In reply to prathamesh3492 from comment #15)

> I am not understanding why vfpv3-d16 appears in collect_gcc_options in
> run_gcc().
Isn't this because you configured GCC --with-fpu=vfpv3-d16?

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #17 from prathamesh3492 at gcc dot gnu.org ---
(In reply to clyon from comment #16)
> (In reply to prathamesh3492 from comment #15)
> 
> > I am not understanding why vfpv3-d16 appears in collect_gcc_options in
> > run_gcc().
> Isn't this because you configured GCC --with-fpu=vfpv3-d16?

COLLECT_GCC_OPTIONS is set by gcc.c:set_collect_gcc_options():
/* Build COLLECT_GCC_OPTIONS to have all of the options specified to
 the compiler.  */
  obstack_grow (&collect_obstack, "COLLECT_GCC_OPTIONS=",
sizeof ("COLLECT_GCC_OPTIONS=") - 1);

and at the end of set_collect_gcc_options():
xputenv (XOBFINISH (&collect_obstack, char *));
which makes it environment variable.

set_collect_gcc_options() is called by do_spec, which is called by
driver::maybe_run_linker(), before executing linker.
So the driver has no knowledge of options passed at compile-time,
it sets the default -mfpu=vfpv3-d16.

When lto-wrapper executes,
it gets linker command line options from environment variable
COLLECT_GCC_OPTIONS,
which contains -mfpu=vfpv3-d16.
and since that was being appended after compile-time options
(fdecoded_options), -mfpu=vfpv3-d16 overrides -mfpu=neon.

This also explains why it works in one shot
arm-linux-gnueabihf -flto -mfpu=neon test.c

COLLECT_GCC_OPTIONS will have "-mfpu=neon" since it's mentioned on command
line, and lto-wrapper has access to this COLLECT_GCC_OPTIONS.

When compiler and linker are run separately, at link time, the driver has no
knowledege of flags of compile-time run,
and hence sets default flags in COLLECT_GCC_OPTIONS.

I think correct way to fix would be in run_gcc() to get values from
COLLECT_GCC_OPTIONS in decoded_options as is currently done.
run_gcc() walks through options in object file and saves it in
fdecoded_options. So override the value in
decoded_options for the same option found in fdecoded_options. 
Would that be a right approach ?

Thank you,
Prathamesh

[Bug libstdc++/65883] [5/6 Regression] numeric_limits::max() returns incorrect value

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
Author: glisse
Date: Tue Apr 28 19:35:49 2015
New Revision: 222540

URL: https://gcc.gnu.org/viewcvs?rev=222540&root=gcc&view=rev
Log:
2015-04-28  Marc Glisse  

PR libstdc++/65883
* include/std/limits (numeric_limits): Add missing unsigned.


Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/limits

[Bug libstdc++/65883] [5 Regression] numeric_limits::max() returns incorrect value

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||wrong-code
  Known to work||4.9.2, 6.0
   Target Milestone|--- |5.2
Summary|[5/6 Regression]|[5 Regression]
   |numeric_limits::max() returns|__int128>::max() returns
   |incorrect value |incorrect value
  Known to fail||5.1.0

--- Comment #3 from Marc Glisse  ---
Fixed on trunk. This needs to be backported to 5, but I don't have time to do
it right now, anyone feel free...

[Bug preprocessor/60014] Bad warning suppression caused by track-macro-expansion when not using integrated cpp

[megahallon at gmail dot com]

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

--- Comment #5 from Fredrik Hallenberg  ---
Same results with gcc 5.1.0.

[Bug c++/44282] fastcall is not mangled at all

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #7 from Jason Merrill  ---
Created attachment 35417
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35417&action=edit
patch

Here's a fix.  I want to get the ABI committee to sign off on the mangling
before I check it in.

[Bug c++/65919] Regression - GCC 5.1 with options "-g -std=c++14" fails to compile multiple lambdas used as default function parameters

[maltsevm at gmail dot com]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||maltsevm at gmail dot com

--- Comment #1 from Mikhail Maltsev  ---
Reduced testcase:

template  class function;
template  class _Base_manager {
public:
  void _M_manager();
  template  static bool _M_not_empty_function(_Tp);
};

template  class A;
template 
class A : public _Base_manager<_Functor> {};

template 
class function<_Res(_ArgTypes...)> {
  template  using _Requires = int;

public:
  template >
  function(_Functor);
};

template 
template 
function<_Res(_ArgTypes...)>::function(_Functor p1) {
  A<_Res(), _Functor>::_M_not_empty_function(p1);
}

struct B {
  static void do_things(function = [] {}, function = [] {});
};

int main() {
  B::do_things();
}

[Bug c/65920] New: Not able to compile a code

[imran.siddiqui at live dot com]

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

Bug ID: 65920
   Summary: Not able to compile a code
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: imran.siddiqui at live dot com
  Target Milestone: ---

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

I got an upgrade in AIX server i.e. 7.1 with the DB2 version 9.5. Whenever we
complied a legacy C code in previous AIX server i.e 5.3 with Db2 version 9.5
and GCC version 2.9 it worked fined.

But now i am facing issues in compling.It is very critical for my project to
solve this..

I am attaching some errors

[Bug c/65920] Not able to compile a code

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID
   Severity|critical|normal

--- Comment #1 from Andrew Pinski  ---
Sounds like you don't know that string is now in the std namespace.  Either add
"using std::string;" after the include of string.h or change all references to
string to std::string.

You need to figure out where LogFile is defined and compile that c++ file too.

This is not a GCC bug but rather an issue with your code.
If you want to ask C++ questions it is best to ask on a different place than
here.  Also how to use gcc it would be best to ask on gcc-h...@gcc.gnu.org
rather than in a bug report.

[Bug c++/65920] Not able to compile a code

[imran.siddiqui at live dot com]

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

Imran  changed:

   What|Removed |Added

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

--- Comment #2 from Imran  ---
Thans for the quick reply. The code is perfectly fine as it was workinng as i
mentioned earlier

But after the upgrade only it started throwing the error.

I tried repalcing char * with string in the log.cpp..but again it left me some
other errors