search for: gcc48

...NS on FSF gcc will require the missing blocks support to be implemented. I did a quick and dirty attempt to build libasan using libsanitizer/asan/dynamic/asan_interceptors_dynamic.cc imported from llvm svn. The bootstrap chokes on... /bin/sh ../libtool --tag=CXX --mode=compile /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc/xg++ -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc/ -nostdinc++ -nostdinc++ -I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/include/x86_64-apple-darwin12.2.0 -I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86...

...o, there is no choice for us but to use the Apple-blessed mechanism. Do we want to support both? No, that's too expensive. And very likely once we move to function interposition, mach_override will rot very soon. > > /bin/sh ../libtool --tag=CXX --mode=compile > /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc/xg++ > -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc/ -nostdinc++ > -nostdinc++ > -I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/include/x86_64-apple-darwin12.2.0 > -I/sw/src/fink.build/gcc48-4.8.0-10...

...rg/bugzilla/attachment.cgi?id=28849 with the addition of the usage of -DMISSING_BLOCKS_SUPPORT and the appropriate tests on that to avoid the missing blocks support on FSF gcc. Jack > > > > > > /bin/sh ../libtool --tag=CXX --mode=compile > > /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc/xg++ > > -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc/ -nostdinc++ > > -nostdinc++ > > -I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/include/x86_64-apple-darwin12.2.0 > > -I/sw/src/fink....

Just want to remind everyone that we plan to stop using mach_override in asanin favor of OSX's native function interposition. So, we probably don't want to spend too much effort fixing mach_override. --kcc On Fri, Nov 30, 2012 at 4:46 AM, Alexander Potapenko <glider at google.com>wrote: > Looks like this happens on x86_64 because the position of __cxa_throw > is too far from

...specific failures I see with -fsanitize=address in the FSF g++ testsuite typically appear as simple segfaults such as with... FAIL: g++.dg/abi/covariant3.C -std=c++98 execution test FAIL: g++.dg/abi/covariant3.C -std=c++11 execution test that backtraces as... Starting program: /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/covariant3.exe Reading symbols for shared libraries +++++................................. done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x000010002000068a 0x00000001000015d0 in c1::c1 (thi...

Currently the replacement of allocation routines is based on creating a new malloc zone and a new CFAllocator (because the allocator replacement is done later than it could be, we must have both). This makes us depend on CoreFoundation to call CFAllocatorSetDefault. Because of some bugs in CF which start firing after CFAllocatorSetDefault, we have to add several hacks to circumvent the effects of

The drgaonegg 3.4 release branch is broken against current llvm/clang/compiler-rt at r196792 with the build failure... Compiling Debug.cpp /sw/opt/llvm-3.4/bin/clang++ -c -I/sw/src/fink.build/dragonegg-gcc48-3.4-0/dragonegg-3.4/include/x86 -I/sw/src/fink.build/dragonegg-gcc48-3.4-0/dragonegg-3.4/include/darwin -g -DENABLE_BUILD_WITH_CXX -DENABLE_LTO -I/sw/include -I/sw/opt/llvm-3.4/include -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fno-rtti -MD -MP -DIN_GCC -DLLVM_VERSIO...

On Thu, Jun 12, 2014 at 10:57:46AM +0200, Armin Steinhoff wrote: > > Hi, > > first problem was: > > >FileManager.cpp:311:21: error: range-based ‘for’ loops are not allowed > >in C++98 mode > >for (auto & fe: SeenFileEntries) { > >^ > >FileManager.cpp:312:14: error: request for member ‘getValue’ in ‘fe’, > >which is of non-class type ‘int’

Looks like this happens on x86_64 because the position of __cxa_throw is too far from the allocated branch island (should be <2G). This can be solved by allocating the branch islands somewhere near the text segment (look for kIslandEnd in asan_mac.cc, this is currently 0x7fffffdf0000) or by patching the function with a longer instruction sequence that stores the jump target in a register and

...site Index: config.site =================================================================== --- config.site (revision 69236) +++ config.site (working copy) @@ -278,3 +278,8 @@ ## Path to the version of pkg-config to be used for locating cairographics. ## PKGCONF = +F77=gfortran48 +FC=${F77} +CC=gcc48 +CXX=g++48 +OBJC=gcc48 Then plain-vanilla configure && make worked without a hitch: ~/R-3.2.2$ ./configure [...] R is now configured for x86_64-unknown-freebsd10.2 Source directory: . Installation directory: /usr/local C compiler: gcc48 -std=gnu99 -g -O...

...experience with dragonegg. > > I would like to use tilera-gcc as the compiler driver. native gcc would > not > > be able to > > handle things like tilera specific intrinsics in the source code. > > > > I built dragonegg using > > > > GCC=/path/to/tilera-gcc48/bin/tile-gcc > > LLVM_CONFIG=/path/to/tilera-llvm/bin/tilegx-llvm-config make > > > > and also tried only emitting the IR > > > > /path/to/tilera-gcc48/bin/tile-gcc -fplugin=/path/to/dragonegg.so > > -fplugin-arg-dragonegg-emit-ir -S -o hello.ll hello.c > &...

...============================================== > --- config.site (revision 69236) > +++ config.site (working copy) > @@ -278,3 +278,8 @@ > > ## Path to the version of pkg-config to be used for locating cairographics. > ## PKGCONF = > +F77=gfortran48 > +FC=${F77} > +CC=gcc48 > +CXX=g++48 > +OBJC=gcc48 > > Then plain-vanilla configure && make worked without a hitch: > > ~/R-3.2.2$ ./configure > [...] > R is now configured for x86_64-unknown-freebsd10.2 > > Source directory: . > Installation directory: /usr/local...

Hi Brian, Thanks for sharing your experience with dragonegg. I would like to use tilera-gcc as the compiler driver. native gcc would not be able to handle things like tilera specific intrinsics in the source code. I built dragonegg using GCC=/path/to/tilera-gcc48/bin/tile-gcc LLVM_CONFIG=/path/to/tilera-llvm/bin/tilegx-llvm-config make and also tried only emitting the IR /path/to/tilera-gcc48/bin/tile-gcc -fplugin=/path/to/dragonegg.so -fplugin-arg-dragonegg-emit-ir -S -o hello.ll hello.c (and still get the error: cannot load plugin dragonegg.so: wron...

...rsions/3.2/Resources/library/nlme? Warning in install.packages : installation of package ?nlme? had non-zero exit status I'm using gfortran 4.8 from Macports and running OS X 10.11.4 with RStudio Version 0.99.893. I've tried to use the FLIBS command in R: FLIBS="-L/opt/local/lib/gcc48/gcc/x86_64-apple-darwin15/4.8.5/" so that it knows where the Fortran libraries are at and compile again, but it still searchesregardless for the directory: /usr/local/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2. which of course doesn't exist. Any suggestions? Cheers, Angelo [[alternat...

Prof Brian Ripley writes: > Second, we don't have all the pertinent information such as the > configure options used and the architecture (x86_64?). I am going to > have to guess none as none were mentioned, but using --enable-R-shlib > would be pertinent. > > On 31/08/2015 05:47, Davor Cubranic wrote: >> On FreeBSD 10.2, I get the following error when compiling R

Hi, Thanks for the information. Is it possible to compile LLVM 3.8 in FreeBSD 10.x and eventually use/run it on 8.4. Our production environment is running 8.4 and we cannot update it. Thanks, Sushil Pangeni On Wed, Jun 22, 2016 at 2:01 PM, Dimitry Andric <dimitry at andric.com> wrote: > You cannot build any llvm or clang releases after 3.4 on FreeBSD 8.x > natively, as it is not

...-Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -Woverloaded-virtual -fno-common -fvisibility=hidden -Werror=return-type -fvisibility-inlines-hidden -Wno-return-type-c-linkage -O2 -DNDEBUG -DQT_NO_DEBUG -Wl,-rpath=/usr/local/lib/gcc48 -L/usr/local/lib/gcc48 -B/usr/local/bin -fstack-protector CMakeFiles/rkward.rbackend.dir/rkrbackend.o CMakeFiles/rkward.rbackend.dir/rksignalsupport.o CMakeFiles/rkward.rbackend.dir/rklocalesupport.o CMakeFiles/rkward.rbackend.dir/rkrsupport.o CMakeFiles/rkward.rbackend.dir/rkstructuregetter.o CMa...

Dirk, Dirk Eddelbuettel <edd at debian.org> writes: > On 20 November 2016 at 21:49, Joseph Mingrone wrote: > | Hello Dirk, > | > | Dirk Eddelbuettel <edd at debian.org> writes: > | > | > On 20 November 2016 at 19:28, Joseph Mingrone wrote: > | > | Hello, > | > | > | > | R's shared libraries are linked without setting the soname. This is

Hello, I'm not sure if this is right list, but has anything recently changed which could explain why cmake c++ project (http://sourceforge.net/projects/gemrb/) started to fail upon linking stage (looking like libstdc++ is not included /usr/include/c++/4.2/)? It works normally if passed gcc48 as compiler which subsequently uses (ld) binutils from ports and relevant libstdc++. I have in src.conf- WITH_CLANG_IS_CC=true WITHOUT_GCC=true WITHOUT_CLANG_FULL=true This project was routinely building with clang for me just fine earlier (as well as with gcc47 if told so). I even checked so...

I am using a gcc (v 4.8.2) cross compiler for the tilera architecture. There is an LLVM (v 3.3) cross compiler available for tilera ( http://tilera.github.io/llvm), but the frontend only has partial support for certain tilera intrinsics and no OpenMP support. Hence, I have decided to use DragonEgg (v 3.3) to resolve this. I was able to build DragonEgg, but when I pass the command line argument