[Bug tree-optimization/58508] [Missed-Optimization] Redundant vector load of "actual" loop invariant in loop body.

[bernd.edlinger at hotmail dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58508

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #4 from Bernd Edlinger  ---
Hi,

the test case is failing on a i686-pc-linux-gnu.
Reason: by default the -msse2 is not enabled.
If I add -msse2 to dg_options the test passes.

Regards
Bernd.

[Bug c/58892] New: ICE in combine.c when using -Os on alpha

[mcree at orcon dot net.nz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58892

Bug ID: 58892
   Summary: ICE in combine.c when using -Os on alpha
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mcree at orcon dot net.nz
Target: alpha

Created attachment 31096
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31096&action=edit
Preprocessed C source that causes ICE.

While compiling linux kernel for Alpha get ICE in combine.c:711 when compiling
drivers/media/dvb-core/dvb-demux.c.

Attached preprocessed source from that compilation.  Established that it is the
use of -Os that leads to the ICE. Namely running:

gcc-4.8 -nostdinc -Os -c ices.c

generates the following output:

In file included from
/home/mjc/debian/linux/linux-3.11.5/include/linux/thread_info.h:54:0,
 from
/home/mjc/debian/linux/linux-3.11.5/include/linux/preempt.h:9,
 from
/home/mjc/debian/linux/linux-3.11.5/include/linux/spinlock.h:50,
 from
/home/mjc/debian/linux/linux-3.11.5/include/linux/seqlock.h:29,
 from
/home/mjc/debian/linux/linux-3.11.5/include/linux/time.h:5,
 from
/home/mjc/debian/linux/linux-3.11.5/include/uapi/linux/timex.h:56,
 from
/home/mjc/debian/linux/linux-3.11.5/include/linux/timex.h:56,
 from
/home/mjc/debian/linux/linux-3.11.5/include/linux/sched.h:17,
 from
/home/mjc/debian/linux/linux-3.11.5/drivers/media/dvb-core/dvb_demux.c:24:
/home/mjc/debian/linux/linux-3.11.5/arch/alpha/include/asm/thread_info.h:52:30:
warning: call-clobbered register used for global register variable [enabled by
default]
 register struct thread_info *__current_thread_info __asm__("$8");
  ^
/home/mjc/debian/linux/linux-3.11.5/drivers/media/dvb-core/dvb_demux.c: In
function ‘dvb_dmx_swfilter_packet’:
/home/mjc/debian/linux/linux-3.11.5/drivers/media/dvb-core/dvb_demux.c:474:1:
internal compiler error: in do_SUBST, at combine.c:711
 }
 ^


Compilation is sucessful without -Os option or with -O1.  ICE reappears if
compile with -O2.  ICE only occurs with gcc-4.8 (Debian 4.8.2-1) but not
gcc-4.6 or gcc-4.7 so looks like a regression.

[Bug tree-optimization/58890] Doesn't generate warning about potentially uninitialized variable

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58890

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #2 from Manuel López-Ibáñez  ---
Exactly 18501. No fix in sight unfortunately.

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

[Bug tree-optimization/18501] [4.7/4.8/4.9 Regression] Missing 'used uninitialized' warning (CCP)

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||igor.shevlyakov at gmail dot 
com

--- Comment #66 from Manuel López-Ibáñez  ---
*** Bug 58890 has been marked as a duplicate of this bug. ***

[Bug c/39693] Warning about uninitialized local variable use

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39693

--- Comment #6 from Manuel López-Ibáñez  ---
Igor, your testcase is exactly PR18501. No fix in sight unfortunately.

[Bug ada/58891] New: Bug box when using limited with, between parent and child packages

[laguest at archeia dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58891

Bug ID: 58891
   Summary: Bug box when using limited with, between parent and
child packages
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: laguest at archeia dot com

Created attachment 31095
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31095&action=edit
All source including those output from -gnatd.n

Hi,

I'm trying to create a binding library and have got a bug box when trying to
reference a type in a parent package from a child package and also using a type
from the child package in the parent, i.e. limited_with.

Compiler information:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/laguest/opt/tinyada/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/laguest/src/mine/tinyada-new/source/gcc-trunk/configure
--prefix=/home/laguest/opt/tinyada --enable-multilib --enable-threads=posix
--disable-shared --with-gnu-as --with-gnu-ld --enable-languages=c,c++,ada
--with-system-zlib --disable-libgomp --without-libffi --without-libiconv-prefix
--disable-libmudflap --disable-nls --disable-libstdcxx-pch
--disable-cloog-version-check --disable-isl-version-check
--with-gmp=/home/laguest/opt/tinyada --with-mpfr=/home/laguest/opt/tinyada
--with-mpc=/home/laguest/opt/tinyada --with-isl=/home/laguest/opt/tinyada
--with-cloog=/home/laguest/opt/tinyada CFLAGS=
Thread model: posix
gcc version 4.9.0 20130916 (experimental) (GCC) 

System information:

$ uname -a
Linux rogue 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux

Error:

+===GNAT BUG DETECTED==+
| 4.9.0 20130916 (experimental) (x86_64-unknown-linux-gnu) Storage_Error stack
overflow or erroneous memory access|
| Error detected at doxmlada-docs.adb:2:4  |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

doxmlada-docs.adb
doxmlada-docs.ads
doxmlada.ads
doxmlada-docs-lists.ads

compilation abandoned
gnatmake: "doxmlada-docs.adb" compilation error

[Bug ada/58891] Bug box when using limited with, between parent and child packages

[laguest at archeia dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58891

--- Comment #1 from Luke A. Guest  ---
Compiled with:

gnatchop source.ada
gnatmake -gnatd.n -c doxmlada-docs.adb

[Bug target/52483] SH Target: Loads from volatile memory leave redundant sign/zero extensions

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52483

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #6 from Oleg Endo  ---
Fixed on 4.9.

[Bug target/52483] SH Target: Loads from volatile memory leave redundant sign/zero extensions

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52483

--- Comment #5 from Oleg Endo  ---
Author: olegendo
Date: Sat Oct 26 22:07:37 2013
New Revision: 204097

URL: http://gcc.gnu.org/viewcvs?rev=204097&root=gcc&view=rev
Log:
PR target/52483
* config/sh/predicates.md (general_movdst_operand): Allow reg+reg
addressing, do not use general_operand for memory operands.

PR target/52483
* gcc.target/sh/pr52483-1.c: Add tests for memory stores.
* gcc.target/sh/pr52483-2.c: Likewise.
* gcc.target/sh/pr52483-3.c: Likewise.
* gcc.target/sh/pr52483-4.c: Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/predicates.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/sh/pr52483-1.c
trunk/gcc/testsuite/gcc.target/sh/pr52483-2.c
trunk/gcc/testsuite/gcc.target/sh/pr52483-3.c
trunk/gcc/testsuite/gcc.target/sh/pr52483-4.c

[Bug tree-optimization/58890] Doesn't generate warning about potentially uninitialized variable

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58890

--- Comment #1 from Andrew Pinski  ---
This looks like a dup of another unitialized warning issue.

[Bug tree-optimization/58890] New: Doesn't generate warning about potentially uninitialized variable

[igor.shevlyakov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58890

Bug ID: 58890
   Summary: Doesn't generate  warning about potentially
uninitialized variable
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: igor.shevlyakov at gmail dot com

Created attachment 31094
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31094&action=edit
Test case

[Bug c/39693] Warning about uninitialized local variable use

[igor.shevlyakov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39693

Igor Shevlyakov  changed:

   What|Removed |Added

 CC||igor.shevlyakov at gmail dot 
com

--- Comment #5 from Igor Shevlyakov  ---
Created attachment 31093
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31093&action=edit
test file

[Bug c++/58885] Template static variable linking issue!

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58885

--- Comment #5 from Daniel Krügler  ---
(In reply to Vehbi Esref Bayraktar from comment #4)
> So why doesn't it compile as is
> CGEnum::instances_list CGEnum::msInstances;
> and asks for a specialization notation (template<>)?

Well, because that would be invalid C++ otherwise. The most reasonable
interpretation is to assume that this would be an attempt to specialize that
member and this would require the template<> prefix. What else should it be?

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687

Andrew Pinski  changed:

   What|Removed |Added

   Severity|major   |normal

--- Comment #5 from Andrew Pinski  ---
> Simply to make identification host independent.  The fact that my
>projects are stored on '/VOL10' on one of my machines and '/DATA0.2'

This sounds like a bug in how you are compiling the sources.  Also there are
options inside GDB to transpose paths to the path on your machine.

[Bug preprocessor/58887] Allow recursion in varadic macros?

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887

--- Comment #1 from Andrew Pinski  ---
I think this should go through the standards committee instead of being a GNU
extension.

[Bug c++/58885] Template static variable linking issue!

[vehbi.esref.bayraktar at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58885

--- Comment #4 from Vehbi Esref Bayraktar  ---
So why doesn't it compile as is
CGEnum::instances_list CGEnum::msInstances;

and asks for a specialization notation (template<>)?

Thanks

[Bug c++/58885] Template static variable linking issue!

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58885

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
Thanks Daniel.

[Bug c/58889] GCC 4.9 fails to compile certain functions with intrinsics with __attribute__((target))

[thiago at kde dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58889

--- Comment #1 from Thiago Macieira  ---
This problem also happens with other combinations of functions in use and
compiler options.

My original problem happened on a 64-bit build with -march=corei7-avx and a
function with __attribute__((target("avx2"))).

[Bug c/58889] New: GCC 4.9 fails to compile certain functions with intrinsics with __attribute__((target))

[thiago at kde dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58889

Bug ID: 58889
   Summary: GCC 4.9 fails to compile certain functions with
intrinsics with __attribute__((target))
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thiago at kde dot org

Source:

$ cat t.c
#include 
__attribute__((target("avx2"))) int f(void *ptr)
{ 
  return _mm256_movemask_epi8(_mm256_loadu_si256((__m256i*)ptr)); 
}

Works:

$ ~/gcc4.9/bin/g++ -S -O3 -o /dev/null t.c
$ ~/gcc4.9/bin/g++ -m32 -S -O3 -o /dev/null t.c
$ ~/gcc4.9/bin/g++ -march=core2 -S -O3 -o /dev/null t.c
$ ~/gcc4.9/bin/g++ -march=core2 -m32 -S -O3 -o /dev/null t.c
$ ~/gcc4.9/bin/g++ -march=nocona -S -O3 -o /dev/null t.c
$ ~/gcc4.9/bin/g++ -march=nocona -m32 -S -O3 -o /dev/null t.c
$ ~/gcc4.9/bin/g++ -march=prescott -m32 -S -O3 -o /dev/null t.c
$ ~/gcc4.9/bin/g++ -march=pentium4 -m32 -S -O3 -o /dev/null t.c
$ ~/gcc4.9/bin/g++ -march=pentium3 -m32 -S -O3 -o /dev/null t.c

Fails:
$ ~/gcc4.9/bin/g++ -march=pentium2 -m32 -S -O3 -o /dev/null t.c
avxintrin.h: In function ‘int f(void*)’:
avxintrin.h:890:1: error: inlining failed in call to always_inline ‘__m256i
_mm256_loadu_si256(const __m256i*)’: target specific option mismatch
 _mm256_loadu_si256 (__m256i const *__P)
 ^
[...]
g++: internal compiler error: Segmentation fault (program cc1plus)
0x409614 execute
/home/thiago/src/gcc/gcc/gcc.c:2864


$ ~/gcc4.9/bin/g++ -march=pentium -m32 -S -O3 -o /dev/null t.c
avxintrin.h: In function ‘int f(void*)’:
avxintrin.h:890:1: error: inlining failed in call to always_inline ‘__m256i
_mm256_loadu_si256(const __m256i*)’: target specific option mismatch
 _mm256_loadu_si256 (__m256i const *__P)
 ^
[...]
[no segfault]

This is an unpatched, pristine GCC, built from trunk@203862.
System: Linux 64-bit (Fedora 17)
Configure options: --enable-lang=c,c++

[Bug c++/58888] New: [c++11] Rejects-valid: static member with auto and initializer

[thomas.br...@virtuell-zuhause.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5

Bug ID: 5
   Summary: [c++11] Rejects-valid: static member with auto and
initializer
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.br...@virtuell-zuhause.de

The following code is rejected by 
~/gcc-4.8.2/bin/g++ -std=c++11 test.cpp

#include 

struct A
{
  static constexpr auto b{1.0};
};

constexpr decltype(A::b) A::b;

int main(int argc, char** argv)
{
  std::cout << &A::b << std::endl;
}


with the message

#
test.cpp:46:30: error: invalid use of 'auto'
   static constexpr auto b{1.0};
  ^
test.cpp:49:30: error: invalid type in declaration before ';' token
 constexpr decltype(A::b) A::b;
  ^
test.cpp:49:30: error: declaration of 'constexpr A::b' outside
of class is not definition [-fpermissive]
#

I'm using g++ (GCC) 4.8.2.

My interpretation of &7.1.6.4 is that this code is valid, clang accepts the
code and
http://stackoverflow.com/questions/12834874/auto-static-in-class-constant-initalization-with-meta-programming
also suggests that it is valid.

[Bug target/58792] [4.9 Regression] ICE at mode-switching.c:421 when compiling clang lib/AST/MicrosoftCXXABI.cpp

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58792

--- Comment #9 from Uroš Bizjak  ---
(In reply to Hristo Venev from comment #8)
> Created attachment 31092 [details]
> Reduced testcase
> 
> b.cpp: In function ‘int f(int)’:
> b.cpp:7:1: internal compiler error: in create_pre_exit, at
> mode-switching.c:422
> 
> GCC fails to compile gcc libstdc++-v3/libsupc++/eh_terminate.cc.
> 
> libstdc++-v3/libsupc++/eh_terminate.cc: In function ‘void (*
> std::set_terminate(std::terminate_handler))()’:
> libstdc++-v3/libsupc++/eh_terminate.cc:85:1: internal compiler error: in
> create_pre_exit, at mode-switching.c:422

If this is with today's compiler, then this is PR58679.

[Bug rtl-optimization/58679] [4.9 regression] ICE in create_pre_exit, at mode-switching.c:421 with -mavx after r202915

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58679

--- Comment #12 from Jorn Wolfgang Rennecke  ---
(In reply to Jorn Wolfgang Rennecke from comment #10)
> (In reply to Uroš Bizjak from comment #7)
>  
> > CC author. Hopefully, following part will be reverted:
> > 
> > 2013-10-25  Vladimir Makarov 
> > 
> > [...]
> > * lra-spills.c (lra_final_code_change): Remove useless move insns.
> 
> For the return value sanity checks, we need only a subset of these moves
> preserved.
> Ones that are
> - in the exit block, and
> - likely_spilled_p, and
> - pertain to the function result register, or a part of it.

P.S.: the fact that we have no-op moves like that indicates potential
trouble - it means this likely spilled register is also live before
the return value copy.  So if we need to spill it to do a mode switch,
we are between a rock and a hard place.

[Bug rtl-optimization/58679] [4.9 regression] ICE in create_pre_exit, at mode-switching.c:421 with -mavx after r202915

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58679

--- Comment #11 from Eric Botcazou  ---
> There is also a wider issue: the documentation in passes.texi is incorrect
> now.
> It says:
> "Unlike the reload pass, intermediate LRA decisions are reflected in
>  RTL as much as possible."
> Now, with the removal of REG_DEAD / REG_UNUSED notes, the complete opposite
> is true.  These notes are a bit fuzzy after reload, but their fuzzyness is
> well-defined - i.e. the notes pertain to a death in the same BB, unless
> superceded by a simultaneous (with use) or later set.

Are you really sure these notes are still present after reload?  The comment
and the code at line 1170 of reload1.c are clear enough.

Here's the result of "grep -c REG_READ" for a private target not using LRA:

unwind-dw2-fde.i.150r.expand:0
unwind-dw2-fde.i.151r.sibling:0
unwind-dw2-fde.i.153r.initvals:0
unwind-dw2-fde.i.154r.unshare:0
unwind-dw2-fde.i.155r.vregs:0
unwind-dw2-fde.i.156r.into_cfglayout:0
unwind-dw2-fde.i.157r.jump:0
unwind-dw2-fde.i.158r.subreg1:0
unwind-dw2-fde.i.159r.dfinit:0
unwind-dw2-fde.i.160r.cse1:0
unwind-dw2-fde.i.161r.fwprop1:869
unwind-dw2-fde.i.162r.cprop1:869
unwind-dw2-fde.i.163r.pre:867
unwind-dw2-fde.i.165r.cprop2:865
unwind-dw2-fde.i.167r.cse_local:667
unwind-dw2-fde.i.168r.ce1:1627
unwind-dw2-fde.i.169r.reginfo:863
unwind-dw2-fde.i.170r.loop2:863
unwind-dw2-fde.i.171r.loop2_init:863
unwind-dw2-fde.i.172r.loop2_invariant:4402
unwind-dw2-fde.i.176r.loop2_done:863
unwind-dw2-fde.i.178r.cprop3:863
unwind-dw2-fde.i.179r.cse2:856
unwind-dw2-fde.i.180r.dse1:827
unwind-dw2-fde.i.181r.fwprop2:833
unwind-dw2-fde.i.183r.init-regs:833
unwind-dw2-fde.i.184r.ud_dce:833
unwind-dw2-fde.i.185r.combine:792
unwind-dw2-fde.i.186r.ce2:1045
unwind-dw2-fde.i.188r.regmove:731
unwind-dw2-fde.i.189r.outof_cfglayout:731
unwind-dw2-fde.i.190r.split1:731
unwind-dw2-fde.i.191r.subreg2:731
unwind-dw2-fde.i.195r.asmcons:731
unwind-dw2-fde.i.197r.sched1:731
unwind-dw2-fde.i.198r.ira:731
unwind-dw2-fde.i.199r.reload:0
unwind-dw2-fde.i.200r.postreload:0
unwind-dw2-fde.i.202r.split2:0
unwind-dw2-fde.i.206r.pro_and_epilogue:0
unwind-dw2-fde.i.207r.dse2:711
unwind-dw2-fde.i.208r.csa:697
unwind-dw2-fde.i.209r.peephole2:697
unwind-dw2-fde.i.210r.ce3:856
unwind-dw2-fde.i.212r.cprop_hardreg:697
unwind-dw2-fde.i.213r.rtl_dce:696
unwind-dw2-fde.i.214r.bbro:710
unwind-dw2-fde.i.216r.split4:710
unwind-dw2-fde.i.217r.sched2:703
unwind-dw2-fde.i.220r.alignments:703
unwind-dw2-fde.i.221r.compgotos:703
unwind-dw2-fde.i.225r.barriers:703
unwind-dw2-fde.i.226r.dbr:616
unwind-dw2-fde.i.227r.split5:616
unwind-dw2-fde.i.229r.shorten:616
unwind-dw2-fde.i.230r.nothrow:616
unwind-dw2-fde.i.232r.final:616
unwind-dw2-fde.i.233r.dfinish:616
unwind-dw2-fde.i.235r.mach2:616

[Bug target/58792] [4.9 Regression] ICE at mode-switching.c:421 when compiling clang lib/AST/MicrosoftCXXABI.cpp

[mustrumr97 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58792

Hristo Venev  changed:

   What|Removed |Added

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

[Bug target/58792] [4.9 Regression] ICE at mode-switching.c:421 when compiling clang lib/AST/MicrosoftCXXABI.cpp

[mustrumr97 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58792

Hristo Venev  changed:

   What|Removed |Added

  Attachment #31044|0   |1
is obsolete||

--- Comment #8 from Hristo Venev  ---
Created attachment 31092
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31092&action=edit
Reduced testcase

b.cpp: In function ‘int f(int)’:
b.cpp:7:1: internal compiler error: in create_pre_exit, at mode-switching.c:422

GCC fails to compile gcc libstdc++-v3/libsupc++/eh_terminate.cc.

libstdc++-v3/libsupc++/eh_terminate.cc: In function ‘void (*
std::set_terminate(std::terminate_handler))()’:
libstdc++-v3/libsupc++/eh_terminate.cc:85:1: internal compiler error: in
create_pre_exit, at mode-switching.c:422

[Bug rtl-optimization/58679] [4.9 regression] ICE in create_pre_exit, at mode-switching.c:421 with -mavx after r202915

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58679

--- Comment #10 from Jorn Wolfgang Rennecke  ---
(In reply to Uroš Bizjak from comment #7)

> CC author. Hopefully, following part will be reverted:
> 
> 2013-10-25  Vladimir Makarov 
> 
> [...]
> * lra-spills.c (lra_final_code_change): Remove useless move insns.

For the return value sanity checks, we need only a subset of these moves
preserved.
Ones that are
- in the exit block, and
- likely_spilled_p, and
- pertain to the function result register, or a part of it.

[Bug libstdc++/58729] tr2::dynamic_bitset::resize fails

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58729

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug libstdc++/58804] dynamic_bitset<> uses popcountl on long long

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58804

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug rtl-optimization/58679] [4.9 regression] ICE in create_pre_exit, at mode-switching.c:421 with -mavx after r202915

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58679

--- Comment #9 from Uroš Bizjak  ---
(In reply to Eric Botcazou from comment #8)
> > Or should we use a different approach, and use DF to re-create REG_DEAD
> > notes?
> 
> Yes, if you need REG_DEAD/REG_UNUSED notes, just tell DF to compute them:

I think that missing REG_DEAD/REG_UNUSED notes and r202915 just triggered the
problem, fixed with [1] - at least I'm not able to trigger the ICE described in
Comment #0 anymore.

The new problem was introduced by Vladimir's patch that removed final
assignments to return registers in several cases. The postreload mode-switching
pass depends on them, and gcc.target/i386/{avx-1,sse-23,sse-24}.c testcases
start to fail on x86 [2]. Also, bootstrap will be broken when configured with
"--with-arch=core-avx-i --with-cpu=core-avx-i --with-fpmath=avx" due to
post-reload mode switching failures in libjava and libgo.


[1] http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01606.html
[2] http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg02051.html

[Bug rtl-optimization/58679] [4.9 regression] ICE in create_pre_exit, at mode-switching.c:421 with -mavx after r202915

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58679

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #8 from Eric Botcazou  ---
> Or should we use a different approach, and use DF to re-create REG_DEAD
> notes?

Yes, if you need REG_DEAD/REG_UNUSED notes, just tell DF to compute them:

eric@polaris:~/gnat/gnat-head/src/gcc> grep df_note_add_problem *.c
auto-inc-dec.c:  df_note_add_problem ();
cfgrtl.c:  df_note_add_problem ();
combine.c:  df_note_add_problem ();
combine-stack-adj.c:  df_note_add_problem ();
cse.c:  df_note_add_problem ();
df-problems.c:df_note_add_problem (void)
dse.c:  df_note_add_problem ();
fwprop.c:  df_note_add_problem ();
haifa-sched.c:  df_note_add_problem ();
ira.c:  df_note_add_problem ();
loop-iv.c:  df_note_add_problem ();
recog.c:  df_note_add_problem ();
regmove.c:  df_note_add_problem ();
regrename.c:  df_note_add_problem ();
reg-stack.c:  df_note_add_problem ();

[Bug c++/58885] Template static variable linking issue!

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58885

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #2 from Daniel Krügler  ---
The linker is correct to signal an error here, because the explicit
specialization

template<> 
CGEnum::instances_list 
CGEnum::msInstances;

is considered a non-defining declaration as of 14.7.3 p13:

"An explicit specialization of a static data member of a template or an
explicit specialization of a static data member template is a definition if the
declaration includes an initializer; otherwise, it is a declaration."

The necessary fix is to provide the initializer, because the corresponding
entity is odr-used in the program:

template<> 
CGEnum::instances_list 
CGEnum::msInstances{};

[Bug preprocessor/58887] New: Allow recursion in varadic macros?

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887

Bug ID: 58887
   Summary: Allow recursion in varadic macros?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mtewoodbury at gmail dot com

With good reason, recursion in macro definitions is suppressed -- it leads to
infinite expansion loops and subsequent software failure, HOWEVER

Recursion of varadic macros where the number of arguments in the argument list
decreases would necessarily stop expanding when the argument list became empty.

It would be nice if this could be handled easily, but doing it requires an
extension -- something beyond what the standard calls for/allows.

I can see two ways to do this -- there may be other ways as well:

1)  Allow recursion as long as the new invocation has fewer arguments
than the current invocation.

This is the general solution, but should only be allowed if some
special mode is set, such as a command line switch or 'pragma'

2)  Make the number of arguments easily available.

There is a way to write a varadic macro that return a count of
its arguments, but it has severe limitations -- it will necessarily
have an upper bound on the number of arguments it can count and
that limit will be half the implementation limit the preprocessor
puts on the number of arguments that can be passed to varadic
macros.

It would help if there were a predefined macro that did this
counting and did not have the upper bound limitation.

Once the argument count is available, it is possible to construct
the name of a macro for the correct number of arguments and have
those macros chain their expansion.

This solution is sub-optimal:  macros for each argument count have
to be defined, which means there will be an arbitrary upper bound
on the number of arguments handled and puts a strain on preprocessor
resources.

For this reason, solution 1 is preferable.

[Bug rtl-optimization/58679] [4.9 regression] ICE in create_pre_exit, at mode-switching.c:421 with -mavx after r202915

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58679

Uroš Bizjak  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #7 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #1)
> The patch at [1] now removes useless moves in the exit bb. This change
> breaks assumption in the mode-switching pass that all USEs of return values
> have a corresponding simple return value copy somewhere up in the insn
> stream.

I was referring to:

[1] http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02208.html

CC author. Hopefully, following part will be reverted:

2013-10-25  Vladimir Makarov 

[...]
* lra-spills.c (lra_final_code_change): Remove useless move insns.

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687

Max TenEyck Woodbury  changed:

   What|Removed |Added

   Severity|normal  |major

--- Comment #4 from Max TenEyck Woodbury  ---
Why is this important?

1)  There must be a way to modify the '__FILE__' value without messing
up the '__LINE__' value.  A 'Google' shows that the expected way to
do this is:

# line __LINE__ "new-__FILE__-value"

but with this bug, the __LINE__ value gets messed up and all 
subsequent diagnostics are off by at least one.  It also makes
debugging more difficult if not impossible.

Now, why change the '__FILE__' value?

Simply to make identification host independent.  The fact that my
projects are stored on '/VOL10' on one of my machines and '/DATA0.2'
on another only confuses any trouble reports.  What is important is
that the file is 'myproject/configure.c' (or whatever).

2)  Similarly, adding multi-line comments to the '# line __LINE__ ...'
directive should NOT mess with the line numbering.

3)  Why not use a specific value in place of '__LINE__'?

Because that embeds a maintenance problem that should not be there
into the source.  If something gets added before the '# line  ...'
directive, then  has to be updated.  If the source is 'generated'
by some tool, this is reasonable, but it is NOT reasonable for base
level source files.  Similarly, there should be a freedom to edit
the comment without having to play with the line number.

[Bug libstdc++/58839] [4.8/4.9 Regression] dereferencing void* in shared_ptr(unique_ptr&& u) constructor

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58839

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC|jwakely.gcc at gmail dot com   |
  Known to work||4.7.3
   Target Milestone|--- |4.8.3
Summary|Regression: dereferencing   |[4.8/4.9 Regression]
   |void* in|dereferencing void* in
   |shared_ptr(unique_ptr&& u)  |shared_ptr(unique_ptr&& u)
   |constructor |constructor

[Bug rtl-optimization/58679] [4.9 regression] ICE in create_pre_exit, at mode-switching.c:421 with -mavx after r202915

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58679

--- Comment #6 from Jorn Wolfgang Rennecke  ---
(In reply to Uroš Bizjak from comment #1)

> There is no return value copy insn.
> 
> The assumption in the mode switching pass, that there is a return value copy
> is not correct anymore, due to recent enhancements in the RA. The mode
> switching pass should perform life analysis by itself. Simply looking for a
> return copy is not correct anymore.

You got that backwards.  The point of most of the code in create_pre_exit
is to look for a return value copy, to make sure it is not separated any
more from the return statement unless that can't be helped.

The reason is that for likely_spilled registers, there is a double
hazard of clobbering the return value:
- The mode switching code itself might clobber the return value.
- A successive pass might clobber the return value.
  At the time the mode switching code was written - not sure if that
  has changed in the meantime - the value in a likely_spilled FUNCTION_VALUE
  register was only guaranteed to be preserved if the return value copy was
  the very last instruction before the return insn (or the end of the exit
  block).  Every pass is supposed to keep the return value copy in that
  position if a likely_spilled register FUNCTION_VALUE register is involved.


Thus, we still have to look for a return value copy.

The change in the rtl representation means that we can no longer use
REG_DEAD / REG_UNUSED notes in optimize_mode_switching to keep track of
the set of live registers that EMIT_MODE_SET has to avoid using as scratch
registers.
Also, new cases of disappearing return value copies can mean one of two
things:
- the removal is a legit optimization, and the sanity checks in
create_pre_exit should be accordingly relaxed.
- the removal increases likely_spilled register pressure in a manner that can
  lead to wrong code, and must be suppressed.

There is also a wider issue: the documentation in passes.texi is incorrect now.
It says:
"Unlike the reload pass, intermediate LRA decisions are reflected in
 RTL as much as possible."
Now, with the removal of REG_DEAD / REG_UNUSED notes, the complete opposite
is true.  These notes are a bit fuzzy after reload, but their fuzzyness is
well-defined - i.e. the notes pertain to a death in the same BB, unless
superceded by a simultaneous (with use) or later set.
But with lra, we don't have them at all anymore - that means a lot of target
code has to be re-written to use DF.
Some of this seems quite preposterous to do in place- e.g. using df inside
an output pattern.  So maybe we need to put more clobbers for opportunistic
register usage into rtl - we might use additional peephole2 patterns,
e.g. one after branch shortening for the arc casesi patterns.

SH splitters could also use such inserted clobbers, not sure where the extra
peephole2 pass should be inserted.

That raises the question - should we able to tag peephole2 patterns to
be run during specific peephole2 passes / pass sets?
Or should we call them peepholen, with n being an integer?

Or should we use a different approach, and use DF to re-create REG_DEAD notes?
Will that work now in the later stages of the compiler too?

[Bug libgcc/58886] regex with (?s) (valid in Java and boost) yields regex_error

[bremende55 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58886

--- Comment #1 from Jo  ---
compiler used:
g++ (GCC) 4.9.0 20131020 (experimental)

on SuSe Linux 12.2

[Bug libgcc/58886] New: regex with (?s) (valid in Java and boost) yields regex_error

[bremende55 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58886

Bug ID: 58886
   Summary: regex with (?s) (valid in Java and boost) yields
regex_error
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bremende55 at gmail dot com

regex  with (?s) (valid in Java and boost) yields regex_error
(?s) ist the 'dot-matches-all" match mode, i.e. \n ist treated as normal char
see example:

#include 
#include 
#include 
int main() {
   std::string multilinecomment("/* text\n\n\n */");
// execution of the next line gives regex_error !!
   std::string result = std::regex_replace(multilinecomment, 
   std::regex("(?s)/\\*.*?\\*/"), "replacement");
   std::cout << result << std::endl;  
}
// The same code DOES WORK with BOOST:
// #include 
// #include
// #include 
// int main() {
//std::string multilinecomment("/* text\n\n\n */");
//std::string result = boost::regex_replace(multilinecomment, 
//boost::regex("(?s)/\\*.*?\\*/"), "replacement");
//std::cout << result << std::endl;  // replacement
// }

[Bug rtl-optimization/58679] [4.9 regression] ICE in create_pre_exit, at mode-switching.c:421 with -mavx after r202915

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58679

--- Comment #5 from Uroš Bizjak  ---
Another problem:

--cut here--
int f (long long a, long long b)
{
  return (a * b) >> 16;
}
--cut here--

-O2 -mavx -m32 results in the ICE in mode switching due to following sequence:

(insn 14 12 23 2 (parallel [
(set (reg:DI 0 ax [orig:99 D.1985 ] [99])
(ashiftrt:DI (reg:DI 0 ax [orig:97 D.1985 ] [97])
(const_int 16 [0x10])))
(clobber (reg:CC 17 flags))
]) t-2.c:3 528 {*ashrdi3_doubleword}
 (nil))
(insn 23 14 30 2 (use (reg/i:SI 0 ax)) t-2.c:4 -1
 (nil))

The set and use have different modes. Before the change:

(insn 14 12 20 2 (parallel [
(set (reg:DI 0 ax [orig:99 D.1985 ] [99])
(ashiftrt:DI (reg:DI 0 ax [orig:97 D.1985 ] [97])
(const_int 16 [0x10])))
(clobber (reg:CC 17 flags))
]) t-2.c:3 528 {*ashrdi3_doubleword}
 (nil))
(insn 20 14 23 2 (set (reg/i:SI 0 ax)
(reg:SI 0 ax [orig:99 D.1985 ] [99])) t-2.c:4 86 {*movsi_internal}
 (nil))
(insn 23 20 30 2 (use (reg/i:SI 0 ax)) t-2.c:4 -1
 (nil))

[Bug c++/58885] Template static variable linking issue!

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58885

Paolo Carlini  changed:

   What|Removed |Added

   Severity|major   |normal

--- Comment #1 from Paolo Carlini  ---
Yet to be analyzed, but looks like a bug in your code: up to date g++, clang++,
icc, all reject it at link time the same way.

[Bug c++/58627] [4.9 Regression] crash during compilation of boost testsuite

[octoploid at yandex dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58627

--- Comment #3 from octoploid at yandex dot com ---
Valgrind shows:

markus@x4 /tmp % valgrind --track-origins=yes --trace-children=yes g++ -O2
-std=c++11 -c test.ii
==6647== Memcheck, a memory error detector
==6647== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==6647== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==6647== Command: g++ -O2 -std=c++11 -c test.ii
==6647== 
==6647== Memcheck, a memory error detector
==6647== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==6647== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==6647== Command: /usr/x86_64-pc-linux-gnu/gcc-bin/4.9.0/g++ -O2 -std=c++11 -c
test.ii
==6647== 
==6655== Memcheck, a memory error detector
==6655== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==6655== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==6655== Command: /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus
-fpreprocessed test.ii -quiet -dumpbase test.ii -mtune=generic -march=x86-64
-auxbase test -O2 -std=c++11 -o /tmp/cctcTn3y.s
==6655== 
==6655== Invalid read of size 1
==6655==at 0x5E453A: gt_ggc_mx_lang_tree_node(void*) (c-common.h:1211)
==6655==by 0x5E5AEB: gt_ggc_mx_lang_tree_node(void*) (gt-cp-tree.h:510)
==6655==by 0x5E61AF: gt_ggc_mx_tinst_level(void*) (gt-cp-tree.h:124)
==6655==by 0x533E3F: gt_ggc_mx_pending_template(void*) (gt-cp-pt.h:44)
==6655==by 0x78A8E5: ggc_mark_root_tab(ggc_root_tab const*)
(ggc-common.c:133)
==6655==by 0x78AC90: ggc_mark_roots() (ggc-common.c:152)
==6655==by 0x65A9EA: ggc_collect() (ggc-page.c:2077)
==6655==by 0x869A4D: execute_one_pass(opt_pass*) (passes.c:2255)
==6655==by 0x869D65: execute_pass_list(opt_pass*) (passes.c:2267)
==6655==by 0x6AF0EB: analyze_function(cgraph_node*) (cgraphunit.c:650)
==6655==by 0x6B0127: analyze_functions() (cgraphunit.c:1004)
==6655==by 0x6B0F35: finalize_compilation_unit() (cgraphunit.c:2262)
==6655==  Address 0x17125d8 is not stack'd, malloc'd or (recently) free'd
==6655== 
test.ii: In function ‘void
fastest_itl_total_icl_quantifier_check_monoid_plus_4_bicremental_types_invoker()’:
test.ii:3069:14: internal compiler error: Segmentation fault
  static void
fastest_itl_total_icl_quantifier_check_monoid_plus_4_bicremental_types_invoker()
{ ::boost::unit_test::unit_test_log.set_checkpoint(
::boost::unit_test::const_string(
"../libs/icl/test/fastest_total_icl_quantifier_/../fastest_total_icl_quantifier_cases.hpp",
sizeof(
"../libs/icl/test/fastest_total_icl_quantifier_/../fastest_total_icl_quantifier_cases.hpp"
) - 1 ), static_cast(  15 
  ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug rtl-optimization/58679] [4.9 regression] ICE in create_pre_exit, at mode-switching.c:421 with -mavx after r202915

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58679

Uroš Bizjak  changed:

   What|Removed |Added

 CC||amylaar at gcc dot gnu.org,
   ||olegendo at gcc dot gnu.org

--- Comment #4 from Uroš Bizjak  ---
Adding some CCs for targets that also use mode switching pass.

[Bug rtl-optimization/58679] [4.9 regression] ICE in create_pre_exit, at mode-switching.c:421 with -mavx after r202915

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58679

--- Comment #3 from Uroš Bizjak  ---
For reference, the discussion of the change that removed REG_DEAD and
REG_UNUSED notes, started at [1].

[1] http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01781.html

[Bug rtl-optimization/58679] [4.9 regression] ICE in create_pre_exit, at mode-switching.c:421 with -mavx after r202915

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58679

--- Comment #2 from Uroš Bizjak  ---
The compile failure with the testcase from Comment #0 has gone latent, but the
problem looks similar to PR 58792 [1].

On a related note, the allocator introduces extra move for pr30185.c testcase
that results in:

foo:
movq%rsi, %rax
cqto
idivq   %rcx
movq%rax, %rsi < here (*)
xorl%eax, %eax
movq%rsi, %rdx
ret

"movq %rax, %rdx" should be emitted at (*).

[1] http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01606.html

[Bug rtl-optimization/58679] [4.9 regression] ICE in create_pre_exit, at mode-switching.c:421 with -mavx after r202915

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58679

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-10-26
   Host|x86 |
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
The patch at [1] now removes useless moves in the exit bb. This change breaks
assumption in the mode-switching pass that all USEs of return values have a
corresponding simple return value copy somewhere up in the insn stream.

The testcase:

--cut here--
typedef long long __m128i __attribute__ ((__vector_size__ (16)));
typedef char __v16qi __attribute__ ((__vector_size__ (16)));


__m128i _mm_cmpistrm (__m128i __X, __m128i __Y, const int __M)
{
  return (__m128i) __builtin_ia32_pcmpistrm128((__v16qi)__X, (__v16qi)__Y, 1);
}
--cut here--

Before the above change, RA generated:

(insn 2 6 3 2 (set (reg/v:V2DI 21 xmm0 [orig:92 __X ] [92])
(reg:V2DI 21 xmm0 [ __X ])) tt.c:6 1156 {*movv2di_internal}
 (nil))
(note 3 2 5 2 NOTE_INSN_DELETED)
(note 5 3 20 2 NOTE_INSN_FUNCTION_BEG)
(insn 20 5 14 2 (parallel [
(set (reg:V16QI 21 xmm0 [95])
(unspec:V16QI [
(reg:V16QI 21 xmm0 [orig:92 __X ] [92])
(reg:V16QI 22 xmm1 [ __Y ])
(const_int 1 [0x1])
] UNSPEC_PCMPISTR))
(set (reg:CC 17 flags)
(unspec:CC [
(reg:V16QI 21 xmm0 [orig:92 __X ] [92])
(reg:V16QI 22 xmm1 [ __Y ])
(const_int 1 [0x1])
] UNSPEC_PCMPISTR))
]) tt.c:7 1979 {sse4_2_pcmpistrm}
 (nil))
(insn 14 20 17 2 (set (reg/i:V2DI 21 xmm0)
(reg:V2DI 21 xmm0 [95])) tt.c:8 1156 {*movv2di_internal}
 (nil))
(insn 17 14 21 2 (use (reg/i:V2DI 21 xmm0)) tt.c:8 -1
 (nil))

Please note useless (insn 14), expected by mode switching pass (this insn was
actually removed by later passes). After the change, following insn stream is
generated:

(insn 20 5 17 2 (parallel [
(set (reg:V16QI 21 xmm0 [95])
(unspec:V16QI [
(reg:V16QI 21 xmm0 [orig:92 __X ] [92])
(reg:V16QI 22 xmm1 [ __Y ])
(const_int 1 [0x1])
] UNSPEC_PCMPISTR))
(set (reg:CC 17 flags)
(unspec:CC [
(reg:V16QI 21 xmm0 [orig:92 __X ] [92])
(reg:V16QI 22 xmm1 [ __Y ])
(const_int 1 [0x1])
] UNSPEC_PCMPISTR))
]) tt.c:7 1979 {sse4_2_pcmpistrm}
 (nil))
(insn 17 20 21 2 (use (reg/i:V2DI 21 xmm0)) tt.c:8 -1
 (nil))

There is no return value copy insn.

The assumption in the mode switching pass, that there is a return value copy is
not correct anymore, due to recent enhancements in the RA. The mode switching
pass should perform life analysis by itself. Simply looking for a return copy
is not correct anymore.

Confirmed by above testcase.

[Bug ada/58881] GNAT crashes with bug box when trying to instantiate a generic package

[contact at flyx dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58881

--- Comment #4 from Felix  ---
Oh sorry, forgot to mention: Simplified code can be compiled with:

gnatchop simplified.adb
gnatmake bug-proc.adb

[Bug ada/58881] GNAT crashes with bug box when trying to instantiate a generic package

[contact at flyx dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58881

Felix  changed:

   What|Removed |Added

  Attachment #31089|0   |1
is obsolete||

--- Comment #3 from Felix  ---
Created attachment 31091
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31091&action=edit
Simplified code to reproduce the crash (extract with gnatchop)

I managed to create a minimal code example to reproduce the bug. The bug only
occurs when:

 * Bug.Tagged_Type has a determinant.
 * Bug.Generic_Package.Derived2 is present.
 * Bug.Instances instantiates Bug.Generic_Package.