https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61336
--- Comment #2 from Michael Cree <mcree at orcon dot net.nz> --- OK, I had reported the ICE on the basis that any ICE, whether the code under compilation is correct or not, is a bug. I guess you are implying that when the problem is an inlined asm then it cannot be guaranteed that all the compiler's assumptions are satisfied thus an ICE might be a reasonable outcome? I think I said the source file is from glibc, but actually it is Debian eglibc, which has come via the eglibc project from glibc before being masssaged by Debian. I shall try to see if I can trip the ICE on glibc source itself (it doesn't happen with default configure options, but that's not a sufficient test). Is there some way one can identify in the source exactly the problematic inline asm? I see line 4764 of malloc.c reported in the comment above but that line involves macros. (The difference between the eglibc I used and glibc is not at that point in malloc.c; it might be somewhere in the header files and the macros defined.)
