[Bug rtl-optimization/67325] Optimize shift (aka subreg) of load to simple load

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #3 from Markus Trippelsdorf  ---
Apparently never worked with gcc. Clang gets it right.
https://goo.gl/BB4KMZ

[Bug target/67325] Optimize shift (aka subreg) of load to simple load

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|rtl-optimization|target

--- Comment #4 from Andrew Pinski  ---
This is a target issue:
Trying 6 -> 7:
Failed to match this instruction:
(parallel [
(set (reg:DI 65)
(sign_extend:DI (mem:SI (plus:DI (reg/v/f:DI 63 [ l ])
(const_int 4 [0x4])) [2 *l_1(D)+4 S4 A32])))
(clobber (reg:CC 17 flags))
])
Successfully matched this instruction:
(set (reg:DI 65)
(sign_extend:DI (mem:SI (plus:DI (reg/v/f:DI 63 [ l ])
(const_int 4 [0x4])) [2 *l_1(D)+4 S4 A32])))
rejecting combination of insns 6 and 7
original costs 4 + 4 = 8
replacement cost 12
starting the processing of deferred insns
ending the processing of deferred insns

So GCC is able to do it but rejects it because the cost is worse for some
reason.

That is it is replacing:
(insn 6 3 7 2 (set (reg:DI 66 [ *l_1(D) ])
(mem:DI (reg/v/f:DI 63 [ l ]) [2 *l_1(D)+0 S8 A64])) t1.c:2 62
{*movdi_internal_rex64}
 (expr_list:REG_DEAD (reg/v/f:DI 63 [ l ])
(nil)))

(insn 7 6 13 2 (parallel [
(set (reg:DI 65)
(ashiftrt:DI (reg:DI 66 [ *l_1(D) ])
(const_int 32 [0x20])))
(clobber (reg:CC 17 flags))
]) t1.c:2 530 {*ashrdi3_1}
 (expr_list:REG_DEAD (reg:DI 66 [ *l_1(D) ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil

With the above.  Note the clobber gets in the way of combining with the next
insn of the subreg.

[Bug target/67310] [PATCH] gcc 4.8.4 fails to compile with -march=native on VIA nano CPU

[jol_indien at yahoo dot fr]

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

--- Comment #3 from jol_indien at yahoo dot fr ---
Here are two new patches, one for gcc 4.8.x versions (tested with 4.8.4 &
4.8.5), one for 4.9+ versions (tested with 4.9.3).
This patch is safer, support of VIA Nano based on CPU vendor name instead of
"has_longmode" in the previous one.
The 4.9+ patch also applies for gcc 5.x; unfortunately, for any reason, I
cannot get the "host_detect_local_cpu" function being called with gcc 5.2 as if
-march=native, -mcpu=native and -mtune=native options were ignored by the
compiler.

[Bug target/67310] [PATCH] gcc 4.8.4 fails to compile with -march=native on VIA nano CPU

[jol_indien at yahoo dot fr]

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

jol_indien at yahoo dot fr changed:

   What|Removed |Added

  Attachment #36239|0   |1
is obsolete||

--- Comment #4 from jol_indien at yahoo dot fr ---
Created attachment 36244
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36244&action=edit
patch to properly detect VIA nano CPU for gcc 4.8.x versions

[Bug target/67310] [PATCH] gcc 4.8.4 fails to compile with -march=native on VIA nano CPU

[jol_indien at yahoo dot fr]

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

--- Comment #5 from jol_indien at yahoo dot fr ---
Created attachment 36245
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36245&action=edit
patch to properly detect VIA nano CPU for gcc 4.9+ versions

[Bug target/67325] Optimize shift (aka subreg) of load to simple load

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse  ---
(In reply to Andrew Pinski from comment #4)
> So GCC is able to do it but rejects it because the cost is worse for some
> reason.

Indeed, and -Os produces the expected
movl4(%rdi), %eax

(I did not benchmark)

[Bug tree-optimization/67326] New: [5.2/6.0 regression] -ftree-loop-if-convert-stores does not vectorize conditional assignment (anymore)

[vincenzo.innocente at cern dot ch]

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

Bug ID: 67326
   Summary: [5.2/6.0 regression] -ftree-loop-if-convert-stores
does not vectorize conditional assignment (anymore)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincenzo.innocente at cern dot ch
  Target Milestone: ---

in 5.1 looks ok (according to http://gcc.godbolt.org)

cat condBug.cc 
float v0[1024];
float v1[1024];
float v2[1024];
float v3[1024];

void condAssign1() {
  for(int i=0; i<1024; ++i)
v0[i] = (v2[i]>v1[i]) ? v2[i]*v3[i] : v0[i];
}


void condAssign2() {
  for(int i=0; i<1024; ++i)
v0[i] = (v2[i]>v1[i]) ? v2[i]*v1[i] : v0[i];
}

c++ -Ofast -fopt-info-vec -ftree-loop-if-convert-stores -S condBug.cc
condBug.cc:7:3: note: loop vectorized
condBug.cc:13:3: note: loop vectorized
gcc version 4.9.3 (GCC) 

c++ -Ofast -fopt-info-vec -ftree-loop-if-convert-stores -S condBug.cc
condBug.cc:13:17: note: loop vectorized
with gcc version 6.0.0 20150801 (experimental) [trunk revision 226463] (GCC)

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

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima  changed:

   What|Removed |Added

 CC||kkojima at gcc dot gnu.org

--- Comment #1 from Kazumoto Kojima  ---
Created attachment 36246
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36246&action=edit
patch

>.long foo@PCREL-(.LPCS0+2-.)

looks to be reasonable.  It seems that sh backend shouldn't
use UNSPEC_SYMOFF for that case in the first place.  Does
the patch attached work for you?

[Bug c++/67164] ICE: tree check: expected class ‘expression’, have ‘exceptional’ (argument_pack_select) in tree_operand_check, at tree.h:3356

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #3 from Markus Trippelsdorf  ---
Here's another testcase: 

namespace std {
template  struct A { static constexpr _Tp value = 0; };
template  struct conditional;
template  struct B;
template 
struct B<_B1, _B2> : conditional<1, _B1, _B2> {};
template  struct C;
template 
struct C<_B1, _B2> : conditional<1, _B2, _B1> {};
template  struct D;
template  struct I : B, D<_Tp>>::type {};
template  _Tp declval();
struct F {
  template ()))>
  static A __test(int);
};
template  struct J : F {
  decltype(__test<_Tp, _Arg>(0)) type;
};
template  struct K : C> {};
template 
struct L : conditional::value, int, K<_Tp, _Arg>> {};
template 
struct __is_direct_constructible : L<_Tp, _Arg>::type {};
template  struct G;
template 
struct G<_Tp, _Arg> : __is_direct_constructible<_Tp, _Arg> {};
template 
struct is_constructible : G<_Tp, _Args...>::type {};
template  struct enable_if;
template  struct conditional {
  typedef _Iftrue type;
};
template 
struct conditional {
  typedef _Iffalse type;
};
}
namespace detail {
template  struct fast_and;
template  struct closure {
  template ::value...>::value>>
  closure(Yn...);
  template  closure(closure);
};
}
template  struct make_impl;
template  struct H {
  template  decltype(auto) operator()(X... x) {
return make_impl::apply(x...);
  }
};
template  H make;
struct Tuple;
template  struct M : detail::closure {
  using detail::closure::closure;
};
template <> struct make_impl {
  template  static M apply(Xs...);
};
namespace test {
struct {
  template  decltype(auto) operator()(Xs... xs) {
auto storage = make(xs...);
return storage;
  }
} seq;
}
int main() { test::seq(test::seq()); }

[Bug other/57195] Mode attributes with specific mode iterator can not be used as mode iterators in *.md files

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
Hello Michael,

Patches should be sent to gcc-patches@.

If you do, either make in_angle_bracket a bool, or actually count
the nesting level; and you probably want to handle the case where
there are more closing than opening brackets.

And one of your lines is much too long ;-)

[Bug target/67281] HTM builtins aren't treated as compiler barriers on powerpc

[torvald at gcc dot gnu.org]

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

torvald at gcc dot gnu.org changed:

   What|Removed |Added

 CC||torvald at gcc dot gnu.org

--- Comment #6 from torvald at gcc dot gnu.org ---
I think tbegin needs to have same semantics as a lock acquisition and the
compiler must not assume to know anything about tbegin's return value; tend
must have same semantics as a lock release.

See the libc-alpha discussion for why I think this is the case:
https://sourceware.org/ml/libc-alpha/2015-08/msg00963.html

Thus, I don't think a full compiler barrier is necessary, but if we don't have
something finer-grained to capture the semantics of a lock acquisition, then we
need the compiler barrier (GCC currently assumes atomics to be compiler
barriers AFAIK).  We should in any case agree on a semantics and document it in
the GCC sources.  Documenting that we need a full compiler barrier is not
correct in that it's not a necessary condition (even though it should be a
sufficient condition).

[Bug middle-end/67327] New: Missed tail call with __noreturn__ attribute

[hjl.tools at gmail dot com]

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

Bug ID: 67327
   Summary: Missed tail call with __noreturn__ attribute
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

[hjl@gnu-tools-1 tmp]$ cat x.c 
extern void xxx (void) __attribute__ ((__noreturn__));
void
foo (int len)
{
  if (len)
xxx ();
}
[hjl@gnu-tools-1 tmp]$ gcc -S -O2 x.c
[hjl@gnu-tools-1 tmp]$ cat x.s
.file   "x.c"
.section.text.unlikely,"ax",@progbits
.LCOLDB0:
.text
.LHOTB0:
.p2align 4,,15
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
testl   %edi, %edi
jne .L6
rep ret
.L6:
pushq   %rax
.cfi_def_cfa_offset 16
callxxx
.cfi_endproc
.LFE0:
.size   foo, .-foo
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.ident  "GCC: (GNU) 5.2.1 20150716 (Red Hat 5.2.1-1)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-tools-1 tmp]$

[Bug middle-end/67327] Missed tail call with __noreturn__ attribute

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I can't remember how many duplicate bugs there are of this one.

This is done on purpose.

[Bug middle-end/67327] Missed tail call with __noreturn__ attribute

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 10837.

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

[Bug tree-optimization/67328] New: range test rather than single bit test for code testing enum values

[amodra at gmail dot com]

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

Bug ID: 67328
   Summary: range test rather than single bit test for code
testing enum values
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amodra at gmail dot com
  Target Milestone: ---

The attached file generates ideal code, a test of a single bit, for the
condition in test_pic or test_exe depending on -DALT.  gcc ought to be able to
optimise to a single bit test for both functions whether or not -DALT.  It
looks like gcc incorrectly prefers a range test.

[Bug rtl-optimization/10837] noreturn attribute causes no sibling calling optimization

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #11 from Andrew Pinski  ---
*** Bug 67327 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/67328] range test rather than single bit test for code testing enum values

[amodra at gmail dot com]

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

--- Comment #1 from Alan Modra  ---
Created attachment 36247
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36247&action=edit
testcase from binutils/include/bfdlink.h

[Bug c++/67324] Failures in Assignable concept's requires-expression

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-23
 Ever confirmed|0   |1
   Severity|major   |normal

[Bug c++/64117] warning control #pragmas in precompiled headers are not obeyed for template code

[gcc-o...@ben-kiki.org]

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

--- Comment #2 from Oren Ben-Kiki  ---
Problem persists in gcc 5.2. Sigh.

[Bug target/67329] New: [5] gcc.dg/tree-ssa/ssa-dom-cse-2.c fails on -march=pentium or -march=iamcu

[julia.koval at intel dot com]

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

Bug ID: 67329
   Summary: [5] gcc.dg/tree-ssa/ssa-dom-cse-2.c fails on
-march=pentium or -march=iamcu
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: julia.koval at intel dot com
  Target Milestone: ---

The normal -m32 version optimizes the sum to just return 28. However if i use
-march=pentium: 191t.optimized dump has:
foo ()
{
  int sum;
  const int a[8];
  int _6;
  int _9;
  int _22;
  int _29;
  int _36;
  int _43;
  int _50;
  int _57;

  :
  a = *.LC0;
  _9 = a[0];
  _22 = a[1];
  sum_23 = _9 + _22;
  _29 = a[2];
  sum_30 = sum_23 + _29;
  _36 = a[3];
  sum_37 = sum_30 + _36;
  _43 = a[4];
  sum_44 = sum_37 + _43;
  _50 = a[5];
  sum_51 = sum_44 + _50;
  _57 = a[6];
  sum_58 = sum_51 + _57;
  _6 = a[7];
  sum_7 = _6 + sum_58;
  a ={v} {CLOBBER};
  return sum_7;

}

[Bug target/67329] [5] gcc.dg/tree-ssa/ssa-dom-cse-2.c fails on -march=pentium or -march=iamcu

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
This is a cost issue.
And even has this comment in the testcase:
/* See PR63679 and PR64159, if the target forces the initializer to memory then
   DOM is not able to perform this optimization.  */

[Bug c/67330] New: ICE handling weak attributes

[sasha.levin at oracle dot com]

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

Bug ID: 67330
   Summary: ICE handling weak attributes
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sasha.levin at oracle dot com
  Target Milestone: ---

Created attachment 36248
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36248&action=edit
Preprocessed source

Hi,

I'm seeing the following ICE when compiling the kernel's kernel/sched/core.c:

kernel/sched/core.c:5925:1: note: in expansion of macro ‘DEFINE_PER_CPU’
 DEFINE_PER_CPU(struct sched_domain *, sd_llc);
 ^
0x63552c symtab_node::get(tree_node const*)
../../gcc/cgraph.h:370
0x63552c handle_weak_attribute
../../gcc/c-family/c-common.c:8332
0x5af16b decl_attributes(tree_node**, tree_node*, int)
../../gcc/attribs.c:557
0x5cb3da start_decl(c_declarator*, c_declspecs*, bool, tree_node*)
../../gcc/c/c-decl.c:4547
0x61d140 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:1828
0x62168d c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:4622
0x621cbe c_parser_compound_statement
../../gcc/c/c-parser.c:4533
0x61dc27 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:1966
0x627e1f c_parser_external_declaration
../../gcc/c/c-parser.c:1436
0x6286d9 c_parser_translation_unit
../../gcc/c/c-parser.c:1323
0x6286d9 c_parse_file()
../../gcc/c/c-parser.c:15449
0x684fa2 c_common_parse_file()
../../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've bisected it down to:

commit 8e857c4151f8f0aae992f9b5f22ee5b4c1cc1c73  
Author: hubicka   
Date:   Fri Sep 19 23:56:52 2014 +  

PR c++/61825  
* c-family/c-common.c (handle_alias_ifunc_attribute): Check  
that visibility change is possible  
(handle_weakref_attribute): Likewise.  
* cgraph.h (symtab_node): Add method get_create and  
field refuse_visibility_changes.  
(symtab_node::get_create): New method.  
* fold-const.c (tree_single_nonzero_warnv_p): Use get_create.  
* varasm.c (mark_weak): Verify that visibility change is  
possible.  

* gcc.dg/tree-ssa/nonzero-1.c: Require error to be output.  


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@215409
138bc75d-0d04-0410-961f-82ee72b054a4

Attached a preprocessed source file.

[Bug middle-end/67330] ICE handling weak attributes

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #1 from Markus Trippelsdorf  ---
Please post the full output of -v invocation.

[Bug pch/64117] warning control #pragmas in precompiled headers are not obeyed for template code

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-23
 CC||manu at gcc dot gnu.org
  Component|c++ |pch
 Ever confirmed|0   |1

--- Comment #3 from Manuel López-Ibáñez  ---
I can confirm this with GCC 6. I'm not sure if the pragmas are even saved in
the pch file. Someone would need to debug what is happening.

[Bug middle-end/67330] ICE handling weak attributes

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
Doesn't happen with --enable-checking=release.

markus@x4 tmp % cat core.i
void fn1 (void)
{
  __attribute__ ((weak)) int a;
}
markus@x4 tmp % gcc -c core.i
core.i: In function ‘fn1’:
core.i:3:30: error: weak declaration of ‘a’ must be public
   __attribute__ ((weak)) int a;
  ^

markus@x4 tmp % /var/tmp/gcc_test/usr/local/bin/gcc -c core.i
core.i: In function ‘fn1’:
core.i:3:3: internal compiler error: in get, at cgraph.h:371
   __attribute__ ((weak)) int a;
   ^
0x62f80c symtab_node::get(tree_node const*)
../../gcc/gcc/cgraph.h:368
0x62f80c handle_weak_attribute
../../gcc/gcc/c-family/c-common.c:8332
0x5a966a decl_attributes(tree_node**, tree_node*, int)
../../gcc/gcc/attribs.c:557
0x5c5674 start_decl(c_declarator*, c_declspecs*, bool, tree_node*)
../../gcc/gcc/c/c-decl.c:4547
0x6174e0 c_parser_declaration_or_fndef
../../gcc/gcc/c/c-parser.c:1830
0x61bb2d c_parser_compound_statement_nostart
../../gcc/gcc/c/c-parser.c:4622
0x61bf9e c_parser_compound_statement
../../gcc/gcc/c/c-parser.c:4533
0x617f88 c_parser_declaration_or_fndef
../../gcc/gcc/c/c-parser.c:1966
0x622107 c_parser_external_declaration
../../gcc/gcc/c/c-parser.c:1436
0x6229c9 c_parser_translation_unit
../../gcc/gcc/c/c-parser.c:1323
0x6229c9 c_parse_file()
../../gcc/gcc/c/c-parser.c:15449
0x67e642 c_common_parse_file()
../../gcc/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.

[Bug middle-end/67330] ICE handling weak attributes

[sasha.levin at oracle dot com]

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

--- Comment #3 from Sasha Levin  ---
This is the -v invocation:

Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/home/sasha/gcc-inst/ --with-arch=native
--with-tune=native --enable-languages=c --enable-lto --enable-gold
--enable-stage1-languages=c
Thread model: posix
gcc version 6.0.0 20150823 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-nostdinc' '-isystem'
'/home/sasha/gcc-inst/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include' '-I'
'./arch/x86/include' '-I' 'arch/x86/include/generated/uapi' '-I'
'arch/x86/include/generated' '-I' 'include' '-I' './arch/x86/include/uapi' '-I'
'arch/x86/include/generated/uapi' '-I' './include/uapi' '-I'
'include/generated/uapi' '-include' './include/linux/kconfig.h' '-D'
'__KERNEL__' '-Wall' '-Wundef' '-Wstrict-prototypes' '-Wno-trigraphs'
'-fno-strict-aliasing' '-fno-common' '-Werror=implicit-function-declaration'
'-Wno-format-security' '-std=gnu90' '-mno-sse' '-mno-mmx' '-mno-sse2'
'-mno-3dnow' '-mno-avx' '-m64' '-falign-jumps=1' '-falign-loops=1' '-mno-80387'
'-mno-fp-ret-in-387' '-mpreferred-stack-boundary=3' '-mskip-rax-setup'
'-march=native' '-mno-red-zone' '-mcmodel=kernel' '-funit-at-a-time'
'-maccumulate-outgoing-args' '-D' 'CONFIG_X86_X32_ABI' '-D'
'CONFIG_AS_FXSAVEQ=1' '-D' 'CONFIG_AS_SSSE3=1' '-D' 'CONFIG_AS_CRC32=1' '-D'
'CONFIG_AS_AVX=1' '-D' 'CONFIG_AS_AVX2=1' '-pipe' '-Wno-sign-compare'
'-fno-asynchronous-unwind-tables' '-fno-delete-null-pointer-checks' '-O2'
'--param' 'allow-store-data-races=0' '-fno-reorder-blocks' '-fno-ipa-cp-clone'
'-fno-partial-inlining' '-Wframe-larger-than=2048' '-fstack-protector'
'-Wno-unused-but-set-variable' '-fno-omit-frame-pointer'
'-fno-optimize-sibling-calls' '-fno-var-tracking-assignments' '-g' '-gdwarf-4'
'-pg' '-mfentry' '-D' 'CC_USING_FENTRY' '-fno-inline-functions-called-once'
'-Wdeclaration-after-statement' '-Wno-pointer-sign' '-fno-strict-overflow'
'-fconserve-stack' '-Werror=implicit-int' '-Werror=strict-prototypes'
'-Werror=date-time' '-D' 'CC_HAVE_ASM_GOTO' '-fsanitize=kernel-address'
'-fasan-shadow-offset=0xdc00' '--param' 'asan-stack=1' '--param'
'asan-globals=1' '--param' 'asan-instrumentation-with-call-threshold=1'
'-D' 'KBUILD_STR(s)=#s' '-D' 'KBUILD_BASENAME=KBUILD_STR(core)' '-D'
'KBUILD_MODNAME=KBUILD_STR(core)' '-c' '-o' 'kernel/sched/.tmp_core.o'
 /home/sasha/gcc-inst/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/cc1 -quiet
-nostdinc -v -I ./arch/x86/include -I arch/x86/include/generated/uapi -I
arch/x86/include/generated -I include -I ./arch/x86/include/uapi -I
arch/x86/include/generated/uapi -I ./include/uapi -I include/generated/uapi
-imultiarch x86_64-linux-gnu -D __KERNEL__ -D CONFIG_X86_X32_ABI -D
CONFIG_AS_FXSAVEQ=1 -D CONFIG_AS_SSSE3=1 -D CONFIG_AS_CRC32=1 -D
CONFIG_AS_AVX=1 -D CONFIG_AS_AVX2=1 -D CC_USING_FENTRY -D CC_HAVE_ASM_GOTO -D
KBUILD_STR(s)=#s -D KBUILD_BASENAME=KBUILD_STR(core) -D
KBUILD_MODNAME=KBUILD_STR(core) -isystem
/home/sasha/gcc-inst/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include -include
./include/linux/kconfig.h -MD kernel/sched/.core.o.d kernel/sched/core.c
-march=nehalem -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16
-msahf -mno-movbe -mno-aes -mno-sha -mno-pclmul -mpopcnt -mno-abm -mno-lwp
-mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2
-msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c
-mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt
-mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1
-mno-clflushopt -mno-xsavec -mno-xsaves -mno-avx512dq -mno-avx512bw
-mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-clwb -mno-pcommit
-mno-mwaitx --param l1-cache-size=32 --param l1-cache-line-size=64 --param
l2-cache-size=24576 -mtune=nehalem -quiet -dumpbase core.c -mno-sse -mno-mmx

[Bug tree-optimization/37021] Fortran Complex reduction / multiplication not vectorized

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org

--- Comment #20 from Bill Schmidt  ---
We still don't vectorize the original code example on Power.  It appears that
this is being disabled because of an alignment issue.  The data references are
being rejected by:

product.f:9:0: note: can't force alignment of ref: REALPART_EXPR <*a.0_24[_50]>

and similar for the other three DRs.  This happens due to this code in
vect_compute_data_ref_alignment:

  if (base_alignment < TYPE_ALIGN (vectype))
{
  /* Strip an inner MEM_REF to a bare decl if possible.  */
  if (TREE_CODE (base) == MEM_REF
  && integer_zerop (TREE_OPERAND (base, 1))
  && TREE_CODE (TREE_OPERAND (base, 0)) == ADDR_EXPR)
base = TREE_OPERAND (TREE_OPERAND (base, 0), 0);

  if (!vect_can_force_dr_alignment_p (base, TYPE_ALIGN (vectype)))
{
  if (dump_enabled_p ())
{
  dump_printf_loc (MSG_NOTE, vect_location,
   "can't force alignment of ref: ");
  dump_generic_expr (MSG_NOTE, TDF_SLIM, ref);
  dump_printf (MSG_NOTE, "\n");
}
  return true;
}

Here TYPE_ALIGN (vectype) is 128 (Power vectors are normally aligned on a
128-bit value), and base_alignment is 64.  a.0 is defined as:

complex(kind=8) [0:D.1831] * restrict a.0;

In both ELFv1 and ELFv2 ABIs for Power, a complex type is defined to have the
same alignment as the underlying type.  So "complex double" has 8-byte
alignment.

On earlier versions of Power, the decision is fine, because unaligned accesses
are expensive prior to POWER8.  With POWER8, though, an unaligned access will
(most of the time) perform as well as an aligned access.  So ideally we would
like to teach the vectorizer to allow vectorization here.

It seems like vect_supportable_dr_alignment ought to be considered as part of
the SLP vectorization decision here, rather than just comparing the base
alignment with the vector type alignment.  Adding a check for that allows
things to get a little further, but we still don't vectorize the block.  (I
haven't yet looked into why, but I assume more needs to be done downstream to
handle this case.)

My understanding of the vectorizer is not yet very deep, so before going too
far down the wrong path, I'd like your opinion on the best approach to fixing
the problem.  Thanks!

Bill

[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

[myriachan at gmail dot com]

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

Melissa  changed:

   What|Removed |Added

 CC||myriachan at gmail dot com

--- Comment #12 from Melissa  ---
(In reply to Kai Tietz from comment #11)
> Fixed with delayed-folding for C++.  Therefore mine.

Why fix it?  The Standard doesn't allow it, but it's still useful.  For
example, std::numeric_limits::infinity() cannot be implemented without
it or compiler magic (e.g. __builtin_huge_valf in the current libstdc++).

Melissa

[Bug c++/67331] New: ICE with recursive variable template with non-type template parameters

[morwenn29 at hotmail dot fr]

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

Bug ID: 67331
   Summary: ICE with recursive variable template with non-type
template parameters
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: morwenn29 at hotmail dot fr
  Target Milestone: ---

I tried to write a recursive variable template with non-type template
parameters (booleans in my case) and got an internal compiler error. Here is a
minimal failing example:

template
constexpr bool any = Head || any;

template
constexpr bool any = Head;

int main()
{
static_assert(any, "");
}


And here is the error message I get:

main.cpp:2:16: internal compiler error: Segmentation fault

 constexpr bool any = Head || any;


It also fails if I remove the terminal case or if I change bool to another
non-type template parameter. It only fails when the variable template
definition is recursive.

[Bug c++/67331] ICE with recursive variable template with non-type template parameters

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
Already fixed on gcc-5 branch and trunk.

[Bug middle-end/64920] bootstrap-ubsan [build/gengtype -r gtype.state]: libiberty/regex.c:6970:11: runtime error: left shift of negative value -1

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #1 from Vittorio Zecca  ---
I have the same messages during gcc 5.2.0 generation

Fixing directory /usr/include into
/home/vitti/gcc-5.2.0-sanitize-all/gcc/include-fixed
../../../gcc-5.2.0/libiberty/regex.c:6972:11: runtime error: left shift of
negative value -1
../../../gcc-5.2.0/libiberty/regex.c:7167:4: runtime error: left shift of
negative value -1
Applying machine_name to slang.h

I believe this is because at line 688

(destination) += SIGN_EXTEND_CHAR (*((source) + 1)) << 8;

(*((source) + 1)) is negateive (-1)

[Bug other/66827] [6 Regression] left shifts of negative value warnings due to C++14 switch

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #2 from Vittorio Zecca  ---
The warnings in regex.c are already described in issue 64920

[Bug libfortran/62296] EXECUTE_COMMAND_LINE not F2008 conforming

[fxcoudert at gcc dot gnu.org]

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

--- Comment #8 from Francois-Xavier Coudert  ---
Author: fxcoudert
Date: Sun Aug 23 21:24:49 2015
New Revision: 227105

URL: https://gcc.gnu.org/viewcvs?rev=227105&root=gcc&view=rev
Log:
PR libfortran/62296

* intrinsics/execute_command_line.c (EXEC_INVALIDCOMMAND): New
error code.
(cmdmsg_values): New error message.
(set_cmdstat): Rework runtime error.
(execute_command_line): Handle invalid command line error status.

* gfortran.dg/execute_command_line_2.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/execute_command_line_2.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/intrinsics/execute_command_line.c

[Bug libfortran/62296] EXECUTE_COMMAND_LINE not F2008 conforming

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #9 from Francois-Xavier Coudert  ---
Fixed on trunk.

[Bug libfortran/54572] Use libbacktrace library

[fxcoudert at gcc dot gnu.org]

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

--- Comment #17 from Francois-Xavier Coudert  ---
Author: fxcoudert
Date: Sun Aug 23 21:50:30 2015
New Revision: 227106

URL: https://gcc.gnu.org/viewcvs?rev=227106&root=gcc&view=rev
Log:
PR libfortran/54572

* Makefile.def: Make libgfortran depend on libbacktrace.
* Makefile.in: Regenerate.

* config-lang.in: Add libbacktrace to target_libs.

* Makefile.am (libgfortran_la_LDFLAGS): Link in libbacktrace.
(AM_CPPFLAGS): Add libbacktrace directories to include paths.
* Makefile.in: Regenerate.
* aclocal.m4: Regenerate.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Remove checks for strtok_r, wait, execve, pipe,
and dup2. Remove call to GCC_CHECK_UNWIND_GETIPINFO.
* libgfortran.h (full_exe_path, find_addr2line, backtrace): Remove
prototypes.
(show_backtrace): Add prototype.
* runtime/backtrace.c: Rework file entirely.
* runtime/compile_options.c (backtrace_handler): Rename backtrace
to show_backtrace.
(maybe_find_addr2line): Remove function.
(set_options): Remove call to maybe_find_addr2line.
* runtime/error.c (sys_abort): Rename backtrace to show_backtrace.
* runtime/main.c (store_exe_path): Empty function body.
(full_exe_path, gfstrtok_r, find_addr2line): Remove functions.
(cleanup): Don't free removed variables.
* runtime/minimal.c (full_exe_path): Remove function.
(set_args): Don't set exe_path.

* gfortran.dg/backtrace_1.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/backtrace_1.f90
Modified:
trunk/ChangeLog
trunk/Makefile.def
trunk/Makefile.in
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/config-lang.in
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/Makefile.am
trunk/libgfortran/Makefile.in
trunk/libgfortran/aclocal.m4
trunk/libgfortran/config.h.in
trunk/libgfortran/configure
trunk/libgfortran/configure.ac
trunk/libgfortran/libgfortran.h
trunk/libgfortran/runtime/backtrace.c
trunk/libgfortran/runtime/compile_options.c
trunk/libgfortran/runtime/error.c
trunk/libgfortran/runtime/main.c
trunk/libgfortran/runtime/minimal.c

[Bug libfortran/54572] Use libbacktrace library

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #18 from Francois-Xavier Coudert  ---
Fixed on trunk.

[Bug other/57195] Mode attributes with specific mode iterator can not be used as mode iterators in *.md files

[michael.collison at linaro dot org]

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

--- Comment #5 from Michael Collison  ---
On 08/23/2015 04:50 AM, segher at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57195
>
> --- Comment #4 from Segher Boessenkool  ---
> Hello Michael,
Hi Segher,
>
> Patches should be sent to gcc-patches@.
I did send the patch upstream:

https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01366.html
>
> If you do, either make in_angle_bracket a bool, or actually count
> the nesting level; and you probably want to handle the case where
> there are more closing than opening brackets.
>
> And one of your lines is much too long ;-)

Okay thanks. I'll address that once I get feedback on the other parts of 
the patch
>

[Bug c++/67332] New: [C++11] g++ rejects expansion of multiple parameter packs

[miyuki at gcc dot gnu.org]

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

Bug ID: 67332
   Summary: [C++11] g++ rejects expansion of multiple parameter
packs
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: miyuki at gcc dot gnu.org
  Target Milestone: ---

Consider the following code:

$ cat test2.cc
template
struct Typelist { };

template
void foo (Typelist, Typelist, InvokableArgs&&...,
Rest&&...) { }

void bar()
{
foo (Typelist(), Typelist(), 2.5, 1);
}

GCC 6 rejects it:
$ g++ -c test2.cc
test2.cc: In function 'void bar()':
test2.cc:9:53: error: no matching function for call to 'foo(Typelist,
Typelist, double, int)'
 foo (Typelist(), Typelist(), 2.5, 1);
 ^
test2.cc:5:6: note: candidate: template void foo(Typelist, Typelist, InvokableArgs&&
..., Rest&& ...)
 void foo (Typelist, Typelist, InvokableArgs&&...,
Rest&&...) { }
  ^
test2.cc:5:6: note:   template argument deduction/substitution failed:
test2.cc:9:53: note:   inconsistent parameter pack deduction with '' and ''
 foo (Typelist(), Typelist(), 2.5, 1);

Clang 3.7 accepts the code, but EDG also rejects:
$ /opt/intel/bin/icpc -std=c++11 -c test2.cc
test2.cc(9): error: no instance of function template "foo" matches the argument
list
argument types are: (Typelist, Typelist, double, int)
  foo (Typelist(), Typelist(), 2.5, 1);
  ^

compilation aborted for test2.cc (code 2)

Although I'm not sure, whether the code is valid or not, at least the
diagnostic is somewhat confusing.

[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 #2 from Rich Felker  ---
The patch in comment 1 applies successfully to GCC 5.2.0 and fixes both the
test case and the real-world code I was experiencing problems with.
Unfortunately it doesn't apply to some of the older GCC versions I need to
support, but I think I can backport it. Thanks!

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

[kkojima at gcc dot gnu.org]

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

--- Comment #3 from Kazumoto Kojima  ---
(In reply to Rich Felker from comment #2)

Thanks for the confirmation.  I'll commit the patch after the undergoing
additional test done.

[Bug c++/67333] New: [C++11][constexpr] constexpr functions incorrectly prohibit taking references to volatile types

[myriachan at gmail dot com]

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

Bug ID: 67333
   Summary: [C++11][constexpr] constexpr functions incorrectly
prohibit taking references to volatile types
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: myriachan at gmail dot com
  Target Milestone: ---

GCC 4.7.3 (at least) through GCC 6.0 reject the following due to "meow has
side-effects":

#include 
#include 

template 
constexpr std::size_t lengthof(const volatile T (&)[S])
{
return S;
}

int main()
{
volatile int meow[4];
static_cast(meow); // shut up warning
return static_cast(std::integral_constant::value);
}

I believe that this is legal per [expr.const] in the Standard, because the
volatile parameter is never used in an lvalue-to-rvalue conversion, which is
what [expr.const] disallows in constant-expressions for volatile types.  Clang
versions that understand this code accept it; Visual C++ 2015 does as well.

Someone who replied to my question on the "std-discussion" mailing list
suggested that this is also technically legal as well:

#include 

constexpr int Test(int x)
{
volatile int v = x;
return x;
}

int main()
{
return std::integral_constant::value;
}

GCC also rejects this, but Clang accepts this as well.  Any attempt to read v
will fail, though, so Clang is enforcing the rule.  I'm not on my Windows
machine as I write this, so I can't check MSVC.

[Bug c++/67333] [C++11][constexpr] constexpr functions incorrectly prohibit taking references to volatile types

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||miyuki at gcc dot gnu.org

--- Comment #1 from Mikhail Maltsev  ---
EDG accepts the first testcase. The second one is rejected, but presumably due
to incomplete C++14 support.

In potential_constant_expression_1 we have a check:

  if (TREE_THIS_VOLATILE (t))
{
  if (flags & tf_error)
error ("expression %qE has side-effects", t);

The comment in tree.h says:
/* Nonzero means this expression is volatile in the C sense:
   its address should be of type `volatile WHATEVER *'.
   In other words, the declared item is volatile qualified.
...
   If this bit is set in an expression, so is TREE_SIDE_EFFECTS.  */

In our case t is:
(gdb) p t
$10 = 
(gdb) pt
warning: Expression is not an assignment (and might have no effect)
 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x76800a80
precision 32 min  max 
pointer_to_this >
TI
size 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x76800c78
domain 
type_6 DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x76800b28
precision 64 min  max >
pointer_to_this >
side-effects addressable volatile used tree_1 decl_5 TI file
/home/miyuki/gcc/test/meow/meow.cc line 15 col 18 size  unit size 
align 32 context >

I.e. the condition is probably wrong and we should also check that t is an
expression, not a declaration.

[Bug inline-asm/67334] New: [4.7 arm inline-asm] inline assembly incorrect register allocation

[anmin_deng at yahoo dot com.tw]

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

Bug ID: 67334
   Summary: [4.7 arm inline-asm] inline assembly incorrect
register allocation
   Product: gcc
   Version: 4.7.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anmin_deng at yahoo dot com.tw
  Target Milestone: ---

A very simple code with ARM inline assembly

== "test.c" ==>
extern unsigned x;
extern unsigned s;

void
h(void)
{
 unsigned a, b, c, d;
 unsigned i;
 __asm__ volatile ("mrrc p15,2,%0,%1,c14" : "=r"(a),"=r"(b));
 i = 1200;
 __asm__ volatile ("\n"
  "   adds%0,%2,%4\n"
  "   adc %1,%3,$0"
  : "=r"(c),"=r"(d)
  : "r"(a),"r"(b),"r"(i) : "cc");
 __asm__ volatile ("mcrr p15,2,%0,%1,c14" : : "r"(c),"r"(d));
 if (a == x) {
  ++s;
 }
}
<===

To compile the above simple test code on PC cygwin with ARM target
cross-compiler and "-Os" options:
"arm-none-eabi-gcc -ansi -Wall -W -Os -mcpu=cortex-a7 test.c -S".


The generated result is allocating incorrect register...

=== "test.s" ===>
...
h:
...
@ 9 "test.c" 1
mrrcp15,2,r3,r2,c14
@ 0 "" 2
ldr r1, .L3
@ 11 "test.c" 1

addsr2,r3,r1 @INCORRECT! reg "r2" allocated, "@ 9" above corrupted
adc r1,r2,$0
@ 0 "" 2
@ 16 "test.c" 1
mcrrp15,2,r2,r1,c14
@ 0 "" 2
...
<===

On the other hand, to compile with "-O2" option
"arm-none-eabi-gcc -ansi -Wall -W -O2 -mcpu=cortex-a7 test.c -S",
the generated result is OK.


--
Details about this "ARM target cross-compiler"..
arm-none-eabi-gcc -ansi -Wall -W -Os -mcpu=cortex-a7 test.c -S -v -save-temps
>>
Using built-in specs.
COLLECT_GCC=/cygdrive/c/tool-chain/arm-none-eabi-gcc
Target: arm-none-eabi
Configured with: ../gcc-4.7.4/configure LDFLAGS=--static
--prefix='/cygdrive/c/tool-chain' --target=arm-none-eabi --build=i686-pc-cygwin
--host=i686-pc-cygwin --with-sysroot='/cygdrive/c/tool-chain' --with-gnu-as
--with-gnu-ld --with-float=soft --disable-threads --with-stabs --disable-nls
--disable-host-shared --disable-shared --with-tls=gnu2 --with-newlib
--without-headers --disable-biendian --disable-initfini-array
--enable-version-specific-runtime-libs --enable-languages=c,c++
--disable-libssp --disable-libquadmath --disable-libgomp --disable-libvtv
--disable-lto --disable-add-ons --enable-target-optspace --disable-profile
--disable-nss-crypt --disable-nss --enable-cloog-backend=isl
--with-host-libstdcxx=-Wl,-Bstatic,-lstdc++,-lm
--with-mpc=/cygdrive/u/develop/tool_chain/prerequisites-4.7.4
--with-mpfr=/cygdrive/u/develop/tool_chain/prerequisites-4.7.4
--with-gmp=/cygdrive/u/develop/tool_chain/prerequisites-4.7.4
--with-ppl=/cygdrive/u/develop/tool_chain/prerequisites-4.7.4
--with-isl=/cygdrive/u/develop/tool_chain/prerequisites-4.7.4
--with-cloog=/cygdrive/u/develop/tool_chain/prerequisites-4.7.4
Thread model: single
gcc version 4.7.4 (GCC)
COLLECT_GCC_OPTIONS='-ansi' '-Wall' '-Wextra' '-Os' '-mcpu=cortex-a7' '-S' '-v'
'-save-temps' '-mfloat-abi=soft' '-mtls-dialect=gnu2'
 /cygdrive/c/tool-chain/bin/../libexec/gcc/arm-none-eabi/4.7.4/cc1.exe -E
-quiet -v -iprefix /cygdrive/c/tool-chain/bin/../lib/gcc/arm-none-eabi/4.7.4/
-isysroot /cygdrive/c/tool-chain/bin/../../tool-chain -D__USES_INITFINI__
test.c -mcpu=cortex-a7 -mfloat-abi=soft -mtls-dialect=gnu2 -ansi -Wall -Wextra
-Os -fpch-preprocess -o test.i

#include "..." search starts here:
#include <...> search starts here:
 /cygdrive/c/tool-chain/bin/../lib/gcc/arm-none-eabi/4.7.4/include
 /cygdrive/c/tool-chain/bin/../lib/gcc/arm-none-eabi/4.7.4/include-fixed

/cygdrive/c/tool-chain/bin/../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/include
End of search list.
COLLECT_GCC_OPTIONS='-ansi' '-Wall' '-Wextra' '-Os' '-mcpu=cortex-a7' '-S' '-v'
'-save-temps' '-mfloat-abi=soft' '-mtls-dialect=gnu2'
 /cygdrive/c/tool-chain/bin/../libexec/gcc/arm-none-eabi/4.7.4/cc1.exe
-fpreprocessed test.i -quiet -dumpbase test.c -mcpu=cortex-a7 -mfloat-abi=soft
-mtls-dialect=gnu2 -auxbase-strip test.s -Os -Wall -Wextra -ansi -version
GNU C (GCC) version 4.7.4 (arm-none-eabi)
compiled by GNU C version 4.8.3, GMP version 6.0.0, MPFR version
3.1.2-p10, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (GCC) version 4.7.4 (arm-none-eabi)
compiled by GNU C version 4.8.3, GMP version 6.0.0, MPFR version
3.1.2-p10, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2291625f97745215868a9e7332f1f761
COMPILER_PATH=/cygdrive/c/tool-chain/bin/../libexec/gcc/arm-none-eabi/4.7.4/:/cygdrive/c/tool-chain/bin/../libexec/gcc/:/cygdrive/c/tool-chain/bin/../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/bin/
LIBRARY_PATH=/cygdrive/c/tool-chain/bin/../lib/gcc/arm-none-eabi/4.7.4/:/cygdrive/c/tool-chain/bin/../lib/gcc/:/cygdrive/c/tool-cha