[Bug middle-end/67821] [5 Regression] ICE in duplicate_ssa_name_range_info

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #8 from Markus Trippelsdorf  ---
*** Bug 67873 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/67873] ice in duplicate_ssa_name_range_info

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
dup, already fixed.

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

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

[uros at gcc dot gnu.org]

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

--- Comment #21 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Oct  6 15:31:11 2015
New Revision: 228527

URL: https://gcc.gnu.org/viewcvs?rev=228527=gcc=rev
Log:
PR c/65345
* config/alpha/alpha.c (alpha_atomic_assign_expand_fenv): Use
create_tmp_var_raw instead of create_tmp_var.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/alpha/alpha.c

[Bug middle-end/67868] [4.9/5/6 regression] ICE in named section handling on targets with section anchors.

[ramana at gcc dot gnu.org]

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

--- Comment #2 from Ramana Radhakrishnan  ---
However the ICE is specific to the VTV feature I think and not generally
applicable.

[Bug tree-optimization/67683] Missed vectorization: shifts of an induction variable

[alalaw01 at gcc dot gnu.org]

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

alalaw01 at gcc dot gnu.org changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=35226

--- Comment #2 from alalaw01 at gcc dot gnu.org ---
Is there a way to do this kind of thing other than extending polynomial_chrec's
to understand operations other than addition ? Whilst beneficial, that looks to
be quite a large task.

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

[ramana at gcc dot gnu.org]

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

--- Comment #20 from Ramana Radhakrishnan  ---
Author: ramana
Date: Tue Oct  6 15:09:43 2015
New Revision: 228526

URL: https://gcc.gnu.org/viewcvs?rev=228526=gcc=rev
Log:
Fix PR c/65345 for AArch64 



2015-10-06  Ramana Radhakrishnan  

PR c/65345
* config/aarch64/aarch64-builtins.c
(aarch64_atomic_assign_expand_fenv):
Use create_tmp_var_raw instead of create_tmp_var.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64-builtins.c

[Bug middle-end/67861] [6 Regression] coreutils' wc.c:write_counts is miscompiled since commit 7e3a76de7c496449b187c2688d958631cf21a944

[jim at meyering dot net]

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

--- Comment #3 from jim at meyering dot net ---
Created attachment 36452
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36452=edit
wc.i

Attaching wc.i:

[Bug fortran/65889] [6 Regressions] [OOP] ICE with sizeof a polymorphic variable.

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from vehre at gcc dot gnu.org ---
First patch available at:

https://gcc.gnu.org/ml/fortran/2015-10/msg00033.html

[Bug target/67869] New: [SH] Expand some dynamic shifts inline

[olegendo at gcc dot gnu.org]

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

Bug ID: 67869
   Summary: [SH] Expand some dynamic shifts inline
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
  Target Milestone: ---
Target: sh*-*-*

On SH variants without dynamic shift instructions like shld and shad dynamic
shifts are done via a libcall.  For some cases the shift range is known to be
limited, for example:

unsigned int test_0 (unsigned int x, unsigned int y)
{
  // valid value for y is 0,1,2,3
  // otherwise it's undefined behavior
  return x >> (y * 8);
}


unsigned int test_1 (unsigned int x, unsigned int y)
{
  // value of y i known to be 0,1,2,3
  return x << (y & 3);
}

In such cases a sequence like:
 shlrr4
 bf  .Lx0
 shll8   r5
.Lx0:
 shlrr4
 bf  .L0x
 shll16  r5
.L0x:

can be expanded inline which is better than the libcall.

[Bug c++/67878] New: [concepts] when processing a valid concept check, gcc errors trying to expand variadic in unrelated code

[ryan.burn at gmail dot com]

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

Bug ID: 67878
   Summary: [concepts] when processing a valid concept check, gcc
errors trying to expand variadic in unrelated code
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

The below code should be valid, but gcc gives the following error, which
references a completely unrelated concept:

t2.cpp:42:53: error: expansion pattern ‘indexes#0’ contains no argument packs
 requires cpt_Scalar>();
 ^
t2.cpp: In function ‘int main()’:
t2.cpp:89:42: error: cannot call function ‘auto make_indexed_evaluator(const
Evaluator&) [with long unsigned int K = 2ul; Evaluator =
main()::]’
   auto f1_ = make_indexed_evaluator<2>(f1);
  ^
t2.cpp:81:6: note:   constraints not satisfied
 auto make_indexed_evaluator(const Evaluator& evaluator) {
  ^
t2.cpp:81:6: note:   concept ‘cpt_IndexedEvaluatable, 2ul>()’ was not satisfied

//
#include 
#include 

using index_t = long;

//--
// repeat_type_c
//--
namespace DETAIL_NS {
template  struct repeat_type_c_impl {
  using type = T;
};
}

template 
using repeat_type_c = typename DETAIL_NS::repeat_type_c_impl::type;

//--
// uncvref_t
//--
template 
using uncvref_t =
typename std::remove_cv::type>::type;

//--
// cpt_Scalar
//--
template  concept bool cpt_Scalar() {
  return std::is_floating_point::value;
}

//--
// cpt_KEvaluator
//--
namespace DETAIL_NS {
template  constexpr bool k_evaluator_impl = false;

// clang-format off
template 
  requires requires(const Evaluator& evaluator,
repeat_type_c... indexes) {
requires cpt_Scalar>();
::operator();
  }
constexpr bool k_evaluator_impl =
true;
// clang-format on
}

template  concept bool cpt_KEvaluator() {
  return DETAIL_NS::k_evaluator_impl, X>;
}

//--
// cpt_IndexedEvaluatable
//--
namespace DETAIL_NS {
template  constexpr bool indexed_evaluatable_impl = false;

// clang-format off
template 
requires requires(const Evaluator& evaluator,
  repeat_type_c... indexes) {
  requires cpt_Scalar>();
 }
constexpr bool indexed_evaluatable_impl<
  std::index_sequence, Evaluator> = true;
// clang-format on
}

template 
concept bool cpt_IndexedEvaluatable() {
  return DETAIL_NS::indexed_evaluatable_impl,
 Evaluator>;
}

//--
// make_indexed_evaluator
//--
template  Evaluator>
auto make_indexed_evaluator(const Evaluator& evaluator) {
  return true;
}

int main() {
  auto f1 = [](index_t i, index_t m, index_t j, index_t n) {
return 2.0;
  };
  auto f1_ = make_indexed_evaluator<2>(f1);
  return 0;
}
//

[Bug rtl-optimization/67856] callee-saved register saves should be shrink-wrapped

[luto at mit dot edu]

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

--- Comment #4 from Andy Lutomirski  ---
I don't want to comment on how code generation works in GCC, but in terms of
what works in the output:

x86_64 generally has a 16-byte stack alignment in user code, which is two
slots.  (In the kernel, we use 8-byte alignment, since we don't use SSE/AVX.) 
This means that the stack is always aligned appropriately.

For builds with frame pointers on, merely pushing %rbp aligns the stack, so
splitting out the 'push %rbp' from the rest of the pushes doesn't leave an
unaligned window.

With frame pointers off, doing any odd number of pushes will similarly align
the stack.

For functions in which there's a control flow path from the beginning to the
end that call nothing, then the alignment is irrelevant unless there's a
16-byte or higher aligned live variable on the stack.

[Bug target/57112] -march=x86-64 not documented

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Last reconfirmed|2013-04-29 00:00:00 |2015-10-6

--- Comment #2 from Manuel López-Ibáñez  ---
I just learned from it by googling! :(

If someone cared to explain it, I will add it to the FAQ (I can't send patches
ATM, sorry)

[Bug c++/67863] -Wtautological-compare warns when it shouldn't

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/67863] -Wtautological-compare warns when it shouldn't

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Tue Oct  6 17:56:23 2015
New Revision: 228540

URL: https://gcc.gnu.org/viewcvs?rev=228540=gcc=rev
Log:
PR c++/67863
* call.c (build_conditional_expr_1): Build the COND_EXPR with
a location.

* c-c++-common/Wtautological-compare-4.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/Wtautological-compare-4.c
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/47226] [C++0x] GCC doesn't expand template parameter pack that appears in a lambda-expression

[griwes at griwes dot info]

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

griwes at griwes dot info changed:

   What|Removed |Added

 CC||griwes at griwes dot info

--- Comment #6 from griwes at griwes dot info ---
This still exists in GCC 6.0.0 20150902 (also I've heard MSVC manages to work
with this. Come on, guys, don't be worse than MSVC *when it comes to
templates*. Clang of course also understands what's going on).

[Bug c/67872] New: missing -Warray-bounds warning, bogus -Wmaybe-uninitialized

[msebor at gcc dot gnu.org]

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

Bug ID: 67872
   Summary: missing -Warray-bounds warning, bogus
-Wmaybe-uninitialized
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC doesn't diagnose either of the out of bounds accesses in the following
program unless -O2 is used.  At -O1 and above, GCC issues a bogus
-Wmaybe-uninitialized warning about the access to b[4] but no -Warray-bounds
warning:

$ cat z.c && gcc -c z.c -Wall
int a[] = { 1, 2, 3 };

int foo (int i)
{
int b[] = { 4, 5, 6};
if (i)
return a [4];
else
return b [4];
}
$

Clang, on the other hand, diagnoses both accesses with the expected warning
regardless of optimization:

clang -Wall -S -c -o/dev/null z.c
z.c:7:16: warning: array index 4 is past the end of the array (which contains 3
  elements) [-Warray-bounds]
return a [4];
   ^  ~
z.c:1:1: note: array 'a' declared here
int a[] = { 1, 2, 3 };
^
z.c:9:16: warning: array index 4 is past the end of the array (which contains 3
  elements) [-Warray-bounds]
return b [4];
   ^  ~
z.c:5:5: note: array 'b' declared here
int b[] = { 4, 5, 6};
^
2 warnings generated.

[Bug middle-end/67861] coreutils' wc.c:write_counts is miscompiled since commit 7e3a76de7c496449b187c2688d958631cf21a944

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org,
   ||trippels at gcc dot gnu.org
   Severity|blocker |normal

[Bug middle-end/67861] coreutils' wc.c:write_counts is miscompiled since commit 7e3a76de7c496449b187c2688d958631cf21a944

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-06
 CC||segher at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Segher Boessenkool  ---
That commit adds a case BUILT_IN_ACC_ON_DEVICE but forgot to add a
break to the previous case (BUILT_IN_{V,}PRINTF_CHK).

[Bug target/66697] Feature request: -mstackrealign and force_align_arg_pointer for x86_64

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak  ---
(In reply to Justas L from comment #8)
> I applied the first (testing) version of the patch on gcc 5.2.0 release
> source (with slight modifications to make it apply). All new features work
> as expected, as per the test in comment #2. However, compiling Wine with
> either -mstackrealign or -mincoming-stack-boundary=3 fails, throwing this
> error:
> 
> -
> ../../../wine/dlls/dxerr8/dxerr8.c:135:1: internal compiler error: in
> ix86_compute_frame_layout, at config/i386/i386.c:10212
> -
> 
> which refers to this line in i386.c:
> 
> -
> gcc_assert (INCOMING_STACK_BOUNDARY >= 128);
> -
> 
> Commenting out the assert allows Wine to compile normally. (I assume the
> correct fix would be to change the number to 64.) And compiling Wine with
> -mincoming-stack-boundary=3 does fix the original issue (or at least the one
> instance of it that I care about). So the gcc side of the issue is almost
> resolved, with just the assert left to address.

Thanks, this assert triggered on target I'm not able to test.

The correct solution is to emit unaligned moves when INCOMING_STACK_BOUNDARY <
128. This is the same problem as HJ is solving for interrupt handler.

[Bug rtl-optimization/67828] [6 Regression] wrong code at -O3 on x86_64-linux-gnu

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #3 from Alexandre Oliva  ---
Created attachment 36448
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36448=edit
Patch I'm testing to fix the bug

This testcase invokes undefined behavior because of the overflow on the
iterator, but the cause of the problem is undefined behavior we introduce
ourselves by unswitching the loop on the uninitialized variable j.  Things go
down the hill from there, as we uncprop j's default def in the j==0 branch into
one of D's phi nodes in that version of the loop, then we coalesce j's default
def with some versions of d (we only detect conflicts for parms' and results'
default defs), including the one passed to printf.  init-regs adds zero
initialization for j, the loop-entry initialization of d with 1 overrides it,
and the assignment to zero within the loop, that uncprop had turned into a copy
from j (known to be zero in that branch), is optimized out because of the
coalescing.  So the initialization of d to 1 prevails.  Preventing coalescing
by detecting conflicts with non-params would also avoid the symptom, but since
accessing uninitialized variables is undefined behavior, we shouldn't have to
worry about that.  This is only relevant in this case because we introduce the
undefined access in the first place, so that's what the patch fixes.

[Bug tree-optimization/67794] [6 regression] internal compiler error: Segmentation fault

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||mjambor at suse dot cz

--- Comment #5 from Alexandre Oliva  ---
Martin, why doesn't SRA's modify_function use tree_versioning's args_to_skip
infrastructure to remap the function, including its prototype, and instead
makes an (incomplete) work itself?  We end up with cloned PARM_DECLs that
aren't parms at all, which may confuse other parts of the compiler.

[Bug c/67873] New: ice in duplicate_ssa_name_range_info

[dcb314 at hotmail dot com]

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

Bug ID: 67873
   Summary: ice in duplicate_ssa_name_range_info
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 36455
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36455=edit
C source code

$ ../results/bin/gcc -c -O3 bug235.c
src/filer.c: In function ‘str_cut’:
src/filer.c:980:16: warning: implicit declaration of function ‘wcswidth’
[-Wimplicit-function-declaration]
src/filer.c: In function ‘str_cut2.constprop’:
src/filer.c:1015:6: internal compiler error: in duplicate_ssa_name_range_info,
at tree-ssanames.c:506
0xd9de75 duplicate_ssa_name_range_info(tree_node*, value_range_type,
range_info_def*)
../../src/trunk/gcc/tree-ssanames.c:506
0xd1a874 eliminate_dom_walker::before_dom_children(basic_block_def*)
../../src/trunk/gcc/tree-ssa-pre.c:4127
0x1256eb9 dom_walker::walk(basic_block_def*)
../../src/trunk/gcc/domwalk.c:177

[Bug c/67872] missing -Warray-bounds warning, bogus -Wmaybe-uninitialized

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
(In reply to comment #1)

Based on bug 41935 it looks like the offsetof warning is suppressed
intentionally when the array is the last element of a struct.

[Bug c/67872] missing -Warray-bounds warning, bogus -Wmaybe-uninitialized

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
Looking for existing code in place to issue -Warray-bounds warnings I came
across fold_offsetof_1 in c-family/c-common.c.  The function is designed to
warn for out of bounds indices in offsetof expressions but doesn't detect the
following:

struct A {
int a[3];
} a;

int foo (void)
{
return __builtin_offsetof (struct A, a[4]);
}


This (otherwise untested) patch fixes it and makes the function diagnose this
case.  (The comment about flexible array members above the block suggests that
the patch might need tweaking to avoid false positives for such constructs.)

--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -10623,7 +10623,8 @@ fold_offsetof_1 (tree expr)
 man's flexible array member with a very permissive
 definition thereof.  */
  if (TREE_CODE (v) == ARRAY_REF
- || TREE_CODE (v) == COMPONENT_REF)
+ || TREE_CODE (v) == COMPONENT_REF
+ || TREE_CODE (v) == INDIRECT_REF)
warning (OPT_Warray_bounds,
 "index %E denotes an offset "
 "greater than size of %qT",

[Bug target/67677] [6 Regression] r226005 causes "Conditional jump or move depends on uninitialised value(s)"

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-10-06
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Segher Boessenkool  ---
Mine.

[Bug tree-optimization/67794] [6 regression] internal compiler error: Segmentation fault

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #4 from Alexandre Oliva  ---
Created attachment 36454
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36454=edit
Patch that removes the crash

This patch fixes the problem by tolerating IPA ESRA's leaving removed
PARM_DECLs alone, instead of replacing them with VAR_DECLs.  I would rather we
used a VAR_DECL instead, because I'm concerned about other places that
distinguish between PARM_DECLs and VAR_DECLs, at least when it comes to
handling their default defs.  I haven't looked into this possibility yet,
though; it might be that other pieces of the compiler rely on the decls
remaining as PARM_DECLs for other purposes.

[Bug c++/67875] New: missing -Warray-bounds in a default placement new expression, bogus location on an overload

[msebor at gcc dot gnu.org]

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

Bug ID: 67875
   Summary: missing -Warray-bounds in a default placement new
expression, bogus location on an overload
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC fails to diagnose placement new expressions that attempt to access an array
past its bounds and that involve the default placement operator new:

$ cat t.cpp && g++ -c -O2 -Wall -std=gnu++11 t.cpp
#include 

struct A {
char a [4];
} a;

void foo ()
{
new ( [5]) char;
}
$

When the out-of-bounds access involves a user-defined overload of the placement
new operator that makes use of the out-of-bounds pointer, GCC issues an
-Warray-bounds warning that points into the body of the operator instead of the
new expression. (Clang diagnoses both cases correctly.)

$ cat t.cpp && g++ -c -O2 -Wall -std=gnu++11 t.cpp
typedef __typeof__ (sizeof 0) size_t;

extern "C" int printf (const char*, ...);

void* operator new (size_t n, void *p, int) {
printf ("%s: %zu, %p\n", __PRETTY_FUNCTION__, n, p);
return p;
}
struct A { char a [4]; } a;

void foo () {
new ( [5], 0) char;
}
t.cpp: In function ‘void foo()’:
t.cpp:6:56: warning: array subscript is above array bounds [-Warray-bounds]
 printf ("%s: %zu, %p\n", __PRETTY_FUNCTION__, n, p);
^

[Bug rtl-optimization/67856] callee-saved register saves should be shrink-wrapped

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
The prologue does a lot of separate things:
- Save non-volatile registers;
- Do whatever needs to be done to be able to call things (save the
return address, align the stack, whatever; different per target);
- Set up a stack frame;
- Do whatever needs to be done for the static chain;
- Set up registers for PIC;
- Etc.

Not all of those can be separated for every target.  There also is
a required ordering between them, different per target as well.
Doing multiple of those together may be cheaper as well (say, pushing
registers to set up the stack frame or aligned stack).

GCC does not yet have any way to ask the backend to split the prologue
into such separate pieces.  It isn't clear to me what a good interface
would be.

Relatedly, there are cases where it would be useful to insert (pieces
of) the prologue at multiple points, not at a common dominator of all
that need it.  For example, a function that requires no prologue at
all except for no-return error paths (that need the backchain saved
for backtracing to work).  What would be good heuristics for that is
unclear as well.

[Bug c++/67810] Non-expression recognized as fold expression

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-10-06
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/67876] New: ICE when compiling Firefox 38

[gk at torproject dot org]

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

Bug ID: 67876
   Summary: ICE when compiling Firefox 38
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gk at torproject dot org
  Target Milestone: ---

I get an internal compiler error when compiling Firefox 38 with GCC master.
This is not happening with GCC 5.1.0:

c++ -o Unified_cpp_certverifier0.o -c -I../../dist/stl_wrappers
-I../../dist/system_wrappers -include
/home/ubuntu/build/tor-browser/config/gcc_hidden.h -DSTATIC_EXPORTABLE_JS_API
-DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -DMOZ_GLUE_IN_PROGRAM -DAB_CD=en-US
-DNO_NSPR_10_SUPPORT -I/home/ubuntu/build/tor-browser/security/certverifier -I.
-I/home/ubuntu/build/tor-browser/security/certverifier/../manager/boot/src
-I/home/ubuntu/build/tor-browser/security/certverifier/../manager/ssl/src
-I/home/ubuntu/build/tor-browser/security/certverifier/../pkix/include
-I../../dist/include  
-I/home/ubuntu/build/tor-browser/obj-x86_64-unknown-linux-gnu/dist/include/nspr
-I/home/ubuntu/build/tor-browser/obj-x86_64-unknown-linux-gnu/dist/include/nss 
 -fPIC   -DMOZILLA_CLIENT -include ../../mozilla-config.h -MD -MP -MF
.deps/Unified_cpp_certverifier0.o.pp  -Wall -Wempty-body -Woverloaded-virtual
-Wsign-compare -Wwrite-strings -Wno-invalid-offsetof -Wcast-align
-fsanitize=address -Dxmalloc=myxmalloc -fsanitize=undefined -fno-exceptions
-fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x
-pthread -pipe  -DNDEBUG -DTRIMMED -g -freorder-blocks -Os
-fno-omit-frame-pointer   -Wall   
/home/ubuntu/build/tor-browser/obj-x86_64-unknown-linux-gnu/security/certverifier/Unified_cpp_certverifier0.cpp
In file included from
/home/ubuntu/build/tor-browser/security/certverifier/NSSCertDBTrustDomain.cpp:21:0,
 from
/home/ubuntu/build/tor-browser/obj-x86_64-unknown-linux-gnu/security/certverifier/Unified_cpp_certverifier0.cpp:20:
/home/ubuntu/build/tor-browser/security/certverifier/../pkix/include/pkix/ScopedPtr.h:78:46:
internal compiler error: tree check: expected class 'expression', have
'exceptional' (template_parm_index) in tree_operand_check, at tree.h:3383
 operator==(T* a, const ScopedPtr& b)
  ^
0xf00f37 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../.././gcc/tree.c:9573
0x65c1f0 expr_check(tree_node const*, char const*, int, char const*)
../.././gcc/tree.h:3287
0x65c1f0 tree_operand_check(tree_node const*, int, char const*, int, char
const*)
../.././gcc/tree.h:3383
0x65c1f0 convert_template_argument
../.././gcc/cp/pt.c:7219
0x63161a coerce_template_parms
../.././gcc/cp/pt.c:7658
0x63358a lookup_template_class_1
../.././gcc/cp/pt.c:8251
0x63358a lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../.././gcc/cp/pt.c:8595
0x767b8d finish_template_type(tree_node*, tree_node*, int)
../.././gcc/cp/semantics.c:3051
0x6ee777 cp_parser_template_id
../.././gcc/cp/parser.c:14477
0x6eeac2 cp_parser_class_name
../.././gcc/cp/parser.c:20670
0x6ef336 cp_parser_qualifying_entity
../.././gcc/cp/parser.c:5984
0x6ef336 cp_parser_nested_name_specifier_opt
../.././gcc/cp/parser.c:5670
0x6e4210 cp_parser_simple_type_specifier
../.././gcc/cp/parser.c:15751
0x6e0525 cp_parser_type_specifier
../.././gcc/cp/parser.c:15448
0x6f14bb cp_parser_decl_specifier_seq
../.././gcc/cp/parser.c:12336
0x6f42f7 cp_parser_parameter_declaration
../.././gcc/cp/parser.c:19916
0x6f4c73 cp_parser_parameter_declaration_list
../.././gcc/cp/parser.c:19731
0x6f5279 cp_parser_parameter_declaration_clause
../.././gcc/cp/parser.c:19652
0x6ebd31 cp_parser_direct_declarator
../.././gcc/cp/parser.c:18438
0x6ebd31 cp_parser_declarator
../.././gcc/cp/parser.c:18316

GCC is configured just with

./configure --prefix=$INSTDIR/gcc --disable-multilib --enable-languages=c,c++

and Firefox is basically built with DEB_BUILD_HARDENING=1 and
CFLAGS/CXXFLAGS="-fsanitize=address -Dxmalloc=myxmalloc -fsanitize=undefined" +
LDFLAGS="-fsanitize=address -fsanitize=undefined

[Bug c++/67876] ICE when compiling Firefox 38

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Can you supply the preprocessed source?

[Bug go/67874] New: fd_unix.go does not build when there is fcntl64 and no fcntl syscall

[pinskia at gcc dot gnu.org]

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

Bug ID: 67874
   Summary: fd_unix.go does not build when there is fcntl64 and no
fcntl syscall
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: pinskia at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---
Target: aarch64-linux-gnu (ilp32)

Since a request from the ARM64 kernel maintainers on the ABI for AARCH64 ILP32
to just use off_t and time_t as 32bit rather than what I originally had it as
64bit, we use the compat syscalls instead which means there is no fcntl syscall
only fcntl64 now.

This breaks building fd_unix.go which depends on SYS_FCNTL being defined but
there is only SYS_FCNTL64 now.

[Bug go/67874] fd_unix.go does not build when there is fcntl64 and no fcntl syscall

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Note I think tilegx32 target might have the same issue as it uses the new
generic syscall interface and there is no fcntl there either.

[Bug target/66697] Feature request: -mstackrealign and force_align_arg_pointer for x86_64

[bucaneer at gmail dot com]

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

--- Comment #17 from Justas L  ---
Yes, this one works fine too.

[Bug libstdc++/66145] [5/6 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Reduced from testcase at  https://bugzilla.redhat.com/show_bug.cgi?id=1269290

#include 
#include 
#include 
#include 


int main() {

  try {
std::ifstream input("notafile");
input.exceptions(std::ifstream::failbit | std::ifstream::badbit);
input.get();
  } catch(const std::ios::failure ) {
std::cout << "caught a failure " << e.what()
  << '\n';
  } catch(const std::system_error ) {
std::cout << "caught a system_error " << e.what()
  << '\n';
  } catch(const std::runtime_error ) {
std::cout << "caught a runtime_error " << e.what()
  << '\n';
  } catch(const std::exception ) {
std::cout << "caught an exception " << e.what()
  << '\n';
  }
}

The last handler matches, but it should have matched earlier.

[Bug target/67877] New: Split stack needs to be support for AARCH64

[pinskia at gcc dot gnu.org]

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

Bug ID: 67877
   Summary: Split stack needs to be support for AARCH64
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-linux-gnu*

To support gccgo better split stack should be implemented.

[Bug tree-optimization/67859] [6 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-10-06
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |6.0
Summary|ICE on valid code at -O2|[6 Regression] ICE on valid
   |and -O3 on x86_64-linux-gnu |code at -O2 and -O3 on
   ||x86_64-linux-gnu
 Ever confirmed|0   |1

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

[Bug middle-end/67861] [6 Regression] coreutils' wc.c:write_counts is miscompiled since commit 7e3a76de7c496449b187c2688d958631cf21a944

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |6.0
   Target Milestone|--- |6.0
Summary|coreutils'  |[6 Regression] coreutils'
   |wc.c:write_counts is|wc.c:write_counts is
   |miscompiled since commit|miscompiled since commit
   |7e3a76de7c496449b187c2688d9 |7e3a76de7c496449b187c2688d9
   |58631cf21a944   |58631cf21a944

[Bug tree-optimization/67859] [6 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with r228471.

[Bug c++/67862] [concepts] ICE in tsubst, at cp/pt.c:12625

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-06
 Ever confirmed|0   |1

[Bug c++/67862] [concepts] ICE in tsubst, at cp/pt.c:12625

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

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

[Bug fortran/66927] [6 Regression] ICE in gfc_conf_procedure_call

[vehre at gcc dot gnu.org]

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

--- Comment #8 from vehre at gcc dot gnu.org ---
More elaborate patch available at:

https://gcc.gnu.org/ml/fortran/2015-09/msg00142.html

This patch also handles functions for source= that return a class object.

[Bug middle-end/67861] coreutils' wc.c:write_counts is miscompiled since commit 7e3a76de7c496449b187c2688d958631cf21a944

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Jim, could you please provide a preprocessed source file for wc?

[Bug rtl-optimization/67828] [6 Regression] wrong code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Use ssa_undefined_value_p (..., true), otherwise looks sensible.  I suppose
we could unswitch on the value if the condition is always executed in the loop
but then that's hardly a useful optimization (on undefined values).

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

[ebotcazou at gcc dot gnu.org]

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

--- Comment #16 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Oct  6 09:14:48 2015
New Revision: 228516

URL: https://gcc.gnu.org/viewcvs?rev=228516=gcc=rev
Log:
PR c/65345
* config/sparc/sparc.c (sparc_atomic_assign_expand_fenv): Adjust to
use create_tmp_var_raw rather than create_tmp_var.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sparc/sparc.c

[Bug lto/67871] New: LTO falis for ARM big-endian

[jonathan at codesourcery dot com]

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

Bug ID: 67871
   Summary: LTO falis for ARM big-endian
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jonathan at codesourcery dot com
  Target Milestone: ---

$ touch empty.c
$ arm-none-eabi-gcc -mbig-endian -flto empty.c
/tmp/ccUtMyOv.o: file not recognized: File format is ambiguous
/tmp/ccUtMyOv.o: matching formats: elf32-bigarm elf32-big
collect2: error: ld returned 1 exit status

[Bug c++/67810] Non-expression recognized as fold expression

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Wed Oct  7 01:46:54 2015
New Revision: 228556

URL: https://gcc.gnu.org/viewcvs?rev=228556=gcc=rev
Log:
PR c++/67810
* parser.c (cp_parser_fold_expr_p): Remove.
(is_binary_op): New.
(cp_parser_fold_expression): Take LHS as parameter.
(cp_parser_primary_expression): Call it after parsing an expression.
(cp_parser_binary_expression, cp_parser_assignment_operator_opt)
(cp_parser_expression): Ignore an operator followed by '...'.
(is_binary_op): New.
* pt.c (tsubst_unary_left_fold, tsubst_binary_left_fold)
(tsubst_unary_right_fold, tsubst_binary_right_fold): Handle errors.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ45.C
trunk/gcc/testsuite/g++.dg/cpp1z/fold6.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/g++.dg/cpp1z/fold2.C

[Bug c++/67810] Non-expression recognized as fold expression

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/67816] [6 Regression] ICE in duplicate_thread_path, 186.crafty fails to build

[law at gcc dot gnu.org]

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

--- Comment #13 from Jeffrey A. Law  ---
Author: law
Date: Wed Oct  7 02:25:57 2015
New Revision: 228559

URL: https://gcc.gnu.org/viewcvs?rev=228559=gcc=rev
Log:
[PATCH][PR tree-optimization/67816] Fix jump threading when DOM removes
conditionals in jump threading path

PR tree-optimization/67816
* tree-ssa-threadupdate.h (remove_jump_threads_including): Renamed
from remove_jump_threads_starting_at.  Accept an edge rather than
a basic block.
* tree-ssa-threadupdate.c (removed_edges): New hash table.
(remove_jump_threads_including): Note edges that get removed from
the CFG for later pruning of jump threading paths including them.
(thread_through_all_blocks): Remove paths which include edges that
have been removed.
* tree-ssa-dom.c (optimize_stmt): Call remove_jump_threads_including
on each outgoing edges when optimizing away a control statement.

* gcc.c-torture/compile/pr67816.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr67816.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-dom.c
trunk/gcc/tree-ssa-threadupdate.c
trunk/gcc/tree-ssa-threadupdate.h

[Bug tree-optimization/67816] [6 Regression] ICE in duplicate_thread_path, 186.crafty fails to build

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #14 from Jeffrey A. Law  ---
Fixed on trunk.

[Bug fortran/65766] gFortran Compiler SEGFAULTING on compiling simple program

[lkrupp at gcc dot gnu.org]

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

lkrupp at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||lkrupp at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #9 from lkrupp at gcc dot gnu.org ---
Fixed on the trunk.  Thanks for the report!

[Bug middle-end/67766] [6 Regression]: Bootstrap failure on alpha-linux-gnu: ICE in simplify_subreg, at simplify-rtx.c

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-10-07
 Ever confirmed|0   |1

--- Comment #1 from Alexandre Oliva  ---
Mine.  Moving down the code in function.c that's under the comment:
 /* If a named return value dumped decl_return to memory, then
we may need to re-do the PROMOTE_MODE signed/unsigned
extension.  */
so that the test:
 else if (GET_MODE (real_decl_rtl) != GET_MODE (decl_rtl))
appears after the blocks that deal with PARALLELs and CONCATs fixes it for me,
without any regressions on x86* regstraps.

Could you please confirm it fixes bootstrap on alpha?  TIA,

[Bug target/66697] Feature request: -mstackrealign and force_align_arg_pointer for x86_64

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Attachment #36445|0   |1
is obsolete||

--- Comment #11 from Uroš Bizjak  ---
Created attachment 36450
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36450=edit
V2 patch that enables force_align_arg_pointer attribute for x86_64 targets

[Bug target/66697] Feature request: -mstackrealign and force_align_arg_pointer for x86_64

[ubizjak at gmail dot com]

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

--- Comment #10 from Uroš Bizjak  ---
Version 2 patch to be attached. For the following testcase:

--cut here--
typedef float __v4sf __attribute__ ((__vector_size__ (16)));

__v4sf
__attribute__((force_align_arg_pointer, ms_abi))
test_ms (__v4sf a, __v4sf b)
{
  volatile register __v4sf x __asm__("%xmm6") = a;
  volatile register __v4sf y __asm__("%xmm7") = b;

  volatile __v4sf r = x + y;

  return r;
}
--cut here--

-O2 generates:

 :
   0:   55  push   %rbp
   1:   48 89 e5mov%rsp,%rbp
   4:   48 83 ec 20 sub$0x20,%rsp
   8:   48 83 e4 f0 and$0xfff0,%rsp
   c:   48 83 ec 10 sub$0x10,%rsp
  10:   0f 28 02movaps (%rdx),%xmm0
  13:   0f 58 01addps  (%rcx),%xmm0
  16:   0f 11 75 e0 movups %xmm6,0xffe0(%rbp)
  1a:   0f 11 7d f0 movups %xmm7,0xfff0(%rbp)
  1e:   0f 29 04 24 movaps %xmm0,(%rsp)
  22:   0f 10 75 e0 movups 0xffe0(%rbp),%xmm6
  26:   0f 28 04 24 movaps (%rsp),%xmm0
  2a:   0f 10 7d f0 movups 0xfff0(%rbp),%xmm7
  2e:   c9  leaveq 
  2f:   c3  retq   

xmm6 and xmm7 are saved outside stack realignment area. Please note that movups
with aligned operand is as fast as movaps, so considering that unaligned
incoming stack should be avoided, I think that the above code is acceptable.

[Bug c/67764] -Wconversion generates false warnings for bitmask+cast expressions

[marcin.slusarz at intel dot com]

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

--- Comment #4 from Marcin Ślusarz  ---
The issue is similar. However what I described in this bug can be considered a
regression, because gcc 4.9 behaves correctly. Bug 40752 is 6 years old.

[Bug target/66697] Feature request: -mstackrealign and force_align_arg_pointer for x86_64

[bucaneer at gmail dot com]

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

--- Comment #18 from Justas L  ---
Out of curiosity, what could it be that makes -mincoming-stack-boundary=3
successfully deal with rogue code while -mstackrealign fails at that? Shouldn't
-mstackrealign do the same job without being told what the outside stack
alignment is, or am I misunderstanding it?

[Bug fortran/65766] gFortran Compiler SEGFAULTING on compiling simple program

[lkrupp at gcc dot gnu.org]

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

--- Comment #8 from lkrupp at gcc dot gnu.org ---
Author: lkrupp
Date: Tue Oct  6 23:47:18 2015
New Revision: 228551

URL: https://gcc.gnu.org/viewcvs?rev=228551=gcc=rev
Log:
2015-10-06  Louis Krupp 
PR fortran/65766
* resolve.c (gfc_resolve_substring_charlen): For derived type,
use typespec of string component when resolving substring length.

2015-10-06  Louis Krupp 

PR fortran/65766
* gfortran.dg/substr_alloc_string_comp_1.f90: New.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/66145] [5/6 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #4)
> The last handler matches, but it should have matched earlier.

Doh, this is expected, because the C++03 ios::failure doesn't derive from
runtime_error.

[Bug lto/67699] [4.9/5 Regression] ICE (segfault) compiling a const array with -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Tue Oct  6 10:19:54 2015
New Revision: 228517

URL: https://gcc.gnu.org/viewcvs?rev=228517=gcc=rev
Log:
2015-10-06  Richard Biener  

Backport from mainline
2015-09-15  Richard Biener  

PR middle-end/67563
* gimple-fold.c (gimplify_and_update_call_from_tree): Do not
transfer EH info from old to new stmt.
(replace_call_with_value): Likewise.
(replace_call_with_call_and_fold): Likewise.
(gimple_fold_builtin_memory_op): Likewise.
(gimple_fold_builtin_memset): Likewise.
(gimple_fold_builtin_stpcpy): Likewise.
(gimple_fold_call): Likewise.

* gcc.dg/pr67563.c: New testcase.

2015-09-24  Richard Biener  

PR lto/67699
* lto-cgraph.c (compute_ltrans_boundary): Do not stream
abstract origins.

* g++.dg/pr67699.C: New testcase.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/pr67699.C
branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr67563.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/gimple-fold.c
branches/gcc-5-branch/gcc/lto-cgraph.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug middle-end/67563] [5 Regression] verify_flow_info failed

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Tue Oct  6 10:19:54 2015
New Revision: 228517

URL: https://gcc.gnu.org/viewcvs?rev=228517=gcc=rev
Log:
2015-10-06  Richard Biener  

Backport from mainline
2015-09-15  Richard Biener  

PR middle-end/67563
* gimple-fold.c (gimplify_and_update_call_from_tree): Do not
transfer EH info from old to new stmt.
(replace_call_with_value): Likewise.
(replace_call_with_call_and_fold): Likewise.
(gimple_fold_builtin_memory_op): Likewise.
(gimple_fold_builtin_memset): Likewise.
(gimple_fold_builtin_stpcpy): Likewise.
(gimple_fold_call): Likewise.

* gcc.dg/pr67563.c: New testcase.

2015-09-24  Richard Biener  

PR lto/67699
* lto-cgraph.c (compute_ltrans_boundary): Do not stream
abstract origins.

* g++.dg/pr67699.C: New testcase.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/pr67699.C
branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr67563.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/gimple-fold.c
branches/gcc-5-branch/gcc/lto-cgraph.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug middle-end/67563] [5 Regression] verify_flow_info failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||5.3.0
 Resolution|--- |FIXED

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

[Bug c++/67863] -Wtautological-compare warns when it shouldn't

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-06
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
And because of the missing location in cc1plus this
 1911   /* Don't warn for various macro expansions.  */
 1912   if (from_macro_expansion_at (loc)
 1913   || from_macro_expansion_at (EXPR_LOCATION (lhs))
 1914   || from_macro_expansion_at (EXPR_LOCATION (rhs)))
 1915 return;
doesn't trigger so we warn.

[Bug c++/67863] -Wtautological-compare warns when it shouldn't

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||diagnostic
   Target Milestone|--- |6.0

[Bug c++/67863] New: -Wtautological-compare warns when it shouldn't

[mpolacek at gcc dot gnu.org]

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

Bug ID: 67863
   Summary: -Wtautological-compare warns when it shouldn't
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

extern int e;
#define A (e ? 4 : 8)
#define B (e ? 4 : 8)

int
fn (void)
{
  if (A <= B)
return 1;
  return 0;
}

cc1plus warns, while cc1 does not.  What happens here is that the COND_EXPRs
warn_tautological_cmp gets don't have a location in cc1plus:

(gdb) pt
warning: Expression is not an assignment (and might have no effect)
 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x716ff7e0 precision
32 min  max 
pointer_to_this >

arg 0 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x716ffd20
precision 1 min  max >

arg 0 
used public external decl_2 SI file b.c line 1 col 12 size
 unit size 
align 32 context  chain
>
arg 1 >
arg 1 
constant 4>
arg 2 
constant 8>>

in cc1:

(gdb) pt
warning: Expression is not an assignment (and might have no effect)
 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x716ff7e0 precision
32 min  max 
pointer_to_this >

arg 0 

arg 0 
arg 1 >
arg 1 
b.c:8:7>
arg 1 
constant 4>
arg 2 
constant 8>
b.c:8:7>

[Bug target/67848] ICE on gcc.dg/atomic/pr65345-4.c and gcc.dg/pr65345-3.c

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Ramana Radhakrishnan  ---
dup of 65345

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

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

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #17 from Ramana Radhakrishnan  ---
*** Bug 67848 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/67864] [6 Regression] CSiBE size regression

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug rtl-optimization/67864] New: [6 Regression] CSiBE size regression

[rguenth at gcc dot gnu.org]

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

Bug ID: 67864
   Summary: [6 Regression] CSiBE size regression
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
CC: segher at kernel dot crashing.org
  Target Milestone: ---

http://gcc.opensuse.org/CSiBE/ shows a big size regression between r228310
(good)
and r228359 (bad).  Flags used are -Os -fgnu89-inline, suspect is


+2015-10-01  Segher Boessenkool  
+
+   * bb-reorder.c (reorder_basic_blocks): Use the algorithm selected
+   with flag_reorder_blocks_algorithm.
+   * common.opt (freorder-blocks-algorithm=): New flag.
+   (reorder_blocks_algorithm): New enum.
+   * flag-types.h (reorder_blocks_algorithm): New enum.
+   * opts.c (default_options_table): Use -freorder-blocks at -O1 and up,
+   and -freorder-blocks-algorithm=stc at -O2 and up (not at -Os).

The size regression is from 3562398 bytes to 3617915 bytes.

[Bug sanitizer/67865] New: ASAN crashes on thread creation

[dominik.stras...@onespin-solutions.com]

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

Bug ID: 67865
   Summary: ASAN crashes on thread creation
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominik.stras...@onespin-solutions.com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

In my application, ASAN crashes with the following stack backtrace:
==1926==ERROR: AddressSanitizer: SEGV on unknown address 0x7f4e24fbd010 (pc
0x7f4e40dafc0b bp 0xffd8 sp 0x7f4e259cf1a0 T13)
#0 0x7f4e40dafc0a in __sanitizer::DTLS_on_tls_get_addr(void*, void*)
../../../../gcc-5.2.0/libsanitizer/sanitizer_common/sanitizer_tls_get_addr.cc:85
#1 0x7f4e40d36925 in __interceptor___tls_get_addr
../../../../gcc-5.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:3873
#2 0x7f4e40db0483 in __lsan::DisabledInThisThread()
../../../../gcc-5.2.0/libsanitizer/lsan/lsan_common.cc:33
#3 0x7f4e40d23004 in Allocate
../../../../gcc-5.2.0/libsanitizer/asan/asan_allocator2.cc:382
#4 0x7f4e40d942fe in __interceptor_realloc
../../../../gcc-5.2.0/libsanitizer/asan/asan_malloc_linux.cc:60
#5 0x3dc3608b3e in pthread_getattr_np (/lib64/libpthread.so.0+0x3dc3608b3e)
#6 0x7f4e40da6fe3 in __sanitizer::GetThreadStackTopAndBottom(bool, unsigned
long*, unsigned long*)
../../../../gcc-5.2.0/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:109
#7 0x7f4e40da750b in __sanitizer::GetThreadStackAndTls(bool, unsigned
long*, unsigned long*, unsigned long*, unsigned long*)
../../../../gcc-5.2.0/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:303
#8 0x7f4e40d9dac4 in __asan::AsanThread::SetThreadStackAndTls()
../../../../gcc-5.2.0/libsanitizer/asan/asan_thread.cc:185
#9 0x7f4e40d9dcc1 in __asan::AsanThread::Init()
../../../../gcc-5.2.0/libsanitizer/asan/asan_thread.cc:144
#10 0x7f4e40d9de7e in __asan::AsanThread::ThreadStart(unsigned long)
../../../../gcc-5.2.0/libsanitizer/asan/asan_thread.cc:157
#11 0x3dc36079d0 in start_thread (/lib64/libpthread.so.0+0x3dc36079d0)
#12 0x3dc2ee8b6c in __clone (/lib64/libc.so.6+0x3dc2ee8b6c)
AddressSanitizer can not provide additional info.

Additional information can be provided on request

My executable has been compiled with:
-fsanitize=address -fno-omit-frame-pointer -fstack-protector-all -O3 -g
-D_REENTRANT -lpthread

[Bug c++/67866] New: False positive -Wshift-count-overflow on template code that checks for shift count overflow

[scovich at gmail dot com]

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

Bug ID: 67866
   Summary: False positive -Wshift-count-overflow on template code
that checks for shift count overflow
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: scovich at gmail dot com
  Target Milestone: ---

The following code snippet evokes an obviously unhelpful warning:

 bug.cpp 
template 
unsigned long int m()
{
unsigned long int max_value = 1;
if (M < 64)
max_value = (max_value << M) - 1;
else
max_value = ~(max_value - 1);

return max_value;
}

int main()
{
m<64>();
}
=

Output is:
g++-5.2 -Wshift-count-overflow bug.cpp -O3
bug.cpp: In instantiation of 'long unsigned int m() [with int M = 64]':
bug.cpp:14:11:   required from here
bug.cpp:6:32: warning: left shift count >= width of type
[-Wshift-count-overflow]
 max_value = (max_value << M) - 1;
^

[Bug target/66697] Feature request: -mstackrealign and force_align_arg_pointer for x86_64

[ubizjak at gmail dot com]

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

--- Comment #13 from Uroš Bizjak  ---
(In reply to Justas L from comment #12)
> This one does not apply neatly on 5.2.0 and I have trouble getting the dev
> version to compile, so I can't test it. Any chance of a backport?

Sent via private mail.

[Bug target/67480] AVX512 bitwise logic operations pattern is incorrect

[kyukhin at gcc dot gnu.org]

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

--- Comment #6 from Kirill Yukhin  ---
This bug is reproducible on gcc-5-branch

[Bug sanitizer/67867] UBSan bootstrap fails with error: ‘otype’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

[chefmax at gcc dot gnu.org]

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

--- Comment #2 from Maxim Ostapenko  ---
Created attachment 36451
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36451=edit
Reprocase.

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

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Target||arm, aarch64, x86_64,i386,
   ||sparc, powerpc*
 Status|RESOLVED|REOPENED
 CC||ramana at gcc dot gnu.org
 Resolution|FIXED   |---

--- Comment #18 from Ramana Radhakrishnan  ---
This is not fixed till all the targets are fixed -

Also the target milestone is set at 5.3 but the fix hasn't been applied to the
5 branch.

[Bug tree-optimization/67859] [6 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue Oct  6 12:34:15 2015
New Revision: 228519

URL: https://gcc.gnu.org/viewcvs?rev=228519=gcc=rev
Log:
2015-10-06  Richard Biener  

PR tree-optimization/67859
* tree-ssa-pre.c (create_expression_by_pieces): Properly
discard not inserted stmts.

* gcc.dg/torture/pr67859.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr67859.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-pre.c

[Bug target/66697] Feature request: -mstackrealign and force_align_arg_pointer for x86_64

[bucaneer at gmail dot com]

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

--- Comment #12 from Justas L  ---
This one does not apply neatly on 5.2.0 and I have trouble getting the dev
version to compile, so I can't test it. Any chance of a backport?

[Bug tree-optimization/67859] [6 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/67849] AVX512 Hitting upper-bank register on extract insn split

[kyukhin at gcc dot gnu.org]

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

--- Comment #1 from Kirill Yukhin  ---
Author: kyukhin
Date: Tue Oct  6 13:49:30 2015
New Revision: 228525

URL: https://gcc.gnu.org/viewcvs?rev=228525=gcc=rev
Log:
AVX-512. Avoid upper-bank registers when splitting vec_extract_lo instruction.

gcc/
PR target/67849
* config/i386/sse.md (define_split vec_select/V8FI): Restrict
split for upper-bank registers when target does not support
AVX512VL.
(define_insn "vec_extract_lo_"): Restrict
split when target does not support AVX512VL.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md

[Bug sanitizer/67867] UBSan bootstrap fails with error: ‘otype’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-10-06
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Yeah, I've seen this many times and even had a patch to fix it, but I never
posted it.  Let me do it this time.

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

[dje at gcc dot gnu.org]

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

--- Comment #19 from David Edelsohn  ---
Author: dje
Date: Tue Oct  6 13:46:34 2015
New Revision: 228524

URL: https://gcc.gnu.org/viewcvs?rev=228524=gcc=rev
Log:
PR c/65345
* config/rs6000/rs6000.c (rs6000_atomic_assign_expand_fenv):
Adjust to use create_tmp_var_raw instead of create_tmp_var.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c

[Bug target/67849] AVX512 Hitting upper-bank register on extract insn split

[afomin.mailbox at gmail dot com]

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

Alexander Fomin  changed:

   What|Removed |Added

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

--- Comment #2 from Alexander Fomin  ---
See previous comment.

[Bug sanitizer/67865] ASAN crashes on thread creation

[dominik.stras...@onespin-solutions.com]

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

dominik.stras...@onespin-solutions.com changed:

   What|Removed |Added

 Target||x86_64-unknown-linux-gnu
   Host||x86_64-unknown-linux-gnu
  Build||x86_64-unknown-linux-gnu

--- Comment #1 from dominik.stras...@onespin-solutions.com ---
Host system: CentOS release 6.4 (Final)
glibc: glibc-2.12-1.132.el6.x86_64

[Bug sanitizer/67867] New: UBSan bootstrap fails with error: ‘otype’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

[chefmax at gcc dot gnu.org]

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

Bug ID: 67867
   Summary: UBSan bootstrap fails with error: ‘otype’ may be used
uninitialized in this function
[-Werror=maybe-uninitialized]
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chefmax at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org,
mpolacek at gcc dot gnu.org, y.gribov at samsung dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

$ /home/max/build/master-ref/./prev-gcc/xg++
-B/home/max/build/master-ref/./prev-gcc/
-B/home/max/install/master-ref/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/home/max/build/master-ref/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/home/max/build/master-ref/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/max/build/master-ref/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu

-I/home/max/build/master-ref/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
 -I/home/max/workspace/downloads/gcc/libstdc++-v3/libsupc++
-L/home/max/build/master-ref/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/max/build/master-ref/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-fno-PIE -c  -DIN_GCC_FRONTEND -g -O2 -fsanitize=undefined -DIN_GCC
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-fno-common  -DHAVE_CONFIG_H -I. -Icp -I/home/max/workspace/downloads/gcc/gcc
-I/home/max/workspace/downloads/gcc/gcc/cp
-I/home/max/workspace/downloads/gcc/gcc/../include
-I/home/max/workspace/downloads/gcc/gcc/../libcpp/include 
-I/home/max/workspace/downloads/gcc/gcc/../libdecnumber
-I/home/max/workspace/downloads/gcc/gcc/../libdecnumber/bid -I../libdecnumber
-I/home/max/workspace/downloads/gcc/gcc/../libbacktrace   -o cp/search.o -MT
cp/search.o -MMD -MP -MF cp/.deps/search.TPo
/home/max/workspace/downloads/gcc/gcc/cp/search.c
/home/max/workspace/downloads/gcc/gcc/cp/search.c: In function ‘int
accessible_p(tree, tree, bool)’:
/home/max/workspace/downloads/gcc/gcc/cp/search.c:1011:41: error: ‘otype’ may
be used uninitialized in this function [-Werror=maybe-uninitialized]
   dfs_accessible_data d = { decl, otype };
 ^

$ /home/max/build/master-ref/./prev-gcc/xg++ -v
Using built-in specs.
COLLECT_GCC=/home/max/build/master-ref/./prev-gcc/xg++
Target: x86_64-unknown-linux-gnu
Configured with: /home/max/workspace/downloads/gcc/configure --enable-multilib
--enable-checking --target=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu
--prefix=/home/max/install/master-ref --enable-languages=c,c++,lto
--enable-bootstrap --with-build-config=bootstrap-ubsan
Thread model: posix
gcc version 6.0.0 20151006 (experimental) (GCC)

I'm also attaching preprocessed source as bug.i.

[Bug middle-end/67868] New: [4.9/5/6 regression] ICE on targets with section anchors.

[ramana at gcc dot gnu.org]

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

Bug ID: 67868
   Summary: [4.9/5/6 regression] ICE on targets with section
anchors.
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ramana at gcc dot gnu.org
  Target Milestone: ---

Given this testcase on targets with section anchors. I see the  following ICE
on arm, aarch64 and powerpc targets.

$> cat /tmp/test.c
char _vtable_map_vars_start []
__attribute__ ((__visibility__ ("protected"), used, aligned(4096),
  section(".vtable_map_vars")))
  = { };

$> ./xgcc -B`pwd` -S -O2 /tmp/test.c

/tmp/test.c:5:3: internal compiler error: Segmentation fault
   = { };
   ^
0xa95d6f crash_signal
../../gcc-fsf/gcc/toplev.c:353
0xd6faec tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc-fsf/gcc/tree.h:2863
0xd6faec default_elf_asm_named_section(char const*, unsigned int, tree_node*)
../../gcc-fsf/gcc/varasm.c:6303
0xd7191f switch_to_section(section*)
../../gcc-fsf/gcc/varasm.c:7144
0xd75603 output_object_block
../../gcc-fsf/gcc/varasm.c:7335
0xd75603 output_object_blocks()
../../gcc-fsf/gcc/varasm.c:7440
Please submit a full bug report,
with preprocessed source if appropriate.

The reason for the failure appears to be a failure to handle VAR_DECLS in
default_elf_asm_named_section.  Given that switch_to_section essentially passes
a VAR_DECL or a FUNCTION_DECL into targetm.elf_asm_named_section while
targetm.elf_asm_named_section only handles IDENTIFIER_NAMES in it, there is a
clear mismatch in terms of what is passed and what is expected.

I've got a patch that I'm currently testing.

[Bug c++/67866] False positive -Wshift-count-overflow on template code that checks for shift count overflow

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-06
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Richard Biener  ---
The warning occurs in the "dead" code region.  Not sure, but maybe template
substitution can mark "obviously" dead regions with TREE_NO_WARNING?  This
is an issue for other warnings as well.

[Bug c++/67863] -Wtautological-compare warns when it shouldn't

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
I think I have a fix.

[Bug middle-end/67868] [4.9/5/6 regression] ICE in named section handling on targets with section anchors.

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target||aarch64*, arm*, powerpc*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-06
Summary|[4.9/5/6 regression] ICE on |[4.9/5/6 regression] ICE in
   |targets with section|named section handling on
   |anchors.|targets with section
   ||anchors.
 Ever confirmed|0   |1

--- Comment #1 from Ramana Radhakrishnan  ---
Confirmed.

[Bug target/67808] LRA ICEs on simple double to long double conversion test case

[meissner at gcc dot gnu.org]

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

--- Comment #3 from Michael Meissner  ---
Author: meissner
Date: Tue Oct  6 17:20:49 2015
New Revision: 228538

URL: https://gcc.gnu.org/viewcvs?rev=228538=gcc=rev
Log:
[gcc]
2015-10-05  Michael Meissner  
Peter Bergner  

PR target/67808
* config/rs6000/rs6000.md (extenddftf2): In the expander, only
allow registers, but provide insns for the combiner to create for
loads from memory. Separate VSX code from non-VSX code. For
non-VSX code, combine extenddftf2_fprs into extenddftf2 and rename
externaldftf2_internal to externaldftf2_fprs. Reorder constraints
so that registers come before memory operations. Drop support from
converting DFmode to TFmode, if the DFmode value is in a GPR
register.
(extenddftf2_fprs): Likewise.
(extenddftf2_internal): Likewise.
(extenddftf2_vsx): Likewise.
(extendsftf2): In the expander, only allow registers, but provide
insns for the combiner to create for stores and loads.

[gcc/testsuite]
2015-10-05  Michael Meissner  
Peter Bergner 

PR target/67808
* gcc.target/powerpc/pr67808.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr67808.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/testsuite/ChangeLog

[Bug target/66697] Feature request: -mstackrealign and force_align_arg_pointer for x86_64

[bucaneer at gmail dot com]

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

Justas L  changed:

   What|Removed |Added

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

--- Comment #14 from Justas L  ---
The backported patch works fine and does fix multiple instances of the Wine
issue. Marking the report as resolved.

[Bug middle-end/67861] [6 Regression] coreutils' wc.c:write_counts is miscompiled since commit 7e3a76de7c496449b187c2688d958631cf21a944

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell  ---
Author: nathan
Date: Tue Oct  6 16:47:00 2015
New Revision: 228536

URL: https://gcc.gnu.org/viewcvs?rev=228536=gcc=rev
Log:
PR 67861
* gimple-fold.c (gimple_fold_builtin): Add break after
BUILT_IN_PRINTF_CHK, BUILT_IN_VPRINTF_CHK folding.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c

[Bug c++/67870] ICE: in type_throw_all_p, at cp/except.c:1306

[dragonroot at gmail dot com]

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

--- Comment #1 from Konstantin Isakov  ---
$ g++-4.9 --std=c++11 bug.cc 
bug.cc: In destructor ‘Foo::~Foo()’:
bug.cc:17:3: internal compiler error: in type_throw_all_p, at cp/except.c:1306
   {}
   ^
Please submit a full bug report,
with preprocessed source if appropriate.

$ g++-4.9 --version
g++-4.9 (Debian 4.9.3-4) 4.9.3

[Bug middle-end/67861] [6 Regression] coreutils' wc.c:write_counts is miscompiled since commit 7e3a76de7c496449b187c2688d958631cf21a944

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #5 from Nathan Sidwell  ---
Fixed in 228536.

[Bug target/66697] Feature request: -mstackrealign and force_align_arg_pointer for x86_64

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Attachment #36450|0   |1
is obsolete||

--- Comment #16 from Uroš Bizjak  ---
Created attachment 36453
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36453=edit
V3 patch that enables force_align_arg_pointer attribute for x86_64 targets

Slightly updated V2 patch. Now REG_CFA_EXPRESSION note is attached to an
unaligned store insn instead of REG_FRAME_RELATED_EXPR note.

This is the patch in testing.

[Bug c++/67870] New: ICE: in type_throw_all_p, at cp/except.c:1306

[dragonroot at gmail dot com]

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

Bug ID: 67870
   Summary: ICE: in type_throw_all_p, at cp/except.c:1306
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dragonroot at gmail dot com
  Target Milestone: ---

The following code snippet makes the compiler ICE. Affects at least 4.8.2 and
4.9.3. Does not seem to affect 5.x. Compile with --std=c++11

==

#include 

template< class T >
struct Tmpl
{
  ~Tmpl() noexcept( std::is_nothrow_destructible< T >::value )
  {}
};

struct Empty
{
};

struct Foo
{
  ~Foo()
  {}

  Tmpl< Empty > member;
};

int main()
{
}

==

Live snippet to play with: http://melpon.org/wandbox/permlink/6vmp1P7Ppwzjk1kh

[Bug sanitizer/67865] ASAN crashes on thread creation

[kcc at gcc dot gnu.org]

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

--- Comment #2 from Kostya Serebryany  ---
(In reply to dominik.strasser from comment #1)
> Host system: CentOS release 6.4 (Final)
> glibc: glibc-2.12-1.132.el6.x86_64

glibc-2.12 might be a bit too old. 
We don't test with it, and this code is very glibc-dependent. 

Also, the asan run-time in gcc has not been updated for at least 1 year. 
Do you observe the same behavior with fresh clang?

[Bug target/66697] Feature request: -mstackrealign and force_align_arg_pointer for x86_64

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #15 from Uroš Bizjak  ---
(In reply to Justas L from comment #14)
> The backported patch works fine and does fix multiple instances of the Wine
> issue. Marking the report as resolved.

No, not yet.

I have adjusted the patch slightly (5.2 version sent to you privately), so it
will also fit x86 interrupt handlers. If you can confirm that the adjusted
patch works as well (it should, but just in case ...), it will be committed to
mainline SVN and backported to 5.2.