[Bug fortran/64416] New: RFE: Support REAL128 on arm

[orion at cora dot nwra.com]

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

Bug ID: 64416
   Summary: RFE: Support REAL128 on arm
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: orion at cora dot nwra.com

SUBROUTINE PMPI_Sizeof_complex128_scalar(x, size, ierror)
USE, INTRINSIC :: iso_fortran_env, ONLY: REAL128
  COMPLEX(REAL128)::x
INTEGER, INTENT(OUT) :: size
INTEGER, INTENT(OUT) :: ierror

size = storage_size(x) / 8
ierror = 0
  END SUBROUTINE PMPI_Sizeof_complex128_scalar

gfortran -c psizeof_f.f90 
psizeof_f.f90:3.21:

  COMPLEX(REAL128)::x
 1
Error: Kind -1 not supported for type COMPLEX at (1)

Linux fedora-rawhide-arm 3.18.1-2.fc22.armv7hl+lpae #1 SMP Fri Dec 19 00:19:30
UTC 2014 armv7l armv7l armv7l GNU/Linux

Is it possible to add support for this, or can the architecture not handle it?

[Bug middle-end/64415] New: [5 Regression] ICE: verify_ssa failed / segmentation fault with LTO

[d.g.gorbachev at gmail dot com]

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

Bug ID: 64415
   Summary: [5 Regression] ICE: verify_ssa failed / segmentation
fault with LTO
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d.g.gorbachev at gmail dot com

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

With testcase 1:

foo.c: In function 'foo':
foo.c:5:6: internal compiler error: Segmentation fault
 void foo()
  ^
0x87fd6b8 crash_signal
../../gcc-5/gcc/toplev.c:359
0x8a2d417 gimple_code
../../gcc-5/gcc/gimple.h:1545
0x8a2e0a6 gimple_nop_p
../../gcc-5/gcc/gimple.h:5589
0x8a30bac verify_use
../../gcc-5/gcc/tree-ssa.c:769
0x8a3166c verify_ssa(bool, bool)
../../gcc-5/gcc/tree-ssa.c:1024
0x8713cdb execute_function_todo
../../gcc-5/gcc/passes.c:1947
0x8712dfe do_per_function
../../gcc-5/gcc/passes.c:1632
0x8713e85 execute_todo
../../gcc-5/gcc/passes.c:1997

With testcase 2:

foo.c: In function 'foo':
foo.c:5:6: error: definition in block 3 does not dominate use in block 2
 void foo()
  ^
for SSA_NAME: _2 in statement:
# DEBUG p => _2
foo.c:5:6: internal compiler error: verify_ssa failed
0x8a318dc verify_ssa(bool, bool)
../../gcc-5/gcc/tree-ssa.c:1062
0x8713cdb execute_function_todo
../../gcc-5/gcc/passes.c:1947
0x8712dfe do_per_function
../../gcc-5/gcc/passes.c:1632
0x8713e85 execute_todo
../../gcc-5/gcc/passes.c:1997

GCC 5.0.0 20141226 (experimental) /r219070/.

[Bug target/36557] -m32 -mpowerpc64 produces better code than -m64 for a!=0

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Still happens.  It now does

cntlzw 3,3
srwi 3,3,5
xori 3,3,0x1
rldicl 3,3,0,63
blr

which is better but not exactly ideal yet.

[Bug c++/64414] cc1plus: internal compiler error: Segmentation fault

[jpyeron at pdinc dot us]

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

--- Comment #1 from Jason Pyeron  ---
In an attempt to be lazy, I added a .h file to refer to a .h file in the parent
directory.

2154b9ff583610a5ab97821ed6b45646df2f4e2b:src/Main/Unix/System.h:
#include "../System.h"

removing that file eliminates the crash.

[Bug lto/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[iverbin at gcc dot gnu.org]

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

--- Comment #2 from iverbin at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #1)
> (In reply to iverbin from comment #0)
> > To reproduce using Intel Xeon Phi emulation:
> > 1. Build offload and host compilers as described in
> > https://gcc.gnu.org/wiki/Offloading#How_to_try_offloading_enabled_GCC
> > 2. Run make check-target-libgomp RUNTESTFLAGS="c.exp=e.53.5.c"
> 
> Can you create a stanalone testcase for the Intel Xeon Phi offload
> cross compiler?  It will be easier to debug.

The offload model in GCC implies 2 compilers: one produces IR for OpenMP target
regions, and another compiles this IR for Intel Xeon Phi.
There is no single compiler, which could stream offload IR out, then stream it
in, and then compile.
I can reduce e.53.5.c testcase, not sure whether this is helpful.

[Bug c++/64414] New: cc1plus: internal compiler error: Segmentation fault

[jpyeron at pdinc dot us]

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

Bug ID: 64414
   Summary: cc1plus: internal compiler error: Segmentation fault
   Product: gcc
   Version: 4.4.7
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jpyeron at pdinc dot us

Centos/RHEL 6: gcc-c++-4.4.7-11.el6.x86_64

root@twelve-233 ~/CipherShed/src/Main
# g++ -MMD -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGE_FILES
-I/root/CipherShed/src -I/root/CipherShed/src/Crypto -O2 -fno-strict-aliasing  
-D TC_ARCH_X64 -DTC_UNIX -DTC_LINUX -fdata-sections -ffunction-sections -Wall
-Wno-unused-parameter  -I/root/CipherShed/src/Main
-I/usr/lib64/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8
-D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -c Unix/Main.cpp -o
Unix/Main.o
cc1plus: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccYM4plV.out file, please attach this to
your bugreport.

[Bug lto/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-12-26
 CC||hjl.tools at gmail dot com
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
(In reply to iverbin from comment #0)
> After fixing PR lto/64043 (r218767) the offload target compiler began
> crashing while reading intermediate bytecode.
> 
> FAIL: libgomp.c/examples-4/e.53.5.c (internal compiler error)
> FAIL: libgomp.c/for-3.c (internal compiler error)
> FAIL: libgomp.c++/for-11.C (internal compiler error)
> FAIL: libgomp.fortran/examples-4/e.53.3.f90   -O2  (internal compiler error)
> etc.
> 
> 
> To reproduce using Intel Xeon Phi emulation:
> 1. Build offload and host compilers as described in
> https://gcc.gnu.org/wiki/Offloading#How_to_try_offloading_enabled_GCC
> 2. Run make check-target-libgomp RUNTESTFLAGS="c.exp=e.53.5.c"

Can you create a stanalone testcase for the Intel Xeon Phi offload
cross compiler?  It will be easier to debug.

[Bug target/64409] ICE building Mesa 10.4.0 for x32 ABI

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.5

--- Comment #5 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01875.html

[Bug target/64409] ICE building Mesa 10.4.0 for x32 ABI

[steven at uplinklabs dot net]

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

--- Comment #4 from Steven Noonan  ---
Ahh, didn't even think about an x32/ms_abi compatibility problems. That totally
makes sense. It probably shouldn't work anyway, but an ICE is obviously not the
right reaction from the compiler. What I should be doing is passing
--disable-nine to the Mesa configure script and it will just skip the
ms_abi-dependent features.

[Bug middle-end/64413] New: [AArch64/ARMv7] ICE in copy_to_mode_reg, at explow.c:654

[david.abdurachmanov at gmail dot com]

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

Bug ID: 64413
   Summary: [AArch64/ARMv7] ICE in copy_to_mode_reg, at
explow.c:654
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.abdurachmanov at gmail dot com

Created attachment 34338
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34338&action=edit
testcase (AArch64, Fortran)

OpenLoops 1.0.1 package is failing to compile on AArch64 with GCC 4.9.{1,2}
there gfortran ICE'd:

test.f90: In function 'vert_aq_s':
test.f90:38:0: internal compiler error: in copy_to_mode_reg, at explow.c:654
 Jout_S%j(1) = 0
 ^

I managed to extract a minimal testcase (testcase.f90). It should be compiled
like this:

gfortran -o testcase.os -c -ffixed-line-length-0 -ffree-line-length-0 -O0 -O0
-fPIC testcase.f90

A similar ICE was recently posted (Oct 20) with GCC 4.9.1, ARMv7, C++ on
stackoverflow:
http://stackoverflow.com/questions/26474507/compiler-crash-with-arm-neon-datatypes

I.e., the ICE point to the same "copy_to_mode_reg, at explow.c:654". Might be
related.

Have not tested with GCC 5.0 (trunk).

[Bug libstdc++/58876] No non-virtual-dtor warning in std::unique_ptr

[mw_triad at users dot sourceforge.net]

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

--- Comment #9 from Matthew Woehlke  ---
(In reply to Jonathan Wakely from comment #8)
> No, really, that's not how make_unique works. You do not use 'new' with
> make_unique, that's the whole point [...]

D'oh, sorry :-). Not sure what I was thinking. I think I meant
'unique_ptr(new B)', like to the original example. That said...

> unique_ptr p = make_unique();

...this is also a good example that I would like to see warn. (I think this has
the same problems; the warning would need to trigger in the conversion
operator, otherwise the knowledge of the true type is lost by the time the
unique_ptr is destroyed.)

[Bug fortran/59198] [4.8/4.9/5 Regression] ICE on cyclically dependent polymorphic types

[dominiq at lps dot ens.fr]

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

--- Comment #18 from Dominique d'Humieres  ---
> However, it is a patch that doesn't do the job.
>
> Cheers
>
> Paul

Almost!

[Bug fortran/59198] [4.8/4.9/5 Regression] ICE on cyclically dependent polymorphic types

[paul.richard.thomas at gmail dot com]

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

--- Comment #17 from paul.richard.thomas at gmail dot com  ---
However, it is a patch that doesn't do the job.

Cheers

Paul
On Dec 26, 2014 2:35 PM, "dominiq at lps dot ens.fr" <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59198
>
> --- Comment #16 from Dominique d'Humieres  ---
> For the record a patch has been submitted at
> https://gcc.gnu.org/ml/fortran/2014-03/msg00165.html.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

[Bug tree-optimization/63743] Thumb1: big regression for float operators by r216728

[ysrumyan at gmail dot com]

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

Yuri Rumyantsev  changed:

   What|Removed |Added

 CC||ysrumyan at gmail dot com

--- Comment #6 from Yuri Rumyantsev  ---
We also noticed regression on x86 32-bit targets after this fix and prepared a
simple fix which cures it: swap operands of commutative operations is performed
if cost of second operand is higher than the first one (the operand cost is
number of statements required for producing it). It is done at expand phase
inside expand_gimple_basic_block.

[Bug fortran/60507] Passing function call into procedure argument not caught

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
What is the status of the patch in comment 4?

[Bug fortran/59198] [4.8/4.9/5 Regression] ICE on cyclically dependent polymorphic types

[dominiq at lps dot ens.fr]

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

--- Comment #16 from Dominique d'Humieres  ---
For the record a patch has been submitted at
https://gcc.gnu.org/ml/fortran/2014-03/msg00165.html.

[Bug target/64409] ICE building Mesa 10.4.0 for x32 ABI

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com

--- Comment #3 from H.J. Lu  ---
(In reply to Markus Trippelsdorf from comment #2)
> x32 doesn't handle the ms_abi attribute:
> 
> markus@x4 tmp % cat getproc.i
> int a;
> int* __attribute__ ((ms_abi)) fn1 () { return &a; }
> 
> markus@x4 tmp % gcc -mx32 -O2 -c getproc.i
> getproc.i: In function ‘fn1’:
> getproc.i:2:47: internal compiler error: in emit_move_insn, at expr.c:3583

There is no counter part of x32 in MS ABI.  I can issue an error.  How should
the ms_abi attribute even work in x32?

[Bug c++/64410] gcc 25% slower than clang 3.5 for adding complex numbers

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
(In reply to Conrad from comment #2)
> (In reply to Marc Glisse from comment #1)
> > 3) the ABI for complex uses 2 separate double instead of a vector of 2
> > double.
> 
> Technically yes, but in practice aren't the 2 separate doubles guaranteed to
> be consecutive in memory?

When the complex is in memory, yes. But passing a complex by value to a
function is done with 2 separate registers. And somehow that means the default
expansion for complex addition is 2 addsd, whereas the default expansion for
vector addition is addpd. Using addpd by default for complex would make some
code better (this example would hopefully be optimal without need for any
optimization) and some worse, I don't know if there are good benchmarks for
complex numbers.

Clang's use of add[ps]d seems based entirely on what is done with the result,
as can be seen on:

typedef _Complex double cd;
void f(cd&r,cd x,cd y){
  r=x+y;
}
cd f(cd&x,cd&y,cd&z){
  return x+y+z;
}

(I agree that gcc should be improved, I am not trying to defend the current
code generation. And now I'll shut up and let people who actually know the code
speak ;-)

[Bug lto/63923] FAIL: libgomp.c/examples-4/e.50.1.c (test for excess errors)

[iverbin at gcc dot gnu.org]

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

iverbin at gcc dot gnu.org changed:

   What|Removed |Added

 CC||iverbin at gcc dot gnu.org

--- Comment #2 from iverbin at gcc dot gnu.org ---
This issue is fixed by r217773

[Bug lto/64412] New: [regression] ICE in offload compiler: in extract_insn, at recog.c:2327

[iverbin at gcc dot gnu.org]

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

Bug ID: 64412
   Summary: [regression] ICE in offload compiler: in extract_insn,
at recog.c:2327
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iverbin at gcc dot gnu.org
CC: bernds at gcc dot gnu.org, hubicka at gcc dot gnu.org,
kyukhin at gcc dot gnu.org, tschwinge at gcc dot gnu.org

After fixing PR lto/64043 (r218767) the offload target compiler began crashing
while reading intermediate bytecode.

FAIL: libgomp.c/examples-4/e.53.5.c (internal compiler error)
FAIL: libgomp.c/for-3.c (internal compiler error)
FAIL: libgomp.c++/for-11.C (internal compiler error)
FAIL: libgomp.fortran/examples-4/e.53.3.f90   -O2  (internal compiler error)
etc.


To reproduce using Intel Xeon Phi emulation:
1. Build offload and host compilers as described in
https://gcc.gnu.org/wiki/Offloading#How_to_try_offloading_enabled_GCC
2. Run make check-target-libgomp RUNTESTFLAGS="c.exp=e.53.5.c"


libgomp/testsuite/libgomp.c/examples-4/e.53.5.c: In function 'accum._omp_fn.1':
libgomp/testsuite/libgomp.c/examples-4/e.53.5.c:53:13: error: unrecognizable
insn:
 #pragma omp parallel for reduction(+:tmp)
 ^
(insn 176 66 177 4 (set (reg:DI 0 ax)
(symbol_ref:DI ("Q") )) -1
 (nil))
libgomp/testsuite/libgomp.c/examples-4/e.53.5.c:53:13: internal compiler error:
in extract_insn, at recog.c:2327
0xbadaf7 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
gcc/rtl-error.c:110
0xbadb38 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
gcc/rtl-error.c:118
0xb60522 extract_insn(rtx_insn*)
gcc/recog.c:2327
0xb60221 extract_constrain_insn(rtx_insn*)
gcc/recog.c:2228
0xb6e973 copyprop_hardreg_forward_1
gcc/regcprop.c:773
0xb701db execute
gcc/regcprop.c:1279
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
mkoffload-intelmic: fatal error:
x86_64-pc-linux-gnu-accel-x86_64-intelmicemul-linux-gnu-gcc returned 1 exit
status
compilation terminated.
lto-wrapper: fatal error: accel/x86_64-intelmicemul-linux-gnu/mkoffload
returned 1 exit status
compilation terminated.
ld: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug c++/64410] gcc 25% slower than clang 3.5 for adding complex numbers

[conradsand.arma at gmail dot com]

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

--- Comment #2 from Conrad  ---
(In reply to Marc Glisse from comment #1)
> 3) the ABI for complex uses 2 separate double instead of a vector of 2
> double.

Technically yes, but in practice aren't the 2 separate doubles guaranteed to be
consecutive in memory?

[Bug target/64411] New: ICE: in verify_target_availability, at sel-sched.c:1577 with -Os -mcmodel=medium -fPIC -fschedule-insns -fselective-scheduling

[zsojka at seznam dot cz]

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

Bug ID: 64411
   Summary: ICE: in verify_target_availability, at
sel-sched.c:1577 with -Os -mcmodel=medium -fPIC
-fschedule-insns -fselective-scheduling
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz

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

Compiler output:
$ gcc -Os -mcmodel=medium -fPIC -fschedule-insns -fselective-scheduling
testcase.C
testcase.C: In function 'void checkx813()':
testcase.C:24:1: internal compiler error: in verify_target_availability, at
sel-sched.c:1577
 }
 ^
0xdd8489 verify_target_availability
/mnt/svn/gcc-trunk/gcc/sel-sched.c:1577
0xdd8489 find_best_reg_for_expr
/mnt/svn/gcc-trunk/gcc/sel-sched.c:1692
0xdd8489 fill_vec_av_set
/mnt/svn/gcc-trunk/gcc/sel-sched.c:3805
0xddab77 fill_ready_list
/mnt/svn/gcc-trunk/gcc/sel-sched.c:4035
0xddab77 find_best_expr
/mnt/svn/gcc-trunk/gcc/sel-sched.c:4398
0xddab77 fill_insns
/mnt/svn/gcc-trunk/gcc/sel-sched.c:5565
0xddc815 schedule_on_fences
/mnt/svn/gcc-trunk/gcc/sel-sched.c:7390
0xddc815 sel_sched_region_2
/mnt/svn/gcc-trunk/gcc/sel-sched.c:7528
0xddf60d sel_sched_region_1
/mnt/svn/gcc-trunk/gcc/sel-sched.c:7570
0xddf60d sel_sched_region(int)
/mnt/svn/gcc-trunk/gcc/sel-sched.c:7671
0xde0851 run_selective_scheduling()
/mnt/svn/gcc-trunk/gcc/sel-sched.c:7747
0xdb650d rest_of_handle_sched
/mnt/svn/gcc-trunk/gcc/sched-rgn.c:3633
0xdb650d execute
/mnt/svn/gcc-trunk/gcc/sched-rgn.c:3743
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Tested revisions:
r219067 - ICE
4_9 r219040 - ICE
4_8 r218176 - ICE
4_7 r211571 - spill failure
4_6 r197894 - spill failure

[Bug c++/64410] gcc 25% slower than clang 3.5 for adding complex numbers

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
There are a number of things that make it complicated.
1) gcc doesn't like to vectorize when the number of iterations is not known at
compile time.
2) gcc doesn't vectorize anything already involving complex or vector
operations.
3) the ABI for complex uses 2 separate double instead of a vector of 2 double.

I believe there are dups at least for 2).

[Bug target/64409] ICE building Mesa 10.4.0 for x32 ABI

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Severity|major   |normal

[Bug target/64409] ICE building Mesa 10.4.0 for x32 ABI

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Target||x32
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-12-26
 CC||hjl.tools at gmail dot com,
   ||trippels at gcc dot gnu.org
  Component|middle-end  |target
 Ever confirmed|0   |1
  Known to fail||4.8.4, 4.9.2, 5.0

--- Comment #2 from Markus Trippelsdorf  ---
x32 doesn't handle the ms_abi attribute:

markus@x4 tmp % cat getproc.i
int a;
int* __attribute__ ((ms_abi)) fn1 () { return &a; }

markus@x4 tmp % gcc -mx32 -O2 -c getproc.i
getproc.i: In function ‘fn1’:
getproc.i:2:47: internal compiler error: in emit_move_insn, at expr.c:3583

[Bug tree-optimization/64406] [5 Regression] ICE: SIGSEGV in estimate_numbers_of_iterations_loop (tree-ssa-loop-niter.c:3453) with custom flags

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-12-26
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Revision r211698 (2014-06-16) is OK, r212119 (2014-06-29) gives the ICE.