ICE happens in in expand_expr_addr_expr_1 because the result is (reg/v:TI 86 [ func ]), which is obviously no memory.
Issue seems here to be that x64 ABI has pre-allocated stack-area on call, so for the first 4 arguments no stack-allocation is necessary.  So we might need to specialize allocate_stack_slots_for_args-hook for this target.

Interestingly, I have the exact same error while compiling some C++ code in Qt5 on an ARM platform:

svg/SVGPathElement.h: In member function 'virtual WebCore::FloatRect WebCore::SVGPathElement::_ZTv0_n24_N7WebCore14SVGPathElement7getBBoxENS_12SVGLocatable19StyleUpdateStrategyE(WebCore::SVGLocatable::StyleUpdateStrategy)':
svg/SVGPathElement.h:95:23: internal compiler error: in expand_expr_addr_expr_1, at expr.c:7669
     virtual FloatRect getBBox(StyleUpdateStrategy = AllowStyleUpdate);
                       ^
Please submit a full bug report,
with preprocessed source if appropriate.

The file is also built with -Os. This is with gcc 4.9.1.

More build output at http://autobuild.buildroot.org/results/9fd/9fdbe9bb3bd32276f9793fa60d802756811c1abe/build-end.log.

Hmm, does it help to specify additional option '-fno-ms-extensions'?

(In reply to Kai Tietz from comment #3)
> Hmm, does it help to specify additional option '-fno-ms-extensions'?

No, it doesn't help. In fact in my case, it isn't a -Os problem, but a -O3 problem. I had both the compile command line, with -O3 being last. So in the end, I tested the following cases:

* -O2 -> builds fine
* -Os -> builds fine
* -O3 -> breaks
* -O3 -fno-ms-extensions -> breaks

If you want to have a look at the code, I've put the pre-processed version of the file at http://free-electrons.com/~thomas/pub/SVGAllInOne.cpp.xz.

I'm able to reproduce the bug under Ubuntu, using the Ubuntu ARM g++ compiler, which uses gcc 4.9.1 :

# Default -> OK

thomas@skate:/tmp$ arm-linux-gnueabihf-g++ -c SVGAllInOne.cpp 

# -O2 -> OK

thomas@skate:/tmp$ arm-linux-gnueabihf-g++ -O2 -c SVGAllInOne.cpp 

# -Os -> OK

thomas@skate:/tmp$ arm-linux-gnueabihf-g++ -Os -c SVGAllInOne.cpp 

# -O3 -> NOK

thomas@skate:/tmp$ arm-linux-gnueabihf-g++ -O3 -c SVGAllInOne.cpp 
In file included from svg/SVGAnimateMotionElement.cpp:37:0,
                 from svg/SVGAllInOne.cpp:36:
svg/SVGPathElement.h: In member function ‘virtual WebCore::FloatRect WebCore::SVGPathElement::_ZTv0_n24_N7WebCore14SVGPathElement7getBBoxENS_12SVGLocatable19StyleUpdateStrategyE(WebCore::SVGLocatable::StyleUpdateStrategy)’:
svg/SVGPathElement.h:95:23: internal compiler error: in expand_expr_addr_expr_1, at expr.c:7649
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.9/README.Bugs> for instructions.
Preprocessed source stored into /tmp/cccMXXZg.out file, please attach this to your bugreport.

# -O3 -fno-ms-extensions -> NOK

thomas@skate:/tmp$ arm-linux-gnueabihf-g++ -O3 -fno-ms-extensions -c SVGAllInOne.cpp 
In file included from svg/SVGAnimateMotionElement.cpp:37:0,
                 from svg/SVGAllInOne.cpp:36:
svg/SVGPathElement.h: In member function ‘virtual WebCore::FloatRect WebCore::SVGPathElement::_ZTv0_n24_N7WebCore14SVGPathElement7getBBoxENS_12SVGLocatable19StyleUpdateStrategyE(WebCore::SVGLocatable::StyleUpdateStrategy)’:
svg/SVGPathElement.h:95:23: internal compiler error: in expand_expr_addr_expr_1, at expr.c:7649
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.9/README.Bugs> for instructions.

Beware that the C++ source file is 7 MB in size, and takes a little while to build:

$ time arm-linux-gnueabihf-g++ -O2 -c SVGAllInOne.cpp 
real	0m32.544s
user	0m32.032s
sys	0m0.431s

This also happens when compiling Boost 1.57.0. I've reproduced it using TDM64-GCC (version 4.9.2-3) and Stephan T. Lavavej's MinGW distribution (version 12.2).

How to reproduce:

- Unpack Boost 1.57.0 and change into source directory
- g++ -v -save-temps -Os -I. libs\test\src\unit_test_parameters.cpp

As mentioned in earlier comments, -O{1,2,3} work and only -Os produced an ICE. I'm not attaching 2.3 MB preprocessed file due to the wide availability of Boost sources.

at least on arm-linux-gnueabihf, this is a regression in 4.9 (seen with -Os and -O3), works on the trunk.

$ g++ -c -O3 moc_workplane.ii 
moc_workplane.ii: In member function 'virtual A C<int>::_ZTv0_n12_NK1CIiE5m_fn1Ev() const':
moc_workplane.ii:8:45: internal compiler error: in expand_expr_addr_expr_1, at expr.c:7634
 template <typename> class C : virtual B { A m_fn1() const; };
                                             ^
Please submit a full bug report,
with preprocessed source if appropriate.

$ cat moc_workplane.ii 
class A {
  float xp;
  float yp;
};
class B {
  virtual A m_fn1() const;
};
template <typename> class C : virtual B { A m_fn1() const; };
class D : C<int> {
  virtual const int *m_fn2() const;
};
template <typename T> A C<T>::m_fn1() const { return A(); }
const int *D::m_fn2() const {}

For the testcase in comment #6, it works if i use -fno-tree-sra.


diff -u6 nok/pr1314.c.022t.forwprop1  nok/pr1314.c.024t.esra 
--- nok/pr1314.c.022t.forwprop1	2015-03-07 16:16:43.839799627 +1100
+++ nok/pr1314.c.024t.esra	2015-03-07 16:16:43.839799627 +1100
@@ -25,24 +25,38 @@
 }
 
 ;; Function virtual A C<int>::_ZTv0_n12_NK1CIiE5m_fn1Ev() const (_ZTv0_n12_NK1CIiE5m_fn1Ev, funcdef_no=3, decl_uid=4649, symbol_order=12)
 
+Created a replacement for D.4707 offset: 0, size: 32: SR.6
+Created a replacement for D.4707 offset: 32, size: 32: SR.7
+Removing load: <retval> = D.4707;
+
+Symbols to be put in SSA form
+{ D.4697 D.4708 D.4709 }
+Incremental SSA update started at block: 0
+Number of blocks in CFG: 3
+Number of blocks to update: 2 ( 67%)
+
+
 virtual A C<int>::_ZTv0_n12_NK1CIiE5m_fn1Ev() const (const struct C * const this)
 {
+  float SR.7;
+  float SR.6;
   struct A D.4707;
   const struct C * adjusted_this.3;
   int (*<Tdf0>) () vcalloffset.2;
   int (*<Tdf0>) () * vtableaddr.1;
   int (*<Tdf0>) () * * vptr.0;
   struct A <retval>;
 
   <bb 2>:
-  D.4707.xp = 0.0;
-  D.4707.yp = 0.0;
-  <retval> = D.4707;
+  SR.6_12 = 0.0;
+  SR.7_11 = 0.0;
+  MEM[(struct A *)&<retval>] = SR.6_12;
+  MEM[(struct A *)&<retval> + 4B] = SR.7_11;
   return <retval>;
 
 }

Regarding https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61207#c5

It's not a question of being able to get the source code, it's about reducing the code to the minimum amount that exhibits the bug. In the old days (maybe still now?) gccbug would be used, now-a-days, creduce works well. Here is the testcase from Boost:

// reduced test case:

namespace std {
class basic_string typedef string;
class basic_string {
public:
  basic_string(char *, unsigned);
};
}
class A {
public:
  A(char);
  size();
  char *begin();
  *m_begin;
  *m_end;
};
enum output_format {};
namespace std {
class runtime_error {
public:
  runtime_error(string);
};
}
struct B : std::runtime_error {
  B(A m) : runtime_error(std::string(m.begin(), m.size())) {}
};
fn1(int, output_format) {
  B(0);
  B(0);
}

// elapsed time: 30405 seconds

Compiling with MSYS2's mingw64/mingw-w64-x86_64-gcc 4.9.2-4 package with:
/mingw64/bin/g++ -Os testcase.ii

Gives:
internal compiler error: in expand_expr_addr_expr_1, at expr.c:7669

well, it might be same issue, but on x64 target the testcase of comment #6 works without issues.
As SRA seems to be involved here, the changes on trunk for DOM might be the solution.

This is a duplicate of PR64896 and was fixed on trunk at r220489.

I've backported and tested on Linaro 4.9 branch and will prepare the backport on FSF 4.9.

Yvan

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