[Bug testsuite/67905] running the libstdc++ testsuite as root removed /dev/null from my system

2015-10-08 Thread egall at gwmail dot gwu.edu 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67905

--- Comment #1 from Eric Gallager  ---
Actually, disregard my previous statement about mail-report.log being
incomplete; everything ended up in it, despite the messages printed while
making it. The part about it being un-emailable was still true though; it was
only after rebooting and /dev/null successfully being recreated that I was able
to send it, which ended up as
https://gcc.gnu.org/ml/gcc-testresults/2015-10/msg00910.html

[Bug middle-end/67891] [6 Regression] FAIL: gcc.dg/pr43300.c (internal compiler error) on alpha-linux-gnu

2015-10-08 Thread aoliva at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67891

--- Comment #2 from Alexandre Oliva  ---
Created attachment 36469
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36469&action=edit
Patch that works around the problem

Ugh.  assign_parms's use of emit_block_move (as for parameter a in this
testcase) marks decls as addressable that weren't before, so they no longer
pass is_gimple_reg in spite of having SSA defs.  This is turn causes
set_parm_rtl to pass the parm down to set_rtl, instead of the default def, so
the RTL isn't associated with the partition holding the default def.  Oops.

Fortunately, ssa_default_def doesn't seem to mind being called for addressable
decls, so we can just skip the is_gimple_reg test.  I'm testing further to see
that this is indeed the case.

[Bug middle-end/67891] [6 Regression] FAIL: gcc.dg/pr43300.c (internal compiler error) on alpha-linux-gnu

2015-10-08 Thread aoliva at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67891

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #1 from Alexandre Oliva  ---
Mine.  Looking into it.

[Bug testsuite/67905] New: running the libstdc++ testsuite as root removed /dev/null from my system

2015-10-08 Thread egall at gwmail dot gwu.edu 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67905

Bug ID: 67905
   Summary: running the libstdc++ testsuite as root removed
/dev/null from my system
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egall at gwmail dot gwu.edu
  Target Milestone: ---
  Host: i386-apple-darwin9.8.0
Target: i386-apple-darwin9.8.0
 Build: i386-apple-darwin9.8.0

Created attachment 36468
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36468&action=edit
what survived from `make mail-report.log`

So first of all, I know I should be more careful about running things as root,
but the gcc testsuite let me go ahead as root without complaint, so here I am.
Anyways, I ran `make -k check` in my builddir, and things were going pretty
normal until it got to the libstdc++ part, where everything blew up:

Test Run By root on Thu Oct  8 20:51:44 2015
Native configuration is i386-apple-darwin9.8.0

=== libstdc++ tests ===

Schedule of variations:
unix

Running target unix
Using /sw/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /sw/share/dejagnu/config/unix.exp as generic interface file for target.
Using /var/root/gcc-git/libstdc++-v3/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /var/root/gcc-git/libstdc++-v3/testsuite/libstdc++-abi/abi.exp ...
Running /var/root/gcc-git/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp
...
FAIL: 20_util/temporary_buffer.cc (test for excess errors)
[snip a large number of similar FAILs in between]
FAIL: 21_strings/basic_string/cons/char/1.cc (test for excess errors)
WARNING: program timed out.
ERROR: tcl error sourcing
/var/root/gcc-git/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp.
ERROR: sh: cannot redirect standard input from /dev/null: No such file or
directory
sh: /dev/null: Operation not supported
while executing
"exec sh -c "exec > /dev/null 2>&1 && (kill -2 $pgid || kill -2 $pid) && sleep
5 && (kill $pgid || kill $pid) && sleep 5 && (kill -9 $pgid || kill -9 $..."
invoked from within
"if [board_info ${host} exists fileid] {
set shell_id [board_info ${host} fileid]
set pid -1

verbose "Closing the remote shell $shell_id" 2
if [bo..."
(procedure "standard_close" line 4)
invoked from within
"standard_close "unix""
("eval" body line 1)
invoked from within
"eval ${try}_${proc} \"$dest\" $args"
(procedure "call_remote" line 33)
invoked from within
"call_remote "" close "$host""
(procedure "remote_close" line 3)
invoked from within
"remote_close $dest"
(procedure "saved_standard_wait" line 55)
invoked from within
"saved_standard_wait $dest $timeout"
(procedure "standard_wait" line 6)
invoked from within
"standard_wait "unix" 300"
("eval" body line 1)
invoked from within
"eval ${try}_${proc} \"$dest\" $args"
(procedure "call_remote" line 57)
invoked from within
"call_remote "" wait "unix" 300"
("eval" body line 1)
invoked from within
"eval call_remote \"\" wait \"$dest\" $timeout"
(procedure "remote_wait" line 2)
invoked from within
"remote_wait $dest 300"
invoked from within
"if ![is_remote $dest] {
if { "$inp" != "" } {
set command "$prog $parg < $inp"
} else {
set command "$prog $parg"
}

if ![info ex..."
(procedure "unix_load" line 25)
invoked from within
"unix_load "unix" ./1.exe {} {}"
("eval" body line 1)
invoked from within
"eval ${try}_${proc} \"$dest\" $args"
(procedure "call_remote" line 57)
invoked from within
"call_remote "" load "unix" "./1.exe" {} {}"
("eval" body line 1)
invoked from within
"eval call_remote \"\" load \"$dname\" \"$prog\" $args"
invoked from within
"if ![info exists result] {
set result [eval call_remote \"\" load \"$dname\" \"$prog\" $args]
# Not quite happy about the "pass" condition, but it m..."
(procedure "remote_load" line 66)
invoked from within
"remote_load target $program $program_args $input_file"
(procedure "libstdc++_load" line 13)
invoked from within
"${tool}_load $output_file"
invoked from within
"if ![file exists $output_file] {
warning "$name compilation failed to produce executable"
} else {
set status -1
set result [${tool}_l..."
(procedure "saved-dg-test" line 224)
invoked from within
"saved-dg-test
/var/root/gcc-git/libstdc++-v3/testsuite/21_strings/basic_string/cons/char/1.cc
{} { -include bits/stdc++.h}"
("eval" body line 1)
invoked from within
"eval saved-dg-test $args "
(procedure "dg-test" line 6)
invoked from within
"dg-test $testcase $flags ${default-extra-flags}"
(procedure "dg-ru

[Bug bootstrap/25470] [4.9/5/6 Regression] fixincludes/ subdirectory not cleaned by "make distclean"

2015-10-08 Thread egall at gwmail dot gwu.edu 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25470

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #22 from Eric Gallager  ---
This seems to be fixed; the only subdir that fails to distclean properly for me
currently is libcc1...

[Bug c++/67904] New: g++ crashes and asks for bugreport

2015-10-08 Thread namibj.der.echte at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67904

Bug ID: 67904
   Summary: g++ crashes and asks for bugreport
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: namibj.der.echte at gmail dot com
  Target Milestone: ---

Created attachment 36467
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36467&action=edit
compiler output

As the preprocessed source is to big to be included, I uploaded it therefore to
google drive (7 MB). https://googledrive.com/host/0B4TFIWqwdtVbMHBiVFVaLTB2S00
it had the name "MonCap.i"

Version  information:
root@bananapiCeph1 ~/ceph/src (git)-[hammer] # g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/5/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 5.2.1-17'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-armhf/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-armhf
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-armhf
--with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-sjlj-exceptions
--with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb
--enable-checking=release --build=arm-linux-gnueabihf
--host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 5.2.1 20150911 (Debian 5.2.1-17)

[Bug debug/65779] [5/6 Regression] undefined local symbol on powerpc [regression]

2015-10-08 Thread pangbw at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779

baoshan  changed:

   What|Removed |Added

 CC||pangbw at gmail dot com

--- Comment #9 from baoshan  ---
(In reply to Jakub Jelinek from comment #6)
>> I.e. not perform it at all if !MAY_HAVE_DEBUG_INSNS, and use D

There are some regression test cases would check if the generated RTL are same
with or without debug option enabled(like gcc.dg/pr45055.c), so if we perform
optimization depend on if there is debug instructions, these test cases would
fail. Will GCC community accept such patch with these regressions? I have a fix
that could fix this issue but with regression on pr45055.c, so far I am
hesitate if I can post it for review.

[Bug libstdc++/67903] New: std::locale compatibility between gcc4.9 and gcc5.1

2015-10-08 Thread ylow at graphlab dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67903

Bug ID: 67903
   Summary: std::locale compatibility between gcc4.9 and gcc5.1
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ylow at graphlab dot com
  Target Milestone: ---

Created attachment 36466
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36466&action=edit
patch to locale.cc

This is a complex issue and is probably an artifact of how we are doing our
linking. In general, I am not entirely confident of my diagnosis and it is hard
to replicate in a smaller test case.

In our code, we statically link libstdc++ into our shared library since that
resolves a lot of issues with dynamic libstdc++ since a different (older)
libstdc++ may be loaded before us.

However, there is some kind of conflict in std::locale static initialization
when:
 - There is a system libstdc++ from gcc 5.1 (i.e. a newer libstdc++)
   which creates a lot more facets
 - The system libstdc++ first (and initializes it)
 - Then our shared library loads and the following occurs:
- std::locale::_S_initialize_once() is called again.
  This is probably due to _S_once not being exported so
  so every occurance of the libstdc++ initializes again.
 - However, the local init implementation IS exported
- So the new init function is called, 
 - However, _S_global is NOT exported
- So the old object is used.

So to summarize,
- We have a repeat initialization of std::locale. Once in the new libstdc++
  and once in the old libstdc++ (this is actually OK)
- However, the new locale function initialization is used always which
causes issues since in gcc 5.1, the locale has more stuff: It fills 46 locales
into _M_facets rather than 28.

This would not be a problem if not for the fact that:
- the global locale is initialized with an inplace new:
 locale_init.cc:378
_M_facets = new (&facet_vec) const facet*[_M_facets_size];
_M_caches = new (&cache_vec) const facet*[_M_facets_size];
- the locale inserter (locale_init.cc:354) correctly checks when it should
extend the _M_facets, but happily just deletes the old array.
 locale.cc:348
delete [] __oldf;
delete [] __oldc;
- which of course fails gloriously with the inplace new.

- The solution is to actually do the resize correctly and check when we 
do not actually need to delete.

The attached patch does fix the problem.

[Bug libgcc/67902] New: Undefined negation in __divdi3

2015-10-08 Thread matthew.fernandez at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67902

Bug ID: 67902
   Summary: Undefined negation in __divdi3
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matthew.fernandez at gmail dot com
CC: joseph at codesourcery dot com
  Target Milestone: ---

As discussed on the GCC list, I believe the function __divdi3 performs a signed
negation that may be undefined behaviour.

In more detail: AIUI, signed 64-bit division can be emitted as a call to
software emulation in libgcc when the current target has no native hardware
support. For example, on 32-bit x86 this can mean signed 64-bit division
becomes a call to __divdi3. Internally, this function negates its operands if
they are negative. I believe this negation, in the case when either of the
operands is INT64_MIN is undefined behaviour. This seems to mean that a legal
operation like `INT64_MIN / INT64_MIN` inadvertently causes undefined
behaviour. Thus I believe __divdi3's implementation doesn't strictly comply
with the C standard.

There may be some disagreement about this as presumably GCC does the expected
thing when compiling this code and, as Joseph Myers has pointed out, the
shipped libgcc binaries are probably fine. However, I believe a compiler is
within its rights to transform `x = -x` into:

if (x == INT64_MIN) {
  // nasal demons
} else {
  x = -x;
}

Please let me know if I'm mistaken or if you need more information. If I'm
incorrect, apologies for taking up your time.

GCC commit: 03ca0c3cbd35930b7e08135e5f2ac069db22f7f7

[Bug fortran/67900] [4.9/5/6 Regression] Interface bug: Binding parameters to C causes a compiler segmentation fault.

2015-10-08 Thread kargl at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67900

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #1)
> The Ice appeared between revisions r199034 (2013-05-17):
> 
> pr67900.f90:4.33:
> 
> function f_real(x)
>  1
> pr67900.f90:9.36:
> 
> function f_integer(x)
> 2
> Error: Binding label 'x' at (1) collides with global entity 'x' at (2)
> 
> and r199221 (2013-05-17, ICE). Likely one of the revisions r199118, r199119,
> or r199120 (pr48858 and pr55465). I did not follow the convoluted arguments,
> but the code may be invalid: see the audit trail of the two PRs. Good Luck!
> 
> Backtrace
> 
> * thread #1: tid = 0x44d1226, 0x7fff90ac7bb0
> libsystem_platform.dylib`_platform_strcmp + 176, queue =
> 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
> frame #0: 0x7fff90ac7bb0 libsystem_platform.dylib`_platform_strcmp +
> 176
> libsystem_platform.dylib`_platform_strcmp:
> ->  0x7fff90ac7bb0 <+176>: movdqa (%rdi,%rcx), %xmm0
> 0x7fff90ac7bb5 <+181>: movdqu (%rsi,%rcx), %xmm1
> 0x7fff90ac7bba <+186>: pcmpeqb %xmm1, %xmm0
> 0x7fff90ac7bbe <+190>: pcmpeqb %xmm2, %xmm1
> (lldb) bt
> * thread #1: tid = 0x44d1226, 0x7fff90ac7bb0
> libsystem_platform.dylib`_platform_strcmp + 176, queue =
> 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
>   * frame #0: 0x7fff90ac7bb0 libsystem_platform.dylib`_platform_strcmp +
> 176
> frame #1: 0x000100094f17 f951`(sym=0x000141f09680)(gfc_symbol *)
> + 599 at resolve.c:10783
> frame #2: 0x0001000bedac
> f951`::do_traverse_symtree(st=, st_func=,
> sym_func=(f951`(null)(gfc_symbol *) at resolve.c:10735))(gfc_symtree *),
> void (*)(gfc_symbol *)) + 236 at symbol.c:3703
> frame #3: 0x0001000a7f54 f951`::resolve_types(ns=) +
> 1028 at resolve.c:15336
> frame #4: 0x0001000a3458 f951`gfc_resolve(ns=0x000142015400) +
> 56 at resolve.c:15416
> frame #5: 0x0001000a662f
> f951`::resolve_symbol(sym=0x000141f09550) + 8479 at resolve.c:13362
> frame #6: 0x0001000bedac
> f951`::do_traverse_symtree(st=, st_func=,
> sym_func=(f951`::resolve_symbol(gfc_symbol *) at
> resolve.c:13482))(gfc_symtree *), void (*)(gfc_symbol *)) + 236 at
> symbol.c:3703
> frame #7: 0x0001000a7d15 f951`::resolve_types(ns=0x00014480)
> + 453 at resolve.c:15306
> frame #8: 0x0001000a3458 f951`gfc_resolve(ns=0x00014480) +
> 56 at resolve.c:15416
> frame #9: 0x00010008c03b f951`gfc_parse_file() [inlined]
> resolve_all_program_units(gfc_global_ns_list=0x00014480) + 71 at
> parse.c:5485
> frame #10: 0x00010008bff4 f951`gfc_parse_file() + 1044
> frame #11: 0x0001000d19b6 f951`::gfc_be_parse_file() + 54 at
> f95-lang.c:209
> frame #12: 0x00010091e89a f951`::compile_file() + 58 at toplev.c:483
> frame #13: 0x000100cfddbc f951`toplev::main(int, char**) + 1151 at
> toplev.c:1973
> frame #14: 0x000100cfd93d f951`toplev::main(this=,
> argc=2, argv=0x7fff5fbff350) + 717
> frame #15: 0x000100cff779 f951`main(argc=2, argv=0x7fff5fbff350)
> + 41 at main.c:39

Patch

Index: resolve.c
===
--- resolve.c   (revision 228206)
+++ resolve.c   (working copy)
@@ -10702,7 +10702,7 @@ gfc_verify_binding_labels (gfc_symbol *s
   sym->binding_label = NULL;

 }
-  else if (sym->attr.flavor == FL_VARIABLE
+  else if (sym->attr.flavor == FL_VARIABLE && module
   && (strcmp (module, gsym->mod_name) != 0
   || strcmp (sym->name, gsym->sym_name) != 0))
 {

[Bug fortran/67900] [4.9/5/6 Regression] Interface bug: Binding parameters to C causes a compiler segmentation fault.

2015-10-08 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67900

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-08
Summary|Interface bug: Binding  |[4.9/5/6 Regression]
   |parameters to C causes a|Interface bug: Binding
   |compiler segmentation   |parameters to C causes a
   |fault.  |compiler segmentation
   ||fault.
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
The Ice appeared between revisions r199034 (2013-05-17):

pr67900.f90:4.33:

function f_real(x)
 1
pr67900.f90:9.36:

function f_integer(x)
2
Error: Binding label 'x' at (1) collides with global entity 'x' at (2)

and r199221 (2013-05-17, ICE). Likely one of the revisions r199118, r199119, or
r199120 (pr48858 and pr55465). I did not follow the convoluted arguments, but
the code may be invalid: see the audit trail of the two PRs. Good Luck!

Backtrace

* thread #1: tid = 0x44d1226, 0x7fff90ac7bb0
libsystem_platform.dylib`_platform_strcmp + 176, queue =
'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
frame #0: 0x7fff90ac7bb0 libsystem_platform.dylib`_platform_strcmp +
176
libsystem_platform.dylib`_platform_strcmp:
->  0x7fff90ac7bb0 <+176>: movdqa (%rdi,%rcx), %xmm0
0x7fff90ac7bb5 <+181>: movdqu (%rsi,%rcx), %xmm1
0x7fff90ac7bba <+186>: pcmpeqb %xmm1, %xmm0
0x7fff90ac7bbe <+190>: pcmpeqb %xmm2, %xmm1
(lldb) bt
* thread #1: tid = 0x44d1226, 0x7fff90ac7bb0
libsystem_platform.dylib`_platform_strcmp + 176, queue =
'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x7fff90ac7bb0 libsystem_platform.dylib`_platform_strcmp +
176
frame #1: 0x000100094f17 f951`(sym=0x000141f09680)(gfc_symbol *) +
599 at resolve.c:10783
frame #2: 0x0001000bedac f951`::do_traverse_symtree(st=,
st_func=, sym_func=(f951`(null)(gfc_symbol *) at
resolve.c:10735))(gfc_symtree *), void (*)(gfc_symbol *)) + 236 at
symbol.c:3703
frame #3: 0x0001000a7f54 f951`::resolve_types(ns=) + 1028
at resolve.c:15336
frame #4: 0x0001000a3458 f951`gfc_resolve(ns=0x000142015400) + 56
at resolve.c:15416
frame #5: 0x0001000a662f f951`::resolve_symbol(sym=0x000141f09550)
+ 8479 at resolve.c:13362
frame #6: 0x0001000bedac f951`::do_traverse_symtree(st=,
st_func=, sym_func=(f951`::resolve_symbol(gfc_symbol *) at
resolve.c:13482))(gfc_symtree *), void (*)(gfc_symbol *)) + 236 at
symbol.c:3703
frame #7: 0x0001000a7d15 f951`::resolve_types(ns=0x00014480) +
453 at resolve.c:15306
frame #8: 0x0001000a3458 f951`gfc_resolve(ns=0x00014480) + 56
at resolve.c:15416
frame #9: 0x00010008c03b f951`gfc_parse_file() [inlined]
resolve_all_program_units(gfc_global_ns_list=0x00014480) + 71 at
parse.c:5485
frame #10: 0x00010008bff4 f951`gfc_parse_file() + 1044
frame #11: 0x0001000d19b6 f951`::gfc_be_parse_file() + 54 at
f95-lang.c:209
frame #12: 0x00010091e89a f951`::compile_file() + 58 at toplev.c:483
frame #13: 0x000100cfddbc f951`toplev::main(int, char**) + 1151 at
toplev.c:1973
frame #14: 0x000100cfd93d f951`toplev::main(this=, argc=2,
argv=0x7fff5fbff350) + 717
frame #15: 0x000100cff779 f951`main(argc=2, argv=0x7fff5fbff350) +
41 at main.c:39

[Bug c++/67901] New: [concepts] overloading bug when considered more specialized vs more constrained

2015-10-08 Thread ryan.burn at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67901

Bug ID: 67901
   Summary: [concepts] overloading bug when considered more
specialized vs more constrained
   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 think the below code should compile. 

>From section 14.6.6.2:

Partial ordering selects which of two function templates is more specialized
than the other by transforming each template in turn (see next paragraph) and
performing template argument de- duction using the function type. The deduction
process determines whether one of the templates is more specialized than the
other. If so, the more specialized template is the one chosen by the partial
ordering process. If both deductions succeed, the partial ordering selects the
more
constrained template as described by the rules in 14.10.3.

And since the first version of apply_odd_arguments is more specialized, it
should be selected before considering which version is more constrained.

/
template  
  //requires true // works if uncommented   
decltype(auto) apply_odd_arguments(const Functor& functor,  
   ArgumentFirst argument_first,
   ArgumentSecond argument_second) {
  return functor(argument_first);   
}   

template
  requires sizeof...(ArgumentsRest) % 2 == 0
decltype(auto) apply_odd_arguments(const Functor& functor,  
   ArgumentFirst argument_first,
   ArgumentSecond argument_second,  
   ArgumentsRest... arguments_rest) {   
  return apply_odd_arguments([&](auto... arguments) {   
return functor(argument_first, arguments...);   
  }, arguments_rest...);
}   

int main() {
  auto f = [](int i1, int i2) { 
return i1+i2;   
  };
  apply_odd_arguments(f, 1, 2, 3, 4);   
  return 0; 
}
/

[Bug target/67383] reload_cse_simplify_operands fails on ARMV7-M

2015-10-08 Thread vmakarov at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67383

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #4 from Vladimir Makarov  ---
I've tried to reproduce it on gcc-4.9 branch as of today but failed.  The
problem with constraints and overlapped hard regs was probably fixed by
backported patches.

Still I have another problem:

../lib/mm/mm.c: In function ‘chunk_node’:
../lib/mm/mm.c:430:1: internal compiler error: in assign_by_spills, at
lra-assigns.c:1357
0x853dd5 assign_by_spills
/home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/lra-assigns.c:1357
0x854617 lra_assign()
/home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/lra-assigns.c:1503
0x84de9c lra(_IO_FILE*)
/home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/lra.c:2388
0x80ca16 do_reload
/home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/ira.c:5474
0x80ca16 rest_of_handle_reload
/home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/ira.c:5615
0x80ca16 execute
/home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/ira.c:5644
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

The problem is in assigning a hard reg to reload pseudo 442 for insns

 Choosing alt 0 in insn 153:  (0) =&r  (1) %0  (2) r {*arm_adddi3}
  Creating newreg=441, assigning class GENERAL_REGS to r441
  Creating newreg=442 from oldreg=268, assigning class GENERAL_REGS to r442
  153: {r441:DI=r441:DI+r442:DI;clobber cc:CC;}
  REG_DEAD r268:DI
  REG_UNUSED cc:CC
  REG_EQUIV [sp:SI+0x10]
Inserting insn reload before:
  642: r441:DI=[sp:SI+0x8]
  644: r442:DI=r268:DI
Inserting insn reload after:
  643: [sp:SI+0x10]=r441:DI

We canot use hard reg 0, 1, 2 as they live through insn 153:

 ...
  153: {r272:DI=r268:DI+r159:DI;clobber cc:CC;}
  REG_DEAD r268:DI
  REG_UNUSED cc:CC
  REG_EQUIV [sp:SI+0x10]
  ...
  159: call [`debug_printf'] argc:0x20
  REG_DEAD r1:SI
  REG_DEAD r0:SI
  REG_DEAD r2:DI

Hard reg 7 (FP), 9 (thread), 10 (pic), 13 (sp), 15 (pc) are fixed.  So
we have only one hole for DI value containing 2 regs (4, 5) and pair
(4,5) is assigned to 441 and there are no regs for 442.

By the way, reload pass also gives up for this case:

../lib/mm/mm.c:430:1: error: unable to find a register to spill in class
‘GENERAL_REGS’
../lib/mm/mm.c:430:1: error: this is the insn:
(insn 153 136 139 10 (parallel [
(set (reg:DI 272 [ D.9125 ])
(plus:DI (reg:DI 268 [ D.9125 ])
(reg:DI 159 [ D.9125 ])))
(clobber (reg:CC 100 cc))
]) ../lib/mm/mm.c:349 2 {*arm_adddi3}
 (expr_list:REG_DEAD (reg:DI 268 [ D.9125 ])
(expr_list:REG_UNUSED (reg:CC 100 cc)
(expr_list:REG_EQUIV (mem:DI (plus:SI (reg/f:SI 13 sp)
(const_int 16 [0x10])) [0  S8 A64])
(nil)

Interesting enough that LRA on the trunk has no such problem but I had no time
to figure why.

[Bug libgcc/67897] [mingw] Error compile for create libraries static in single user (2 CRITICAL BUGS)

2015-10-08 Thread rmbeer2 at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67897

--- Comment #2 from RM Beer  ---
ok, now pasted here.

LOG 1:

x86_64-w64-mingw32/libgcc/config.log:


This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by GNU C Runtime Library configure 1.0, which was
generated by GNU Autoconf 2.64.  Invocation command line was

  $ ${HOME}/src/gcc-5.2.0/libgcc/configure --srcdir=../../../libgcc
--cache-file=./config.cache --with-cross-host=i686-pc-linux-gnu
--prefix=${DEST}/GCC --libexecdir=${DEST}/GCC/lib --enable-shared
--enable-static --enable-threads=posix --enable-fully-dynamic-string
--enable-libstdcxx-time=yes --with-system-zlib --enable-cloog-backend=isl
--enable-lto --disable-dw2-exceptions --enable-libgomp --disable-multilib
--disable-checking --enable-languages=c,c++,fortran,lto,objc,obj-c++
--program-transform-name=s&^&x86_64-w64-mingw32-& --disable-option-checking
--with-target-subdir=x86_64-w64-mingw32 --build=i686-pc-linux-gnu
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32

## - ##
## Platform. ##
## - ##

hostname = ${HOST}
uname -m = i686
uname -r = 4.2.2-1-ARCH
uname -s = Linux
uname -v = #1 SMP PREEMPT Tue Sep 29 22:36:45 CEST 2015

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch  = unknown
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /usr/bin
PATH: /usr/lib/jvm/default/bin
PATH: /usr/bin/site_perl
PATH: /usr/bin/vendor_perl
PATH: /usr/bin/core_perl


## --- ##
## Core tests. ##
## --- ##

configure:2018: loading cache ./config.cache
configure:2232: checking build system type
configure:2246: result: i686-pc-linux-gnu
configure:2266: checking host system type
configure:2279: result: x86_64-w64-mingw32
configure:2382: checking for --enable-version-specific-runtime-libs
configure:2395: result: no
configure:2443: checking for a BSD-compatible install
configure:2511: result: /usr/bin/install -c
configure:2527: checking for gawk
configure:2554: result: gawk
configure:2654: checking for x86_64-w64-mingw32-ar
configure:2681: result: x86_64-w64-mingw32-ar
configure:2746: checking for x86_64-w64-mingw32-lipo
configure:2773: result: x86_64-w64-mingw32-lipo
configure:2838: checking for x86_64-w64-mingw32-nm
configure:2865: result: ${HOME}/src/gcc-5.2.0/Build/./gcc/nm
configure:2930: checking for x86_64-w64-mingw32-ranlib
configure:2957: result: x86_64-w64-mingw32-ranlib
configure:3022: checking for x86_64-w64-mingw32-strip
configure:3049: result: x86_64-w64-mingw32-strip
configure:3111: checking whether ln -s works
configure:3115: result: yes
configure:3132: checking for x86_64-w64-mingw32-gcc
configure:3159: result: ${HOME}/src/gcc-5.2.0/Build/./gcc/xgcc
-B${HOME}/src/gcc-5.2.0/Build/./gcc/ -L${DEST}/GCC/x86_64-w64-mingw32/lib
-L${DEST}/GCC/mingw/lib -isystem ${DEST}/GCC/x86_64-w64-mingw32/include
-isystem ${DEST}/GCC/mingw/include -B${DEST}/GCC/x86_64-w64-mingw32/bin/
-B${DEST}/GCC/x86_64-w64-mingw32/lib/ -isystem
${DEST}/GCC/x86_64-w64-mingw32/include -isystem
${DEST}/GCC/x86_64-w64-mingw32/sys-include   
configure:3428: checking for C compiler version
configure:3437: ${HOME}/src/gcc-5.2.0/Build/./gcc/xgcc
-B${HOME}/src/gcc-5.2.0/Build/./gcc/ -L${DEST}/GCC/x86_64-w64-mingw32/lib
-L${DEST}/GCC/mingw/lib -isystem ${DEST}/GCC/x86_64-w64-mingw32/include
-isystem ${DEST}/GCC/mingw/include -B${DEST}/GCC/x86_64-w64-mingw32/bin/
-B${DEST}/GCC/x86_64-w64-mingw32/lib/ -isystem
${DEST}/GCC/x86_64-w64-mingw32/include -isystem
${DEST}/GCC/x86_64-w64-mingw32/sys-include--version >&5
xgcc (GCC) 5.2.0
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.

configure:3448: $? = 0
configure:3437: ${HOME}/src/gcc-5.2.0/Build/./gcc/xgcc
-B${HOME}/src/gcc-5.2.0/Build/./gcc/ -L${DEST}/GCC/x86_64-w64-mingw32/lib
-L${DEST}/GCC/mingw/lib -isystem ${DEST}/GCC/x86_64-w64-mingw32/include
-isystem ${DEST}/GCC/mingw/include -B${DEST}/GCC/x86_64-w64-mingw32/bin/
-B${DEST}/GCC/x86_64-w64-mingw32/lib/ -isystem
${DEST}/GCC/x86_64-w64-mingw32/include -isystem
${DEST}/GCC/x86_64-w64-mingw32/sys-include-v >&5
Reading specs from ${HOME}/src/gcc-5.2.0/Build/./gcc/specs
COLLECT_GCC=${HOME}/src/gcc-5.2.0/Build/./gcc/xgcc
COLLECT_LTO_WRAPPER=${HOME}/src/gcc-5.2.0/Build/./gcc/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../configure --prefix=${DEST}/GCC --libexecdir=${DEST}/GCC/lib
--target=x86_64-w64-mingw32 --enable-languages=c,lto,c++,objc,obj-c++,fortran
--enable-shared --enable-static --enable-threads=posix
--enable-fully-dynamic-string --enable-libstdcxx-time=yes --with-system-zlib
--enable-cloog-backend=isl --enable-lto --di

[Bug fortran/67900] New: Interface bug: Binding parameters to C causes a compiler segmentation fault.

2015-10-08 Thread giorgianb at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67900

Bug ID: 67900
   Summary: Interface bug: Binding parameters to C causes a
compiler segmentation fault.
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: giorgianb at gmail dot com
  Target Milestone: ---

Created attachment 36465
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36465&action=edit
Compiling this file will cause the compiler to segmentation fault.

A simple interface declaration in which the parameter names are the same and
are binding to C causes the compiler to segfault. Usually when declaring a
generic interface that does the same operation on varied types, it is good
practice to give the parameters the same name.

The program:

program main
implicit none
interface f
function f_real(x)
real, bind(c) :: x
real :: f_real
end function f_real

function f_integer(x)
integer, bind(c) :: x
integer :: f_integer
end function f_integer
end interface f
end program main

Info about gcc:

$ gcc --version
gcc (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)
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.

Basic machine info:
$ uname -a
Linux localhost.localdomain 4.1.8-200.fc22.x86_64 #1 SMP Tue Sep 22 12:13:21
UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

[Bug libgcc/67897] [mingw] Error compile for create libraries static in single user (2 CRITICAL BUGS)

2015-10-08 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67897

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-10-08
 Ever confirmed|0   |1
   Severity|critical|normal

--- Comment #1 from Andrew Pinski  ---
Can you attach the full config.log ?  The problem is most likely xgcc -E is
failing too and then trying /lib/cpp instead.

[Bug sanitizer/67899] New: build failure in the sanitizer libs on sparc-linux-gnu

2015-10-08 Thread aaro.koskinen at iki dot fi 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67899

Bug ID: 67899
   Summary: build failure in the sanitizer libs on sparc-linux-gnu
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aaro.koskinen at iki dot fi
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

Sanitizer lib build is broken on sparc-linux-gnu:

libtool: compile:  /build/los/work/sparc/gcc-full-5.2.0-build/./gcc/xgcc
-shared-libgcc -B/build/los/work/sparc/gcc-full-5.2.0-build/./gcc -nostdinc++
-L/build/los/work/sparc/gcc-full-5.2.0-build/sparc-linux-gnu/libstdc++-v3/src
-L/build/los/work/sparc/gcc-full-5.2.0-build/sparc-linux-gnu/libstdc++-v3/src/.libs
-L/build/los/work/sparc/gcc-full-5.2.0-build/sparc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/build/los/work/sparc/toolchain/sparc-linux-gnu/bin/
-B/build/los/work/sparc/toolchain/sparc-linux-gnu/lib/ -isystem
/build/los/work/sparc/toolchain/sparc-linux-gnu/include -isystem
/build/los/work/sparc/toolchain/sparc-linux-gnu/sys-include -D_GNU_SOURCE
-D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-DHAVE_RPC_XDR_H=1 -DHAVE_TIRPC_RPC_XDR_H=0 -I.
-I/build/los/work/shared/gcc-5.2.0/libsanitizer/sanitizer_common -I.. -I
/build/los/work/shared/gcc-5.2.0/libsanitizer/include -isystem
/build/los/work/shared/gcc-5.2.0/libsanitizer/include/system -Wall -W
-Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC
-fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables
-fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/sparc-linux-gnu
-I/build/los/work/shared/gcc-5.2.0/libsanitizer/../libstdc++-v3/libsupc++
-std=gnu++11 -DSANITIZER_LIBBACKTRACE -DSANITIZER_CP_DEMANGLE -I
/build/los/work/shared/gcc-5.2.0/libsanitizer/../libbacktrace -I
../libbacktrace -I /build/los/work/shared/gcc-5.2.0/libsanitizer/../include
-include
/build/los/work/shared/gcc-5.2.0/libsanitizer/libbacktrace/backtrace-rename.h
-g -O2 -D_GNU_SOURCE -MT sanitizer_platform_limits_posix.lo -MD -MP -MF
.deps/sanitizer_platform_limits_posix.Tpo -c
/build/los/work/shared/gcc-5.2.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
 -fPIC -DPIC -o .libs/sanitizer_platform_limits_posix.o
In file included from
/build/los/work/shared/gcc-5.2.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:180:0:
/build/los/work/shared/gcc-5.2.0/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:272:72:
error: size of array 'assertion_failed__990' is negative
 typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
^
/build/los/work/shared/gcc-5.2.0/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:266:30:
note: in expansion of macro 'IMPL_COMPILER_ASSERT'
 #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__)
  ^
/build/los/work/shared/gcc-5.2.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:990:1:
note: in expansion of macro 'COMPILER_CHECK'
 COMPILER_CHECK(sizeof(__sanitizer_sigaction) == sizeof(struct sigaction));
 ^
/build/los/work/shared/gcc-5.2.0/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:272:72:
error: size of array 'assertion_failed__994' is negative
 typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
^
/build/los/work/shared/gcc-5.2.0/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:266:30:
note: in expansion of macro 'IMPL_COMPILER_ASSERT'
 #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__)
  ^
/build/los/work/shared/gcc-5.2.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h:1353:3:
note: in expansion of macro 'COMPILER_CHECK'
   COMPILER_CHECK(offsetof(struct __sanitizer_##CLASS, MEMBER) ==  \
   ^
/build/los/work/shared/gcc-5.2.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:994:1:
note: in expansion of macro 'CHECK_STRUCT_SIZE_AND_OFFSET'
 CHECK_STRUCT_SIZE_AND_OFFSET(sigaction, sa_flags);
 ^
/build/los/work/shared/gcc-5.2.0/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:272:72:
error: size of array 'assertion_failed__996' is negative
 typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
^
/build/los/work/shared/gcc-5.2.0/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:266:30:
note: in expansion of macro 'IMPL_COMPILER_ASSERT'
 #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__)
  ^
/build/los/work/share

[Bug c++/67898] New: rejects-valid on overloaded function as non-type template argument of dependent type

2015-10-08 Thread richard-gccbugzilla at metafoo dot co.uk 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67898

Bug ID: 67898
   Summary: rejects-valid on overloaded function as non-type
template argument of dependent type
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk
  Target Milestone: ---

Test case:

  void f(int);
  void f(float);
  template struct X {};
  template void test() { X(); }
  int main() { test(); }

GCC rejects this valid code saying:

  :4:51: error: ‘void(T)’ is not a valid type for a template non-type
parameter
  :4:51: error: ‘void(T)’ is not a valid type for a template non-type
parameter
  :4:51: error: template argument 4 is invalid

If we work around this bug by changing the code as follows:

  template void test() { X(); }

... then we get a different rejects-valid:

  :3:43: error: invalid operands of types ‘’ and ‘’ to binary
‘operator==’
  :4:54: error: template argument 4 is invalid

[Bug libgcc/67897] New: [mingw] Error compile for create libraries static in single user (2 CRITICAL BUGS)

2015-10-08 Thread rmbeer2 at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67897

Bug ID: 67897
   Summary: [mingw] Error compile for create libraries static in
single user (2 CRITICAL BUGS)
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rmbeer2 at gmail dot com
  Target Milestone: ---

I use the Archlinux System, with all libraries of gcc, mingw-32 and mingw-64 in
correct function.

I need recompile the new files of mingw-64 for create static libraries that i
not have.

I create a new path in single user count, and change the DEST for destination
installation and HOME for getting source code. Using this configure line
(getting from PKGBUILD, with any modifications, remove the ada and disable all
chekings):


$ ../configure --prefix=${DEST}/GCC --libexecdir=${DEST}/GCC/lib \
--target=x86_64-w64-mingw32 \
--enable-languages=c,lto,c++,objc,obj-c++,fortran \
--enable-shared --enable-static \
--enable-threads=posix --enable-fully-dynamic-string
--enable-libstdcxx-time=yes \
--with-system-zlib --enable-cloog-backend=isl \
--enable-lto --disable-dw2-exceptions --enable-libgomp \
--disable-multilib --disable-checking
:
:
:
$ make
:
:
:
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether ${HOME}/src/gcc-5.2.0/Build/./gcc/xgcc
-B${HOME}/src/gcc-5.2.0/Build/./gcc/ -L${DEST}/GCC/x86_64-w64-mingw32/lib
-L${DEST}/GCC/mingw/lib -isystem ${DEST}/GCC/x86_64-w64-mingw32/include
-isystem ${DEST}/GCC/mingw/include -B${DEST}/GCC/x86_64-w64-mingw32/bin/
-B${DEST}/GCC/x86_64-w64-mingw32/lib/ -isystem
${DEST}/GCC/x86_64-w64-mingw32/include -isystem
${DEST}/GCC/x86_64-w64-mingw32/sys-includeaccepts -g... yes
checking for ${HOME}/src/gcc-5.2.0/Build/./gcc/xgcc
-B${HOME}/src/gcc-5.2.0/Build/./gcc/ -L${DEST}/GCC/x86_64-w64-mingw32/lib
-L${DEST}/GCC/mingw/lib -isystem ${DEST}/GCC/x86_64-w64-mingw32/include
-isystem ${DEST}/GCC/mingw/include -B${DEST}/GCC/x86_64-w64-mingw32/bin/
-B${DEST}/GCC/x86_64-w64-mingw32/lib/ -isystem
${DEST}/GCC/x86_64-w64-mingw32/include -isystem
${DEST}/GCC/x86_64-w64-mingw32/sys-includeoption to accept ISO C89...
unsupported
checking how to run the C preprocessor... /lib/cpp
configure: error: in `${HOME}/src/gcc-5.2.0/Build/x86_64-w64-mingw32/libgcc':
configure: error: C preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details.
Makefile:11661: fallo en las instrucciones para el objetivo
'configure-target-libgcc'
make[1]: *** [configure-target-libgcc] Error 1
make[1]: se sale del directorio '${HOME}/src/gcc-5.2.0/Build'
Makefile:871: fallo en las instrucciones para el objetivo 'all'
make: *** [all] Error 2




Checking this log:

CONFIG.LOG: x86_64-w64-mingw32/libgcc/config.log

configure:3993: result: /lib/cpp
configure:4013: /lib/cpp  conftest.c
${HOME}/src/gcc-5.2.0/libgcc/configure: line 1476: /lib/cpp: No such file or
directory
configure:4013: $? = 127
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/";
| /* end confdefs.h.  */
| #ifdef __STDC__
| # include 
| #else
| # include 
| #endif
|Syntax error






In this error getting that not have the "/lib/cpp" file for GCC. Linked the
cc1plus binarie from /usr/lib to /lib/cpp. Now getting always this lines:


configure: error: C preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details.
Makefile:11661: recipe for target 'configure-target-libgcc' failed
make[1]: *** [configure-target-libgcc] Error 1




but with this config.log:

CONFIG.LOG: x86_64-w64-mingw32/libgcc/config.log

configure:4013: /lib/cpp  conftest.c
 void __debugbreak()
conftest.c: At global scope:
conftest.c:14:8: error: 'Syntax' does not name a type
Syntax error
^

Analyzing compilation unit

Execution times (seconds)
 phase setup :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 (100%) wall
833 kB (56%) ggc
 TOTAL :   0.00 0.00 0.01  
1492 kB
configure:4013: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/";
| /* end confdefs.h.  */
| #ifdef __STDC__
| # include 
| #else
| # include 
| #endif
|Syntax error






I not found the conftest.c.

I found two bugs:

1) I want need compiler all gcc in single user for

[Bug go/66870] split stack issues on ppc64le and ppc64

2015-10-08 Thread boger at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870

--- Comment #31 from boger at gcc dot gnu.org ---
Author: boger
Date: Thu Oct  8 19:21:45 2015
New Revision: 228623

URL: https://gcc.gnu.org/viewcvs?rev=228623&root=gcc&view=rev
Log:
Backport of rev 228311

PR target/66870
* config/rs6000/sysv4.h (TARGET_CAN_SPLIT_STACK_64BIT): Define.
* configure.ac: Define HAVE_GOLD_ALTERNATE_SPLIT_STACK on Power
based on gold linker version.
* gcc.c: Add -fuse-ld=gold to STACK_SPLIT_SPEC if
HAVE_GOLD_ALTERNATE_SPLIT_STACK defined.
* configure, config.in: Regenerate.
go:
* gospec.c (lang_specific_driver): Set appropriate split stack
options for 64 bit compiles based on TARGET_CAN_SPLIT_STACK_64BIT.



Modified:
branches/ibm/gcc-5-branch/gcc/config.in
branches/ibm/gcc-5-branch/gcc/config/rs6000/linux64.h
branches/ibm/gcc-5-branch/gcc/config/rs6000/sysv4.h
branches/ibm/gcc-5-branch/gcc/configure
branches/ibm/gcc-5-branch/gcc/configure.ac
branches/ibm/gcc-5-branch/gcc/gcc.c
branches/ibm/gcc-5-branch/gcc/go/gospec.c

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

2015-10-08 Thread gk at torproject dot org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67876

--- Comment #2 from Georg Koppen  ---
Created attachment 36464
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36464&action=edit
Preprocessed file for Unified_cpp_certverifier0.cpp

Attached is the compressed preprocessed file. FWIW: GCC 5.2.0 is not affected
either.

[Bug target/67896] New: Inconsistent behaviour between C and C++ for types poly8x8_t and poly16x8_t

2015-10-08 Thread roger.ferrer at bsc dot es 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67896

Bug ID: 67896
   Summary: Inconsistent behaviour between C and C++ for types
poly8x8_t and poly16x8_t
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roger.ferrer at bsc dot es
  Target Milestone: ---
Target: aarch64-linux-gnu

Hi,

aarch64-linux-gnu-gcc is able to distinguish Neon poly types "poly8x8_t" and
"poly16x8_t" but aarch64-linux-gnu-g++ seems it can't.

The following snippet

-- test.c
#include  

void f(poly8x8_t *a, poly16x8_t *b)
{
a = b;
}
-- end of test.c

triggers a warning in C

$ aarch64-linux-gnu-gcc -Wall -c test.c
test.c: In function ‘f’:
test.c:5:7: warning: assignment from incompatible pointer type
[-Wincompatible-pointer-types]
 a = b;
   ^

but is accepted without complaints in C++

$ aarch64-linux-gnu-g++ -x c++ -Wall -c test.c


A more elaborated C++11 testcase reveals that these two types are mostly equal
except for sizeof.

-- testcxx11.cc
#include 

typedef poly8x8_t T;
typedef poly16x8_t T; // this is OK in C++ if they are the same type

template 
struct Equal;

template 
struct Equal
{
typedef int X;
};

Equal::X x;

static_assert(sizeof(poly8x8_t) == sizeof(poly16x8_t), "");
-- end of testcxx11.cc

In this example, g++ only complains about their sizeof being different (8 and
16 respectively)

$ aarch64-linux-gnu-g++ -Wall -std=c++11 -c testcxx11.cc 
testcxx11.cc:17:1: error: static assertion failed: 
 static_assert(sizeof(poly8x8_t) == sizeof(poly16x8_t), "");
 ^

Kind regards,

[Bug libstdc++/65913] [5 Regression] Linking failure without -latomic

2015-10-08 Thread redi at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65913

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #10 from Jonathan Wakely  ---
Fixed for 5.3 too.

[Bug libstdc++/65913] [5 Regression] Linking failure without -latomic

2015-10-08 Thread redi at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65913

--- Comment #9 from Jonathan Wakely  ---
Author: redi
Date: Thu Oct  8 16:54:23 2015
New Revision: 228615

URL: https://gcc.gnu.org/viewcvs?rev=228615&root=gcc&view=rev
Log:
Backport PR libstdc++/65913 fix from mainline.

Handle alignment in __atomic_is_lock_free

gcc:

2015-09-17  Richard Henderson  

PR libstdc++/65913
* builtins.c (fold_builtin_atomic_always_lock_free): Handle fake
pointers that encode the alignment of the object.

libstdc++-v3:

2015-09-17  Jonathan Wakely  

PR libstdc++/65913
* include/bits/atomic_base.h (__atomic_base<_TTp>::is_lock_free(),
__atomic_base<_PTp*>::is_lock_free()): Call the built-in with the
immediate pointer value, not a variable.
* include/std/atomic (atomic::is_lock_free()): Likewise.
* testsuite/29_atomics/atomic/65913.cc: New.

Added:
branches/gcc-5-branch/libstdc++-v3/testsuite/29_atomics/atomic/65913.cc
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/builtins.c
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/include/bits/atomic_base.h
branches/gcc-5-branch/libstdc++-v3/include/std/atomic

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

2015-10-08 Thread manu at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67192

--- Comment #15 from Manuel López-Ibáñez  ---
(In reply to Andreas Arnez from comment #11)
> Any news here?  AFAIK the problem still exists.

I still think the solution in comment #10 is the least invasive without being a
hack. But someone (you?) would need to submit a patch and get it approved by
the C maintainers.

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

2015-10-08 Thread manu at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67192

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

--- Comment #14 from Manuel López-Ibáñez  ---
Regression must have a target milestone (otherwise various scripts would not
recognize them as such, I think).

[Bug c/64868] C front-end rejects valid syntax.

2015-10-08 Thread tschwinge at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64868

--- Comment #5 from Thomas Schwinge  ---
Anything left to be done here?

[Bug c/64765] [OpenACC] Bogus "'copy' is not valid for '#pragma acc kernels loop'"

2015-10-08 Thread tschwinge at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64765

Thomas Schwinge  changed:

   What|Removed |Added

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

[Bug c/64880] OpenACC gcc/g++ Discrepancy

2015-10-08 Thread tschwinge at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64880

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-10-08
  Component|libgomp |c
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
 Ever confirmed|0   |1

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

2015-10-08 Thread jamborm at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67794

--- Comment #7 from Martin Jambor  ---
I have proposed a fix on the mailing list:

https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00858.html

[Bug c/41517] Unexpected behaviour of #pragma in statement context

2015-10-08 Thread jan.echternach at de dot gbs.com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41517

Jan Echternach  changed:

   What|Removed |Added

 CC||jan.echternach at de dot 
gbs.com

--- Comment #1 from Jan Echternach  ---
I can confirm this bug in gcc 4.9 (Debian 4.9.2-10). A different example which
also produces wrong code (should return 0, but returns 1):

//#include 
int main ()
{
if (0)
#pragma GCC diagnostic ignored "-Wtype-limits"
{
//printf ("bug\n");
return 1;
}
//printf ("ok\n");
return 0;
}

And an example that fails to compile ("error: ‘else’ without a previous ‘if’"):

void foo (void)
{
if (0)
#pragma GCC diagnostic ignored "-Wtype-limits"
{}
else {}
}

[Bug c++/67557] [4.9/5/6 regression] Calling copy constructor of base class in constructor of derived class produces crashing code

2015-10-08 Thread jason at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67557

--- Comment #13 from Jason Merrill  ---
Author: jason
Date: Thu Oct  8 14:42:02 2015
New Revision: 228602

URL: https://gcc.gnu.org/viewcvs?rev=228602&root=gcc&view=rev
Log:
PR c++/67557

* call.c (is_base_field_ref): New.
(unsafe_copy_elision_p): New.
(build_over_call): Use it.

Added:
trunk/gcc/testsuite/g++.dg/init/elide3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug libstdc++/67843] experimental/filesystem/iterators/directory_iterator.cc fails on armv5t

2015-10-08 Thread clyon at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67843

--- Comment #7 from Christophe Lyon  ---
You are probably correct: I recompiled my cross-toolchain to default to armv5t
and the test now passes.

(as opposed to armv7-a toolchain + -march=armv5t to compile the testcase).

I agree that a linker error would be good, though I don't fully understand your
patch :-)

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

2015-10-08 Thread ubizjak at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67124

--- Comment #13 from Uroš Bizjak  ---
Almost identical problem is reported in PR 67609, but with:

(insn 7 6 0 (set (subreg:DF (reg/v:TI 90 [ v ]) 0)
(reg/v:DF 88 [ b ])) pr67609.c:8 -1
 (nil))

[Bug target/67895] New: Wrong assembly: incorrect rounding/SAE specifier position

2015-10-08 Thread afomin.mailbox at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67895

Bug ID: 67895
   Summary: Wrong assembly: incorrect rounding/SAE specifier
position
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: assemble-failure, wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: afomin.mailbox at gmail dot com
CC: kyukhin at gcc dot gnu.org
  Target Milestone: ---
Target: i?86-*-*, x86_64-*-*

Trying to assemble avx512dq-vrange*.c tests from gcc.target/i386 testsuite
using GNU as v2.25 or higher results in a number of errors like:

RC/SAE operand must follow immediate operands for `vrange*`.

Same thing happens for avx512f-vcvt?si2*.c tests (but error message is slightly
different):
operand type mismatch for `vcvt?si2*'.

The reason is that GCC emits an insn with rounding/SAE specifier in a wrong
place.

[Bug rtl-optimization/67749] FAIL: gcc.dg/ifcvt-2.c scan-rtl-dump ce1 "3 true changes made"

2015-10-08 Thread ktkachov at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67749

--- Comment #4 from ktkachov at gcc dot gnu.org ---
(In reply to Uroš Bizjak from comment #3)
> Please note that with -m32 we have additional testsuite FAIL [1] with
> ifcvt-3.c:
> 
> FAIL: gcc.dg/ifcvt-2.c scan-rtl-dump ce1 "3 true changes made"
> FAIL: gcc.dg/ifcvt-3.c scan-rtl-dump ce1 "3 true changes made"
> 
> [1] https://gcc.gnu.org/ml/gcc-testresults/2015-10/msg00812.html

Yes, the ifcvt-3.c failure is PR 67462.
But there it's a costs decision, and I'm inclined to skip that test for
x86/-m32

[Bug fortran/67894] New: bounds of assumed-rank dummy argument not equal to actual argument

2015-10-08 Thread john.donners at surfsara dot nl 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67894

Bug ID: 67894
   Summary: bounds of assumed-rank dummy argument not equal to
actual argument
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.donners at surfsara dot nl
  Target Milestone: ---

the draft Fortran 2015 standard reads:

An actual argument of any rank may correspond to an assumed-rank dummy
argument. The rank and shape of the dummy argument are the rank and shape of 
the corresponding actual argument. If the rank is nonzero, the lower and upper 
bounds of the dummy argument are those that would be given by the intrinsic 
functions LBOUND and UBOUND respectively if applied to the actual argument, 
except that when the actual argument is assumed-size, the upper bound of the 
last dimension of the dummy argument is 2 less than the lower bound of
that dimension.

(section 12.5.2.4, paragraph 15)

Here is a small test program:

program assumedrank
 implicit none
 real,dimension(:,:,:),allocatable :: bb
 real,dimension(3:9,10:15,16:32) :: c

 allocate(bb(3:9,10:15,16:32))
 print*, 'Actual argument, allocatable, lbound=',lbound(bb)
 call p(bb)
 print*, 'Actual argument, lbound=',lbound(c)
 call p(c)

 contains

 subroutine p(a)
  real,dimension(..) :: a
  print*,'Dummy argument, lbound=',lbound(a)

 end subroutine p

end

gfortran 5.2.0 returns 1 1 1 as the lower bounds, both for the allocatable and
the fixed-shape array.

[Bug rtl-optimization/67749] FAIL: gcc.dg/ifcvt-2.c scan-rtl-dump ce1 "3 true changes made"

2015-10-08 Thread ubizjak at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67749

--- Comment #3 from Uroš Bizjak  ---
Please note that with -m32 we have additional testsuite FAIL [1] with
ifcvt-3.c:

FAIL: gcc.dg/ifcvt-2.c scan-rtl-dump ce1 "3 true changes made"
FAIL: gcc.dg/ifcvt-3.c scan-rtl-dump ce1 "3 true changes made"

[1] https://gcc.gnu.org/ml/gcc-testresults/2015-10/msg00812.html

[Bug rtl-optimization/67749] FAIL: gcc.dg/ifcvt-2.c scan-rtl-dump ce1 "3 true changes made"

2015-10-08 Thread ktkachov at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67749

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
I'm working on it.
Testing a patch.

This is a missed-optimization rather than wrong-code

[Bug rtl-optimization/67749] FAIL: gcc.dg/ifcvt-2.c scan-rtl-dump ce1 "3 true changes made"

2015-10-08 Thread izamyatin at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67749

Igor Zamyatin  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #1 from Igor Zamyatin  ---
Any progress on this?

[Bug translation/67892] [5/6 Regression] Wrong code at -O1 and above

2015-10-08 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67892

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.9.3
   Keywords||wrong-code
   Last reconfirmed||2015-10-08
 CC||law at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Wrong code at -O1 and above |[5/6 Regression] Wrong code
   ||at -O1 and above
   Target Milestone|--- |5.3

--- Comment #1 from Richard Biener  ---
Confirmed.  Sounds like a FSM threading bug, confirmed on trunk as well.

[Bug other/67893] [5 Regression] memory hog building a C++ file (on x86_64-linux-gnu)

2015-10-08 Thread doko at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67893

--- Comment #3 from Matthias Klose  ---
> What's the second preprocessed source from?

the same .cpp file built with gcc-4.9.

[Bug other/67893] [5 Regression] memory hog building a C++ file (on x86_64-linux-gnu)

2015-10-08 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67893

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-08
Version|6.0 |5.2.1
   Target Milestone|--- |5.3
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Can't yet confirm the regression (need to look for a bigger box...) but I can
confirm it uses >2GB even with plain -O2.  Note that -O2 has quite some
quadratic algorithms.

As even plain -O1 goes up to 2GB my usual suspect would be DF.

Note that with -O1 frontend processing peaks at 600MB and after gimplification
and lowering we are at 1GB - so this is a huge CU in the first place.  Early
opts plus IPA get us to 2GB already (same at -O2).

What's the second preprocessed source from?

Confirmed as memory-hog though.

Unfortunately as the testcase is so large it's hard to work with it but it
looks
like we gradually leak memory during late optimization/expansion, there are no
"big" functions in the end it seems.

Btw, the gcc 5 branch at r228565 peaks at 2.3GB with -O2, -g adds that other
1.2GB (hello var-tracking and VTA).

[Bug target/56592] [SH] Add vector ABI

2015-10-08 Thread olegendo at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56592

--- Comment #3 from Oleg Endo  ---
Maybe also interesting: __attribute__((vector)) (function attribute)

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

2015-10-08 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67124

Richard Biener  changed:

   What|Removed |Added

  Component|target  |rtl-optimization

--- Comment #12 from Richard Biener  ---
Hmm, indeed we fail to preserve the (subreg:DI (reg:TI xmm0)) in LRA

(insn 53 52 16 2 (set (reg:DI 21 xmm0 [orig:90 c ] [90])
(mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])) [0 %sfp+-8 S8 A64])) t.c:16 85
{*movdi_internal}
 (nil))
...
(insn 17 16 49 2 (set (reg:V8HI 21 xmm0 [100])
(vec_merge:V8HI (vec_duplicate:V8HI (reg:HI 0 ax [99]))
(reg:V8HI 21 xmm0 [orig:90 c ] [90])
(const_int 4 [0x4]))) t.c:16 3597 {sse2_pinsrw}
 (nil))

from

(insn 15 14 16 2 (parallel [
(set (subreg:DI (reg/v:TI 90 [ c ]) 0)
(ior:DI (reg:DI 97)
(reg:DI 95)))
(clobber (reg:CC 17 flags))
]) t.c:16 398 {*iordi_1}
 (expr_list:REG_DEAD (reg:DI 97)
(expr_list:REG_DEAD (reg:DI 95)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)
...
(insn 17 16 49 2 (set (reg:V8HI 100)
(vec_merge:V8HI (vec_duplicate:V8HI (subreg:HI (reg:DI 99) 0))
(subreg:V8HI (reg/v:TI 90 [ c ]) 0)
(const_int 4 [0x4]))) t.c:16 3597 {sse2_pinsrw}

A plain DImode move to a DImode reg does not preserve the upper halves.  Not
sure if

(insn 53 52 16 2 (set (subreg:DI (reg:TI xmm0 0) [orig:90 c ] [90])
(mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])) [0 %sfp+-8 S8 A64])) t.c:16 85
{*movdi_internal}
 (nil))

would be valid after "reload" though.

Maybe the bug is that we allocate a DImode register to a subreg of a TImode
destination at all.

[Bug c++/67888] Compiling clang 3.7.0 results in is used but never defined

2015-10-08 Thread redi at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67888

--- Comment #5 from Jonathan Wakely  ---
I don't know what fixed it, or if it's worth backporting.

[Bug c++/67888] Compiling clang 3.7.0 results in is used but never defined

2015-10-08 Thread redi at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67888

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-08
  Known to work||6.0
 Ever confirmed|0   |1
  Known to fail||4.9.4, 5.2.0

--- Comment #4 from Jonathan Wakely  ---
Reduced:

namespace std {

template  struct  remove_reference {typedef _Tp type;};
template  struct  remove_reference<_Tp&> {typedef _Tp type;};
template  struct  remove_reference<_Tp&&> {typedef _Tp type;};

template 
inline
_Tp&&
forward(typename std::remove_reference<_Tp>::type& __t) throw()
{
return static_cast<_Tp&&>(__t);
}

template 
inline
_Tp&&
forward(typename std::remove_reference<_Tp>::type&& __t) throw()
{
return static_cast<_Tp&&>(__t);
}

template class function;

namespace __function
{

template class __base;

template
class __base<_Rp(_ArgTypes...)>
{
public:
virtual _Rp operator()(_ArgTypes&& ...) = 0;
};

template class __func;

template
class __func<_Fp, _Alloc, _Rp(_ArgTypes...)>
: public __base<_Rp(_ArgTypes...)>
{
public:
virtual _Rp operator()(_ArgTypes&& ... __arg);
};



template
_Rp
__func<_Fp, _Alloc, _Rp(_ArgTypes...)>::operator()(_ArgTypes&& ... __arg)
{
return {};
}
}

template
class function<_Rp(_ArgTypes...)>
{
typedef __function::__base<_Rp(_ArgTypes...)> __base;
__base* __f_;

public:

template
  function(_Fp);

_Rp operator()(_ArgTypes...) const;
};


template
template 
function<_Rp(_ArgTypes...)>::function(_Fp)
: __f_(0)
{
}


template
_Rp
function<_Rp(_ArgTypes...)>::operator()(_ArgTypes... __arg) const
{
return (*__f_)(std::forward<_ArgTypes>(__arg)...);
}

}

void setVisible()
{
  struct Visiting { };

  std::function VisitModule { [&](Visiting) { } };
  VisitModule({});
}



Fails with 4.9 and 5.2:

mod.ii:34:17: error: ‘_Rp std::__function::__base<_Rp(_ArgTypes
...)>::operator()(_ArgTypes&& ...) [with _Rp = void; _ArgTypes =
{setVisible()::Visiting}]’, declared using local type ‘setVisible()::Visiting’,
is used but never defined [-fpermissive]
 virtual _Rp operator()(_ArgTypes&& ...) = 0;
 ^

Compiles OK with trunk.

[Bug other/67893] [5 Regression] memory hog building a C++ file (on x86_64-linux-gnu)

2015-10-08 Thread doko at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67893

--- Comment #1 from Matthias Klose  ---
Created attachment 36463
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36463&action=edit
preprocessed source

[Bug other/67893] New: [5 Regression] memory hog building a C++ file (on x86_64-linux-gnu)

2015-10-08 Thread doko at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67893

Bug ID: 67893
   Summary: [5 Regression] memory hog building a C++ file (on
x86_64-linux-gnu)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

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

this is one file from the insighttoolkit software, a swig generated source
file.

built with -g -O2 -fstack-protector-strong -fPIC -fno-strict-aliasing
trunk needs -fpermissive in addition.

memory usage with the 4.9 branch peaks at 2.5G, with the 5 branch at 3.3G, with
trunk at 2.3G.

[Bug fortran/63158] Possible wrong code with absend optional BT_CLASS -> optional BT_DERIVED dummy argument

2015-10-08 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63158

--- Comment #3 from Dominique d'Humieres  ---
> I cannot find any file in gcc/fortran containing the string
> "!e->ref->u.ar.type != AR_FULL" for 4.8, 4.9 and trunk (5.0).

It has been replaced with "e->ref->u.ar.type != AR_FULL" at line 5218:

  if (fsym->attr.optional
  && e->expr_type == EXPR_VARIABLE
  && (!e->ref
  || (e->ref->type == REF_ARRAY
  && e->ref->u.ar.type != AR_FULL))
  && e->symtree->n.sym->attr.optional)

Changed by r214827.

> Is this PR still valid?

*PING*!

Should I close this PR as INVALID to get an answer?

[Bug fortran/67883] ICE on empty array constructor of character function

2015-10-08 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67883

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-08
 CC||pault at gcc dot gnu.org,
   ||vehre at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.2.0, 6.0

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0).

The code compiles and executes if the line

  character(:), allocatable :: f

is replaced with

  character(1), allocatable :: f

[Bug translation/67892] New: Wrong code at -O1 and above

2015-10-08 Thread sikkins at hotmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67892

Bug ID: 67892
   Summary: Wrong code at -O1 and above
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sikkins at hotmail dot com
  Target Milestone: ---

Created attachment 36461
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36461&action=edit
test case

gcc-5 emits wrong code for the attached test case when called with option -O1
and above. However, adding option -fno-tree-dominator-opts fixes the issue.

gcc versions tested: 5.1.0 and 5.2.0
Targets: x86_64-linux-gnu / x86_64-w64-mingw32

[Bug fortran/67826] gcc/fortran/openmp.c:1808: bad test ?

2015-10-08 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67826

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

[Bug middle-end/67891] [6 Regression] FAIL: gcc.dg/pr43300.c (internal compiler error) on alpha-linux-gnu

2015-10-08 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67891

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug fortran/53576] Very unhelpful error message: "Unclassifiable statement" instead of "Can't convert TYPE to ..."

2015-10-08 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53576

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Still present on trunk (6.0) at r228594.

[Bug fortran/53326] -finit-integer, -finit-real and INTENT(OUT)

2015-10-08 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53326

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
Still present on trunk (6.0) at r228594.

[Bug fortran/67884] Missing error message on required allocatable attribute

2015-10-08 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67884

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0).

[Bug target/67124] [6 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

2015-10-08 Thread ubizjak at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67124

--- Comment #11 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #10)
> I think a fix is required for *movdi_internal.  Back to target bug.

Even in the light of Comment #6 ?

[Bug tree-optimization/67889] ICE on valid code at -O1 and above on x86_64-linux-gnu in VN_INFO, at tree-ssa-sccvn.c:384

2015-10-08 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67889

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/67124] [6 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

2015-10-08 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67124

Richard Biener  changed:

   What|Removed |Added

  Component|rtl-optimization|target

--- Comment #10 from Richard Biener  ---
I think a fix is required for *movdi_internal.  Back to target bug.

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

2015-10-08 Thread ubizjak at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67766

--- Comment #5 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #4)

> Bootstrap and regression test went OK [1].  There is however one new
> testsuite failure that looks related to your original patch from 2015-09-27:
> 
> FAIL: gcc.dg/pr43300.c (internal compiler error)
> FAIL: gcc.dg/pr43300.c (test for excess errors)

---> PR 67891

[Bug middle-end/67891] New: [6 Regression] FAIL: gcc.dg/pr43300.c (internal compiler error) on alpha-linux-gnu

2015-10-08 Thread ubizjak at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67891

Bug ID: 67891
   Summary: [6 Regression] FAIL: gcc.dg/pr43300.c (internal
compiler error) on alpha-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---

r228175 introduced following testcase failure on alpha-linux-gnu:

FAIL: gcc.dg/pr43300.c (internal compiler error)
FAIL: gcc.dg/pr43300.c (test for excess errors)

The failure can be triggered with a crosscompiler from x86_64-linux-gnu to
alpha-linux-gnu:

~/gcc-build-alpha/gcc/cc1 -Os -quiet pr43300.c
pr43300.c: In function ‘foo’:
pr43300.c:8:1: internal compiler error: in adjust_one_expanded_partition_var,
at cfgexpand.c:1401
 foo (int x, V2SF a)
 ^
0x7b18e3 adjust_one_expanded_partition_var
../../gcc-svn/trunk/gcc/cfgexpand.c:1401
0x7c2a19 execute
../../gcc-svn/trunk/gcc/cfgexpand.c:6217
Please submit a full bug report,

[Bug driver/67890] search paths for user shared libraries not respected

2015-10-08 Thread francis.andre.kampbell at orange dot fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67890

francis.andre.kampbell at orange dot fr changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from francis.andre.kampbell at orange dot fr ---
Mistake from my side. It appears that only one shared library was linked when
/usr/local/lib was empty..; thus the requested libs was the one in /usr/lib64.

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

2015-10-08 Thread krebbel at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345

--- Comment #25 from Andreas Krebbel  ---
Author: krebbel
Date: Thu Oct  8 07:49:41 2015
New Revision: 228594

URL: https://gcc.gnu.org/viewcvs?rev=228594&root=gcc&view=rev
Log:
S/390: Use create_tmp_var_raw in s390_atomic_assign_expand_fenv.

gcc/ChangeLog:

2015-10-08  Andreas Krebbel  

PR c/65345
* config/s390/s390.c (s390_atomic_assign_expand_fenv): Use
create_tmp_var_raw instead of create_tmp_var.


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

[Bug c++/67888] Compiling clang 3.7.0 results in is used but never defined

2015-10-08 Thread rodrigc at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67888

--- Comment #3 from Craig Rodrigues  ---
This is for cross-compiling the FreeBSD base system with GCC.
The FreeBSD base system has libc++, which was recently upgraded to clang 3.7.0.

Cross-compiling FreeBSD base system with GCC worked before,
with an older version of libc++.

Discussion on the llvm cfe-dev mailing list seems to point to this
being a bug in GCC, hence I filed this bug.

[Bug driver/67890] New: search paths for user shared libraries not respected

2015-10-08 Thread francis.andre.kampbell at orange dot fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67890

Bug ID: 67890
   Summary: search paths for user shared libraries not respected
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: francis.andre.kampbell at orange dot fr
  Target Milestone: ---

Hi

The following g++ command fails to link the target shared library. The command
explicitly states to the linker to use shared libraries into /usr/local/lib
while it picks up those from /usr/lib64


[fandre@obelix cpp]$ g++ -v -o
/home/fandre/ISO-8583/cpp/bin64/ISO-8583-CLI-1987d
-Wl,-rpath,/home/fandre/ISO-8583/cpp/lib64 -Wl,-rpath,/usr/local/lib
/home/fandre/ISO-8583/cpp/make/obj/Linux/x86_64/ISO-8583/CLI/1987/ISO-8583-CLI-1987.o
 -L /home/fandre/ISO-8583/cpp/lib64  -lISO-8583-DFT-1987d -lISO-8583-MSG-1987d
-lISO-8583-DTE-1987d -lISO-8583-DTTd -L /usr/local/lib  -lPocoFoundationd 
-lPocoNetd  -lPocoUtild  -lPocoXMLd  -lCppUnitd
Utilisation des specs internes.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/lto-wrapper
Cible : x86_64-redhat-linux
Configuré avec: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-default-libstdcxx-abi=c++98 --with-isl --enable-libmpx
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Modèle de thread: posix
gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC)
COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/:/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/5.1.1/:/usr/lib/gcc/x86_64-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/5.1.1/:/usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o'
'/home/fandre/ISO-8583/cpp/bin64/ISO-8583-CLI-1987d'
'-L/home/fandre/ISO-8583/cpp/lib64' '-L/usr/local/lib' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/5.1.1/collect2 -plugin
/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/liblto_plugin.so
-plugin-opt=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccd1bF5i.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --build-id
--no-add-needed --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -o
/home/fandre/ISO-8583/cpp/bin64/ISO-8583-CLI-1987d
/usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../../lib64/crt1.o
/usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/5.1.1/crtbegin.o
-L/home/fandre/ISO-8583/cpp/lib64 -L/usr/local/lib
-L/usr/lib/gcc/x86_64-redhat-linux/5.1.1
-L/usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../.. -rpath
/home/fandre/ISO-8583/cpp/lib64 -rpath /usr/local/lib
/home/fandre/ISO-8583/cpp/make/obj/Linux/x86_64/ISO-8583/CLI/1987/ISO-8583-CLI-1987.o
-lISO-8583-DFT-1987d -lISO-8583-MSG-1987d -lISO-8583-DTE-1987d -lISO-8583-DTTd
-lPocoFoundationd -lPocoNetd -lPocoUtild -lPocoXMLd -lCppUnitd -lstdc++ -lm
-lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-redhat-linux/5.1.1/crtend.o
/usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../../lib64/crtn.o
/usr/bin/ld: warning: libPocoFoundationd.so.11, needed by
/home/fandre/ISO-8583/cpp/lib64/libISO-8583-DFT-1987d.so, may conflict with
libPocoFoundationd.so.40
/usr/bin/ld: warning: libPocoNetd.so.11, needed by
/home/fandre/ISO-8583/cpp/lib64/libISO-8583-DFT-1987d.so, may conflict with
libPocoNetd.so.40
/usr/bin/ld: warning: libPocoUtild.so.11, needed by
/home/fandre/ISO-8583/cpp/lib64/libISO-8583-DFT-1987d.so, may conflict with
libPocoUtild.so.40
/usr/bin/ld: warning: libPocoXMLd.so.11, needed by
/home/fandre/ISO-8583/cpp/lib64/libISO-8583-DFT-1987d.so, may conflict with
libPocoXMLd.so.40


[fandre@obelix cpp]$ ll /usr/lib64/*Poco*
lrwxrwxrwx. 1 root root  20 18 août   2014 /usr/lib64/libPocoCryptod.so ->
libPocoCryptod.so.11
-rwxr-xr-x. 1 root root  144976 18 août   2014 /usr/lib64/libPocoCryptod.so.11
lrwxrwxrwx. 1 root root  19 18 août   2014 /usr/lib64/libPocoCrypto.so ->
libPocoCrypto.so.11
-rwxr-xr-x. 1 root root  144896 18 août   2014 /usr/lib64/lib

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

2015-10-08 Thread ubizjak at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67766

--- Comment #4 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #3)
> Created attachment 36456 [details]
> Patch that fixes bootstrap problem

Bootstrap and regression test went OK [1].  There is however one new testsuite
failure that looks related to your original patch from 2015-09-27:

FAIL: gcc.dg/pr43300.c (internal compiler error)
FAIL: gcc.dg/pr43300.c (test for excess errors)

/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/pr43300.c: In function
'foo':
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/pr43300.c:8:1: internal
compiler error: in adjust_one_expanded_partition_var, at cfgexpand.c:1401
0x12034f1eb adjust_one_expanded_partition_var
/space/homedirs/uros/gcc-svn/trunk/gcc/cfgexpand.c:1401
0x12034f1eb execute
/space/homedirs/uros/gcc-svn/trunk/gcc/cfgexpand.c:6217
Please submit a full bug report,
...

[1] https://gcc.gnu.org/ml/gcc-testresults/2015-10/msg00800.html