[Bug other/67630] ymm and zmm register aren't preserved in interrupt handler

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to H.J. Lu from comment #2)
> Created attachment 36349 [details]
> A patch

@@ -867,10 +867,12 @@
case MODE_V16SF:
case MODE_V8SF:
case MODE_V4SF:
- if (TARGET_AVX
- && (misaligned_operand (operands[0], mode)
- || misaligned_operand (operands[1], mode)))
-   return "vmovups\t{%1, %0|%0, %1}";
+ /* We must handle SSE since ix86_emit_save_reg_using_mov
+generates the normal *mov_internal pattern for
+interrupt handler.  */
+ if (misaligned_operand (operands[0], mode)
+ || misaligned_operand (operands[1], mode))
+   return "%vmovups\t{%1, %0|%0, %1}";
  else
return "%vmovaps\t{%1, %0|%0, %1}";

You should use

  if ((TARGET_AVX || cfun->machine->is_interrupt)
  && (misaligned_operand (operands[0], mode)
  || misaligned_operand (operands[1], mode)))
return "%vmovups\t{%1, %0|%0, %1}";

Your patch gives legacy SSE targets ability to load/store unaligned operands
outside interrupt handler for no reason. Legacy SSE is different to AVX, the
latter also allows unaligned 16byte operands in arithmetic/logic VEX-prefixed
insns. This is the reason we have to relax alignment requirements on V4SFmode
load/stores for AVX targets.

[Bug tree-optimization/47679] [4.9/5/6 Regression] Strange uninitialized warning after SRA

[law at redhat dot com]

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

--- Comment #30 from Jeffrey A. Law  ---
AFACT the testcase in c#16 is bogus.  If i is never equal to k, then opt is
never assigned any value.  It's then used in the conditional outside the loop. 
That's how it looks at the source level and that's also what it looks like in
the dom2 dump.

[Bug target/52394] SH Target: SH2A defunct bitops

[olegendo at gcc dot gnu.org]

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

--- Comment #3 from Oleg Endo  ---
(In reply to Oleg Endo from comment #2)
> 
> The code should actually be something like this:
> mov.l   .L2,r2
> bld #0,r5
> mov #0,r0
> bor.b   #5,@(0,r2)
> bst.b   #5,@(0,r2)

Actually this might also result in unexpected side-effects when accessing
external hardware, because the volatile mem is accessed with 2x load and 1x
store.  So actually, this sequence can't be really used safely.

Moreover, it seems the code size improvements for those SH2A bitops are not so
big.  The above code is 14 bytes.  The same on non-SH2A could be:

shlrr5
subcr0,r0
not r0,r0
and #32,r0
mov.l   .L5,r2
mov.b   @r2,r1
or  r0,r1
mov.b   r1,@r2

which is 16 bytes.

And the SH2A version of that could be:
bld #0,r5
mov #0,r0
bst #5,r0
mov.l   .L5,r2
mov.b   @r2,r1
or  r0,r1
mov.b   r1,@r2

which is 14 bytes.

And of course, if GBR can be clobbered it gets down to 8 bytes:
mov.l   .L5,r2
ldc r2,gbr
mov #0,r0
or.b#32,@(r0,gbr)

[Bug target/67646] New: [SH] Improve sign extract of bit test

[olegendo at gcc dot gnu.org]

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

Bug ID: 67646
   Summary: [SH] Improve sign extract of bit test
   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*-*-*

The following:

unsigned int test (unsigned int x)
{
  return (x & 0x30) ? ~0 : 0;
}

compiled with -m4 -ml -O2 results in:

mov r4,r0
tst #48,r0
subcr0,r0
rts
not r0,r0

This is already minimal, but in some cases addc can be used:

mov r4,r0
tst #48,r0
mov #0,r1
mov #-1,r0
addcr1,r0 r0 = 0 + (-1) + T
  T = 0: r0 = 0 + (-1) + 0 = -1
  T = 1: r0 = 0 + (-1) + 1 = 0

If the constant 0 can be shared with some other insn, this would result in a
mov #imm8, addc sequence, which is good for SH4A, because mov #imm8 is an MT
group insn.


If the test constant is only one bit:

unsigned int test (unsigned int x)
{
  return (x & 0x20) ? ~0 : 0;
}

-m4 -ml -O2:
mov r4,r0
tst #32,r0
mov #-1,r0
negcr0,r0
rts 
neg r0,r0

This should result in the same code as for the constant 0x30.

[Bug tree-optimization/47679] [4.9/5 Regression] Strange uninitialized warning after SRA

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[4.9/5/6 Regression]|[4.9/5 Regression] Strange
   |Strange uninitialized   |uninitialized warning after
   |warning after SRA   |SRA

--- Comment #32 from Jeffrey A. Law  ---
Fixed on the trunk.  Not planning to backport the patch series to any of the
release branches.

[Bug tree-optimization/47679] [4.9/5/6 Regression] Strange uninitialized warning after SRA

[law at gcc dot gnu.org]

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

--- Comment #31 from Jeffrey A. Law  ---
Author: law
Date: Sun Sep 20 06:37:39 2015
New Revision: 227942

URL: https://gcc.gnu.org/viewcvs?rev=227942=gcc=rev
Log:
[PATCH] Fix 47679 by improving jump threading

PR tree-optimization/47679
* tree-ssa-dom.c (record_temporary_equivalences): No longer static.
* tree-ssa-dom.h (record_temporary_equivalences): Add prototype.
* tree-ssa-threadedge.c: Include tree-ssa-dom.h.
(thread_through_normal_block): Use record_temporary_equivalences.

PR tree-optimization/47679
* g++.dg/warn/Wuninitialized-6.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wuninitialized-6.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-dom.c
trunk/gcc/tree-ssa-dom.h
trunk/gcc/tree-ssa-threadedge.c

[Bug target/67061] sh64-elf: internal compiler error: in sh_find_set_of_reg, at config/sh/sh-protos.h:235

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #9 from Oleg Endo  ---
Fixed on trunk and GCC 5 branch.

[Bug target/67061] sh64-elf: internal compiler error: in sh_find_set_of_reg, at config/sh/sh-protos.h:235

[olegendo at gcc dot gnu.org]

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

--- Comment #8 from Oleg Endo  ---
Author: olegendo
Date: Sun Sep 20 10:18:45 2015
New Revision: 227943

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

PR target/67061
* config/sh/sh-protos.h (sh_find_set_of_reg): Simplfiy for-loop.
Handle call insns.

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

[Bug c++/67654] New: [concepts] ICE when using concepts in constexpr function

[ryan.burn at gmail dot com]

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

Bug ID: 67654
   Summary: [concepts] ICE when using concepts in constexpr
function
   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: ---

Created attachment 36353
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36353=edit
reproduces problem

My version of gcc:
g++ (GCC) 6.0.0 20150915 (experimental)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

The attached code causes this internal compiler error:

main.cpp: In instantiation of ‘struct A’:
main.cpp:24:18:   required from here
main.cpp:20:33: error: no matching function for call to ‘and_c()’
   A() requires and_c() = default;
 ^
main.cpp:10:42: note: candidate: template constexpr bool
and_c()
 template  constexpr bool and_c() {
  ^
main.cpp:10:42: note:   template argument deduction/substitution failed:
main.cpp:20:33: internal compiler error: unexpected expression ‘C’ of kind
template_id_expr
   A() requires and_c() = default;
 ^
0x816bc0 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:3685
0x812e25 cxx_eval_call_expression
../../gcc/gcc/cp/constexpr.c:1186
0x81575f cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:3205
0x81a53b cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/constexpr.c:3739
0x6846c6 convert_nontype_argument
../../gcc/gcc/cp/pt.c:6314
0x6846c6 convert_template_argument
../../gcc/gcc/cp/pt.c:7190
0x65a514 coerce_template_parameter_pack
../../gcc/gcc/cp/pt.c:7336
0x65a514 coerce_template_parms
../../gcc/gcc/cp/pt.c:7559
0x691bb3 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../gcc/gcc/cp/pt.c:16871
0x5fa73b print_z_candidate
../../gcc/gcc/cp/call.c:3424
0x5fc33e print_z_candidates
../../gcc/gcc/cp/call.c:3494
0x605c17 build_new_function_call(tree_node*, vec**, bool, int)
../../gcc/gcc/cp/call.c:4104
0x78ff5e finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2391
0x68131f tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:15872
0x66aad1 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15044
0x822ed6 tsubst_predicate_constraint(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/constraint.cc:1416
0x824fbf tsubst_constraint_info(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/constraint.cc:1638
0x6739d0 tsubst_decl
../../gcc/gcc/cp/pt.c:11501
0x6624c6 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:12426
0x697a26 instantiate_class_template_1
../../gcc/gcc/cp/pt.c:9919
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/67656] New: [concepts] matched variadics in expression constraint report as unmatched

[ryan.burn at gmail dot com]

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

Bug ID: 67656
   Summary: [concepts] matched variadics in expression constraint
report as unmatched
   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: ---

In this code

/
template   
void consume(Xs&&...) {}

template   
struct A {  
  template 
requires requires(Ys... ys) {   
  consume(Xs{ys}...);   
}   
  A(Ys&&... ys) {   
  } 
};  

int main() {
  A a(55, 2);
  return 0; 
} 
/

"consume(Xs{ys}...)" is a valid expression so the constructor should be called,
but gcc gives a mismatched pack lengths error.

# Error ##
t2.cpp: In instantiation of ‘struct A’:
t2.cpp:15:17:   required from here
t2.cpp:8:14: error: mismatched argument pack lengths while expanding ‘Xs{ys}’
   consume(Xs{ys}...);
  ^
t2.cpp: In function ‘int main()’:
t2.cpp:15:23: error: no matching function for call to ‘A::A(int,
int)’
   A a(55, 2);
   ^
t2.cpp:10:3: note: candidate: A::A(Ys&& ...) [with Ys = {int, int}; Xs =
{int, long int}]
   A(Ys&&... ys) {
   ^
t2.cpp:10:3: note:   constraints not satisfied
t2.cpp:5:8: note: candidate: constexpr A::A(const A&)
 struct A {
^
t2.cpp:5:8: note:   candidate expects 1 argument, 2 provided
t2.cpp:5:8: note: candidate: constexpr A::A(A&&)
t2.cpp:5:8: note:   candidate expects 1 argument, 2 provided

[Bug other/67648] No need to save callee-saved registers in interrupt handler

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
We should update the "IRET" pattern to indicate which
registers should be preserved.

[Bug driver/48524] spec language does not cover switches with separated form

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #9 from Manuel López-Ibáñez  ---
Is this fixed? Can we close it?

[Bug c++/67655] New: [concepts] expression constraints and variadic expansions

[ryan.burn at gmail dot com]

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

Bug ID: 67655
   Summary: [concepts] expression constraints and variadic
expansions
   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: ---

I expect the following should be valid code:

### BEGIN CODE 
template   
void consume(Xs&&...) {}

template   
struct A {  
  template 
requires requires(Ys... ys) {   
  consume(Xs{ys}...);   
}   
  A(Ys&&... ys) {   
  } 
  A(int) {} 
};  

int main() {
  A a(55); 
  return 0; 
} 
### END CODE 

with the first first of the constructor being disabled and the second matching.
But this gives the compilation error:

t2.cpp: In instantiation of ‘struct A’:
t2.cpp:16:19:   required from here
t2.cpp:8:14: error: mismatched argument pack lengths while expanding ‘Xs{ys}’
   consume(Xs{ys}...);

Looking through N4377, I'm not entirely sure how this should be treated, but
would think it should just mean that the expression constraint
consume(Xs{ys}...) shouldn't be satisfied instead of triggering a hard error.

[Bug middle-end/67619] ICE at -O1 and above on x86_64-linux-gnu in int_mode_for_mode, at stor-layout.c:425

[uros at gcc dot gnu.org]

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

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Sep 20 18:07:58 2015
New Revision: 227952

URL: https://gcc.gnu.org/viewcvs?rev=227952=gcc=rev
Log:
PR middle-end/67619
* lib/target-supports.exp (check_effective_target_builtin_eh_return):
New procedure.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/torture/pr67619.c
trunk/gcc/testsuite/lib/target-supports.exp

[Bug c++/67658] New: [concepts] invalid code with constrained concepts compiles

[ryan.burn at gmail dot com]

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

Bug ID: 67658
   Summary: [concepts] invalid code with constrained concepts
compiles
   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: ---

This code compiles with gcc

g++ (GCC) 6.0.0 20150915 (experimental)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

//
template concept bool C1() { return false; }   
template concept bool C2() { return true; }   

void f(C2 x) {  
}   

struct A {} a;  

int main() {
  f(a); 
}
//

>From page 17 example 6.3 of N4377
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4377.pdf), it looks
like constrained concepts are not allowed. And even if they were, the
constraints on concept C2 should not be satisfied.

[Bug c++/67650] undef reference with -fdevirtualize

[vincent.lextrait at gmail dot com]

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

--- Comment #5 from Vincent  ---
The problem is static time, not dynamic time.
This artefact is just a result of source code reduction. In  my code there is
no "0", and the problem exists.
I can provide an alternative case without this artefact, but I do not believe
it harms investigations at all.

[Bug c++/67650] undef reference with -fdevirtualize

[vincent.lextrait at gmail dot com]

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

--- Comment #6 from Vincent  ---
Replace it with (new T())->ax() if you have doubts. Same thing.

[Bug other/67659] New: ICE: Linux kernel/rcu/tree.c:3261:6

[nwmcsween at gmail dot com]

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

Bug ID: 67659
   Summary: ICE: Linux kernel/rcu/tree.c:3261:6
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nwmcsween at gmail dot com
  Target Milestone: ---

ICE while compiling linux kernel, at kernel/rcu/tree.c:3261:6 using latest git
as of sunday 2015-09-20

[Bug target/67573] [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra

[kkojima at gcc dot gnu.org]

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

--- Comment #11 from Kazumoto Kojima  ---
Author: kkojima
Date: Sun Sep 20 23:54:03 2015
New Revision: 227953

URL: https://gcc.gnu.org/viewcvs?rev=227953=gcc=rev
Log:
PR target/67573
* config/sh/sh.md: Add early clobber to scratch operand of *call_*pcrel
insn_and_split so to avoid CSEd scratch reg.


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

[Bug target/67126] [6 Regression][SH] gcc.target/sh/pr51244-12.c failures

[olegendo at gcc dot gnu.org]

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

--- Comment #4 from Oleg Endo  ---
Author: olegendo
Date: Mon Sep 21 00:17:22 2015
New Revision: 227957

URL: https://gcc.gnu.org/viewcvs?rev=227957=gcc=rev
Log:
gcc/
PR target/67126
* config/sh/sh.md (*reg_lsb_t): Emit bld insn on SH2A.
(*mov_t_msb_neg): Rewrite negc pattern.

gcc/testsuite/
PR target/67126
* gcc.target/sh/pr51244-12.c: Adjust testcase.
* gcc.target/sh/pr54236-2.c: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/sh/pr51244-12.c
trunk/gcc/testsuite/gcc.target/sh/pr54236-2.c

[Bug target/67126] [6 Regression][SH] gcc.target/sh/pr51244-12.c failures

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #5 from Oleg Endo  ---
Fixed.

[Bug target/67506] [5/6 Regression][SH]: error: unrecognizable insn when compiling texlive-binaries

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #12 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #11)
> 
> texlive-bin builds fine with the new gcc-5 snapshot [1], thus this PR can be
> closed as fixed.
>

Thanks for reporting back.

[Bug target/67657] [SH][5]: internal compiler error: in cselib_record_set, at cselib.c:2396 when compiling libjpeg-turbo

[olegendo at gcc dot gnu.org]

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

--- Comment #1 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #0)
> Created attachment 36354 [details]
> Preprocessed source for cselib.c

Thanks for reporting.  I was a bit confused ... the attached source is not
cselib.c (which is a GCC file) but rather the problematic jidctflt.c

I've tried compiling it with sh-elf trunk and GCC 5 compilers with

-O2 -g -fPIE -fstack-protector-strong -m4 -ml -matomic-model=soft-gusa,strict

and with

-m4 -ml -matomic-model=soft-gusa,strict -g -O2 -fstack-protector-strong
-ffloat-store -fPIC -frandom-seed=0 -fdump-noaddr

but can't reproduce it.

[Bug tree-optimization/59478] Optimize variable access via byte copy

[olegendo at gcc dot gnu.org]

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

--- Comment #2 from Oleg Endo  ---
Author: olegendo
Date: Mon Sep 21 01:43:50 2015
New Revision: 227958

URL: https://gcc.gnu.org/viewcvs?rev=227958=gcc=rev
Log:
gcc/testsuite/
PR target/59478
* gcc.target/sh/pr59478.c: New.

Added:
trunk/gcc/testsuite/gcc.target/sh/pr59478.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug other/67648] No need to save callee-saved registers in interrupt handler

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

--- Comment #1 from H.J. Lu  ---
Julia, we should avoid changing call_used_regs in
ix86_conditional_register_usage.   Instead, we should
only save and restore caller-saved registers changed by
interrupt handler.

[Bug target/67644] [SH] double load on volatile bitfield mem

[olegendo at gcc dot gnu.org]

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

--- Comment #1 from Oleg Endo  ---
I've just checked with the current GCC 4.9 branch.  It happens there, too.

[Bug rtl-optimization/67644] double load on volatile bitfield mem

[olegendo at gcc dot gnu.org]

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

--- Comment #3 from Oleg Endo  ---
It somehow makes sense ...

  x->ICR0.BIT.BIT5 |= 1;

or maybe better

  x->ICR0.BIT.BIT5 ^= 1;

is a bitfield read and a bitfield write.
A bitfield write implies a bitfield read-modify-write, and thus we get two
reads.

It is sort of documented (at least the docs advice not to use volatile
bitfields for hardware access etc).  But it's still counter intuitive and a
silly trap, because it looks very similar to normal volatile variables.

Anyway, I guess this is an invalid PR...

[Bug other/67648] New: No need to save callee-saved registers in interrupt handler

[hjl.tools at gmail dot com]

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

Bug ID: 67648
   Summary: No need to save callee-saved registers in interrupt
handler
   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: ---

[hjl@gnu-6 interrupt-1]$ cat call-1.i
extern void bar (void);

void
 __attribute__ ((interrupt))
foo (void)
{
  bar ();
}
[hjl@gnu-6 interrupt-1]$ make call-1.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -S -o call-1.s call-1.i
[hjl@gnu-6 interrupt-1]$ cat call-1.s
.file   "call-1.i"
.section.text.unlikely,"ax",@progbits
.LCOLDB0:
.text
.LHOTB0:
.p2align 4,,15
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
pushq   %r15
.cfi_def_cfa_offset 16
.cfi_offset 15, -16
pushq   %r14
.cfi_def_cfa_offset 24
.cfi_offset 14, -24
pushq   %r13
.cfi_def_cfa_offset 32
.cfi_offset 13, -32
pushq   %r12
.cfi_def_cfa_offset 40
.cfi_offset 12, -40
pushq   %r11
.cfi_def_cfa_offset 48
.cfi_offset 11, -48
pushq   %r10
.cfi_def_cfa_offset 56
.cfi_offset 10, -56
pushq   %r9
.cfi_def_cfa_offset 64
.cfi_offset 9, -64
pushq   %r8
.cfi_def_cfa_offset 72
.cfi_offset 8, -72
pushq   %rbp
.cfi_def_cfa_offset 80
.cfi_offset 6, -80
pushq   %rdi
.cfi_def_cfa_offset 88
.cfi_offset 5, -88
pushq   %rsi
.cfi_def_cfa_offset 96
.cfi_offset 4, -96
pushq   %rbx
.cfi_def_cfa_offset 104
.cfi_offset 3, -104
pushq   %rcx
.cfi_def_cfa_offset 112
.cfi_offset 2, -112
pushq   %rdx
.cfi_def_cfa_offset 120
.cfi_offset 1, -120
pushq   %rax
.cfi_def_cfa_offset 128
.cfi_offset 0, -128
subq$256, %rsp
.cfi_def_cfa_offset 384
movups  %xmm0, (%rsp)
movups  %xmm1, 16(%rsp)
movups  %xmm2, 32(%rsp)
movups  %xmm3, 48(%rsp)
movups  %xmm4, 64(%rsp)
movups  %xmm5, 80(%rsp)
movups  %xmm6, 96(%rsp)
movups  %xmm7, 112(%rsp)
movups  %xmm8, 128(%rsp)
movups  %xmm9, 144(%rsp)
movups  %xmm10, 160(%rsp)
movups  %xmm11, 176(%rsp)
movups  %xmm12, 192(%rsp)
movups  %xmm13, 208(%rsp)
movups  %xmm14, 224(%rsp)
movups  %xmm15, 240(%rsp)
.cfi_offset 17, -384
.cfi_offset 18, -368
.cfi_offset 19, -352
.cfi_offset 20, -336
.cfi_offset 21, -320
.cfi_offset 22, -304
.cfi_offset 23, -288
.cfi_offset 24, -272
.cfi_offset 25, -256
.cfi_offset 26, -240
.cfi_offset 27, -224
.cfi_offset 28, -208
.cfi_offset 29, -192
.cfi_offset 30, -176
.cfi_offset 31, -160
.cfi_offset 32, -144
callbar
movups  (%rsp), %xmm0
movups  16(%rsp), %xmm1
movups  32(%rsp), %xmm2
movups  48(%rsp), %xmm3
movups  64(%rsp), %xmm4
movups  80(%rsp), %xmm5
movups  96(%rsp), %xmm6
movups  112(%rsp), %xmm7
movups  128(%rsp), %xmm8
movups  144(%rsp), %xmm9
movups  160(%rsp), %xmm10
movups  176(%rsp), %xmm11
movups  192(%rsp), %xmm12
movups  208(%rsp), %xmm13
movups  224(%rsp), %xmm14
movups  240(%rsp), %xmm15
addq$256, %rsp
.cfi_restore 32
.cfi_restore 31
.cfi_restore 30
.cfi_restore 29
.cfi_restore 28
.cfi_restore 27
.cfi_restore 26
.cfi_restore 25
.cfi_restore 24
.cfi_restore 23
.cfi_restore 22
.cfi_restore 21
.cfi_restore 20
.cfi_restore 19
.cfi_restore 18
.cfi_restore 17
.cfi_def_cfa_offset 128
popq%rax
.cfi_def_cfa_offset 120
popq%rdx
.cfi_def_cfa_offset 112
popq%rcx
.cfi_def_cfa_offset 104
popq%rbx
.cfi_def_cfa_offset 96
popq%rsi
.cfi_def_cfa_offset 88
popq%rdi
.cfi_def_cfa_offset 80
popq%rbp
.cfi_def_cfa_offset 72
popq%r8
.cfi_def_cfa_offset 64
popq%r9
.cfi_def_cfa_offset 56
popq%r10
.cfi_def_cfa_offset 48
popq%r11
.cfi_def_cfa_offset 40
popq%r12
.cfi_def_cfa_offset 32
popq%r13
.cfi_def_cfa_offset 24

[Bug c++/67650] New: undef reference with -fdevirtualize

[vincent.lextrait at gmail dot com]

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

Bug ID: 67650
   Summary: undef reference with -fdevirtualize
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent.lextrait at gmail dot com
  Target Milestone: ---

I get an undefined symbol when using -O2, more specifically, after trying all
additional options on top of -O1, this is due to -fdevirtualize. With -O1
-devirtualize, the symbol is missing. It's not missing with just -O1.
The symbol is a virtual member function of a class template.
I checked that the issue does not occur with gcc-4.9.2, it is new in gcc-5.

Is it worth it to try reducing my code and produce a code snippet exhibiting
the issue? Or is the issue known already? I didn't find any track of it.

gcc version:
/usr/local/bin/g++-5 -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++-5
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/5.2.0/libexec/gcc/x86_64-apple-darwin14.4.0/5.2.0/lto-wrapper
Target: x86_64-apple-darwin14.4.0
Configured with: ../configure --build=x86_64-apple-darwin14.4.0
--prefix=/usr/local/Cellar/gcc/5.2.0
--libdir=/usr/local/Cellar/gcc/5.2.0/lib/gcc/5
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-5
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl
--with-system-zlib --enable-libstdcxx-time=yes --enable-stage1-checking
--enable-checking=release --enable-lto --with-build-config=bootstrap-debug
--disable-werror --with-pkgversion='Homebrew gcc 5.2.0'
--with-bugurl=https://github.com/Homebrew/homebrew/issues --enable-plugin
--disable-nls --enable-multilib
Thread model: posix
gcc version 5.2.0 (Homebrew gcc 5.2.0)

[Bug c/67651] New: Optimizer assumes nothing can reside at address 0 despite -fno-delete-null-pointer-checks

[soren.brinkmann at xilinx dot com]

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

Bug ID: 67651
   Summary: Optimizer assumes nothing can reside at address 0
despite -fno-delete-null-pointer-checks
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: soren.brinkmann at xilinx dot com
  Target Milestone: ---

Created attachment 36351
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36351=edit
Test case source

For the c source:
extern unsigned int _vector_table;

int main(void)
{
unsigned int *vector_base = &_vector_table;

if (vector_base == 0) {
return 1;
} else {
return 2;
}
}


the generated code is, when compiled with '-O2
-fno-delete-null-pointer-checks':
 :
   0:   b8 02 00 00 00  mov$0x2,%eax
   5:   c3  retq


I.e. the if branch is completely removed from the final object.
The behavior is consistent across the gcc versions I could test (4.7, 4.9 for
ARMv7 and 4.9, 5.2 for x86_64)

The behavior has been discussed on the list
(http://thread.gmane.org/gmane.comp.gcc.devel/141346). One workaround/fix
mentioned there is to add the 'weak' attribute to '_vector_table'. But it seems
that '-fno-delete-null-pointer-checks' is supposed to remove the assumption
regarding objects at address 0 and should be sufficient to generate "correct"
code.

For completeness, this is a Makefile to compile the test case:
CC ?= gcc
OBJDUMP = objdump
CFLAGS = -Wall -Wextra -fno-delete-null-pointer-checks -O2
-fno-delete-null-pointer-checks

SRC = main.c

all: $(SRC:.c=.dump) $(SRC:.c=.s) $(SRC:.c=.o)

%.dump: %.o
$(OBJDUMP) -DS $< > $@

%.s: %.c
$(CC) $(CFLAGS) -S $< -o $@

%.o: %.c
$(CC) $(CFLAGS) -c $< -o $@

.PHONY: clean
clean:
rm -rf *.o *.s *.dump

[Bug bootstrap/67647] New: [6 regression] boostrap FAIL with --disable-libstdcxx-dual-abi

[dimhen at gmail dot com]

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

Bug ID: 67647
   Summary: [6 regression] boostrap FAIL with
--disable-libstdcxx-dual-abi
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
  Target Milestone: ---

r227942 FAIL
r227792 PASS

~/src/gcc_current/configure --prefix=/usr/local/gcc_current
--enable-languages=c,c++,lto --enable-plugin --disable-multilib
make PASS

~/src/gcc_current/configure --prefix=/usr/local/gcc_current
--enable-languages=c,c++,lto --enable-plugin --disable-multilib
--disable-libstdcxx-dual-abi
make FAIL

/home/dimhen/build/gcc_current/./prev-gcc/xg++
-B/home/dimhen/build/gcc_current/./prev-gcc/
-B/usr/local/gcc_current/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/home/dimhen/build/gcc_current/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/home/dimhen/build/gcc_current/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/dimhen/build/gcc_current/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
 -I/home/dimhen/build/gcc_current/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
 -I/home/dimhen/src/gcc_current/libstdc++-v3/libsupc++
-L/home/dimhen/build/gcc_current/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/dimhen/build/gcc_current/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-c   -g -O2 -gtoggle -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 -DGENERATOR_FILE -fno-PIE -I. -Ibuild
-I/home/dimhen/src/gcc_current/gcc -I/home/dimhen/src/gcc_current/gcc/build
-I/home/dimhen/src/gcc_current/gcc/../include 
-I/home/dimhen/src/gcc_current/gcc/../libcpp/include  \
-o build/inchash.o /home/dimhen/src/gcc_current/gcc/inchash.c
In file included from
/home/dimhen/build/gcc_current/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/string:52:0,
 from /home/dimhen/src/gcc_current/gcc/system.h:201,
 from /home/dimhen/src/gcc_current/gcc/genconstants.c:28:
/home/dimhen/build/gcc_current/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:3304:7:
error: expected initializer before ‘capacity’
   capacity() const _GLIBCXX_NOEXCEPT
   ^
/home/dimhen/build/gcc_current/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:3325:15:
error: variable or field ‘reserve’ declared void
   reserve(size_type __res_arg = 0);
   ^
/home/dimhen/build/gcc_current/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:3325:15:
error: ‘size_type’ was not declared in this scope
/home/dimhen/build/gcc_current/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:
In function ‘void std::clear()’:

[...]

[Bug bootstrap/67647] [6 regression] boostrap FAIL with --disable-libstdcxx-dual-abi

[dimhen at gmail dot com]

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

--- Comment #1 from Dmitry G. Dyachenko  ---
Fedora 22 / x64

[Bug target/67644] [SH] double load on volatile bitfield mem

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Target|sh*-*-* |sh*-*-* rx*-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-20
 Ever confirmed|0   |1

--- Comment #2 from Oleg Endo  ---
The same happens on GCC 5 rx-elf:

mov.B   [r1], r14
mov.B   [r1], r14
bset#2, r14
mov.B   r14, [r1]
rts

[Bug c/67649] New: 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

Bug ID: 67649
   Summary: trunk build with valgrind fail in get_def_blocks_for
   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: ---

I just tried to build gcc trunk of today (20150920) on x86_64
and got this:

/home/dcb/gcc/working/./gcc/xgcc -B/home/dcb/gcc/working/./gcc/
-B/home/dcb/gcc/results/x86_64-pc-linux-gnu/bin/
-B/home/dcb/gcc/results/x86_64-pc-linux-gnu/lib/ -isystem
/home/dcb/gcc/results/x86_64-pc-linux-gnu/include -isystem
/home/dcb/gcc/results/x86_64-pc-linux-gnu/sys-include-g -O3 -march=native
-O2  -g -O3 -march=native -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -fpic -mlong-double-80 -DUSE_ELF_SYMVER -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector   -fpic -mlong-double-80
-DUSE_ELF_SYMVER -I. -I. -I../.././gcc -I../../../src/trunk/libgcc
-I../../../src/trunk/libgcc/. -I../../../src/trunk/libgcc/../gcc
-I../../../src/trunk/libgcc/../include
-I../../../src/trunk/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
-DHAVE_CC_TLS  -DUSE_TLS -o _ashldi3.o -MT _ashldi3.o -MD -MP -MF _ashldi3.dep
-DL_ashldi3 -c ../../../src/trunk/libgcc/libgcc2.c -fvisibility=hidden
-DHIDE_EXPORTS
==9820== Invalid write of size 8
==9820==at 0x670401: bitmap_initialize_stat (bitmap.h:332)
==9820==by 0x670401: bitmap_obstack_alloc_stat(bitmap_obstack*)
(bitmap.c:286)
==9820==by 0xAEB9B3: get_def_blocks_for (tree-into-ssa.c:489)
==9820==by 0xAEB9B3: set_livein_block (tree-into-ssa.c:543)

[Bug c/67652] New: liboffloadmic/runtime/offload_engine.cpp:176: strange expression in sizeof ?

[dcb314 at hotmail dot com]

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

Bug ID: 67652
   Summary: liboffloadmic/runtime/offload_engine.cpp:176: strange
expression in sizeof ?
   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: ---

[trunk/liboffloadmic/runtime/offload_engine.cpp:176]: (warning) Found
calculation inside sizeof().

Source code is

char * env_var = (char*) malloc(sizeof("COI_DMA_CHANNEL_COUNT=2" +
1));

Maybe better code

char * env_var = (char*) malloc(sizeof("COI_DMA_CHANNEL_COUNT=2") +
1);

[Bug c/67651] Optimizer assumes nothing can reside at address 0 despite -fno-delete-null-pointer-checks

[soren.brinkmann at xilinx dot com]

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

--- Comment #1 from Sören Brinkmann  ---
Created attachment 36352
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36352=edit
Makefile for the test case

[Bug c++/67650] undef reference with -fdevirtualize

[vincent.lextrait at gmail dot com]

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

--- Comment #2 from Vincent  ---
Ok, working on it, thanks.

[Bug c++/67650] undef reference with -fdevirtualize

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
> Is it worth it to try reducing my code and produce a code snippet exhibiting 
> the issue?

Always.

>Or is the issue known already? I didn't find any track of it.

It could also be a bug in your code too.  Devirtualization is known to expose
invalid code too.

[Bug middle-end/67653] New: ICE on valid code on x86_64-linux-gnu: verify_gimple failed

[su at cs dot ucdavis.edu]

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

Bug ID: 67653
   Summary: ICE on valid code on x86_64-linux-gnu: verify_gimple
failed
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk (at
all optimization levels) on x86_64-linux-gnu in both 32-bit and 64-bit modes.

This is a regression from 5.2.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20150920 (experimental) [trunk revision 227943] (GCC) 
$ 
$ gcc-5.2 -c small.c
$
$ gcc-trunk -c small.c
small.c: In function ‘foo’:
small.c:2:1: error: invalid rhs for gimple memory store
 foo ()
 ^
D.1758

a

D.1758 = a;
small.c:2:1: internal compiler error: verify_gimple failed
0xae6b3d verify_gimple_in_seq(gimple*)
../../gcc-trunk/gcc/tree-cfg.c:4766
0x89d765 gimplify_body(tree_node*, bool)
../../gcc-trunk/gcc/gimplify.c:9319
0x89daf6 gimplify_function_tree(tree_node*)
../../gcc-trunk/gcc/gimplify.c:9408
0x72e427 cgraph_node::analyze()
../../gcc-trunk/gcc/cgraphunit.c:636
0x73162b analyze_functions
../../gcc-trunk/gcc/cgraphunit.c:1091
0x732568 symbol_table::finalize_compilation_unit()
../../gcc-trunk/gcc/cgraphunit.c:2540
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


-


void
foo ()
{
  __asm__ (""::"m" ((
{
  static int a;
  a;
})));
}

[Bug target/67660] New: [SH] Automatically insert atomic rewind code into ISR prologue

[olegendo at gcc dot gnu.org]

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

Bug ID: 67660
   Summary: [SH] Automatically insert atomic rewind code into ISR
prologue
   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*-*-*

This has been originally mentioned here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50457#c16

however it's not really SH2A specific, but rather specific to gUSA-like atomic
sequences which need rewinding.

The basic idea is to make the compiler automatically emit the proper atomic
rewind code into the ISR prologue, if it is actually needed.  For example, if
the ISR doesn't touch anything atomic and contains no function calls, it can be
omitted, in a similar way as it's done for FP regs save/store.

This can be useful for bare-metal systems when atomics are used to access
shared state from normal code and ISRs.  Probably the easiest way to do that is
via an additional function attribute, like "rewind_atomics".

[Bug target/67657] [SH][5]: internal compiler error: in cselib_record_set, at cselib.c:2396 when compiling libjpeg-turbo

[olegendo at gcc dot gnu.org]

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

--- Comment #3 from Oleg Endo  ---
(In reply to Kazumoto Kojima from comment #2)
> Created attachment 36356 [details]
> reduced test case
> 
> I can reproduce it with trunk rev. 227929 but can't with 227887.
> Clearly very fragile.
> ...
> into the insn 2292.  Oleg, could you take a look?

Hm .. the peephole looks OK, but maybe emit_move_insn doesn't handle post-inc
properly and thus expands into the parallel.  I'll have a look.

[Bug target/67657] [SH][5]: internal compiler error: in cselib_record_set, at cselib.c:2396 when compiling libjpeg-turbo

[olegendo at gcc dot gnu.org]

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

--- Comment #7 from Oleg Endo  ---
Created attachment 36357
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36357=edit
Proposed patch

Although a "mov @r2+,r2" is actually possible and valid (r2 will contain the
value loaded from memory, AFAIR), it doesn't make sense to keep the post-inc,
as the result will be overwritten anyway.  The patch catches those cases in the
peepholes and removes the post-inc.  I'm now testing this on sh-elf.

[Bug target/50457] SH2A atomic functions

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #17 from Oleg Endo  ---
(In reply to Oleg Endo from comment #16)
> Another thing that might be useful for dealing with atomics on SH1* and SH2*
> targets is to make the compiler generate the rewind sequences in interrupt
> handler functions.

This is not specific to SH2A atomics.  I've opened a new PR 67660 for this.

[Bug target/67657] [SH][5]: internal compiler error: in cselib_record_set, at cselib.c:2396 when compiling libjpeg-turbo

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #4 from Oleg Endo  ---
I can reproduce it with r227929 and "-x c -std=gnu99".  Funnily, it doesn't
happen with "-x c -std=c11" (which I usually use).

[Bug rtl-optimization/67644] double load on volatile bitfield mem

[olegendo at gcc dot gnu.org]

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

--- Comment #4 from Oleg Endo  ---
Hm, maybe it'd be good to add a warning (enabled by default, can be disabled)
if volatile bitfields are used.  To me it looks like volatile bitfields have
almost no use (the way they are implemented by GCC now) and probably everybody
is just trying to avoid them anyway.

[Bug target/67657] [SH][5]: internal compiler error: in cselib_record_set, at cselib.c:2396 when compiling libjpeg-turbo

[olegendo at gcc dot gnu.org]

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

--- Comment #5 from Oleg Endo  ---
(In reply to Oleg Endo from comment #4)

Just for reference, those are the exact options:

-x c -std=gnu99 -m4 -ml -g -O2 -ffloat-store -fPIC

[Bug target/67657] [SH][5]: internal compiler error: in cselib_record_set, at cselib.c:2396 when compiling libjpeg-turbo

[kkojima at gcc dot gnu.org]

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

--- Comment #2 from Kazumoto Kojima  ---
Created attachment 36356
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36356=edit
reduced test case

I can reproduce it with trunk rev. 227929 but can't with 227887.
Clearly very fragile.
It looks that the insn

(insn:TI 2292 1994 1995 11 (parallel [
(set (reg/v/f:SI 2 r2 [orig:320 outptr ] [320])
(mem/f:SI (reg:SI 2 r2) [2 MEM[base: _145, offset: 0B]+0 S4
A32]))
(set (reg:SI 2 r2)
(plus:SI (reg:SI 2 r2)
(const_int 4 [0x4])))
]) foo.c:61 253 {movsi_ie}
 (expr_list:REG_UNUSED (reg:SI 2 r2)
(expr_list:REG_INC (reg:SI 2 r2)
(nil

makes cselib unhappy.  It looks wrong anyway.

It seems that

;;  mov.l   @(r0,r9),r1
;;  mov r1,r0   ->  mov @(r0,r9),r0
(define_peephole2
  [(set (match_operand:SI 0 "arith_reg_dest")
(match_operand:SI 1 "general_movsrc_operand"))
   (set (match_operand:SI 2 "arith_reg_dest")
(match_dup 0))]
  "TARGET_SH1 && peep2_reg_dead_p (2, operands[0])"
  [(const_int 0)]
{
  sh_check_add_incdec_notes (emit_move_insn (operands[2], operands[1]));
})

took 2 insns

(insn 595 1951 1954 20 (set (reg:SI 0 r0)
(mem/f:SI (post_inc:SI (reg:SI 2 r2)) [2 MEM[base: _145, offset: 0B]+0
S4 A32])) foo.c:61 253 {movsi_ie}
 (expr_list:REG_UNUSED (reg:SI 2 r2)
(expr_list:REG_INC (reg:SI 2 r2)
(nil

(insn 1954 595 1994 20 (set (reg/v/f:SI 2 r2 [orig:320 outptr ] [320])
(reg:SI 0 r0)) foo.c:61 253 {movsi_ie}
 (expr_list:REG_DEAD (reg:SI 0 r0)
(nil)))

into the insn 2292.  Oleg, could you take a look?

[Bug target/67657] [SH][5]: internal compiler error: in cselib_record_set, at cselib.c:2396 when compiling libjpeg-turbo

[olegendo at gcc dot gnu.org]

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

--- Comment #6 from Oleg Endo  ---
The peephole outputs this:

(insn 2292 0 0 (set (reg/v/f:SI 2 r2 [orig:320 outptr ] [320])
(mem/f:SI (post_inc:SI (reg:SI 2 r2)) [2 MEM[base: _145, offset: 0B]+0
S4 A32])) -1
 (expr_list:REG_INC (reg:SI 2 r2)
(nil)))


i.e.
  mov.l   @r2+,r2

and then things seem to go wrong.  Disabling the peephole shows the following
code in the output:

.L119:
add #64,r0
mov.l   @(0,r0),r2
add #4,r2
mov.l   r2,@(0,r0)
add #-4,r2 <<<
mov.l   @r2+,r0<<<
mov r0,r2  <<<
mov.w   .L81,r0
add r15,r0
mov.l   @(16,r0),r0
add r0,r2

The peephole should convert it to
add #-4,r2
mov.l   @r2,r2

I'll come up with something.

Lymboo Math - personalized and adaptive online math program

[Melissa White]

Dear Educator,

My name is Melissa White, Lymboo Math Curriculum Specialist. 

The new school year is here and we are excited to introduce a special offer for 
your classroom. Lymboo has launched innovative new additions to our already 
popular on-line math program. We invite you to enroll all of your students 
during our "Back to School" promotion. Lymboo Math is free to sign-up. 

Lymboo is one of the leading providers of math enrichment resources in the 
country. Our flagship product, Lymboo Math, is currently being used by over 
25,000 teachers and their students both at school and at home. The program’s 
emphasis on personalization and differentiation, combined with structure and 
rigor, builds a strong foundation in math. 

I am confident that, after experiencing Lymboo Math, you will wonder how you 
ever managed your classroom without it. The personalized, adaptive and rigorous 
program will meet your students at their individual level. Differentiated 
learning in a classroom has never been easier! 

The premise is simple. Sign-up for free. Try it, if you like it, buy it. If you 
are not convinced, continue to use the basic version for free for the rest of 
the school year. It could not be simpler. Your students can access Lymboo Math 
from any internet accessible computer or tablet and from a variety of locations 
(home, school, library, etc.). Please visit 
http://www.lymboo.com/requestclassroom to activate your classroom account. All 
of your students will receive their individual login and password for Lymboo 
Math. They can access Lymboo Math from anywhere (home, school, library, etc.) 
and from any computer or tablet with Internet access. 

For a full list of program features, including product comparisons, please 
visit www.lymboo.com. 

Additional details on research behind Lymboo Math are available at 
www.lymboo.com/research 

I look forward to working with you during the set-up, training and support of 
our "Back to School" pilot program. Lymboo's main focus will be to ensure that 
your students receive the maximum benefits from this superb resource. 

Join us in our mission to improve the math proficiency of our future 
generation, one student at a time! 

Sincerely,
Melissa White
Curriculum Specialist
855 LYMBOO1 (596-2661)
mwh...@lymboo.com
www.lymboo.com

 This email is intended for gcc-bugs@gcc.gnu.org .

Note: If you do not wish to receive emails in future, please visit 
http://www.lymboo.com/emailpref?e=gcc-bugs@gcc.gnu.org=teach2015=lymboomail6.com
 .

Lymboo LLC.
13492 Research Blvd, Suite 120, #208
Austin, TX 78750-2254

[Bug c++/67650] undef reference with -fdevirtualize

[vincent.lextrait at gmail dot com]

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

--- Comment #3 from Vincent  ---
Created attachment 36355
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36355=edit
Test case

Compile using gcc 5.2.0:
g++-5 -O1 -std=c++11 main.ii -fdevirtualize

The function missing at link edition is:

AN::LLC, BLKC>::rp()

Without -fdevirtualize, the function is there.

[Bug c++/67650] undef reference with -fdevirtualize

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
> ((T*)0)->ax();

This is undefined behavior.

[Bug other/67648] No need to save callee-saved registers in interrupt handler

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
I checked a fix into hjl/interrupt/master branch:

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=b21f445ed3e067ac1b401798b953a1ec5b093202

Please take a look.

[Bug driver/48524] spec language does not cover switches with separated form

[rhill at gentoo dot org]

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

Ryan Hill  changed:

   What|Removed |Added

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

--- Comment #10 from Ryan Hill  ---
As far as we're concerned it is.

[Bug target/67657] New: [SH][5]: internal compiler error: in cselib_record_set, at cselib.c:2396 when compiling libjpeg-turbo

[glaubitz at physik dot fu-berlin.de]

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

Bug ID: 67657
   Summary: [SH][5]: internal compiler error: in
cselib_record_set, at cselib.c:2396 when compiling
libjpeg-turbo
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: kkojima at gcc dot gnu.org, olegendo at gcc dot gnu.org
  Target Milestone: ---
Target: sh*-*-*

Created attachment 36354
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36354=edit
Preprocessed source for cselib.c

Hi!

Just ran into another ICE which occurs when compiling libjpeg-turbo on SH:

jidctflt.c: In function 'jpeg_idct_float':
jidctflt.c:237:1: internal compiler error: in cselib_record_set, at
cselib.c:2396
 }
 ^
0x5fffc1 cselib_record_set
../../src/gcc/cselib.c:2396
0x5fffc1 cselib_record_sets
../../src/gcc/cselib.c:2613
0x600553 cselib_process_insn(rtx_insn*)
../../src/gcc/cselib.c:2686
0xa2da0b vt_initialize
../../src/gcc/var-tracking.c:10132
0xa31bd9 variable_tracking_main_1
../../src/gcc/var-tracking.c:10331
0xa31bd9 variable_tracking_main()
../../src/gcc/var-tracking.c:10384
0xa31bd9 execute
../../src/gcc/var-tracking.c:10421
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /tmp/ccHHXJkq.out file, please attach this to
your bugreport.

This definitely looks like a regression as the same upstream version 1.4.1 of
libjpeg-turbo previously built fine with gcc-4.9 [1].

Attaching the pre-processed C sources with this bug report. The full build log
can be found in [2].

Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=libjpeg-turbo=sh4=1%3A1.4.1-1=1438090332
> [2] 
> https://buildd.debian.org/status/fetch.php?pkg=libjpeg-turbo=sh4=1%3A1.4.1-2=1442742941

[Bug target/67506] [5/6 Regression][SH]: error: unrecognizable insn when compiling texlive-binaries

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #11 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #10)
> I guess it will take a while until you've got a new GCC build.  I think we
> can close this as fixed?

texlive-bin builds fine with the new gcc-5 snapshot [1], thus this PR can be
closed as fixed.

Cheers,

Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=texlive-bin=sh4=2015.20150524.37493-6=1442627466