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
clang caused 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
ixed 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
> fix too, after a few days timeout.
Thanks!
___
freebsd-current@freebsd.or
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
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/li
nd restore them.
This fixes most of the crashes I was able 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-cur
t segfaults that are now gone.
>
> 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&#x
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
, 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, a
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 pr
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
ixes this bug, could we apply something like this as a
>> work-around?
>>
>> Stefan
>>
>> Index: gnu/lib/libgcc/Makefile
>> =======
>> --- gnu/lib/libgcc/Makefile (revision 245055)
>>
nd?
>
> 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
ug:
>>> [...]
>>>
>>> Until someone fixes this bug, could we apply something like this as a
>>> work-around?
>>>
>>> Stefan
>>>
>>> Index: gnu/lib/libgcc/Makefile
>>> =====
t; Until someone fixes this bug, could we apply something like this as a
> > work-around?
> >
> > Stefan
> >
> > Index: gnu/lib/libgcc/Makefile
> > =======
> > --- gnu/lib/libgcc/Makefil
ug, could we apply something like this as a
>> work-around?
>>
>> Stefan
>>
>> Index: gnu/lib/libgcc/Makefile
>> ===========
>> --- gnu/lib/libgcc/Makefile(revision 245055)
>> +++ gnu/l
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/Mak
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/
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.
gt;> } catch (const std::exception &) {
>>>> return 1;
>>>> }
>>>> }
>>>> $ g++ -O2 -finline-limit=0 throw-crash.cc
>>>> $ ./a.out
>>>> zsh: bus error (core dumped) ./a.out
>>>
>>> Wha
ot;foo"); }
>>>>
>>>> void f1(void) { f2(); }
>>>>
>>>> int main(void) { try { std::string s1, s2; f1(); return 0; }
>>>> catch (const std::exception &) { return 1; } } $ g++ -O2
>>>> -finline-limit=0 throw-cras
;
> > > }
> > >
> > > int main(void) {
> > > try {
> > > std::string s1, s2;
> > > f1();
> > > return 0;
> > > } catch (const std::exception &) {
> > > return 1;
> >
> > return 0;
> > } catch (const std::exception &) {
> > return 1;
> > }
> > }
> > $ g++ -O2 -finline-limit=0 throw-crash.cc
> > $ ./a.out
> > zsh: bus error (core dumped) ./a.out
>
> What is the backtrace ?
>
while now, and while I
> > > can reproduce 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
> > > lib
ut 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&#x
> 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 try to come up wit
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.
Stefan
___
freebsd-cur
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
necessar
t 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. In fact, the breakage only occurs with libgcc compiled by a
> > post-r243830 clang and an application compiled wit
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 li
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. In
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
&
Hi all,
* Ed Schouten , 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 li
* Ed Schouten , 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 libgcc.a is static
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
On Mon, 30 Aug 2010 13:36:03 -0400
Boris Kochergin 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
> &
gt; 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, but there are no
> > FBS
Alexander Kabaev wrote:
On Mon, 30 Aug 2010 13:36:03 -0400
Boris Kochergin 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
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, but th
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 version
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
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
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 smoo
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 thi
> 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 a
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
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 c
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
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 `c
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. Se
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
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
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.
> R
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 Makef
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 lo
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 servic
When does subj links with the executables? I have many problems linking
new KDE, because it uses service function from this library, and i suspect
that libgcc.a is not linked by default. :( Should it or i have to point it
(?) by hands?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubs
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 Makefi
m.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 -I. -fexceptions
>> *** 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
ude "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 &qu
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/
>> 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
ho '#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
&
just cvsupped
echo '#include ' >> 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/fre
On Sat, 29 May 1999, John Polstra wrote:
> In article ,
> Chuck Robey 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++.
Yeah, g
In article ,
Chuck Robey 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 j...@polstra.com
John
s, because it's 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
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 link
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/conf
72 matches
Mail list logo
