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 actuall
> 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 so
==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: std::os
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,
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
http://lists.freebsd.org/mailm
On Tue, Sep 6, 2011 at 10:41 AM, Oliver Lehmann 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 want to instal
> 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" "-m
> 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
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
39 #endif
40 #ifdef __SSSE3__
41 #in
> 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
> "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 mi
> 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
> lim
>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
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= s
On Fri, Dec 31, 2010 at 11:35 PM, René Ladan 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 replaced
> -
>> /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
> 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 w
17 matches
Mail list logo
