similar to: [LLVMdev] 3.4 branch gcc 4.9 build error

On 4/29/14, Markus Trippelsdorf wrote: > On 2014.04.29 at 12:16 +0200, Tuncer Ayaz wrote: > > On 4/29/14, Markus Trippelsdorf wrote: > > > On 2014.04.29 at 11:04 +0200, Tuncer Ayaz wrote: > > > > On 4/27/14, Markus Trippelsdorf wrote: > > > > > On 2014.04.27 at 16:18 +0200, Tuncer Ayaz wrote: > > > > > > Using gcc 4.9 to build the llvm

On Thu, 15 May 2014 02:25:30 +0200, Tom Stellard wrote: > On Sat, May 10, 2014 at 11:48:23PM +0200, Tuncer Ayaz wrote: > > Tom, > > > > now that 3.4.1 is out, any chance of a 3.4.2 with just the three > > fixes or at least merging them to the 3.4 branch? > > I've pushed the two approved patches to the 3.4 branch, can you > verify that they work with gcc

On 15/05/2014 22:12, Tom Stellard wrote: > On Thu, May 15, 2014 at 01:38:32PM +0200, Tuncer Ayaz wrote: >> On Thu, 15 May 2014 02:25:30 +0200, Tom Stellard wrote: >> >>> On Sat, May 10, 2014 at 11:48:23PM +0200, Tuncer Ayaz wrote: >>>> Tom, >>>> >>>> now that 3.4.1 is out, any chance of a 3.4.2 with just the three >>>> fixes

Tom, now that 3.4.1 is out, any chance of a 3.4.2 with just the three fixes or at least merging them to the 3.4 branch?

On 15/05/2014 22:52, Tom Stellard wrote: > On Thu, May 15, 2014 at 10:41:08PM +0300, Alp Toker wrote: >> On 15/05/2014 22:12, Tom Stellard wrote: >>> On Thu, May 15, 2014 at 01:38:32PM +0200, Tuncer Ayaz wrote: >>>> On Thu, 15 May 2014 02:25:30 +0200, Tom Stellard wrote: >>>> >>>>> On Sat, May 10, 2014 at 11:48:23PM +0200, Tuncer Ayaz wrote:

On 04/05/2014 02:30, Tom Stellard wrote: > On Sat, May 03, 2014 at 12:32:02AM +0100, Alp Toker wrote: >> On 02/05/2014 20:45, Tuncer Ayaz wrote: >>> Bump. >>> >>> Is it really unsupported to build llvm from scratch with gcc 4.9 and >>> libstdc++ 4.9? Should I file a bugzilla ticket instead? >> Obviously LLVM/clang should compile out of the box

On 02/05/2014 20:45, Tuncer Ayaz wrote: > Bump. > > Is it really unsupported to build llvm from scratch with gcc 4.9 and > libstdc++ 4.9? Should I file a bugzilla ticket instead? Obviously LLVM/clang should compile out of the box using the current stable GCC version, and failure to do so would be a potential release blocker. Please file a PR Tom, do you know about this issue? Alp.

Hello there, I'm building a Linux distribution based on musl and LLVM as default toolchain (including lld/libc++/libc++abi/libunwind rather than GNU). For most of the time this works pretty well. However I'm having troubles with few packages, webkit for instance fails because of max_align_t being redeclared in musl's stddef.h I see that stddef.h is provided by both musl and in the

Hi Devs, Consider below testcase. $cat test.cpp #include <vector> #include<type_traits> typedef int _int4 __attribute__((vector_size(16))); typedef union{ int data[4]; struct {int x, y, z, w;}; _int4 vec; } int4; typedef int4 int3; int main() { static_assert(std::alignment_of<int4>::value <= alignof(max_align_t), "over aligned!"); } $clang++ -m32 error:

On Mon, May 5, 2014 at 10:47 AM, Chandler Carruth <chandlerc at google.com>wrote: > On Mon, May 5, 2014 at 8:11 AM, Alp Toker <alp at nuanti.com> wrote: > >> I suspect that pulling in clang header fixes r201729, r202911 and r207606 >> to 3.4.1 will resolve libstdc++ / glibc compatibility issues people have >> been having with 3.4: >> >> r201729:

On Mon, May 05, 2014 at 11:42:28PM +0100, Alp Toker wrote: > > On 05/05/2014 20:51, Richard Smith wrote: > > On Mon, May 5, 2014 at 10:47 AM, Chandler Carruth > > <chandlerc at google.com <mailto:chandlerc at google.com>> wrote: > > > > On Mon, May 5, 2014 at 8:11 AM, Alp Toker <alp at nuanti.com > > <mailto:alp at nuanti.com>>

On Wed, Mar 8, 2017 at 2:28 PM Tim Shen <timshen at google.com> wrote: > On Wed, Mar 8, 2017 at 1:49 PM David Blaikie <dblaikie at gmail.com> wrote: > > So I stumbled across an issue that I think is a bit fundamental: > > The xray runtime uses the C++ standard library. > > This seems like a problem because whatever C++ standard library is used to > compile the

The hardware we are planning to use is: Micronet SP5050 FXO Gateway http://www.micronet.com.tw/Products/VoIP/SP5050.asp Micronet SP5100 IP Phone http://www.micronet.com.tw/Products/VoIP/SP5100.asp We are hoping to use this hardware along with AsteriskPBX to replace our aging PBX system. What I want to acheive is: * Any incoming call from PSTN (via gateway) rings on the receptionists phone for

On Sun, Mar 12, 2017, 4:10 PM Dean Michael Berris <dean.berris at gmail.com> wrote: > > > On 9 Mar 2017, at 09:32, David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > I agree that we should clean up the standard library usage even just for > consistency. > > > > +1 -- now that I think about it, it should be fairly doable

Hi, These warnings are included by default with -Wall in GCC 4.6 [1], and LLVM should support them instead of throwing -Wunknown-warning-option. [1]: http://gcc.gnu.org/gcc-4.6/porting_to.html Thanks.

Hi. As mentioned here: https://bugzilla.opensuse.org/show_bug.cgi?id=1123136 there's a new issue with GCC 9, it's related to: https://gcc.gnu.org/gcc-9/porting_to.html#complit in: /* Not const! Never return this as a result directly! */ #define SMTP_ADDRESS_LITERAL(localpart, domain) \ &((struct smtp_address){ (localpart), (domain) }) Thanks, Martin

On 1/25/19 8:24 PM, Stephan Bosch wrote: > > > Op 25/01/2019 om 10:59 schreef Martin Li?ka: >> Hi. >> >> As mentioned here: >> https://bugzilla.opensuse.org/show_bug.cgi?id=1123136 >> >> there's a new issue with GCC 9, it's related to: >> https://gcc.gnu.org/gcc-9/porting_to.html#complit >> >> in: >> /* Not const! Never

So I stumbled across an issue that I think is a bit fundamental: The xray runtime uses the C++ standard library. This seems like a problem because whatever C++ standard library is used to compile the XRay runtime may not be the same as the C++ standard library (if any) that is used to build the target application and link XRay into. Does this make sense? Is this a problem? Talking to Chandler

On Tue, Mar 14, 2017 at 5:34 PM Dean Michael Berris <dean.berris at gmail.com> wrote: > On 13 Mar 2017, at 15:39, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Sun, Mar 12, 2017, 4:10 PM Dean Michael Berris <dean.berris at gmail.com> > wrote: > > > > On 9 Mar 2017, at 09:32, David Blaikie via llvm-dev < > llvm-dev at

Hello > GCC versions listed here are known to not work. If you are using one of > these versions, please try to upgrade your GCC to something more recent. > If you run into a problem with a version of GCC not listed here, please > let us know. Please use the "gcc -v" command to find out which version > of GCC you are using. This is not true. GCC is not broken. 1. You