compiled by
gcc ran OK.
your patch seems to work just fine. No crashes whatsoever so far. Thank
you.
I have committed a slighly cleaned-up version of this hack in r245272,
so until this is fixed by upstream, everybody will at least have a
correctly functioning libgcc on amd64.
Since this issue
functioning libgcc on amd64.
Since this issue can potentially also occur on stable/9, I will MFC
the
fix too, after a few days timeout.
___
Very appreciated and thanks.
oh
For the record, I rebuilt my world/kernel after this commit, and
rebuilt VirtualBox
just fine. No crashes whatsoever so far. Thank
you.
I have committed a slighly cleaned-up version of this hack in r245272,
so until this is fixed by upstream, everybody will at least have a
correctly functioning libgcc on amd64.
Since this issue can potentially also occur on stable/9, I will MFC
the crashes, but when compiled by
gcc ran OK.
your patch seems to work just fine. No crashes whatsoever so far. Thank
you.
I have committed a slighly cleaned-up version of this hack in r245272,
so until this is fixed by upstream, everybody will at least have a
correctly functioning libgcc
On 7 Jan 2013, at 23:21, Dimitry Andric wrote:
This is at least the direction I'm looking at. It seems that in some
cases with __builtin_eh_return(), llvm does not see that registers can
be clobbered, and it doesn't save and restore them.
Do you mean that some registers were clobbered by a
.
Can you please try the attached patch, which is a very horrid, atrocious
hack, and will only work for amd64. Then rebuild libgcc with clang, and
please try if this fixes at least some of the crashes...
This is at least the direction I'm looking at. It seems that in some
cases
to reproduce. I think I still
have another unrelated issue in libgcc with clang, but this only occurs
when compiling the testcases with gcc 4.7, and very high optimization.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo
08.01.2013 03:21, Dimitry Andric пишет:
Can you please try the attached patch, which is a very horrid, atrocious
hack, and will only work for amd64. Then rebuild libgcc with clang, and
please try if this fixes at least some of the crashes...
The patch fixed building editors/libreoffice
On Sun, Jan 06, 2013 at 04:51:11PM +, David Chisnall wrote:
On 6 Jan 2013, at 16:48, Nathan Whitehorn wrote:
No. It's completely broken at all optimization levels. There do not
appear to be any flags that change the behavior. Building unwind-dw2.c
either with gcc or with the previous
, atrocious
hack, and will only work for amd64. Then rebuild libgcc with clang, and
please try if this fixes at least some of the crashes...
This is at least the direction I'm looking at. It seems that in some
cases with __builtin_eh_return(), llvm does not see that registers can
be clobbered
On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote:
Here's a minimal test case that reproduces the bug:
[...]
Until someone fixes this bug, could we apply something like this as a
work-around?
Stefan
Index: gnu/lib/libgcc/Makefile
On 2013-01-06 15:17, Stefan Farfeleder wrote:
On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote:
Here's a minimal test case that reproduces the bug:
[...]
Until someone fixes this bug, could we apply something like this as a
work-around?
Stefan
Index: gnu/lib/libgcc/Makefile
-around?
Stefan
Index: gnu/lib/libgcc/Makefile
===
--- gnu/lib/libgcc/Makefile(revision 245055)
+++ gnu/lib/libgcc/Makefile(working copy)
@@ -6,6 +6,8 @@
SHLIB_NAME=libgcc_s.so.1
SHLIBDIR?=/lib
+CC=gcc
something like this as a
work-around?
Stefan
Index: gnu/lib/libgcc/Makefile
===
--- gnu/lib/libgcc/Makefile (revision 245055)
+++ gnu/lib/libgcc/Makefile (working copy)
@@ -6,6 +6,8 @@
SHLIB_NAME= libgcc_s.so.1
we apply something like this as a
work-around?
Stefan
Index: gnu/lib/libgcc/Makefile
===
--- gnu/lib/libgcc/Makefile(revision 245055)
+++ gnu/lib/libgcc/Makefile(working copy)
@@ -6,6 +6,8 @@
SHLIB_NAME
/libgcc/Makefile
===
--- gnu/lib/libgcc/Makefile (revision 245055)
+++ gnu/lib/libgcc/Makefile (working copy)
@@ -6,6 +6,8 @@
SHLIB_NAME= libgcc_s.so.1
SHLIBDIR?=/lib
+CC= gcc
+
.include bsd.own.mk
#
# libgcc
this as a
work-around?
Stefan
Index: gnu/lib/libgcc/Makefile
===
--- gnu/lib/libgcc/Makefile (revision 245055)
+++ gnu/lib/libgcc/Makefile (working copy)
@@ -6,6 +6,8 @@
SHLIB_NAME= libgcc_s.so.1
SHLIBDIR?= /lib
+CC= gcc
On 6 Jan 2013, at 16:48, Nathan Whitehorn wrote:
No. It's completely broken at all optimization levels. There do not
appear to be any flags that change the behavior. Building unwind-dw2.c
either with gcc or with the previous import of clang in our tree does
fix it, however.
Do you have an
On Fri, Jan 04, 2013 at 10:23:34PM +0200, Konstantin Belousov wrote:
Thank you for digging more.
In fact, it is more likely that there is some bug or incompatibility in
c++ unwinder than in the libgcc itself, but as you noted, a compiler bug
is also possible.
Anyway, I was mostly
to have something to do with throwing exceptions, but I am
still not sure whether I am looking at a bug in boost, gcc, clang, or
libgcc...
Do you happen to have a smaller testcase, by any chance?
Not yet, but I'll try to come up with something smaller.
Here's a minimal test case
the crashes, I am still at a loss about the cause. It
does seem to have something to do with throwing exceptions, but I am
still not sure whether I am looking at a bug in boost, gcc, clang, or
libgcc...
Do you happen to have a smaller testcase, by any chance?
Not yet, but I'll
error (core dumped) ./a.out
What is the backtrace ?
Compile the system libraries (ld-elf, libc, libgcc etc) with the
debugging information and obtain the backtrace once more.
I'm afraid the backtrace is not really interesting:
Program received signal SIGBUS, Bus error.
std::string::_Rep
) {
return 1;
}
}
$ g++ -O2 -finline-limit=0 throw-crash.cc
$ ./a.out
zsh: bus error (core dumped) ./a.out
What is the backtrace ?
Compile the system libraries (ld-elf, libc, libgcc etc) with the
debugging information and obtain the backtrace once more.
I'm afraid
1; } } $ g++ -O2
-finline-limit=0 throw-crash.cc $ ./a.out zsh: bus error
(core dumped) ./a.out
What is the backtrace ? Compile the system libraries (ld-elf,
libc, libgcc etc) with the debugging information and obtain the
backtrace once more.
I'm afraid the backtrace is not really
) {
return 1;
}
}
$ g++ -O2 -finline-limit=0 throw-crash.cc
$ ./a.out
zsh: bus error (core dumped) ./a.out
What is the backtrace ?
Compile the system libraries (ld-elf, libc, libgcc etc) with the
debugging information and obtain the backtrace once more.
I'm afraid the backtrace
whether I am looking at a bug in boost, gcc, clang, or
libgcc...
Do you happen to have a smaller testcase, by any chance?
Not yet, but I'll try to come up with something smaller.
Stefan
___
freebsd-current@freebsd.org mailing list
http
something to do with throwing exceptions, but I am
still not sure whether I am looking at a bug in boost, gcc, clang, or
libgcc...
Do you happen to have a smaller testcase, by any chance?
Not yet, but I'll try to come up with something smaller.
Take a look at devel/delta as well as creduce
to
compile libgcc in a wrong or at least incompatible way with what gcc
expects. In fact, the breakage only occurs with libgcc compiled by a
post-r243830 clang and an application compiled with g++ -O2. For me, the
crash happens with boost::program_options, but I'm not sure if that is
necessary
Hi,
I noticed that most of my C++ applications in recent versions of FreeBSD
head suddenly crash without me recompiling them. I tracked it down to
r243830 which imported a new clang version. The new clang seems to
compile libgcc in a wrong or at least incompatible way with what gcc
expects
On 12/27/12 09:07, Stefan Farfeleder wrote:
Hi,
I noticed that most of my C++ applications in recent versions of FreeBSD
head suddenly crash without me recompiling them. I tracked it down to
r243830 which imported a new clang version. The new clang seems to
compile libgcc in a wrong
clang version. The new clang seems to
compile libgcc in a wrong or at least incompatible way with what gcc
expects. In fact, the breakage only occurs with libgcc compiled by a
post-r243830 clang and an application compiled with g++ -O2. For me, the
crash happens with boost::program_options
On 22-10-2010 16:30, Ed Schouten wrote:
Hello everyone,
At EuroBSDCon I was talking with some committers active in the area of
Clang (brooks, kwm, others) about replacing our libgcc shipped with GCC
4.2.1 with a BSD-licensed version. The LLVM folks have a BSD licensed
implementation called
Hi all,
* Ed Schouten e...@80386.nl, 20101022 16:30:
At EuroBSDCon I was talking with some committers active in the area of
Clang (brooks, kwm, others) about replacing our libgcc shipped with GCC
4.2.1 with a BSD-licensed version. The LLVM folks have a BSD licensed
implementation called
Hello everyone,
At EuroBSDCon I was talking with some committers active in the area of
Clang (brooks, kwm, others) about replacing our libgcc shipped with GCC
4.2.1 with a BSD-licensed version. The LLVM folks have a BSD licensed
implementation called libcompiler_rt. See:
http://compiler
* Ed Schouten e...@80386.nl, 20101022 16:30:
- Rebuild all your software (yes, I know it's unfortunate).
Right after I sent this, I thought I'd better clarify this. You don't
need to rebuild your software. This change will not break the existing
ABI. This step is just mentioned here, since
I know that several libraries in FreeBSD
uses symbol versioning. In looking through
src/ I was unable to determine whether
symbol versioning is used on libgcc. Any
guidance would be appreciated.
--
Steve
___
freebsd-current@freebsd.org mailing list
on 30/08/2010 20:32 Steve Kargl said the following:
I know that several libraries in FreeBSD
uses symbol versioning. In looking through
src/ I was unable to determine whether
symbol versioning is used on libgcc. Any
guidance would be appreciated.
Check out output of e.g. objdump -T /usr
On Mon, Aug 30, 2010 at 08:43:40PM +0300, Andriy Gapon wrote:
on 30/08/2010 20:32 Steve Kargl said the following:
I know that several libraries in FreeBSD
uses symbol versioning. In looking through
src/ I was unable to determine whether
symbol versioning is used on libgcc. Any
Steve Kargl wrote:
I know that several libraries in FreeBSD
uses symbol versioning. In looking through
src/ I was unable to determine whether
symbol versioning is used on libgcc. Any
guidance would be appreciated.
I don't think it is. I haven't poked at any sources
Alexander Kabaev wrote:
On Mon, 30 Aug 2010 13:36:03 -0400
Boris Kochergin sp...@acm.poly.edu wrote:
Steve Kargl wrote:
I know that several libraries in FreeBSD
uses symbol versioning. In looking through
src/ I was unable to determine whether
symbol versioning is used on libgcc
whether
symbol versioning is used on libgcc. Any
guidance would be appreciated.
I don't think it is. I haven't poked at any sources, but there are no
FBSD* symbols in /usr/lib/libgcc_s.so, which is what's used in symbol
versioning in, say, /lib/libc.so.7.
-Boris
On Mon, 30 Aug 2010 13:36:03 -0400
Boris Kochergin sp...@acm.poly.edu wrote:
Steve Kargl wrote:
I know that several libraries in FreeBSD
uses symbol versioning. In looking through
src/ I was unable to determine whether
symbol versioning is used on libgcc. Any
guidance would
On Sat, May 11, 2002 at 10:33:03AM -0700, David O'Brien wrote:
On Sat, May 11, 2002 at 12:35:38PM +0300, Ruslan Ermilov wrote:
I say again, the malloc usage is not in c-parse.in, it is in the parser
driver produced by Byacc.
OK, now that you've explained it:
I'll look this patch
On Sat, May 11, 2002 at 10:33:03AM -0700, David O'Brien wrote:
I'll look this patch over carefully, but at first glance it all seems
like stylistic changes. Does it fix a bug, or you just don't like how I
did things?
The changes are mostly _not_ stylistic like .ORDER with one argument
On Sun, May 12, 2002 at 04:43:33AM -0700, David O'Brien wrote:
On Sat, May 11, 2002 at 10:33:03AM -0700, David O'Brien wrote:
I'll look this patch over carefully, but at first glance it all seems
like stylistic changes. Does it fix a bug, or you just don't like how I
did things?
David O'Brien wrote:
People are really making me regret that I sweated over GCC 3 to bring it
into our tree for all of our architectures and to get many serious bugs
fixed in the FSF CVS repository.
Really? It must be in private email... from what I've seen, everything
went incredibly
On Fri, May 10, 2002 at 04:41:53PM -0700, David O'Brien wrote:
On Fri, May 10, 2002 at 06:04:27PM +0300, Ruslan Ermilov wrote:
Bmake bits for Gcc 3.1.
This also vanished my YACC building fixes and broke world while
attempting to build `cc1plus' in a cross-tools stage. The changes
On Sat, May 11, 2002 at 10:44:11AM +0300, Ruslan Ermilov wrote:
On Fri, May 10, 2002 at 04:41:53PM -0700, David O'Brien wrote:
On Fri, May 10, 2002 at 06:04:27PM +0300, Ruslan Ermilov wrote:
Bmake bits for Gcc 3.1.
This also vanished my YACC building fixes and broke world while
On Sat, May 11, 2002 at 10:44:11AM +0300, Ruslan Ermilov wrote:
The malloc usage is in the Byacc output, not the input.
There's no difference, [b]yacc just copies C code blocks intact.
No. Byacc copies C code blocks from the input grammer intact. It also
adds more C code to the output. See
Ruslan Ermilov wrote:
On Fri, May 10, 2002 at 04:41:53PM -0700, David O'Brien wrote:
On Fri, May 10, 2002 at 06:04:27PM +0300, Ruslan Ermilov wrote:
Bmake bits for Gcc 3.1.
=20
This also vanished my YACC building fixes and broke world while
attempting to build `cc1plus' in a
On Sat, May 11, 2002 at 01:00:27AM -0700, David O'Brien wrote:
On Sat, May 11, 2002 at 10:44:11AM +0300, Ruslan Ermilov wrote:
On Fri, May 10, 2002 at 04:41:53PM -0700, David O'Brien wrote:
On Fri, May 10, 2002 at 06:04:27PM +0300, Ruslan Ermilov wrote:
Bmake bits for Gcc 3.1.
On Sat, May 11, 2002 at 12:35:38PM +0300, Ruslan Ermilov wrote:
I say again, the malloc usage is not in c-parse.in, it is in the parser
driver produced by Byacc.
OK, now that you've explained it:
I'll look this patch over carefully, but at first glance it all seems
like stylistic
On Fri, May 10, 2002 at 01:54:50AM -0700, David E. O'Brien wrote:
obrien 2002/05/10 01:54:50 PDT
Modified files:
gnu/lib/csu Makefile
gnu/lib/libgcc Makefile
gnu/lib/libibertyMakefile
gnu/lib/libobjc Makefile
gnu/lib/libstdc
On Fri, May 10, 2002 at 06:04:27PM +0300, Ruslan Ermilov wrote:
Bmake bits for Gcc 3.1.
This also vanished my YACC building fixes and broke world while
attempting to build `cc1plus' in a cross-tools stage. The changes
below fix this and CLEANFILES.
These changes are wrong.
RCS
On Sat, Apr 15, 2000 at 11:26:44AM +0400, Ilmar S. Habibulin wrote:
When does subj links with the executables?
When using the ``cc'' or ``c++'' front ends libgcc.a is automatically
linked in. Use ``cc -v'' to see this happening.
I have many problems linking new KDE, because it uses service
On Sat, 15 Apr 2000, David O'Brien wrote:
On Sat, Apr 15, 2000 at 11:26:44AM +0400, Ilmar S. Habibulin wrote:
When does subj links with the executables?
When using the ``cc'' or ``c++'' front ends libgcc.a is automatically
linked in. Use ``cc -v'' to see this happening.
You mean to look
didn't.
So if you are some what cautious, you might want to hold off a day or two
before your next buildworld.
- Forwarded message from "David E. O'Brien" [EMAIL PROTECTED] -
Modified files:
gnu/usr.bin/cc/cc_tools Makefile
gnu/lib/libgcc Makefile
contrib/
uot;i386/i386.h"' tm.h
echo '#include "i386/att.h"' tm.h
echo '#include "i386/freebsd.h"' tm.h
echo '#include "i386/perform.h"' tm.h
cc -c -O -pipe -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config
-I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc
*** Signal 12
Stop in /usr/src/gnu/lib/libgcc.
*** Error code 1
Suspect that you need a newer kernel before you can build the world.
had to
o make new config
o make new kernel
o reboot
o make world
o ...
must have been an exciting time in current while i was on the road the last
i386/perform.h"' tm.h
cc -c -O -pipe -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config -I/
usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions -DIN_GCC
-I/usr/obj/usr/src/tmp/usr/include -DL_mulsi3 -o _mulsi3.o /usr/src/gnu/lib
/libgcc/../../../contrib/egc
just cvsupped
echo '#include xm-freebsd.h' config.h
echo '#include "i386/xm-i386.h"' tconfig.h
echo '#include "i386/i386.h"' tm.h
echo '#include "i386/att.h"' tm.h
echo '#include "i386/freebsd.h"' tm.h
echo '#include "i386/perform.h&quo
nclude "i386/freebsd.h"' tm.h
echo '#include "i386/perform.h"' tm.h
cc -c -O -pipe -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config
-I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions -DIN_GCC
-I/usr/obj/usr/src/tmp/usr/include -DL_mulsi3 -o _mulsi
just cvsupped
Your system; I just finished a world not five minutes ago. Suspect the
usual.
ok. doing a make clean now
randy
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Sat, 9 Oct 1999, Mike Smith wrote:
just cvsupped
Your system; I just finished a world not five minutes ago. Suspect the
usual.
Suspect that you need a newer kernel before you can build the world.
*** Signal 12
Stop in /usr/src/gnu/lib/libgcc.
*** Error code 1
unable to find the symbol set_new_handler. This
guy is defined in new.h (which points towards new, which has the very
simple code for it). The problem is, the code for it is stuffed into
libgcc.a.
I thought libgcc was being deprecated, isn't that so? That only
libstdc++ was going to be needed
In article pine.bsf.4.10.9905291806500.375-100...@picnic.mat.net,
Chuck Robey chu...@picnic.mat.net wrote:
I thought libgcc was being deprecated, isn't that so? That only
libstdc++ was going to be needed?
No, I think you're confusing libgcc with libg++.
John
--
John Polstra
On Sat, 29 May 1999, John Polstra wrote:
In article pine.bsf.4.10.9905291806500.375-100...@picnic.mat.net,
Chuck Robey chu...@picnic.mat.net wrote:
I thought libgcc was being deprecated, isn't that so? That only
libstdc++ was going to be needed?
No, I think you're confusing libgcc
On 11-Apr-99 Luoqi Chen wrote:
For threaded applications to work correctly, we need a thread-safe
version of libgcc. It is straight forward to build: define _PTHREADS in
CFLAGS. We can have both versions just like libc and libc_r, and use the
thread-safe version when linking threaded
For threaded applications to work correctly, we need a thread-safe version of
libgcc. It is straight forward to build: define _PTHREADS in CFLAGS. We can
have both versions just like libc and libc_r, and use the thread-safe version
when linking threaded applications. If no one objects, I will add
On Sun, 04 Apr 1999 12:48:04 GMT, George Cox wrote:
cc: Internal compiler error: program cc1 got fatal signal 11
[...]
FreeBSD-CURRENT -- Because I'm worth it.
How did you find out about CURRENT without finding out about the FAQ?
Please read section 4 of the FreeBSD FAQ, available online
Well, the troubles continue, after much buggering around with an incorrectly
linked cc1 binary, cooked up from I don't know where I ask Is anyone else
seeing this kind of error on make buildworld'ing
In file included from
/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/i386/freebsd.h:28
71 matches
Mail list logo
