*** Bug 1863557 has been marked as a duplicate of this bug. ***

This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.

I'm going to try clang if that helps.

Proposing as prioritized bug, see https://pagure.io/fesco/issue/2020#comment-671672

Just a note, Jakub is on PTO this week, so I wouldn't expect any progress until he returns.

What would help would be to add -save-temps to the command line and pass along the .ii file.

Looks like https://gcc.gnu.org/PR93028 but even that is missing a test.

This is accepted as a Prioritized Bug: https://meetbot.fedoraproject.org/fedora-meeting/2020-08-26/fedora_prioritized_bugs_and_issues.2020-08-26-15.00.log.html#l-54

Should be fixed in gcc-10.2.1-3.fc{33,34}, except that the fc33 build is stuck on s390x :(.

FEDORA-2020-ebc729af2b has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-ebc729af2b

FEDORA-2020-ebc729af2b has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-ebc729af2b`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-ebc729af2b

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

A different crash comes on i686:

https://kojipkgs.fedoraproject.org//work/tasks/968/50740968/build.log

/builddir/build/BUILD/firefox-80.0.1/toolkit/crashreporter/google-breakpad/src/third_party/lss/linux_syscall_support.h:4188: internal compiler error: output_operand: invalid use of register 'frame'
 4188 |     }
      | 
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.

The most recent builds failed due to a missing openh264-devel dependency, but no gcc builds have occurred since then, so it's likely that resolving the dependency issue will still result in the failure reported in comment 11

(In reply to Ben Cotton from comment #12)
> The most recent builds failed due to a missing openh264-devel dependency,
> but no gcc builds have occurred since then, so it's likely that resolving
> the dependency issue will still result in the failure reported in comment 11

New build with the fixed dependency is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=51112798

 0:06.27 mozbuild.configure.options.InvalidOptionError: Unknown option: --with-system-openh264
 0:06.37 *** Fix above errors and then restart with\
 0:06.37                "./mach build"

There are builds here:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1605574

It's still broken in i686:

https://kojipkgs.fedoraproject.org//work/tasks/1838/51121838/build.log

/builddir/build/BUILD/firefox-80.0.1/toolkit/crashreporter/google-breakpad/src/common/linux/memory_mapped_file.cc:98: internal compiler error: output_operand: invalid use of register 'frame'

arm fails with "memory exhausted" which is not related and may be disabled:

https://kojipkgs.fedoraproject.org//work/tasks/1837/51121837/build.log

and we don't build for s390x/ppc64le/aarch64 right now.

For the i686 issue, I've tried to reproduce it with:
#include <stdarg.h>

extern int *__errno_location (void);

static __attribute__((noinline)) long
sys_socketcall (int op, ...)
{
  long int res;
  va_list ap;
  va_start (ap, op);
  asm volatile ("push %%ebx; movl %2, %%ebx; int $0x80; pop %%ebx"
		: "=a" (res) : "0" (102), "ri" (op), "c" (ap) : "memory", "esp");
  if (__builtin_expect (res > 4294963200UL, 0))
    {
      *__errno_location () = -res;
      res = -1;
    }
  va_end (ap);
  return res;
}

int
foo (void)
{
  return sys_socketcall (16, 1, 2, 3, 4, 5, 6, 7);
}
and
-O2 -m32 -fPIC -shared -flto -o test test.c -fstack-protector-strong
which seems to create the same RTL IL (ok, off by one pseudo numbers and the memory and esp (which is invalid as the warning says) clobbers swapped),
but strangely during LRA the frame hard reg is eliminated in my simple testcase and is not on firefox, which is the reason why it ICEs.
Guess I'll need to do a side-by-side debugging to find out what is the difference.

I've filed PR97032 for this, but the ICE goes away if one fixes the bogus code pointed up by the warning (at least on the small testcase in the PR).
/builddir/build/BUILD/firefox-80.0.1/toolkit/crashreporter/google-breakpad/src/third_party/lss/linux_syscall_support.h: In function 'ElfFileSoName.constprop':
/builddir/build/BUILD/firefox-80.0.1/toolkit/crashreporter/google-breakpad/src/third_party/lss/linux_syscall_support.h:3462: warning: listing the stack pointer register 'esp' in a clobber list is deprecated [-Wdeprecated]
 3462 |   LSS_INLINE _syscall2(int,     munmap,          void*,       s,
      | 
/builddir/build/BUILD/firefox-80.0.1/toolkit/crashreporter/google-breakpad/src/third_party/lss/linux_syscall_support.h:3462: note: the value of the stack pointer after an 'asm' statement must be the same as it was before the statement
So, I'd strongly advise to fix firefox (and thus also workaround the bug in the compiler which will be eventually fixed).
As the warning says, clobbers of the stack pointer in inline asm make no sense, the inline asm is not allowed to end with a different sp value from when it started (and changing it in the middle is not clobbering).
So completely untested:
--- firefox-80.0.1/toolkit/crashreporter/google-breakpad/src/third_party/lss/linux_syscall_support.h	2020-08-31 10:04:19.000000000 -0400
+++ firefox-80.0.1/toolkit/crashreporter/google-breakpad/src/third_party/lss/linux_syscall_support.h	2020-09-12 07:24:35.298931628 -0400
@@ -1962,7 +1962,7 @@ struct kernel_statfs {
                            LSS_ENTRYPOINT                                     \
                            "pop %%ebx"                                        \
                            args                                               \
-                           : "esp", "memory");                                \
+                           : "memory");                                       \
       LSS_RETURN(type,__res)
     #undef  _syscall0
     #define _syscall0(type,name)                                              \
@@ -2019,7 +2019,7 @@ struct kernel_statfs {
                              : "i" (__NR_##name), "ri" ((long)(arg1)),        \
                                "c" ((long)(arg2)), "d" ((long)(arg3)),        \
                                "S" ((long)(arg4)), "D" ((long)(arg5))         \
-                             : "esp", "memory");                              \
+                             : "memory");                                     \
         LSS_RETURN(type,__res);                                               \
       }
     #undef  _syscall6
@@ -2041,7 +2041,7 @@ struct kernel_statfs {
                              : "i" (__NR_##name),  "0" ((long)(&__s)),        \
                                "c" ((long)(arg2)), "d" ((long)(arg3)),        \
                                "S" ((long)(arg4)), "D" ((long)(arg5))         \
-                             : "esp", "memory");                              \
+                             : "memory");                                     \
         LSS_RETURN(type,__res);                                               \
       }
     LSS_INLINE int LSS_NAME(clone)(int (*fn)(void *), void *child_stack,
@@ -2127,7 +2127,7 @@ struct kernel_statfs {
                            : "0"(-EINVAL), "i"(__NR_clone),
                              "m"(fn), "m"(child_stack), "m"(flags), "m"(arg),
                              "m"(parent_tidptr), "m"(newtls), "m"(child_tidptr)
-                           : "esp", "memory", "ecx", "edx", "esi", "edi");
+                           : "memory", "ecx", "edx", "esi", "edi");
       LSS_RETURN(int, __res);
     }

I tried to add the patch to latest i686 builds, Thanks.

The i686 workaround seems to be working.

Since Firefox builds are succeeding, should we close this bug?

FEDORA-2020-ebc729af2b has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

It's a gcc bug tracked here - https://bugzilla.redhat.com/show_bug.cgi?id=1886399

(In reply to Martin Stransky from comment #23)
> It's a gcc bug tracked here -
> https://bugzilla.redhat.com/show_bug.cgi?id=1886399

Err, sorry, wrong bug.