Would it be feasible to change the default for 10?
There is a lot of code that depends on the following behavior:
void* address = shmat(shmkey, NULL /* desired address */, 0 /* flags */);
// Here we mark the shared memory for deletion. Since we attached it in the
// line above, it doesn't
==90885== Memcheck, a memory error detector
==90885== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==90885== Using Valgrind-3.8.0 and LibVEX; rerun with -h for copyright info
==90885== Command: ./protoc
==90885==
==90885== Invalid read of size 8
==90885==at 0x1388506:
Try removing --gc-sections from the link flags for protoc, that should
solve it for now. I am still looking at the root cause, which seems to
be something in our ld; it does not seem to be related to either clang
or libstdc++.
Whoa, thank you! Removing --gc-sections from the link flags
Rebuilding xorg-server with gcc resolves the problem, bt points at libdrm2.
On Thu, Dec 13, 2012 at 10:51 PM, Artyom Mirgorodskiy
art...@ijminteractive.net wrote:
I have a similar problem when running firefox
On Thursday 13 December 2012 15:49:38 Johannes Dieterich wrote:
Dear all,
I
Hello
One example is Google's tcmalloc [1], is this behaviour intended?
[1]
http://code.google.com/p/google-perftools/source/browse/trunk/src/maybe_threads.cc
Regards,
George
___
freebsd-current@freebsd.org mailing list
On Tue, Sep 6, 2011 at 10:41 AM, Oliver Lehmann lehm...@ans-netz.de wrote:
Hi,
I'm about to replace some harddisks in my fileserver and plan to
reinstall FreeBSD this weekend on it. I'll also switch from i386 to amd64
as the hardware the system runs on has changed last year as well.
I don't
Hi list.
It seems that ssse3 support on base gcc is causing some compile errors
on KDE related ports, all of them so far are tracked down to eigen2.
More precisely, /usr/local/include/eigen2/Eigen/Core :
37 #ifdef __SSE3__
38 #include pmmintrin.h
39 #endif
40 #ifdef __SSSE3__
You can just copy /usr/src/contrib/gcc/config/i386/tmmintrin.h to
/usr/include/gcc/4.2 for now, or apply the attached patch and run make
install in /usr/src/gnu/usr.bin/cc/include. I'll commit a fix to
-current tonight.
This is great, thank you very much.
There's one more minor hiccup
It works fine here:
$ gcc -### -march=native -S empty.c
Using built-in specs.
Target: i386-undermydesk-freebsd
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 4.2.2 20070831 prerelease [FreeBSD]
/usr/libexec/cc1 -quiet -D_LONGLONG empty.c -march=core2
I have prepared a patch that finishes the core2 support part and
backports from gcc-4.3
the SSSE3 instruction set (-mssse3, -mno-ssse3).
It is enabled for -march=core2 by default.
Testing and comments are welcome.
Patch:
http://people.freebsd.org/~mm/patches/head-gcc-ssse3.patch
The
Hi,
The following error occurs when i try to build r219385.
cc -O2 -pipe -march=core2 -DHAVE_CONFIG_H
-I/usr/src/kerberos5/tools/make-roken/../../include -std=gnu99 -c
make-roken.c
make-roken.c:1: error: bad value (core2) for -march= switch
make-roken.c:1: error: bad value (core2) for -mtune=
What process did you follow to get here?
I did a make toolchain followed by make buildworld.
that's because the latest gcc commits have support for core2 and thus it no
longer is being expanded to nocona. please note that having core2 in make.conf
has always been *wrong*. hence the need to
either native or nocona (actually native should evaluate to nocona):
touch _native_test.c gcc -march=native -### _native_test.c
should tell which -march and -mtune settings gcc assumes for native.
indeed there are some known problems with native, but i think those are
limited to
native doesn't get handled by bsd.cpu.mk at all! it gets passed to gcc
directly and gcc choses -m{tune,arch} on it's own.
don't add -march=* directly to CFLAGS. this is bound to go wrong at some
point. use CPUTYPE to set the cpu and CFLAGS for -O*, -pipe, etc.
also please keep in mind that
On Fri, Dec 31, 2010 at 11:35 PM, René Ladan r...@freebsd.org wrote:
Hi,
somewhere between 9.0-amd64 r216351 and r216738, I've noticed some
userland weirdness.
Symptoms are:
- pseudo-random number generator not starting, preventing ssh(d) from working
- fonts in X.org (xfce4) missing or
/usr/obj/usr/src/make.amd64/usr/src/usr.bin/make created for
/usr/src/usr.bin/make
Segmentation fault (core dumped)
*** Error code 139
Stop in /usr/src.
*** Signal 11
Stop in /usr/src.
what exactly is crashing here?
I have the same problem with make
Program received signal SIGSEGV,
Recently, we've achieved the state when clang can compile all of FreeBSD world
on i386/amd64 platforms (including all the C++ apps we have and itself)
and a bootable kernel. Thus we feel that the time has come to ask the FreeBSD
community for wider testing on i386/amd64 (you sure can help with
17 matches
Mail list logo
