[Bug rtl-optimization/71588] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in execute_todo, at passes.c:2009

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
attribute pure on strcpy looks invalid to me. (we still shouldn't ice)

[Bug rtl-optimization/71588] New: ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in execute_todo, at passes.c:2009

[su at cs dot ucdavis.edu]

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

Bug ID: 71588
   Summary: ICE on valid code at -O2 and -O3 on x86_64-linux-gnu:
in execute_todo, at passes.c:2009
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  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
-O2 and -O3on x86_64-linux-gnu in both 32-bit and 64-bit modes. 

It is a regression from 6.1.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/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160619 (experimental) [trunk revision 237580] (GCC) 
$ 
$ gcc-trunk -Os -c small.c
$ gcc-6.1 -O2 -c small.c
$ 
$ gcc-trunk -O2 -c small.c
small.c: In function ‘foo’:
small.c:7:7: internal compiler error: in execute_todo, at passes.c:2009
 char *foo ()
   ^~~
0xafa57c execute_todo
../../gcc-source-trunk/gcc/passes.c:2009
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.
$ 


-


char *strcpy (char *, const char *)  __attribute__ ((__pure__));
unsigned long strlen (const char *);
void *malloc (unsigned long); 

char a; 

char *foo ()
{
  unsigned long b = strlen (&a);
  char *c = malloc (b);
  return strcpy (c, &a);
}

[Bug target/71375] Failure on startup on rs6000-ibm-aix{4.3|5.1.0}

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn  ---
Author: dje
Date: Mon Jun 20 02:25:50 2016
New Revision: 237587

URL: https://gcc.gnu.org/viewcvs?rev=237587&root=gcc&view=rev
Log:
PR target/71375
* config/rs6000/aix51.h (TARGET_EXTRA_BUILTINS): Define as 0.
* config/rs6000/aix43.h (TARGET_EXTRA_BUILTINS): Same.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/aix43.h
trunk/gcc/config/rs6000/aix51.h

[Bug c++/71587] New: missed inlining extern template function

[programmerjake at gmail dot com]

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

Bug ID: 71587
   Summary: missed inlining extern template function
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: programmerjake at gmail dot com
  Target Milestone: ---

missed inlining fn2

version: (Ubuntu 5.3.0-3ubuntu1~14.04) 5.3.0 20151204

command: g++-5 -O3 -S -std=c++11 -xc++ -
source:
template 
void fn2();

extern template void fn2();

void fn3();

void fn()
{
  fn2();
  fn3();
}

template 
void fn2()
{
}

template void fn2();

It generates
subq$8, %rsp
callvoid fn2()
addq$8, %rsp
jmp fn3()
It should generate
jmp fn3()

[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash

[hp at gcc dot gnu.org]

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

--- Comment #5 from Hans-Peter Nilsson  ---
(In reply to David B. Robins from comment #0)
> Runs of "make check-gcc-c++ RUNTESTFLAGS=--target_board=cris-sim"
> with/without the fix do not differ in passes/failures.

But that doesn't use -fpic or -fPIC, required to trig the bug.  Trying "make
check-gcc-c++ RUNTESTFLAGS=--target_board=cris-sim/fpic" would hopefully
exercise the bug, but will likely also result in noise from tests where -fpic
is unwanted.

> I would like to add a
> test for this issue but am unsure as to the correct way of doing so;
> crash.ii could be used in an execute test, or is checking the output
> assembly better, or something else?

An execution test gated on PIC-enabled targets and adding "-fpic" would do it.

As a rule, better a generic test than a target-test so as coverage I'll add an
execution test, gcc/testsuite/g++.dg/torture/pr71571.C decorated with:
// { dg-do run }
// { dg-options "-fpic" { target fpic } }
see e.g. gcc/testsuite/g++.dg/torture/pr37922.C.
I'd guess the body of the test could be your crash.ii, if you don't mind.

Completely optional, but if you could verify that that actually exposes the bug
on trunk, and observe that it passes with the patch above, I can commit to
commit faster.  (Please attach the final test here.)

[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash

[hp at gcc dot gnu.org]

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

--- Comment #4 from Hans-Peter Nilsson  ---
Created attachment 38728
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38728&action=edit
fix to be committed, pending test

Here's the patch I'll eventually test and commit.
Unfortunately, it may be a while.

[Bug c++/71586] type confusion when bitfields are accessed from templates

[gnubugzi...@martin-kaesberger.de]

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

--- Comment #1 from M K  ---
the following error occurs:

main.cpp:20:18: error: no matching function for call to 'foo(unsigned char:1&)'
 foo(s2.sa); //error
  ^
main.cpp:4:6: note: candidate: void foo(a) 
 void foo(a e) { }
  ^
main.cpp:4:6: note:   conversion of argument 1 would be ill-formed:
main.cpp:5:6: note: candidate: void foo(b) 
 void foo(b e) { }
  ^
main.cpp:5:6: note:   conversion of argument 1 would be ill-formed:

[Bug c++/71586] New: type confusion when bitfields are accessed from templates

[gnubugzi...@martin-kaesberger.de]

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

Bug ID: 71586
   Summary: type confusion when bitfields are accessed from
templates
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnubugzi...@martin-kaesberger.de
  Target Milestone: ---

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

When enums are used as bitfields of a struct, the type of a bitfield does not
get resolved when accessed from a template, except the template member is
explicitly accessed with 'this->'.

[Bug middle-end/71585] Cannot selectively disable stack protector with LTO

[js at alien8 dot de]

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

--- Comment #2 from Julian Stecklina  ---
I can reproduce this on Fedora 24 with GCC 6.1:

gcc (GCC) 6.1.1 20160510 (Red Hat 6.1.1-2)

[Bug c++/71577] [6/7 regression] ICE on invalid C++11 code (with extra struct initializer) on x86_64-linux-gnu: in digest_init_r, at cp/typeck2.c:1117

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-19
 CC||jason at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
Summary|ICE on invalid C++11 code   |[6/7 regression] ICE on
   |(with extra struct  |invalid C++11 code (with
   |initializer) on |extra struct initializer)
   |x86_64-linux-gnu: in|on x86_64-linux-gnu: in
   |digest_init_r, at   |digest_init_r, at
   |cp/typeck2.c:1117   |cp/typeck2.c:1117
 Ever confirmed|0   |1
  Known to fail||6.1.0, 7.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  The ICE was apparently introduced into 6.0 in r224289:

r224289 | jason | 2015-06-09 12:56:12 -0400 (Tue, 09 Jun 2015) | 4 lines

DR 1467
PR c++/51747
* typeck2.c (digest_init_r): Replace previous change with
gcc_unreachable.

[Bug c/71583] ICE on invalid code on x86_64-linux-gnu (in c_parser_postfix_expression_after_paren_type, at c/c-parser.c:8192)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-19
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.5.0, 5.3.0, 6.1.0, 7.0

--- Comment #3 from Martin Sebor  ---
Confirmed.  My bisection script says the most likely culprit is r157233:

r157233 | pinskia | 2010-03-04 14:59:19 -0500 (Thu, 04 Mar 2010) | 12 lines

2010-03-04  Andrew Pinski  

PR c/43248
* c-decl.c (build_compound_literal): Return early if init is
an error_mark_node.
2010-03-04  Andrew Pinski  

PR c/43248
* gcc.dg/compound-literal-1.c: New testcase.

[Bug target/71549] ICE on valid code at -O2 and -O3 with -g enabled in 64-bit mode on x86_64-linux-gnu: in simplify_subreg, at simplify-rtx.c:5952

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #38725|0   |1
is obsolete||

--- Comment #5 from H.J. Lu  ---
Created attachment 38726
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38726&action=edit
An updated patch to fix a typo

[Bug target/71549] ICE on valid code at -O2 and -O3 with -g enabled in 64-bit mode on x86_64-linux-gnu: in simplify_subreg, at simplify-rtx.c:5952

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
Created attachment 38725
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38725&action=edit
A patch

I am testing this.

[Bug middle-end/71585] Cannot selectively disable stack protector with LTO

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end

--- Comment #1 from Andrew Pinski  ---
This might be fixed already in 6.1.

[Bug c/71585] New: Cannot selectively disable stack protector with LTO

[js at alien8 dot de]

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

Bug ID: 71585
   Summary: Cannot selectively disable stack protector with LTO
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: js at alien8 dot de
  Target Milestone: ---

The following code includes a function that is intended to not be compiled with
a stack canary. This is a reduced example from an embedded project, where this
function is the function that actually sets the __stack_chk_guard variable.

The code is this:

#pragma GCC push_options
#pragma GCC optimize ("-fno-stack-protector")

__attribute__((constructor)) void foo()
{
  asm ("");
}

#pragma GCC pop_options

int main() { return 0; }

When compiled without LTO ( gcc -fstack-protector-all -O2  -o main
lto-func-attr.c ), it correctly emits a non-stack-protected function foo():

004004c0 :
  4004c0:   c3  ret

When compiled with LTO ( gcc -fstack-protector-all -flto -O2  -o main
lto-func-attr.c ), it incorrectly emits a stack canary check:

004004a0 :
  4004a0:   48 83 ec 18 subrsp,0x18
  4004a4:   64 48 8b 04 25 28 00movrax,QWORD PTR fs:0x28
  4004ab:   00 00 
  4004ad:   48 89 44 24 08  movQWORD PTR [rsp+0x8],rax
  4004b2:   31 c0   xoreax,eax
  4004b4:   48 8b 44 24 08  movrax,QWORD PTR [rsp+0x8]
  4004b9:   64 48 33 04 25 28 00xorrax,QWORD PTR fs:0x28
  4004c0:   00 00 
  4004c2:   75 05   jne4004c9 
  4004c4:   48 83 c4 18 addrsp,0x18
  4004c8:   c3  ret
  4004c9:   e8 72 ff ff ff  call   400440 <__stack_chk_fail@plt>


The expected behavior is that even with LTO, no stack canary check is emitted.

I am using gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6) running on Fedora 23
x86_64.

[Bug c/69507] bogus warning: ISO C does not allow ‘__alignof__ (expression)’

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Author: msebor
Date: Sun Jun 19 16:11:40 2016
New Revision: 237582

URL: https://gcc.gnu.org/viewcvs?rev=237582&root=gcc&view=rev
Log:
PR c/69507 - bogus warning: ISO C does not allow ‘__alignof__ (expression)’



Added:
trunk/gcc/testsuite/gcc.dg/alignof.c

[Bug c/69507] bogus warning: ISO C does not allow ‘__alignof__ (expression)’

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Sebor  ---
Fixed via r237581.

[Bug c/69507] bogus warning: ISO C does not allow ‘__alignof__ (expression)’

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
Author: msebor
Date: Sun Jun 19 16:10:04 2016
New Revision: 237581

URL: https://gcc.gnu.org/viewcvs?rev=237581&root=gcc&view=rev
Log:
PR c/69507 - bogus warning: ISO C does not allow ‘__alignof__ (expression)’

gcc/testsuite/ChangeLog:

PR c/69507
* gcc.dg/alignof.c: New test.

gcc/c/ChangeLog:

PR c/69507
* c-parser.c (c_parser_alignof_expression): Avoid diagnosing
__alignof__ (expression).


Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/testsuite/ChangeLog

[Bug target/71470] Wrong code on trunk gcc with westmere target

[anton.mitrokhin at phystech dot edu]

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

Anton Mitrokhin  changed:

   What|Removed |Added

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

--- Comment #2 from Anton Mitrokhin  ---
It works now, thank you.

However, the unreduced test case now fails with a segfault (again, only on
westmere). I will try to reduce it and create a tracker =)

[Bug target/71559] ICE in ix86_fp_cmp_code_to_pcmp_immediate, at config/i386/i386.c:23042 (KNL/AVX512)

[tripiana at gmail dot com]

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

--- Comment #13 from Carlos Tripiana Montes  ---
The code you are referring to (ix86_fp_compare_mode) is an old, well-stablish,
one:

https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/i386/i386.c?r1=38978&r2=38979&pathrev=38979&;

(line 4653 enum machine_mode)

The actual code comes from a 2001's commit. Just to point out that, most
probably, there's a lot of code depending on it.

[Bug sanitizer/66343] "Error: .Lubsan_type3 already defined" with UBSan and precompiled headers

[simon.lindholm10 at gmail dot com]

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

Simon Lindholm  changed:

   What|Removed |Added

 CC||simon.lindholm10 at gmail dot 
com

--- Comment #3 from Simon Lindholm  ---
Seems to happen when both source and precompiled header files contain a
division:

$ echo "void div1(int a, int b) { a / b; }" >header.h
$ echo "void div2(int a, int b) { a / b; }" >src.cpp
$ g++ -fsanitize=undefined header.h
$ g++ -fsanitize=undefined -include header.h src.cpp
/tmp/ccoYhDz6.s: Assembler messages:
/tmp/ccoYhDz6.s:69: Error: symbol `.Lubsan_data0' is already defined

(reproduced on gcc 6.1.1)

[Bug libstdc++/71500] regex::icase only works on first character in a range

[mwd at md5i dot com]

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

--- Comment #11 from Michael Duggan  ---
"timshen at gcc dot gnu.org"  writes:

> (In reply to Michael Duggan from comment #9)
>> I will make two suggestions.  The initial suggestion is simple enough:
>> Given that regex_traits is mandated to be implemented by the library for
>> char and wchar_t, it would be reasonable, I think, to make the
>> specializations that handled these that go ahead and use the locale.
>> This falls into the "as if" rule, where an implementation is fine as
>> long as it works "as if" the more correct way was implemented.
>
>> The other suggestion is this.  Given that the more correct is "terribly
>> inefficient and impractical", I posit that you have three options: Use
>> the "correct", but "bad", implementation, leave the "incorrect in all
>> cases" implementation in place, or just go ahead and use the locale to
>> implement toggle_case().  Of these three, I think the "incorrect in all
>> cases" option is the worst of all worlds.
>
> In long term I think "toggle_case" or its equivalent should be specified by 
> the
> user-defined traits. I think we can use my toggle_case for now. I'll post a 
> new
> patch to reflect the discussion.
>
> I'll only post the patch after we have an agreement, since I shouldn't bother
> the reviewer (sorry Jon!) too frequently. :P

Sounds good to me.

[Bug middle-end/71318] Can't disable ISAs via function attribute

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
Created attachment 38724
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38724&action=edit
A patch to show the problem

[Bug bootstrap/66508] Attempt to Compile gcc-6.0 on OSX 10.9.4 cause segmentation fault

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Iain Sandoe  ---
fixed by 224431

[Bug c++/71584] New: Internal Error compiling LMMS on ARM (Endian Little)

[jeffbai at aosc dot xyz]

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

Bug ID: 71584
   Summary: Internal Error compiling LMMS on ARM (Endian Little)
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeffbai at aosc dot xyz
  Target Milestone: ---

Upstream bug opened at: https://github.com/LMMS/lmms/issues/2859

The issue is that LMMS will fail to build due to a "internal compiler error"
when the flag -fdeclone-ctor-dtor is specified as a part of $CXXFLAGS (the
issue exists since 1.1.90). When the flag is removed, the build passes.

I wasn't able to reproduce the same issue on amd64 (using same GCC version).

-

General configuration info:

-- The C compiler identification is GNU 6.1.0
-- The CXX compiler identification is GNU 6.1.0
-- Check for working C compiler: /bin/gcc
-- Check for working C compiler: /bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /bin/g++
-- Check for working CXX compiler: /bin/g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PkgConfig: /bin/pkg-config (found version "0.29.1") 
-- Found Git: /bin/git (found version "2.8.3") 

Configuring LMMS
--
* Build version   : 1.1.90-g1e7b8e9
*   Major version : 1
*   Minor version : 1
*   Patch version : 90
*   Suffix version: g1e7b8e9
*

Optional Version Usage:
--
*   Override version:   -DFORCE_VERSION=x.x.x-x
*   Disable hash suffix:-DFORCE_VERSION=internal

PROCESSOR: armv7l
Machine: armv7a-hardfloat-linux-gnueabi
Can't identify target host. Assuming 32 bit platform.

Error:

In file included from
/var/lib/abbs/build/tmp.VhyqJso79R/lmms/src/core/MixerWorkerThread.cpp:25:0:
/var/lib/abbs/build/tmp.VhyqJso79R/lmms/include/MixerWorkerThread.h: In
constructor 'MixerWorkerThread::JobQueue::JobQueue()':
/var/lib/abbs/build/tmp.VhyqJso79R/lmms/include/MixerWorkerThread.h:53:21:   in
constexpr expansion of 'QAtomicPointer(0u)'
/var/lib/abbs/build/tmp.VhyqJso79R/lmms/include/MixerWorkerThread.h:53:21:
internal compiler error: in cxx_eval_call_expression, at cp/constexpr.c:1449
m_opMode( Static )
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
src/CMakeFiles/lmmsobjs.dir/build.make:918: recipe for target
'src/CMakeFiles/lmmsobjs.dir/core/MixerWorkerThread.cpp.o' failed

-

GCC version information:

Using built-in specs.
COLLECT_GCC=/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/6.1.0/lto-wrapper
Target: armv7a-hardfloat-linux-gnueabi
Configured with: /var/lib/abbs/build/tmp.Mcu59I8oBl/gcc-6.1.0/configure
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info
--with-bugurl=https://github.com/AOSC-Dev/aosc-os-core
--enable-languages=c,c++,fortran,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-gnu-indirect-function
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --with-isl=/usr --enable-lto --enable-plugin
--enable-install-libiberty --disable-multilib --disable-werror
--enable-checking=release --with-default-libstdcxx-abi=gcc4-compatible
--with-linker-hash-style=gnu --disable-altivec --disable-fixed-point
--with-arch=armv7-a --with-float=hard --with-fpu=neon
--host=armv7a-hardfloat-linux-gnueabi --build=armv7a-hardfloat-linux-gnueabi
--target=armv7a-hardfloat-linux-gnueabi
Thread model: posix
gcc version 6.1.0 20160427 (AOSC OS, Core) (GCC)

[Bug middle-end/71581] [5/6/7 Regression] ICE on valid code on x86_64-linux-gnu with -Wuninitialized (Segmentation fault)

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-19
Summary|ICE on valid code on|[5/6/7 Regression] ICE on
   |x86_64-linux-gnu with   |valid code on
   |-Wuninitialized |x86_64-linux-gnu with
   |(Segmentation fault)|-Wuninitialized
   ||(Segmentation fault)
 Ever confirmed|0   |1

--- Comment #1 from Marc Glisse  ---
TREE_NO_WARNING (expr) where expr is NULL.

[Bug tree-optimization/71558] missed optimization for type short, char and floating point types

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-19
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
Confirmed.

[Bug sanitizer/71445] libsanitizer build failure on aarch64-linux-gnu with recent glibc

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #19 from Andrew Pinski  ---
Won't fix.  That is glibc patch was reverted.

[Bug middle-end/71318] Can't disable ISAs via function attribute

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Do you have an example?