[Bug target/67391] [SH] Convert clrt addc to normal add insn

[olegendo at gcc dot gnu.org]

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

--- Comment #7 from Oleg Endo  ---
(In reply to Kazumoto Kojima from comment #6)
> Test completed with no new failures on sh4-unknown-linux-gnu.

Thanks!

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

[bernds at gcc dot gnu.org]

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

--- Comment #36 from Bernd Schmidt  ---
This looks better. I still don't quite understand why you're treating
MUST_CLOBBER and MAY_CLOBBER defs differently in simulate. It looks like a
MUST_CLOBBER produces a bit in gen which I think is not what is wanted.

Anything wrong with writing this simply as follows?

  if (DF_REF_FLAGS_IS_SET (def, DF_REF_MUST_CLOBBER | DF_REF_MAY_CLOBBER))
{
  bitmap_set_bit (kill, regno);
  bitmap_clear_bit (gen, regno);
}
  /* In the worst case, partial and conditional defs can leave bits
 uninitialized, so assume they do not change anything.  */
  else if (!DF_REF_FLAGS_IS_SET (def, DF_REF_PARTIAL | DF_REF_CONDITIONAL))
{
  bitmap_set_bit (gen, regno);
  bitmap_clear_bit (kill, regno);
}

And, not as a requirement for your patch, but as a point for discussion - do we
want a special all_ones_bitmap that doesn't take up memory for purposes like
this? It would add two additional tests to each bitmap_{and,ior} operation.

[Bug driver/47785] GCC with -flto does not pass options to the assembler

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
Another instance on x86_64-apple-darwin14 with Xcode 7

[Book15] f90/bug% gcc6 /opt/gcc/_clean/gcc/testsuite/gcc.dg/debug/pr41893-1.c
-gstabs1 -Wa,-Q -flto -fwhole-program -O
/opt/gcc/_clean/gcc/testsuite/gcc.dg/debug/pr41893-2.c
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccJ7keUF.s:1:9: error:
unsupported directive '.stabs'
.stabs 
"/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccnRWDSD.ltrans0.o",100,0,0,Ltext0
^
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccJ7keUF.s:4:9: error:
unsupported directive '.stabs'
.stabs  "gcc2_compiled.",60,0,0,0
^
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccJ7keUF.s:8:9: error:
unsupported directive '.stabs'
.stabs 
"/opt/gcc/_clean/gcc/testsuite/gcc.dg/debug/pr41893-1.c",132,0,0,Ltext1
^
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccJ7keUF.s:10:2: error:
unknown directive
.stabd  68,0,16
^
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccJ7keUF.s:13:2: error:
unknown directive
.stabd  68,0,16
^
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccJ7keUF.s:17:9: error:
unsupported directive '.stabs'
.stabs  "main:F(0,1)=r(0,1);-2147483648;2147483647;",36,0,0,_main
^
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccJ7keUF.s:22:2: error:
unknown directive
.stabd  68,0,12
^
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccJ7keUF.s:27:9: error:
unsupported directive '.stabs'
.stabs  "func1:F(0,2)=(0,2)",36,0,0,_func1
^
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccJ7keUF.s:72:9: error:
unsupported directive '.stabs'
.stabs  "",100,0,0,Letext0
^
lto-wrapper: fatal error: gcc6 returned 1 exit status
compilation terminated.
collect2: fatal error: lto-wrapper returned 1 exit status
compilation terminated.

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

[bonzini at gnu dot org]

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

--- Comment #35 from Paolo Bonzini  ---
Comment on attachment 36377
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36377
Updated candidate patch

> + This problem determines which registers may be uninitialized. It first
> + assumes these are all initialized and then it eliminates the ones 
> reached
> + by paths without crossing a definition.  The IN bitmap is clear at first
> + (i.e. all registers are assumed not to be initialized) so don't consider
> + its value the first time.  */
> +  return bitmap_and_into (op1, op2);

Is this comment obsolete?  The IN bitmap is all set at first.  Otherwise looks
good.

[Bug target/67391] [SH] Convert clrt addc to normal add insn

[olegendo at gcc dot gnu.org]

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

--- Comment #10 from Oleg Endo  ---
The core issue should be fixed.  I'd like to keep this PR open though for a
while.

[Bug objc/67694] New: ICE on returning undefined enum in must_pass_in_stack_var_size_or_pad

[miyuki at gcc dot gnu.org]

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

Bug ID: 67694
   Summary: ICE on returning undefined enum in
must_pass_in_stack_var_size_or_pad
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: objc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: miyuki at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-linux-gnu

$ cat test.m 
@interface F
@end
@implementation F
- (enum e) e { return E; };
@end

$ cc1obj test.m 
 -[F e]
test.m: In function '-[F e]':
test.m:4:9: internal compiler error: Segmentation fault
 - (enum e) e { return E; };
 ^
0xaf3ecf crash_signal
/home/miyuki/gcc/src/gcc/toplev.c:353
0x730abf must_pass_in_stack_var_size_or_pad(machine_mode, tree_node const*)
/home/miyuki/gcc/src/gcc/calls.c:5068
0xdeb2af ix86_must_pass_in_stack
/home/miyuki/gcc/src/gcc/config/i386/i386.c:6301
0xdfb530 classify_argument
/home/miyuki/gcc/src/gcc/config/i386/i386.c:6880
0xdfc8e9 examine_argument
/home/miyuki/gcc/src/gcc/config/i386/i386.c:7274
0xe05065 ix86_return_in_memory
/home/miyuki/gcc/src/gcc/config/i386/i386.c:8682
0x8963d5 aggregate_value_p(tree_node const*, tree_node const*)
/home/miyuki/gcc/src/gcc/function.c:2089
0x89cf3e allocate_struct_function(tree_node*, bool)
/home/miyuki/gcc/src/gcc/function.c:4989
0x6155af store_parm_decls()
/home/miyuki/gcc/src/gcc/c/c-decl.c:8866
0x5c3716 objc_start_function(tree_node*, tree_node*, tree_node*, c_arg_info*)
/home/miyuki/gcc/src/gcc/objc/objc-act.c:8630
0x5c7e89 really_start_method
/home/miyuki/gcc/src/gcc/objc/objc-act.c:8683
0x5c946f start_method_def
/home/miyuki/gcc/src/gcc/objc/objc-act.c:8398
0x5c946f objc_start_method_definition(bool, tree_node*, tree_node*, tree_node*)
/home/miyuki/gcc/src/gcc/objc/objc-act.c:2073
0x668ff0 c_parser_objc_method_definition
/home/miyuki/gcc/src/gcc/c/c-parser.c:8645
0x66f929 c_parser_translation_unit
/home/miyuki/gcc/src/gcc/c/c-parser.c:1323
0x66f929 c_parse_file()
/home/miyuki/gcc/src/gcc/c/c-parser.c:15509
0x6cb832 c_common_parse_file()
/home/miyuki/gcc/src/gcc/c-family/c-opts.c:1058
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

I'm not sure, whether the problem is in the Objective C FE or somewhere in
ix86_return_in_memory target hook (and it's callees), but this ICE does not
occur when compiling for i?86:

$ cc1obj -m32 test.m
 -[F e]
test.m: In function '-[F e]':
test.m:4:23: error: 'E' undeclared (first use in this function)
 - (enum e) e { return E; };
   ^
test.m:4:23: note: each undeclared identifier is reported only once for each
function it appears in

[Bug c/49654] Linear search through options in handle_pragma_diagnostic

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #3 from Manuel López-Ibáñez  ---
Fixed in GCC 6.0

[Bug target/67439] [4.9/5/6 Regression]ICE: unrecognizable insn compiling arm-fp16 testcases with -march=armv7-a and -mrestrict-it

[ktkachov at gcc dot gnu.org]

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

--- Comment #8 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Wed Sep 23 10:36:48 2015
New Revision: 228039

URL: https://gcc.gnu.org/viewcvs?rev=228039=gcc=rev
Log:
[ARM] PR 67439: Allow matching of *arm32_movhf when -mrestrict-it is on

Backport from mainline
2015-09-10  Kyrylo Tkachov  

PR target/67439
* config/arm/arm.md (*arm32_movhf): Remove !arm_restrict_it from
predicate.  Set predicable_short_it attr to "no".

PR target/67439
* gcc.target/arm/pr67439_1.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/pr67439_1.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/arm/arm.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c/48885] missed optimization with restrict qualifier?

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-23
 Ever confirmed|0   |1

--- Comment #11 from Richard Biener  ---
It's just a matter of implementing the missing ???

/* Mark "other" loads and stores as belonging to CLIQUE and with
   base zero.  */

static bool
visit_loadstore (gimple *, tree base, tree ref, void *clique_)
{
  unsigned short clique = (uintptr_t)clique_;
  if (TREE_CODE (base) == MEM_REF
  || TREE_CODE (base) == TARGET_MEM_REF)
{
  tree ptr = TREE_OPERAND (base, 0);
  if (TREE_CODE (ptr) == SSA_NAME)
{
  /* ???  We need to make sure 'ptr' doesn't include any of
 the restrict tags in its points-to set.  */
  return false;

(well, we could handle default-defs without adding that).  Thus for the
particular testcase:

@@ -6952,7 +7047,8 @@ visit_loadstore (gimple *, tree base, tr
   || TREE_CODE (base) == TARGET_MEM_REF)
 {
   tree ptr = TREE_OPERAND (base, 0);
-  if (TREE_CODE (ptr) == SSA_NAME)
+  if (TREE_CODE (ptr) == SSA_NAME
+ && ! SSA_NAME_IS_DEFAULT_DEF (ptr))
{
  /* ???  We need to make sure 'ptr' doesn't include any of
 the restrict tags in its points-to set.  */

but we can of course do better.  Remember all 'restrict_var' we added
bases for and above lookup the points-to solution for 'ptr' and intersect
it with the restrict_var set.  If that's empty - fine - if not, we have
to continue failing.

I'm testing the above simple fix and amend the comment.

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

[derodat at adacore dot com]

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

--- Comment #32 from Pierre-Marie de Rodat  ---
(In reply to Bernd Schmidt from comment #28)
> It is sufficient for OUT(3) to be all-zeros. And I don't think the
> LAST_CHANGE_AGE mechanism does anything to prevent it. Please try it
> out. I think you have to initialize your bitmaps correctly rather than
> rely on "visited".
Thank you very much for the reproducer: I confirm that the
LAST_CHANGE_AGE mechanism does not have the effect I thought. I just
updated my patch locally to initialize bitmaps to 1 for all registers
and thus remove the visited field: this fixes the issue you found.

> > (In reply to Bernd Schmidt from comment #14)
> > > I do have to say that I am still uncomfortable with changing RRE to
> 
> I did not write this.
Indeed: Kenneth Zadeck said this in comment #20. I made a pasto, sorry
for that!



(In reply to Paolo Bonzini from comment #29)
> BTW, are you sure that
> 
> +  if (DF_REF_FLAGS_IS_SET (def,
> +  DF_REF_PARTIAL | DF_REF_CONDITIONAL))
> +   /* All partial or conditional def
> +  seen are included in the gen set. */
> +   bitmap_set_bit (gen, regno);
> 
> ?  I would have thought they don't belong in any set, and on the
> contrary I would have thought that may-clobber definitions count as
> kills.
For partial and conditional defs in the context of MIR:

  * if the register was initialized, then it is still initialized
afterwards, whatever happens;

  * if the register was uninitialized, then in the case of partial def
there will still be bits uninitialized and in the case of
conditional def it is possible that the instruction leaves the
register uninitialized: in both case there is a possibility to leave
part of the register uninitialized.

So I would agree with: they don't belong in any set.

While thinking about this, I also realized with REE in mind that since
we need a conservative computation for MIR, we must set KILL/clear GEN
for register refs with DF_REF_MAY_CLOBBER: it may leave the register
uninitialized.

(In reply to Paolo Bonzini from comment #31)
> Ah, I see now.  I think you're right that the DF_REF_MUST_CLOBBER case
> should also clear GEN in df_live_bb_local_compute.
> 
> However, regarding the "BTW" I am fairly sure now that
> df_live_bb_local_compute and the corresponding function for MIR should
> handle may-clobber and may-sets differently.  If you think of
> may-clobber and may-set as a diamond-shaped CFG:
> 
> […]
> 
> Then at the join point you have an "OR" for LIVE (so the clobber's
> KILL disappears and the set's GEN remains), and an "AND" for MIR.  For
> MIR the clobber's KILL remains and the set's GEN disappears.
Agreed, thank you! I have updated both MIR and LIVE in the light of
this. (bootstrapped and regtested on x86_64-linux)

[Bug c/48885] missed optimization with restrict qualifier?

[vries at gcc dot gnu.org]

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

--- Comment #12 from vries at gcc dot gnu.org ---
(In reply to Richard Biener from comment #11)
> I'm testing the above simple fix and amend the comment.

Consider the example with functions f and g I gave in comment 10. Using the
patch from comment 11, I get at ealias:
...
void f(int* __restrict__&, int*) (intD.9 * restrict & restrict pD.2252, intD.9
* p2D.2253)
{
  intD.9 * _3;

  # VUSE <.MEM_1(D)>
  # PT = { D.2265 } (nonlocal)
  _3 = MEM[(intD.9 * restrict &)p_2(D) clique 1 base 1];

  # .MEM_4 = VDEF <.MEM_1(D)>
  MEM[(intD.9 *)_3 clique 1 base 2] = 1;

  # .MEM_6 = VDEF <.MEM_4>
  MEM[(intD.9 *)p2_5(D) clique 1 base 0] = 2;
...

AFAIU, this is incorrect. The two stores can be now disambiguated based on same
clique/different base, but in fact the stores can alias (in fact they do, in
the  "f (gp, gp)" call from g).

[Bug c/49655] diagnostic pragma accepts non-warning options

[manu at gcc dot gnu.org]

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

--- Comment #2 from Manuel López-Ibáñez  ---
Author: manu
Date: Wed Sep 23 13:07:07 2015
New Revision: 228049

URL: https://gcc.gnu.org/viewcvs?rev=228049=gcc=rev
Log:
[c-family/49654/49655] reject invalid options in pragma diagnostic

Use find_opt instead of linear search through options in
handle_pragma_diagnostic (PR 49654) and reject non-warning options and
options not valid for the current language (PR 49655).

gcc/testsuite/ChangeLog:

2015-09-23  Manuel López-Ibáñez  

PR c/49655
* gcc.dg/pragma-diag-6.c: New test.

gcc/ChangeLog:

2015-09-23  Manuel López-Ibáñez  

PR c/49655
* opts.h (write_langs): Declare.
* opts-global.c (write_langs): Make it extern.

gcc/c-family/ChangeLog:

2015-09-23  Manuel López-Ibáñez  

PR c/49654
PR c/49655
* c-pragma.c (handle_pragma_diagnostic): Detect non-warning
options and options not valid for the current language.


Added:
trunk/gcc/testsuite/gcc.dg/pragma-diag-6.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-pragma.c
trunk/gcc/opts-global.c
trunk/gcc/opts.h
trunk/gcc/testsuite/ChangeLog

[Bug c/49654] Linear search through options in handle_pragma_diagnostic

[manu at gcc dot gnu.org]

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

--- Comment #2 from Manuel López-Ibáñez  ---
Author: manu
Date: Wed Sep 23 13:07:07 2015
New Revision: 228049

URL: https://gcc.gnu.org/viewcvs?rev=228049=gcc=rev
Log:
[c-family/49654/49655] reject invalid options in pragma diagnostic

Use find_opt instead of linear search through options in
handle_pragma_diagnostic (PR 49654) and reject non-warning options and
options not valid for the current language (PR 49655).

gcc/testsuite/ChangeLog:

2015-09-23  Manuel López-Ibáñez  

PR c/49655
* gcc.dg/pragma-diag-6.c: New test.

gcc/ChangeLog:

2015-09-23  Manuel López-Ibáñez  

PR c/49655
* opts.h (write_langs): Declare.
* opts-global.c (write_langs): Make it extern.

gcc/c-family/ChangeLog:

2015-09-23  Manuel López-Ibáñez  

PR c/49654
PR c/49655
* c-pragma.c (handle_pragma_diagnostic): Detect non-warning
options and options not valid for the current language.


Added:
trunk/gcc/testsuite/gcc.dg/pragma-diag-6.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-pragma.c
trunk/gcc/opts-global.c
trunk/gcc/opts.h
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/67681] Missed vectorization: induction variable used after loop

[alalaw01 at gcc dot gnu.org]

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

--- Comment #2 from alalaw01 at gcc dot gnu.org ---
Being stupid here, but why does the outer loop having multiple exits matter -
it's the inner loop that should be vectorized?

FOO was a macro used to selectively make the test i>max disappear (enabling
vectorization) - the two commandlines had -DFOO=0 (vectorizes) and -DFOO=1
(doesn't).

[Bug c/48885] missed optimization with restrict qualifier?

[rguenther at suse dot de]

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

--- Comment #13 from rguenther at suse dot de  ---
On Wed, 23 Sep 2015, vries at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48885
> 
> --- Comment #12 from vries at gcc dot gnu.org ---
> (In reply to Richard Biener from comment #11)
> > I'm testing the above simple fix and amend the comment.
> 
> Consider the example with functions f and g I gave in comment 10. Using the
> patch from comment 11, I get at ealias:
> ...
> void f(int* __restrict__&, int*) (intD.9 * restrict & restrict pD.2252, intD.9
> * p2D.2253)
> {
>   intD.9 * _3;
> 
>   # VUSE <.MEM_1(D)>
>   # PT = { D.2265 } (nonlocal)
>   _3 = MEM[(intD.9 * restrict &)p_2(D) clique 1 base 1];
> 
>   # .MEM_4 = VDEF <.MEM_1(D)>
>   MEM[(intD.9 *)_3 clique 1 base 2] = 1;
> 
>   # .MEM_6 = VDEF <.MEM_4>
>   MEM[(intD.9 *)p2_5(D) clique 1 base 0] = 2;
> ...
> 
> AFAIU, this is incorrect. The two stores can be now disambiguated based on 
> same
> clique/different base, but in fact the stores can alias (in fact they do, in
> the  "f (gp, gp)" call from g).

How is this a valid testcase?  You are accessing g()s *gp through
p and p2 even though p is marked as restrict.  Did you mean to write

void
f (int *&__restrict__ p, int *p2)

?

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

[bonzini at gnu dot org]

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

--- Comment #37 from Paolo Bonzini  ---
Bernd is right that you have a missing 'else'.

[Bug middle-end/67662] -fsanitize=undefined cries wolf for X - 1 + X when X is 2**30

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Yeah, r122414 fixed the PR30364 issue incompletely, leaving a special-case that
still mishandles this case.  Testing a patch.

[Bug c++/67693] New: Spurious warning: control reaches end of non-void function [-Wreturn-type]

[larsch at belunktum dot dk]

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

Bug ID: 67693
   Summary: Spurious warning: control reaches end of non-void
function [-Wreturn-type]
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: larsch at belunktum dot dk
  Target Milestone: ---

gcc 4.5.3 through to 5.2.0 all warn about reaching end of non-void function on
this code:

  struct foo { ~foo(); };
  int f(int n, int m) {
foo x; // Remove this to get rid of warning
switch (n) {
case 0:
  if (n == 4)
return 1;
  else
return 2;
  break; // Or remove this
default:
  return 0;
}
  }

Output:

  source.cpp: In function 'int f(int, int)':
  14 : warning: control reaches end of non-void function [-Wreturn-type]

Command line: 

  gcc -Wall -O0 source.cpp

Platforms: x86/arm/arm64.

Other info:

Removing the variable 'x' gets rid of the warning. So does removing the
(unnecessary, but valid) 'break' statement. Adding optimization (-O1 or more)
eliminates the warning.

[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[vogt at linux dot vnet.ibm.com]

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

--- Comment #29 from Dominik Vogt  ---
I think I understand what's going on:

Consider the patched code in match_reloads():

+   = (ins[1] < 0 && REG_P (in_rtx)
+  && (int) REGNO (in_rtx) < lra_new_regno_start
+  && find_regno_note (curr_insn, REG_DEAD, REGNO (in_rtx))
+  ? lra_create_new_reg (inmode, in_rtx, goal_class, "")
+  : lra_create_new_reg_with_unique_value (outmode, out_rtx,
+  goal_class, ""));

(1) This code normally makes a unique copy of the register in in_rtx, but if
the register is marked as REG_DEAD in the curr_insn, it just makes a copy of
the register using lra_create_new_reg(), with the same .val and .offset in the
reg_info structure.

(2) Further down in match_reloads, new insns are generated and stored in
*before and *after.  However, the new "after" insn still references the old
register.  In other words, in step (1) the code has made the assumption that
the old register is no longer used, then generates an insn that uses it after
it was marked as REG_DEAD.

(3) Based on the bogus decision in (1), the condition in lra-lives.c decides
that the two registers are identical copies and can be mapped to the same hard
register:

+ && (((src_regno >= FIRST_PSEUDO_REGISTER
+   && (! sparseset_bit_p (pseudos_live, src_regno)
+   || (dst_regno >= FIRST_PSEUDO_REGISTER
+   && lra_reg_val_equal_p (src_regno,
+   lra_reg_info[dst_regno].val,
+  
lra_reg_info[dst_regno].offset))

[Bug c/49655] diagnostic pragma accepts non-warning options

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #3 from Manuel López-Ibáñez  ---
Fixed in GCC 6.0

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

[derodat at adacore dot com]

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

Pierre-Marie de Rodat  changed:

   What|Removed |Added

  Attachment #36098|0   |1
is obsolete||

--- Comment #33 from Pierre-Marie de Rodat  ---
Created attachment 36377
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36377=edit
Updated candidate patch

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

[derodat at adacore dot com]

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

--- Comment #34 from Pierre-Marie de Rodat  ---
Created attachment 36378
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36378=edit
Fix for DF_LIVE local BB information

[Bug target/67391] [SH] Convert clrt addc to normal add insn

[olegendo at gcc dot gnu.org]

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

--- Comment #9 from Oleg Endo  ---
Author: olegendo
Date: Wed Sep 23 11:57:27 2015
New Revision: 228047

URL: https://gcc.gnu.org/viewcvs?rev=228047=gcc=rev
Log:
gcc/
Backport from mainline
2015-09-23  Oleg Endo  

PR target/67391
* config/sh/sh.md (addsi3, *addsi3_compact): Don't check for
overlapping
regs when matching the pattern.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/sh/sh.md

[Bug target/67391] [SH] Convert clrt addc to normal add insn

[olegendo at gcc dot gnu.org]

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

--- Comment #8 from Oleg Endo  ---
Author: olegendo
Date: Wed Sep 23 11:55:45 2015
New Revision: 228046

URL: https://gcc.gnu.org/viewcvs?rev=228046=gcc=rev
Log:
gcc/
PR target/67391
* config/sh/sh.md (addsi3, *addsi3_compact): Don't check for
overlapping
regs when matching the pattern.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md

[Bug middle-end/67662] -fsanitize=undefined cries wolf for X - 1 + X when X is 2**30

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||6.0

--- Comment #4 from Richard Biener  ---
Fixed on trunk, I am considering to backport to GCC 5 at least.

[Bug c/48885] missed optimization with restrict qualifier?

[vries at gcc dot gnu.org]

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

--- Comment #14 from vries at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #13)
> On Wed, 23 Sep 2015, vries at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48885
> > 
> > --- Comment #12 from vries at gcc dot gnu.org ---
> > (In reply to Richard Biener from comment #11)
> > > I'm testing the above simple fix and amend the comment.
> > 
> > Consider the example with functions f and g I gave in comment 10. Using the
> > patch from comment 11, I get at ealias:
> > ...
> > void f(int* __restrict__&, int*) (intD.9 * restrict & restrict pD.2252, 
> > intD.9
> > * p2D.2253)
> > {
> >   intD.9 * _3;
> > 
> >   # VUSE <.MEM_1(D)>
> >   # PT = { D.2265 } (nonlocal)
> >   _3 = MEM[(intD.9 * restrict &)p_2(D) clique 1 base 1];
> > 
> >   # .MEM_4 = VDEF <.MEM_1(D)>
> >   MEM[(intD.9 *)_3 clique 1 base 2] = 1;
> > 
> >   # .MEM_6 = VDEF <.MEM_4>
> >   MEM[(intD.9 *)p2_5(D) clique 1 base 0] = 2;
> > ...
> > 
> > AFAIU, this is incorrect. The two stores can be now disambiguated based on 
> > same
> > clique/different base, but in fact the stores can alias (in fact they do, in
> > the  "f (gp, gp)" call from g).
> 
> How is this a valid testcase?
> You are accessing g()s *gp through
> p and p2 even though p is marked as restrict.

To be exact, p is a restrict reference to a restrict pointer.
And AFAIU it's a valid test-case.

>  Did you mean to write
> 
> void
> f (int *&__restrict__ p, int *p2)
> 
> ?

No. I'll try explain, renaming variables to help clarification, and adding a
call to g for completeness:
...
void
f (int *__restrict__ &__restrict__ fp, int *fp2)
{
  *fp = 1;
  *fp2 = 2;
}

void
g (int *__restrict__ gp)
{
  f (gp, gp);
}

void
h (void)
{
  int ha;
  g ();
}
...

Let's look at the three restricts in the example.

First, there's the second restrict in "int *__restrict &__restrict fp", which
is a reference to object gp. Since object gp is not modified during f, the
restrict has no consequence.

Then there's the restrict in "int *__restrict__ gp". The object pointed to is
ha, and it's modified during g. So all accesses to ha during g need to be based
on gp. And that is the case. The '*fp2 = 1' is based on gp. And the '*fp2 = 2'
is based on gp.

Finally, there's the first restrict in "int *__restrict &__restrict fp". That's
a copy of the type of gp.

[Bug middle-end/67662] -fsanitize=undefined cries wolf for X - 1 + X when X is 2**30

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Wed Sep 23 14:09:48 2015
New Revision: 228051

URL: https://gcc.gnu.org/viewcvs?rev=228051=gcc=rev
Log:
2015-09-23   Richard Biener  

PR middle-end/67662
* fold-const.c (fold_binary_loc): Do not reassociate two vars with
undefined overflow unless they will cancel out.

* gcc.dg/ubsan/pr67662.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/ubsan/pr67662.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug other/67590] libcc1 cannot find objdump when cross build native

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #1 from Matthias Klose  ---
please send the patch together with an appropriate changelog entry to the
gcc-pat ches ML, maybe referencing this PR.

[Bug c/43651] add warning for duplicate qualifier

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||miyuki at gcc dot gnu.org

--- Comment #6 from Mikhail Maltsev  ---
Clang also emits a warning:

$ cat test.c
int foo(const char const *data);

$ /opt/clang-3.6.2/bin/clang -S -std=c89 test.c
test.c:1:20: warning: duplicate 'const' declaration specifier
[-Wduplicate-decl-specifier]
int foo(const char const *data);
   ^~
1 warning generated.
$ /opt/clang-3.6.2/bin/clang -S -std=c99 test.c
test.c:1:20: warning: duplicate 'const' declaration specifier
[-Wduplicate-decl-specifier]
int foo(const char const *data);
   ^
1 warning generated.
$ /opt/clang-3.6.2/bin/clang -xc++ -S -std=c++11 test.c
test.c:1:20: warning: duplicate 'const' declaration specifier
[-Wduplicate-decl-specifier]
int foo(const char const *data);
   ^~
1 warning generated.

"-pedantic-errors" turns this warning into an error in C++ and C89 (but not
C99).

Recently I came across such problem in the code base, which I work with. In
that case it was clearly a mistake, because the author meant 'const char *const
data', so it would be nice if GCC could warn about this.

[Bug c/67661] Wrong warning when declare VLAs: operation on 'x' may be undefined [-Wsequence-point]

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
You'll need to give a full testcase (complete compilable file and options 
used to compile it).  What you gave isn't a compilable testcase; it gives 
"error: variably modified 'y' at file scope".  Put inside a function, it 
gives "warning: unused variable 'y' [-Wunused-variable]", but does not 
give the warning you mention.  And there's no variable 'b' in your example 
at all.

[Bug c/43651] add warning for duplicate qualifier

[manu at gcc dot gnu.org]

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

--- Comment #7 from Manuel López-Ibáñez  ---
> Recently I came across such problem in the code base, which I work with. In
> that case it was clearly a mistake, because the author meant 'const char
> *const data', so it would be nice if GCC could warn about this.

I think that a patch that warns for 

const Type const x;

but not for:

typedef Type const X;
const X x;

and neither for

#define TYPE Type const
const TYPE;

would be accepted. But someone has to write it.

[Bug go/67695] New: Please improve POSIX shell compatibility of libgo/mksysinfo.sh

[ryo_on at yk dot rim.or.jp]

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

Bug ID: 67695
   Summary: Please improve POSIX shell compatibility of
libgo/mksysinfo.sh
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: ryo_on at yk dot rim.or.jp
CC: cmang at google dot com
  Target Milestone: ---

Created attachment 36379
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36379=edit
Use test = instead of test == in libgo/mksysinfo.sh

Please use POSIX test = notation instead of BASH test == in libgo/mksysinfo.sh.

[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15

[howarth.at.gcc at gmail dot com]

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

--- Comment #9 from Jack Howarth  ---
Note that the earliest upstream boehm-gc release which builds and passes make
check on 10.11 is gc-7.2.tar.gz from http://www.hboehm.info/gc/gc_source/.
Diffing the current boehm-gc sources in gcc trunk suggests that the current FSF
boehm-gc is based on 7.1 (for at least mach_dep.c, etc).

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Started looking into this.  Seems that we should handle specially those
artificial ubsan decls such as *.Lubsan_data in omp_default_clause, i.e. treat
them as shared?  But I hardly know what I'm talking about; inviting Jakub to
comment.

[Bug tree-optimization/67690] [5/6 Regression] wrong code with -O2 on x86_64/Linux

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |5.3
Summary|wrong code with -O2 on  |[5/6 Regression] wrong code
   |x86_64/Linux|with -O2 on x86_64/Linux

--- Comment #2 from Marek Polacek  ---
Confirmed.  Started with r220164.

[Bug tree-optimization/67690] [5/6 Regression] wrong code with -O2 on x86_64/Linux

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-23
 Ever confirmed|0   |1

[Bug c++/67693] Spurious warning: control reaches end of non-void function [-Wreturn-type]

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

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

--- Comment #1 from Mikhail Maltsev  ---
dup

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

[Bug c++/63356] Compilation failure where clang does not have problems

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||manu at gcc dot gnu.org
  Known to work||6.0
 Resolution|--- |FIXED

--- Comment #17 from Manuel López-Ibáñez  ---
(In reply to fiesh from comment #9)
> Ever so little simplified:

All three reduced testcases are working in GCC 6.0. I'm closing this as FIXED.
Feel free to reopen it if required.

[Bug c++/66590] switch statement: incorrect warning "reaches end of non-void function"

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||larsch at belunktum dot dk

--- Comment #3 from Mikhail Maltsev  ---
*** Bug 67693 has been marked as a duplicate of this bug. ***

[Bug fortran/67696] New: libbacktrace prints C++ demangled name for Fortran symbol

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 67696
   Summary: libbacktrace prints C++ demangled name for Fortran
symbol
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

The backtrace printed on abort can contain demangled names, instead of the
Fortran symbols. In the example below, cp__b becomes cp(bool) :

> cat test.f90
MODULE foo
CONTAINS
  SUBROUTINE cp__b()
 CALL ABORT()
  END SUBROUTINE
END MODULE 

PROGRAM test
USE foo
CALL cp__b()
END PROGRAM

> gfortran -g test.f90 ; ./a.out

Program aborted. Backtrace:
#0  0x7FE4810C6B87
#1  0x7FE4810C79C2
#2  0x7FE481198538
#3  0x4006A3 in __foo_MOD_cp(bool) at test.f90:4
#4  0x4006AC in test at test.f90:10
Aborted

I actually notice the same wrong name is printed if a backtrace is asked in
gdb:

(gdb) bt
#0  0x003ba4a32625 in raise () from /lib64/libc.so.6
#1  0x003ba4a33e05 in abort () from /lib64/libc.so.6
#2  0x77cf99a9 in _gfortrani_sys_abort () at
/data/vjoost/toolchain-r15694/build/gcc-5.2.0/libgfortran/runtime/error.c:180
#3  0x77dca539 in _gfortran_abort () at
/data/vjoost/toolchain-r15694/build/gcc-5.2.0/libgfortran/intrinsics/abort.c:33
#4  0x004006a4 in __foo_MOD_cp(bool) ()
#5  0x004006ad in MAIN__ ()
#6  0x004006e4 in main ()
#7  0x003ba4a1ed5d in __libc_start_main () from /lib64/libc.so.6
#8  0x004005a9 in _start ()

[Bug c++/67697] New: [concepts] ICE when using non-constexpr in requires expression

[ryan.burn at gmail dot com]

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

Bug ID: 67697
   Summary: [concepts] ICE when using non-constexpr in requires
expression
   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 following code causes an ICE:

//
template
concept bool C() {
  return requires(X x, bool b) {
requires b;
x++;
  };
}

int main() {
  C();
  return 0;
}
//

Stack Trace:
t1.cpp: In function ‘int main()’:
t1.cpp:10:10: internal compiler error: in xform_decl, at cp/constraint.cc:797
   C();
  ^
0x82016d xform_decl
../../gcc/gcc/cp/constraint.cc:797
0x82016d transform_expression
../../gcc/gcc/cp/constraint.cc:827
0x8202f0 xform_nested_requirement
../../gcc/gcc/cp/constraint.cc:632
0x8202f0 xform_requirement
../../gcc/gcc/cp/constraint.cc:652
0x8202f0 xform_requirements
../../gcc/gcc/cp/constraint.cc:669
0x8202f0 xform_requires_expr
../../gcc/gcc/cp/constraint.cc:680
0x8202f0 xform_expr
../../gcc/gcc/cp/constraint.cc:758
0x8202f0 transform_expression
../../gcc/gcc/cp/constraint.cc:821
0x8252d7 evaluate_function_concept(tree_node*, tree_node*)
../../gcc/gcc/cp/constraint.cc:2002
0x605b94 build_new_function_call(tree_node*, vec**, bool, int)
../../gcc/gcc/cp/call.c:4130
0x78ff5e finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2391
0x70ecc9 cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:6419
0x713679 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7486
0x7142b7 cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:8239
0x7149bf cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:8497
0x71d131 cp_parser_expression
../../gcc/gcc/cp/parser.c:8651
0x71ecd6 cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:10065
0x72a125 cp_parser_statement
../../gcc/gcc/cp/parser.c:9916
0x72ace2 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:10188
0x72ae4b cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:10142
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/66609] [sh] Relative address expressions bind at as-time, even if symbol is weak

[bugdal at aerifal dot cx]

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

--- Comment #9 from Rich Felker  ---
Indeed, the fdpic patch I forward-ported introduced new duplicates of some of
the fragments that were changed in sh.md by the above patch. Once I fixed
those, the problem went away. Sorry for the noise.

[Bug middle-end/67649] trunk build with valgrind fail in get_def_blocks_for

[dcb314 at hotmail dot com]

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

--- Comment #13 from David Binderman  ---
(In reply to Markus Trippelsdorf from comment #10)
> A gave your patch a quick spin on gcc112 (compile farm machine).
> It fixes the issue.

I also tried out the fix and a plain non-bootstrap build
of trunk gcc dated 2015-09-22, compiled with -O3 -march=native,
seems to build ok.

[Bug middle-end/67649] trunk build with valgrind fail in get_def_blocks_for

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #14 from Markus Trippelsdorf  ---
fixed

[Bug debug/67192] Backward-goto in loop can get wrong line number

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org,
   ||rth at gcc dot gnu.org

--- Comment #13 from Manuel López-Ibáñez  ---
(In reply to Patrick Palka from comment #12)
> Would it be a good idea to make the C frontend behave more like the C++
> frontend w.r.t. updating input_location? The behavior of the C++ frontend
> seems more sensible to me. And I think such a change would fix this PR.

As far as I know, everything that reduces spurious differences between C and
C++ FEs is welcome. Lexing at start-up is supposedly faster, thus any changes
in that direction should be acceptable (but I'm not a C maintainer, so better
ask them).

I'm afraid that wholesale changing the C FE behavior is going to lead to a lot
of subtle regressions. Using something like
c_parser_peek_token_keep_input_location allows changing the code case by case
and being able to point out which commit introduced a bug.

Removing uses of input_location throughout the compiler would also help. For
example, by passing an explicit location to c_finish_loop and using that for
the exit node.

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

[ktkachov at gcc dot gnu.org]

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
*** Bug 67689 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/67689] [6 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ktkachov at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from ktkachov at gcc dot gnu.org ---
I can confirm that it's a duplicate of PR 67456 and the patch I posted to fix
it
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01306.html
fixes this testcase as well on x86_64.

That patch is waiting on some SPARC testing. It has been bootstrapped and
tested on x86_64 and aarch64 so perhaps we'd want to take it in sooner rather
than later to prevent more duplicate reports

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

[Bug c++/67686] [concepts] segfault in finish_call_expr function

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-23
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
This is what creduce came up with:

typedef int size_t;
template  struct is_copy_constructible;
template  struct remove_reference;
template  struct remove_reference<_Tp &> { typedef _Tp type; };
template  void forward();
template  struct A {
  typedef A<0, sizeof...(_Indexes)> __next;
};
template  struct B {
  typedef typename B<_Num - 1>::__type::__next __type;
};
template <> struct B<0> { typedef A<> __type; };
template  struct C;
template ::__type> struct D;
template  struct D<_Tp, A<_Idx...>> {
  typedef C<_Tp, _Idx...> __type;
};
template 
using make_integer_sequence = typename D<_Tp>::__type;
template  using index_sequence = C;
template  using make_index_sequence = make_integer_sequence;
template  void and_c();
template  concept bool cpt_CopyConstructible() {
  return is_copy_constructible::value;
}

template  using uncvref_t = typename remove_reference::type;
template  class Tuple {};

auto make_tuple() { return Tuple<>(); }

template  size_t num_elements;
template 
constexpr size_t num_elements = sizeof...(Values);
template  concept bool cpt_MappableElement() {
  return requires(TupleForwards... tuples){requires cpt_CopyConstructible<
  decltype(forward(forward(tuples)...))>()};
}

template  int mappable_elements;
template 
int mappable_elements =
and_c;
template  int mappable_impl;
template 
int mappable_impl =
mappable_elements<
make_index_sequence>,
TupleForwardFirst>;
template  concept bool cpt_Mappable() {
  return mappable_impl;
}

cpt_Mappable { Functor, ... TupleForwards }

auto map(Functor, TupleForwards &&...);
auto t1 = make_tuple();
auto f1 = map(0, t1)

[Bug tree-optimization/67681] Missed vectorization: induction variable used after loop

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
The outer loop also has multiple exits.  The testcase is incomplete (FOO is
undefined).

[Bug tree-optimization/67682] Missed vectorization: (another) straight-line memcpy/memset not vectorized when equivalent loop is

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-23
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Interestingly it works on x86_64.  The key is of course interleaving detection
which has to split the store group properly.

Ah, I have a local patch:

Index: gcc/tree-vect-data-refs.c
===
--- gcc/tree-vect-data-refs.c   (revision 228010)
+++ gcc/tree-vect-data-refs.c   (working copy)
@@ -2610,6 +2636,10 @@ vect_analyze_data_ref_accesses (loop_vec
  != type_size_a))
break;

+ if (!DR_IS_READ (dra)
+ && (init_b - init_a) >= 16)
+   break;
+
  /* If the step (if not zero or non-constant) is greater than the
 difference between data-refs' inits this splits groups into
 suitable sizes.  */

so yes, the key is to split the group according to the active vector size
(so the above is clearly a hack).

A better place to handle this is vect_analyze_slp_instance which when
vect_build_slp_tree fails should have an idea if splitting is worth
(based on 'matches').  It would also need to split load groups for, say

void
test (int*__restrict a, int*__restrict b)
{
a[0] = b[0];
a[1] = b[1];
a[2] = b[2];
a[3] = b[3];
a[4] = b[4] + 1;
a[5] = b[5] + 2;
a[6] = b[6] + 3;
a[7] = b[7] + 4;
}

also the splitting is probably only a good idea for BB SLP (well, not sure).
It would need to re-invoke itself for all the split pieces.  So the hack
above is certainly easier but we don't know the choosen vector size yet
at the point of that analysis.  And BB vectorization could use different
vector sizes for different SLP instances easily.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-23
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The issue is the unsupported induction (the PHI) of val

  :
  # val_16 = PHI <52719(4), val_11(7)>
  # i_17 = PHI <0(4), i_12(7)>
  _6 = (sizetype) i_17;
  _8 = data_7(D) + _6;
  _9 = (unsigned char) val_16;
  *_8 = _9;
  val_11 = val_16 >> 1;
  i_12 = i_17 + 1;
  if (max_5(D) > i_12)

SCEV already fails to analyze the evolution of val_16 so it doesn't appear
as "induction" to the vectorizer.  Reductions with shifts are not handled
either (but reduction uses inside the loop are not supported by the vectorizer
anyway).

[Bug rtl-optimization/67689] [6 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-23
  Component|tree-optimization   |rtl-optimization
   Target Milestone|--- |6.0
Summary|wrong code at -O1, -O2 and  |[6 Regression] wrong code
   |-O3 on x86_64-linux-gnu |at -O1, -O2 and -O3 on
   ||x86_64-linux-gnu
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Looks like a RTL if-conversion issue (again).

[Bug c++/67693] Spurious warning: control reaches end of non-void function [-Wreturn-type]

[miyuki at gcc dot gnu.org]

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

--- Comment #2 from Mikhail Maltsev  ---
Though... maybe it's not an exact duplicate, but the problem looks seems very
similar. We generate (003t.original):

struct foo x;
  try
{
  switch (n)
{
  case 0:;
  if (n == 4)
{
  return  = 1;
}
  else
{
  return  = 2;
}
  goto ;
  default:;
  return  = 0;
}
  :;
}
  finally
{
  foo::~foo ();
}

And GIMPLE looks like this:

int f(int, int) (int n, int m)
{
  int D.2290;
  struct foo x;

  try
{
  try
{
  switch (n) , case 0: >
  :
  if (n == 4) goto ; else goto ;
  :
  D.2290 = 1;
  return D.2290;
  :
  D.2290 = 2;
  return D.2290;
  goto ;
  :
  D.2290 = 0;
  return D.2290;
  :
}
  finally
{
  foo::~foo ();
}
}
  finally
{
  x = {CLOBBER};
}
}

[Bug rtl-optimization/64164] [4.9/5/6 Regression] one more stack slot used due to one less inlining level

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Depends on||67597, 67490

--- Comment #54 from Alexandre Oliva  ---
New patch posted at https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01793.html


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67490
[Bug 67490] [6 regression] FAIL: gcc.target/powerpc/pr16458-1.c
scan-assembler-not cmpw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67597
[Bug 67597] [6 Regression] profiledbootstrap failure on ppc64le

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

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

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

--- Comment #3 from mikulas at artax dot karlin.mff.cuni.cz ---
I think you should treat these artifical variables as private, not shared. If
you treated them as shared, threads would race with each other when accessing
them.

[Bug other/67698] New: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2297

[hjl.tools at gmail dot com]

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

Bug ID: 67698
   Summary: internal compiler error: in maybe_record_trace_start,
at dwarf2cfi.c:2297
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: julia.koval at intel dot com
Blocks: 67552
  Target Milestone: ---

On hjl/interrupt/master branch, I got

[hjl@gnu-6 interrupt-2]$ cat bar.c
extern int check_int (int *i, void *, int align);
typedef int aligned __attribute__((aligned(64)));
typedef unsigned int uword_t __attribute__ ((mode (__word__)));

__attribute__((interrupt))
void
foo (void *frame, uword_t error_code)
{
  aligned j;
  if (check_int (frame, , __alignof__(j)))
__builtin_abort ();
}
[hjl@gnu-6 interrupt-2]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -S -o bar.s bar.c 
bar.c: In function ‘foo’:
bar.c:12:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2297
 }
 ^
0x946051 maybe_record_trace_start
/export/gnu/import/git/sources/gcc/gcc/dwarf2cfi.c:2297
0x94671f scan_trace
/export/gnu/import/git/sources/gcc/gcc/dwarf2cfi.c:2475
0x946cc9 create_cfi_notes
/export/gnu/import/git/sources/gcc/gcc/dwarf2cfi.c:2629
0x9477db execute_dwarf2_frame
/export/gnu/import/git/sources/gcc/gcc/dwarf2cfi.c:2987
0x948536 execute
/export/gnu/import/git/sources/gcc/gcc/dwarf2cfi.c:3467
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-6 interrupt-2]$


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67552
[Bug 67552] [meta] x86 interrupt attribute

[Bug go/67695] Please improve POSIX shell compatibility of libgo/mksysinfo.sh

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Wed Sep 23 20:43:46 2015
New Revision: 228064

URL: https://gcc.gnu.org/viewcvs?rev=228064=gcc=rev
Log:
PR go/67695
mksysinfo.sh: Use = with test rather than ==.

Fixes GCC PR 67695.

Reviewed-on: https://go-review.googlesource.com/14858

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/mksysinfo.sh

[Bug target/54412] Request for 32-byte stack alignment with -mavx on Windows

[roland at rschulz dot eu]

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

--- Comment #13 from Roland Schulz  ---
But this problem is limited to GCC. ICC, Clang and MSVC don't have the problem
with compiling 64bit AVX code. Thus they must have some kind of work-around for
ABI and GCC should be able to use a work-around too (at least in theory).

[Bug go/67695] Please improve POSIX shell compatibility of libgo/mksysinfo.sh

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Fixed.  Thanks.

[Bug target/67391] [SH] Convert clrt addc to normal add insn

[kkojima at gcc dot gnu.org]

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

--- Comment #6 from Kazumoto Kojima  ---
(In reply to Kazumoto Kojima from comment #5)
> Yes, this is clearly a 5/6 regression.  My test has passed C and C++ part
> with no new failures.  I'll report back when test completed.

Test completed with no new failures on sh4-unknown-linux-gnu.

[Bug target/67143] [5/6 Regression] ICE (could not split insn) on aarch64-linux-gnu

[mwahab at gcc dot gnu.org]

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

--- Comment #5 from mwahab at gcc dot gnu.org ---
Author: mwahab
Date: Wed Sep 23 09:48:16 2015
New Revision: 228037

URL: https://gcc.gnu.org/viewcvs?rev=228037=gcc=rev
Log:
[Aarch64][target/PR 67143][5.2] Backport correct constraints for atomic
operations.

gcc/
2015-09-23  Matthew Wahab  

Backport from mainline
2015-08-14  Matthew Wahab  

PR target/67143
* config/aarch64/atomics.md (atomic_): Replace
'lconst_atomic' with 'const_atomic'.
(atomic_fetch_): Likewise.
(atomic__fetch): Likewise.
* config/aarch64/iterators.md (lconst-atomic): Move below
'const_atomic'.
(const_atomic): New.

gcc/testsuite/
2015-09-23  Matthew Wahab  

Backport from mainline
2015-08-14  Matthew Wahab  
Matthias Klose  

PR target/67143
* gcc.c-torture/compile/pr67143.c: New
* gcc.target/aarch64/atomic-op-imm.c
(atomic_fetch_add_negative_RELAXED): New.
(atomic_fetch_sub_negative_ACQUIRE): New.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/compile/pr67143.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/aarch64/atomics.md
branches/gcc-5-branch/gcc/config/aarch64/iterators.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/atomic-op-imm.c

[Bug libstdc++/55815] switch hash function of libstdc++ hash tables to siphash

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to felix-glibc from comment #5)
> I mean seriously, you argue performance for a security measure?
> Does Google turn off stack cookies in production? ACL checks?
> All this password checking is making our code slow?
> I sure hope not.

I asked Geoff to comment here, there's no need to attack strawmen.

[Bug c++/67699] New: Segfault compiling a constexpr array with -fmerge-all-constants -flto

[gcc at norgg dot org]

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

Bug ID: 67699
   Summary: Segfault compiling a constexpr array with
-fmerge-all-constants -flto
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at norgg dot org
  Target Milestone: ---

Created attachment 36380
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36380=edit
Minimal testcase

Minimal test case attached, run with: g++ -std=c++11 -fmerge-all-constants
-flto gcc_crash.cpp -o gcc_crash.o

We've found this is repeatable in:

g++ (Ubuntu 4.9.2-0ubuntu1~14.04) 4.9.2
g++ (Ubuntu 5.1.0-0ubuntu11~14.04.1) 5.1.0
g++ 5.2.1 20150825 (Ubuntu 5.2.1-15ubuntu5)
g++ (Debian 5.2.1-17) 5.2.1 20150911
g++.exe (i686-posix-dwarf-rev0, Built by MinGW-W64 project) 5.1.0

[Bug tree-optimization/67700] [graphite] miscompile due to wrong codegen

[hiraditya at msn dot com]

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

--- Comment #1 from AK  ---
The problem seems to be in 

static void canonicalize_loop_closed_ssa (loop_p loop)

which generates phi node at a wrong place in this case.

[Bug c++/67699] Segfault compiling a constexpr array with -fmerge-all-constants -flto

[gcc at norgg dot org]

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

--- Comment #2 from Norgg  ---
It seems the -fmerge-all-constants isn't necessary to cause the segfault either
any more, although it was in an earlier larger test case.

Minimal command line to reproduce is now:
$ g++ const_crash.cpp -flto
const_crash.cpp:11:24: internal compiler error: Segmentation fault
 template class foo;
^

[Bug fortran/67614] ICE on using arithmetic if with null

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
I'm inclined to close this PR as WONTFIX.  The F2008 in
2.4.8 states: "A pointer that is not associated shall
not be referenced or defined."  This is not a numbered
constraint and so a Fortran processor is not required
to report an error.  It is the programmer's responsibility
to ensure that a referenced pointer is associated.

In addition, consider the code

program y1
   real, pointer :: a
   real, target :: b
   b = 42
   a => b
   call foo(a)
   a => null()
   call foo(a)
   contains
  subroutine foo(x)
 real, pointer :: x
 if (2*x+1) 10, 20, 30
10   print *, 'a'; goto 40
20   print *, 'b'; goto 40
30   print *, 'c'; goto 40
40   continue
  end subroutine
end program y1

The evaluation of the scalar-numeric-expr in the
arithmetic-if would requires a runtime check that
x is in fact an associated pointer.  This could 
be rather costly and prevent possible optimizations
if gfortran tried to always ensure any reference
to a pointer is properly associated.

It is the responsibility of the programmer to
write

if (associated(x) then
   if (2*x+1) 10, 20, 30
   ...
end if

Of course, if someone wants to add an -fcheck=pointer-status
option, then problems in this PR can be at least checked.

[Bug c/67701] Unnecessary/bad instructions for u32-casted access to external symbol (assumes misaligned, superfluous load)

[jwerner at chromium dot org]

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

Julius Werner  changed:

   What|Removed |Added

 Target||armv7a

--- Comment #1 from Julius Werner  ---
edit: target architecture in my example is armv7a, btw (although I doubt that
this is architecture-specific)

[Bug tree-optimization/67700] New: [graphite] miscompile due to wrong codegen

[hiraditya at msn dot com]

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

Bug ID: 67700
   Summary: [graphite] miscompile due to wrong codegen
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hiraditya at msn dot com
  Target Milestone: ---

A reduced test case is below:
compile with trunk gcc: 

gcc -O2 -fgraphite-identity test.c
./a.out
int main(): Assertion `abcd->a[8] == 29' failed


struct abc {
  int a[81];
} *abcd;

#define FPMATH_SSE 2
int global;

void __attribute__ ((noinline)) foo()
{
   int pos = 0;
   int i;

   if (!((global & FPMATH_SSE) != 0)) 
for (i = 8; i <= 15; i++)
  abcd->a[pos++] = i;

   for (i = 29; i <= 36; i++)
abcd->a[pos++] = i;
}

#include 
#include 
#include 

int main()
{
  int i;
  abcd = (struct abc*) malloc (sizeof (abc));
  for (i = 0; i <= 80; i++)
abcd->a[i] = 0;

  foo();

  assert (abcd->a[8] == 29);

  return 0;
}

[Bug c++/67699] Segfault compiling a constexpr array with -fmerge-all-constants -flto

[gcc at norgg dot org]

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

--- Comment #1 from Norgg  ---
Created attachment 36381
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36381=edit
Reduced testcase with const instead of constexpr

Futher testing by slowriot found that you can change the constexpr to const and
drop the --std switch.

[Bug c++/67699] Segfault compiling a const array with -flto

[gcc at norgg dot org]

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

--- Comment #3 from Norgg  ---
Created attachment 36382
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36382=edit
Preprocessed file

[Bug c/67701] New: Unnecessary/bad instructions for u32-casted access to external symbol (assumes misaligned, superfluous load)

[jwerner at chromium dot org]

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

Bug ID: 67701
   Summary: Unnecessary/bad instructions for u32-casted access to
external symbol (assumes misaligned, superfluous load)
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwerner at chromium dot org
  Target Milestone: ---

Consider the following sample program:

static inline void write32(void *addr, unsigned int value) {
*(volatile unsigned int *)addr = value;
}

extern unsigned char testvalue[];
void main() {
write32(, 4);
}

GCC 5.2 (with -O2 -fno-stack-protector -ffreestanding -fomit-frame-pointer)
generates:

main:
mov r1, #4
mov r2, #0
ldr r3, .L2
ldrbr0, [r3]@ zero_extendqisi2
strbr1, [r3]
ldrbr1, [r3, #1]@ zero_extendqisi2
strbr2, [r3, #1]
ldrbr1, [r3, #2]@ zero_extendqisi2
strbr2, [r3, #2]
ldrbr1, [r3, #3]@ zero_extendqisi2
strbr2, [r3, #3]
bx  lr

Whereas GCC 4.9 (same arguments) generates:

main:
movwr3, #:lower16:testvalue
movsr2, #4
movtr3, #:upper16:testvalue
ldr r1, [r3]
str r2, [r3]
bx  lr

I think there are two problems with this:

1. Both GCC 5.2 and 4.9 generate superfluous load instructions to |addr|, even
though the pointer is never dereferenced as an rvalue (only as the left-hand
side of an assignment). This is a) unnecessary and b) dangerous since the
pointer is declared volatile (meaning it could be an MMIO register with read
side-effects).

2. GCC 5.2 seems to somehow assume it must treat the object as unaligned and
generates byte-wise accesses. I don't understand why it would do that, since
nothing here is declared __attribute__((packed)) and the explicit cast to a
4-byte-aligned type should remove any ambiguity for the compiler about which
alignment it can assume. It is important for systems code to have a (portable)
way to dereference an address with an explicit alignment regardless of where it
came from (e.g. for MMIO registers that only support 32-bit wide accesses).

Both of these issues can be solved by using __builtin_assume_aligned(addr,
sizeof(unsigned long)), but I still think the compiler shouldn't have done this
in the first place (and having a portable solution to this problem is
preferable).

Context: http://review.coreboot.org/#/c/11698

[Bug c++/67702] New: Internal compiler error: Segmentation fault

[david.ok8 at gmail dot com]

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

Bug ID: 67702
   Summary: Internal compiler error: Segmentation fault
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.ok8 at gmail dot com
  Target Milestone: ---

Created attachment 36383
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36383=edit
Compilation failing with C++ template code.

Hello gcc team,

g++-4.9.2 fails to compile the attached source code. g++-5.1 also fails to
compile it as well.

Compilation command was: "g++ -std=c++11 test_gcc_4_9_2.cpp"

I don't have this problem with clang and MSVC compilers. I haven't found a
workaround so far for this error, could you please advise?


Below is the following compilation log:

test_gcc_4_9_2.cpp: In instantiation of ‘typename Filter::return_type
Image::compute(const typename Filter::parameter_type&) [with Filter =
Blur; T = double; typename Filter::return_type = Image; typename
Filter::parameter_type = double]’:
test_gcc_4_9_2.cpp:45:47:   required from here
test_gcc_4_9_2.cpp:11:35: internal compiler error: Segmentation fault
   typename Filter::return_type compute(const typename
Filter::parameter_type& param)
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccpCK2W4.out file, please attach this to
your bugreport.


Best,
David.

[Bug c++/67702] Internal compiler error: Segmentation fault

[david.ok8 at gmail dot com]

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

--- Comment #1 from david.ok8 at gmail dot com ---
I would like to add that I did not have this problem with gcc version 4.8.4 and
4.9.1 which are shipped in ubuntu 14.04 and 14.10.

[Bug target/67701] Unnecessary/bad instructions for u32-casted access to external symbol (assumes misaligned, superfluous load)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |target

--- Comment #2 from Andrew Pinski  ---
(In reply to Julius Werner from comment #1)
> edit: target architecture in my example is armv7a, btw (although I doubt
> that this is architecture-specific)

I suspect this is an armv7 issue only where there is missing support for
misaligned load/stores.

Also testvalue is aligned to 1 byte by default so what GCC is doing is correct
as there is no way to do a volatile unaligned loads really.

[Bug other/67698] internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2297

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-24
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
It is triggered by -freorder-blocks-and-partition.

[Bug target/67391] [SH] Convert clrt addc to normal add insn

[kkojima at gcc dot gnu.org]

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

--- Comment #11 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #10)
> The core issue should be fixed.  I'd like to keep this PR open though for a
> while.

I've got

/exp/ldroot/dodes/INTEST/trunk/gcc/testsuite/gfortran.dg/matmul_6.f90:19:0:
Error: could not split insn
(insn 2778 2779 94 (set (reg:SI 3 r3)
(plus:SI (reg:SI 3 r3 [316])
(const_int 372 [0x174])))
/exp/ldroot/dodes/INTEST/trunk/gcc/testsuite/gfortran.dg/matmul_6.f90:20 64
{*addsi3_compact}
 (nil))

in my local tree.  Clearly it was hidden by the wrong extra checks.

[Bug c/67661] Wrong warning when declare VLAs: operation on 'x' may be undefined [-Wsequence-point]

[leechung at 126 dot com]

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

--- Comment #2 from leechung  ---
(In reply to jos...@codesourcery.com from comment #1)
> You'll need to give a full testcase (complete compilable file and options 
> used to compile it).  What you gave isn't a compilable testcase; it gives 
> "error: variably modified 'y' at file scope".  Put inside a function, it 
> gives "warning: unused variable 'y' [-Wunused-variable]", but does not 
> give the warning you mention.  And there's no variable 'b' in your example 
> at all.

Sorry, I am less experience.
The following is the complete code:

#include 

int main (void)
{
int x = 0, y [++ x], z [++ x];
printf ("%d, %d, %d\n", sizeof x, sizeof y, sizeof z);
return 0;
}

and are compiled with option '-Wall'.for example:
gcc xx.c -Wall

then produce a warning 'operation on 'x' may be undefined [-Wsequence-point]'

[Bug target/67391] [SH] Convert clrt addc to normal add insn

[olegendo at gcc dot gnu.org]

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

--- Comment #12 from Oleg Endo  ---
I already thought that something like this might happen.  I will have a look.

[Bug target/67701] Unnecessary/bad instructions for u32-casted access to external symbol (assumes misaligned, superfluous load)

[jwerner at chromium dot org]

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

--- Comment #3 from Julius Werner  ---
> I suspect this is an armv7 issue only where there is missing support for 
> misaligned load/stores.

Did a quick test on aarch64 and you're right, neither of the two issues appears
there.

> Also testvalue is aligned to 1 byte by default so what GCC is doing is 
> correct as there is no way to do a volatile unaligned loads really.

I thought alignment was always tied to a type (at least by default, unless
overridden by __attribute__((align)) or the like)? It's true that the expected
alignment for testvalue is 1, but I'm not dereferencing testvalue... I'm
dereferencing *(volatile unsigned long *) Shouldn't the alignment of
that always be 4? (FWIW, _Alignof(*(volatile unsigned long *))
evaluates to 4 in both compiler versions.)

Another argument: if write32() was defined as a non-inline function in a
separate execution unit, this problem would not appear. Should inlining a
function really change behavior in this way and produce code that is clearly
less efficient (to try to work around a "problem" that the -O0 version of the
same code would have never found)?

[Bug c++/67703] New: assert after placement new

[piotrekpad at gmail dot com]

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

Bug ID: 67703
   Summary: assert after placement new
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: piotrekpad at gmail dot com
  Target Milestone: ---

Hi,
This code is is c++11 valid:

#include 
#include 
struct A {
  virtual void foo();
};

struct B  : A{ 
  void foo();
};
void f() {
  A *a = new A;
  a->foo();
  A* b = new() B;
  assert(a == b);
  b->foo();
  new(b) A;
  a->foo();
}

but when I compile it with g++ 5.1 or 5.2 it fails on assert (checked on
https://gcc.godbolt.org/)

[Bug c++/67703] assert after placement new

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
>  A* b = new() B;


I think that is wrong.  it should have been "new(a) B;"  Otherwise you are
allocating the new object with the space for the variable a instead of what a
points to.