[Bug c++/100041] New: ICE in curr_insn_transform, at lra-constraints.c:4022

[Bug c++/100041] New: ICE in curr_insn_transform, at lra-constraints.c:4022

[mss at tutanota dot de]

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

            Bug ID: 100041
           Summary: ICE in curr_insn_transform, at lra-constraints.c:4022
           Product: gcc
           Version: 10.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mss at tutanota dot de
  Target Milestone: ---

When trying to build LLVM 11.1.0 with GCC 10.3.0 on an x86_64 linux musl
(1.2.1) host, i am getting this ICE:

In file included from
/mss/work/table/llvm-project-llvmorg-11.1.0/llvm/lib/Support/ItaniumManglingCanonicalizer.cpp:13:
/mss/work/table/llvm-project-llvmorg-11.1.0/llvm/include/llvm/Demangle/ItaniumDemangle.h:
In member function 'void
llvm::itanium_demangle::FloatLiteralImpl<Float>::printLeft(llvm::itanium_demangle::OutputStream&)
const [with Float = long double]':
/mss/work/table/llvm-project-llvmorg-11.1.0/llvm/include/llvm/Demangle/ItaniumDemangle.h:2144:3:
error: unable to generate reloads for:
 2144 |   }
      |   ^
(insn 157 156 158 8 (set (mem:XF (pre_modify:DI (reg/f:DI 7 sp)
                (plus:DI (reg/f:DI 7 sp)
                    (const_int -16 [0xfffffffffffffff0]))) [485  S12 A32])
        (mem/j/c:XF (reg/f:DI 19 frame) [0 D.132846.value+0 S12 A64]))
"/mss/work/table/llvm-project-llvmorg-11.1.0/llvm/include/llvm/Demangle/ItaniumDemangle.h":2141:23
105 {*pushxf}
     (expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
        (nil)))
during RTL pass: reload
/mss/work/table/llvm-project-llvmorg-11.1.0/llvm/include/llvm/Demangle/ItaniumDemangle.h:2144:3:
internal compiler error: in curr_insn_transform, at lra-constraints.c:4022
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug target/100041] ICE in curr_insn_transform, at lra-constraints.c:4022

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
             Target|                            |x86_64-linux-musl
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2021-04-12
          Component|c++                         |target

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Can you attach the preprocessed source?

[Bug target/100041] ICE in curr_insn_transform, at lra-constraints.c:4022

[mss at tutanota dot de]

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

--- Comment #2 from mss at tutanota dot de ---
Created attachment 50563
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50563&action=edit
Preprocessed llvm/include/llvm/Demangle/ItaniumDemangle.h

[Bug target/100041] ICE in curr_insn_transform, at lra-constraints.c:4022

[mss at tutanota dot de]

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

--- Comment #3 from mss at tutanota dot de ---
Created attachment 50564
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50564&action=edit
Preprocessed llvm/lib/Support/ItaniumManglingCanonicalizer.cpp

[Bug target/100041] ICE in curr_insn_transform, at lra-constraints.c:4022

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
... and what compiler options do you use please? Please paste output of
--verbose argument.

[Bug target/100041] ICE in curr_insn_transform, at lra-constraints.c:4022

[mss at tutanota dot de]

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

--- Comment #5 from mss at tutanota dot de ---
(In reply to Martin Liška from comment #4)
> ... and what compiler options do you use please? Please paste output of
> --verbose argument.

 0 ~: gcc --verbose
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-apathy-linux-musl/10.3.0/lto-wrapper
Target: x86_64-apathy-linux-musl
Configured with: ../configure --prefix=/usr --libexecdir=/usr/libexec
--mandir=/usr/share/man --infodir=/usr/share/info
--host=x86_64-apathy-linux-musl --build=x86_64-apathy-linux-musl
--target=x86_64-apathy-linux-musl --with-pkgversion=apathy
--enable-checking=release --enable-languages=c,c++,lto --enable-cxx-flags='-w
-pipe -O2 -mtune=native -march=native' --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-linker-build-id --enable-lto
--enable-plugin --enable-shared --enable-threads=posix --enable-tls
--without-included-gettext --without-isl --enable-bootstrap
--disable-default-pie --disable-default-ssp --disable-fixed-point
--disable-libmpx --disable-libmudflap --disable-libsanitizer
--disable-libstdcxx-pch --disable-multilib --disable-nls --disable-rpath
--disable-static --disable-symvers --disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.3.0 (apathy)

[Bug target/100041] ICE in curr_insn_transform, at lra-constraints.c:4022

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to mss from comment #5)
> (In reply to Martin Liška from comment #4)
> > ... and what compiler options do you use please? Please paste output of
> > --verbose argument.
> 
>  0 ~: gcc --verbose
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-apathy-linux-musl/10.3.0/lto-
> wrapper
> Target: x86_64-apathy-linux-musl
> Configured with: ../configure --prefix=/usr --libexecdir=/usr/libexec
> --mandir=/usr/share/man --infodir=/usr/share/info
> --host=x86_64-apathy-linux-musl --build=x86_64-apathy-linux-musl
> --target=x86_64-apathy-linux-musl --with-pkgversion=apathy
> --enable-checking=release --enable-languages=c,c++,lto
> --enable-cxx-flags='-w -pipe -O2 -mtune=native -march=native'
> --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
> --enable-linker-build-id --enable-lto --enable-plugin --enable-shared
> --enable-threads=posix --enable-tls --without-included-gettext --without-isl
> --enable-bootstrap --disable-default-pie --disable-default-ssp
> --disable-fixed-point --disable-libmpx --disable-libmudflap
> --disable-libsanitizer --disable-libstdcxx-pch --disable-multilib
> --disable-nls --disable-rpath --disable-static --disable-symvers
> --disable-werror
> Thread model: posix
> Supported LTO compression algorithms: zlib zstd
> gcc version 10.3.0 (apathy)

I need to see the output of --verbose for the compilation invocation that ends
with the internal compiler error.

[Bug target/100041] ICE in curr_insn_transform, at lra-constraints.c:4022

[mss at tutanota dot de]

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

--- Comment #7 from mss at tutanota dot de ---
Created attachment 50565
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50565&action=edit
Verbose invocation of the cmdline args to reach the ICE.

[Bug target/100041] ICE in curr_insn_transform, at lra-constraints.c:4022

[mss at tutanota dot de]

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

--- Comment #8 from mss at tutanota dot de ---
Apologies for the delay, had my account auto-locked.

While I was waiting for the unlocking of my account, I tried removing flags one
by one to see if that'd do a thing and turns out removing
``-m96bit-long-double'' does not prompt an ICE.

To my knowledge -march=native on my Core2 Duo T8100 is enabled by default, so I
have it added to compile a native-like LLVM for it from another computer.

[Bug target/100041] ICE in curr_insn_transform, at lra-constraints.c:4022

[mss at tutanota dot de]

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

--- Comment #9 from mss at tutanota dot de ---
> To my knowledge -march=native on my Core2 Duo T8100 is enabled by default,
> so I have it added to compile a native-like LLVM for it from another
> computer.

I meant to say that -m96bit-long-double is enabled by -march=native on the
T8100.

[Bug target/100041] ICE in curr_insn_transform, at lra-constraints.c:4022

[mss at tutanota dot de]

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

--- Comment #10 from mss at tutanota dot de ---
Turns out I was horribly wrong, apologies:

>The x86-32 application binary interface specifies the size to be 96 bits, so -m96bit-long-double is the default in 32-bit mode. (https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html)

 0 ~: cat /proc/cpuinfo | grep model\ name | sort -u
model name      : Intel(R) Core(TM)2 Duo CPU     T8100  @ 2.10GHz
 0 ~: gcc -march=core2 -mtune=core2 -Q --help=target | grep m96bit-long-double
  -m96bit-long-double                   [disabled]
 0 ~: gcc -march=native -mtune=native -Q --help=target | grep
m96bit-long-double
  -m96bit-long-double                   [disabled]
 0 ~: gcc -Q --help=target | grep m96bit-long-double
  -m96bit-long-double                   [disabled]

 0 ~: gcc -march=core2 -mtune=core2 -Q --help=target | grep m128bit-long-double
  -m128bit-long-double                  [enabled]
 0 ~: gcc -march=native -mtune=native -Q --help=target | grep
m128bit-long-double
  -m128bit-long-double                  [enabled]
 0 ~: gcc -Q --help=target | grep m128bit-long-double
  -m128bit-long-double                  [enabled]

[Bug target/100041] ICE in curr_insn_transform, at lra-constraints.c:4022

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
                 CC|                            |hjl at gcc dot gnu.org
      Known to fail|                            |10.3.0

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed with just -O1 -m96bit-long-double on the GCC 10 branch and trunk.

Note -m96bit-long-double is an ABI changing option, I'm quite sure it shouldn't
be enabled by some random -march=...

[Bug target/100041] ICE in curr_insn_transform, at lra-constraints.c:4022

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
A possible solution might be to disallow the -m64 -m96bit-long-double
combination, the documentation suggests -m128bit-long-double was intended
as an "optimization" over the x86-32 ABI.

[Bug target/100041] ICE in curr_insn_transform, at lra-constraints.c:4022

[ubizjak at gmail dot com]

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

--- Comment #13 from Uroš Bizjak <ubizjak at gmail dot com> ---
See PR79514.

[Bug target/100041] ICE in curr_insn_transform, at lra-constraints.c:4022

[marxin at gcc dot gnu.org]

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

--- Comment #14 from Martin Liška <marxin at gcc dot gnu.org> ---
Reduced test-case:

$ cat itanium.ii
template <typename _Tp> _Tp forward();
void snprintf(...);
struct StringView {
  StringView(char *);
};
struct Trans_NS_itanium_demangle_Node {
  enum Kind {};
  Trans_NS_itanium_demangle_Node(Kind);
};
struct FloatLiteralImpl : Trans_NS_itanium_demangle_Node {
  StringView Contents;
  Kind KindForClass;
  FloatLiteralImpl(StringView Contents_)
      : Trans_NS_itanium_demangle_Node(KindForClass), Contents(Contents_) {
    union {
      long double value;
    };
    snprintf(value);
  }
};
template <typename> struct ManglingParser;
class CanonicalizerAllocator;
template <typename, typename Alloc> struct AbstractManglingParser {
  char First;
  Alloc ASTAllocator;
  ManglingParser<CanonicalizerAllocator> getDerived();
  template <class... Args> void make(Args...) {
    ASTAllocator.template makeNode<int>(forward<Args>()...);
  }
  template <class> Trans_NS_itanium_demangle_Node *parseFloatingLiteral();
  Trans_NS_itanium_demangle_Node *parse();
};
template <typename Alloc, typename Derived>
template <class>
Trans_NS_itanium_demangle_Node *
AbstractManglingParser<Alloc, Derived>::parseFloatingLiteral() {
  StringView Data(&First);
  make(Data);
  return 0;
}
template <typename Derived, typename Alloc>
Trans_NS_itanium_demangle_Node *
AbstractManglingParser<Derived, Alloc>::parse() {
  getDerived().template parseFloatingLiteral<double>();
  return 0;
}
template <typename Alloc>
struct ManglingParser : AbstractManglingParser<int, Alloc> {};
struct CanonicalizerAllocator {
  template <typename Args> void makeNodeSimple(Args);
  struct MakeNodeImpl {
    CanonicalizerAllocator &Self;
    template <typename... Args> void make(Args...) {
      Self.makeNodeSimple<FloatLiteralImpl>(forward<Args>()...);
    }
  };
  template <typename, typename... Args> void makeNode(Args...) {
    MakeNodeImpl{*this}.make(forward<Args>()...);
  }
};
using CanonicalizingDemangler = ManglingParser<int>;
CanonicalizingDemangler parseMaybeMangledName_Demangler;
void parseMaybeMangledName() { parseMaybeMangledName_Demangler.parse(); }

[Bug target/100041] ICE in curr_insn_transform, at lra-constraints.c:4022

[ubizjak at gmail dot com]

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

--- Comment #15 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Richard Biener from comment #12)
> A possible solution might be to disallow the -m64 -m96bit-long-double
> combination, the documentation suggests -m128bit-long-double was intended
> as an "optimization" over the x86-32 ABI.

Yes, I think this is the way to go.

While it is possible to "fix" the ICE with:

--cut here--
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 2820f6d6188..e2fa01756fd 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -3050,7 +3050,7 @@
            (reg:P SP_REG)
            (plus:P (reg:P SP_REG) (const_int -16))))
        (match_operand:XF 0 "nonmemory_no_elim_operand" "f,r,*r,C"))]
-  "TARGET_64BIT"
+  "TARGET_64BIT && !TARGET_128BIT_LONG_DOUBLE"
   "#"
   "&& 1"
   [(set (reg:P SP_REG) (plus:P (reg:P SP_REG) (const_int -16)))
@@ -3077,7 +3077,7 @@
 (define_insn "*pushxf"
   [(set (match_operand:XF 0 "push_operand" "=<,<,<,<,<")
        (match_operand:XF 1 "general_no_elim_operand" "f,r,*r,oF,oC"))]
-  ""
+  "!TARGET_64BIT || TARGET_128BIT_LONG_DOUBLE"
 {
   /* This insn should be already split before reg-stack.  */
   return "#";
--cut here--

where the above patch prevents the push from memory, it is quite obvious from
ix86_split_long_move that TARGET_128BIT_LONG_DOUBLE is indeed intended as an
optimization for 32bit targets only.

So, let's kill -m96bit-long-double for TARGET_64BIT.

[Bug target/100041] ICE in curr_insn_transform, at lra-constraints.c:4022

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |ubizjak at gmail dot com

--- Comment #16 from Uroš Bizjak <ubizjak at gmail dot com> ---
Created attachment 50568
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50568&action=edit
Proposed patch

Attached patch disables -m96bit-long-double for 64-bit targets.

[Bug target/100041] ICE in curr_insn_transform, at lra-constraints.c:4022

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|x86_64-linux-musl           |x86_64
   Target Milestone|---                         |11.0
           Keywords|ice-on-valid-code,          |
                   |needs-reduction             |

[Bug target/100041] ICE in curr_insn_transform, at lra-constraints.c:4022

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Can we go with #c15 for GCC11 and do #c16 for GCC12?

[Bug target/100041] ICE in curr_insn_transform, at lra-constraints.c:4022

[ubizjak at gmail dot com]

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

--- Comment #18 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #17)
> Can we go with #c15 for GCC11 and do #c16 for GCC12?

I'd like to kill the option for GCC11, and the solution is safer than #c15.

[Bug target/100041] ICE in curr_insn_transform, at lra-constraints.c:4022

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'm worried that there isn't enough time to find out before GCC11 release if
some packages in the wild aren't using that option.
E.g. I wonder where it comes from in this PR.  Clearly it doesn't come from
gcc, so does it come from LLVM makefiles or has the reporter just added it?

[Bug target/100041] ICE in curr_insn_transform, at lra-constraints.c:4022

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.0                        |12.0

--- Comment #20 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #19)
> I'm worried that there isn't enough time to find out before GCC11 release if
> some packages in the wild aren't using that option.
> E.g. I wonder where it comes from in this PR.  Clearly it doesn't come from
> gcc, so does it come from LLVM makefiles or has the reporter just added it?

OK, let's wait with the patch after the branch, and leave things as they are
for now.

BTW: I don't think the fix for PR79514 is enough to handle any non-trivial
usage of -m96bit-long-double, and this PR reflects the fact.

[Bug target/100041] ICE in curr_insn_transform, at lra-constraints.c:4022

[mss at tutanota dot de]

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

--- Comment #21 from mss at tutanota dot de ---
(In reply to Jakub Jelinek from comment #19)
> I'm worried that there isn't enough time to find out before GCC11 release if
> some packages in the wild aren't using that option.
> E.g. I wonder where it comes from in this PR.  Clearly it doesn't come from
> gcc, so does it come from LLVM makefiles or has the reporter just added it?

I was trying to build an LLVM for one of my machines from a much more powerful
machine and wanted to add the flags that `-march=native' enables for that
processor but I was unaware that `-m128bit-long-double' was enabled by default
already.

I accidentally added `-m96bit-long-double' myself instead of
`-m128bit-long-double', running g++ with both `-m64' and `-m96bit-long-double'
caused the ICE.

[Bug target/100041] ICE in curr_insn_transform, at lra-constraints.c:4022

[cvs-commit at gcc dot gnu.org]

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

--- Comment #22 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Uros Bizjak <uros@gcc.gnu.org>:

https://gcc.gnu.org/g:716bb02b40ecef5564abb5ba45a594323123a104

commit r12-94-g716bb02b40ecef5564abb5ba45a594323123a104
Author: Uros Bizjak <ubizjak@gmail.com>
Date:   Fri Apr 23 18:45:14 2021 +0200

    i386: Reject -m96bit-long-double for 64bit targets [PR100041]

    64bit targets default to 128bit long double, so -m96bit-long-double should
    not be used.  Together with -m128bit-long-double, this option was intended
    to be an optimization for 32bit targets only.

    Error out when -m96bit-long-double is used with 64bit targets.

    2021-04-23  Uroš Bizjak  <ubizjak@gmail.com>

    gcc/
            PR target/100041
            * config/i386/i386-options.c (ix86_option_override_internal):
            Error out when -m96bit-long-double is used with 64bit targets.
            * config/i386/i386.md (*pushxf_rounded): Remove pattern.

    gcc/testsuite/

            PR target/100041
            * gcc.target/i386/pr79514.c (dg-error):
            Expect error for 64bit targets.

[Bug target/100041] ICE in curr_insn_transform, at lra-constraints.c:4022

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #23 from Uroš Bizjak <ubizjak at gmail dot com> ---
Fixed for gcc-12, no plan to backport.