https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110955
--- Comment #16 from Petr Sumbera ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #14)
> That's almost certainly due to Solaris still including LLVM 13, which is
> pretty old by now. In particular, it lacks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110955
--- Comment #12 from Petr Sumbera ---
(In reply to Petr Sumbera from comment #9)
> (In reply to r...@cebitec.uni-bielefeld.de from comment #8)
> > > without the JIT patch (033-solaris-LLVM-JIT.patch)? It may be worth a try
> > > until someone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110955
--- Comment #9 from Petr Sumbera ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #8)
> > I'm not sure if we taked about this before: have you tried building SPARC
> > LLVM
> > without the JIT patch (033-solaris-LLVM-JIT.patch)? It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110955
--- Comment #3 from Petr Sumbera ---
(In reply to Andrew Pinski from comment #1)
> Are you sure this is NOT a LLVM JIT issue?
> There was a similar issue on aarch64 too; PR 108994 which was fixed in LLVM
> side.
Don't really know. But the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956
Bug ID: 110956
Summary: gcc_assert is hit at
gcc-13.2.0/libgcc/unwind-dw2-fde.c#L291 with some
special library
Product: gcc
Version: 13.2.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110955
Bug ID: 110955
Summary: SIGSEGV in
libgcc_s.so.1`classify_object_over_fdes+0x140 on
Solaris SPARC with GCC 13 runtime
Product: gcc
Version: 13.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106813
Bug ID: 106813
Summary: getSiginfo() libgo/runtime/go-signal.c missing Solaris
specific code to get ret.sigpc
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472
--- Comment #14 from Petr Sumbera ---
Sorry for late response. Unfortunatelly above patch dosen't make any
difference. The problem is still there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472
--- Comment #4 from Petr Sumbera ---
(In reply to Richard Biener from comment #3)
> There is dependencies = { module=all-target-libgo;
> on=all-target-libbacktrace; }
> in Makefile.def so there's sth fishy going on. Do you use GNU make?
Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472
--- Comment #2 from Petr Sumbera ---
(In reply to Andrew Pinski from comment #1)
> Are you building in the source tree?
No. I'm building it outside of source tree. GCC 11 and older don't seem to have
this problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472
Bug ID: 106472
Summary: No rule to make target
'../libbacktrace/libbacktrace.la', needed by
'libgo.la'.
Product: gcc
Version: 12.1.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97936
Petr Sumbera changed:
What|Removed |Added
CC||sumbera at volny dot cz
--- Comment #19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105792
--- Comment #4 from Petr Sumbera ---
I can confirm that gcc (GCC) 12.1.1 20220528 doesn't have this issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105792
--- Comment #2 from Petr Sumbera ---
Created attachment 53060
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53060=edit
preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105792
Bug ID: 105792
Summary: SPARC GCC 12.1.0 fails with internal compiler error:
in expand_expr_real_2, at expr.cc:10160
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100559
--- Comment #17 from Petr Sumbera ---
(In reply to Petr Sumbera from comment #16)
> (In reply to r...@cebitec.uni-bielefeld.de from comment #15)
> > I'd seen that change before in solaris-userland, but never understood
> > the point. Those
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100559
--- Comment #16 from Petr Sumbera ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #15)
> > --- Comment #14 from Petr Sumbera ---
> [...]
> > It has following comment:
> >
> > # We want sparc/i386 to match locations for their 32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100559
--- Comment #14 from Petr Sumbera ---
(In reply to Eric Botcazou from comment #13)
> > $ cat gcc-11.1.0/gcc/config/sparc/t-sol2
> > MULTILIB_OPTIONS = m32/m64
> > MULTILIB_DIRNAMES = 32 sparcv9
> > MULTILIB_MATCHES =
> > MULTILIB_OSDIRNAMES = .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100559
--- Comment #12 from Petr Sumbera ---
(In reply to Eric Botcazou from comment #11)
> Can you post the contents of $(srcdir)/gcc/config/sparc/t-sol2 in your setup?
$ cat gcc-11.1.0/gcc/config/sparc/t-sol2
MULTILIB_OPTIONS = m32/m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100559
--- Comment #9 from Petr Sumbera ---
(In reply to Eric Botcazou from comment #8)
> Unlikely I'd say. Could you go into the $(buildir]/gcc/ada directory and do:
> ls -l rts/i-cexten.ads
> ls -l rts_32/i-cexten.ads
> They should not point to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100559
--- Comment #7 from Petr Sumbera ---
(In reply to Eric Botcazou from comment #6)
> Have you made local modifications to the source code or is it pristine?
No local changes.
I wonder where i-cexten.ads is being modified...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100559
--- Comment #5 from Petr Sumbera ---
(In reply to Eric Botcazou from comment #4)
> Thanks. What configure line do you use for the Intel build?
(cd /builds/psumbera/userland-gcc-11.1/components/gcc10/build/amd64 ;
/usr/bin/env
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100559
--- Comment #3 from Petr Sumbera ---
(cd /builds/psumbera/userland-gcc-11.1/components/gcc10/build/sparcv9 ;
/usr/bin/env CONFIG_SHELL="/bin/sh"
PKG_CONFIG_PATH="/usr/lib/sparcv9/pkgconfig"
CC="/builds/psumbera/gcc10/bin/gcc"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100559
Petr Sumbera changed:
What|Removed |Added
Version|11.1.0 |unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100559
Bug ID: 100559
Summary: Solaris SPARC GCC 11.1 Ada build: i-cexten.ads:278:28:
modulus exceeds limit (2 ** 64)
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607
--- Comment #7 from Petr Sumbera ---
Just to confirm that '-fno-delayed-branch' as workaround seems to work (at
least based on provided test case).
Probably better is to modify the code like this:
--- gcc-10.2.0/gcc/config/sparc/sparc.c
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97358
--- Comment #17 from Petr Sumbera ---
(In reply to Dan Horák from comment #15)
> Petr, are you going to open a Firefox bug to fix their code or shall I do it?
Please file it. I haven't had time to read whole thread and I don't know what
shall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97358
--- Comment #5 from Petr Sumbera ---
Is there any workaround for this issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97423
--- Comment #2 from Petr Sumbera ---
Created attachment 49373
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49373=edit
test case
Just for record. I have tried to prepare test case. Attached is preprocessed
test case. Following command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97423
Bug ID: 97423
Summary: internal compiler error in gcc-10.2.0/gcc/toplev.c:328
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607
Petr Sumbera changed:
What|Removed |Added
CC||sumbera at volny dot cz
--- Comment #5
31 matches
Mail list logo
