On 5 May 2015 at 11:23, Trevor Saunders wrote:
> Saying forward declaration should be done with class is a value choice
> you've made.
Yes.
> Given forward declarations with struct and class are
> interchangable it seems like a perfectly valid choice to me to decide
> you don't care to bother
On 5 May 2015 at 05:58, Andrew Pinski wrote:
> These two are bogus and really clang in GCC's mind. The main reason
> is the standard says struct and class are the same thing.
Apart from the fact that classes are private by default and structs
are not. They may be similar for layout purposes, and
On 23 January 2015 at 16:07, Ricardo Telichevesky wrote:
> gcc: Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) - don't
> know what that means expected a number like 4.2.1 or something like that,
> 2.53 GHz Intel Core 2 Duo
Hi Ricardo,
This is not gcc at all, it's Clang+LLVM. :/
On 27 November 2014 at 21:48, Christophe Lyon
wrote:
> On 30 September 2014 at 19:08, Konstantin Serebryany
> wrote:
>> Correct, you can run tests from llvm tree with any compiler.
>> https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerTestSuite
>>
>
> I've read that document, and as
On 5 August 2014 16:36, Prathamesh Kulkarni wrote:
> Hi,
>I have written notes on "GCC and LLVM collaboration BOF"
> presented at the Cauldron. I would be grateful if you would
> review it for me.
Hi Prathamesh,
Sounds about right.
Other reviews, FYI:
http://llvmweekly.org/issue/29
http:
On 15 July 2014 15:43, Jan Hubicka wrote:
> I also noticed that GCC code size is bigger for both firefox and libreoffice.
> There was some extra bloat in 4.9 compared to 4.8.
> Martin did some tests with -O2 and various flags, perhaps we could trottle
> some of -O2 optimizations.
Now that you men
On 25 June 2014 10:26, Bingfeng Mei wrote:
> Why is GCC code size so much bigger than LLVM? Does -Ofast have more unrolling
> on GCC? It doesn't seem increasing code size help performance (164.gzip &
> 197.parser)
> Is there comparisons for O2? I guess that is more useful for typical
> mobile/emb
On 24 June 2014 18:16, Eric Christopher wrote:
> Might want to try asking them to run some comparison numbers though. I
> remember they did before EuroLLVM a while back when we were looking at
> merging our two aarch64 ports.
http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-April/072393.html
In t
On 24 June 2014 15:11, Vladimir Makarov wrote:
> A few people asked me about new performance comparison of latest GCC
> and LLVM. So I've finished it and put it on my site
>
> http://vmakarov.fedorapeople.org/spec/
>
> The comparison is achievable from 2014 link and links under it in
> the le
On 23 April 2014 09:03, David Brown wrote:
> Again, this is stepping /way/ outside the appropriate bounds of a
> built-in pre-processor.
>
> I don't disagree with the idea of improving upon autotools. But I don't
> think adding features to the pre-processor is the way to go.
I completely agree.
On 27 March 2014 15:06, wrote:
> But unwind code is inherently platform-dependent. Your objection to the
> inline asm that references SP by name is that it's platform dependent. The
> builtin would reduce the amount of platform dependent code by one line, i.e.,
> probably much less than one
On 27 March 2014 14:44, Behan Webster wrote:
> That is what led to this proposal.
I'm having a go at implementing named registers, and I also have
started a thread in the LLVM mailing list. Let's see how it goes...
> For the existing cases this is true. However such a builtin would allow it
> t
On 27 March 2014 11:33, Jakub Jelinek wrote:
> Sure, normally register keyword is just a hint, that e.g. GCC I think
> ignores whenever optimizing (for -O0 it means a variable doesn't have to
> be allocated on the stack), but when it is part of the GNU global/local
> register
> variable extension
Hi Jakub,
Just to make it clear, I'm not an official representative of Clang, or
LLVM, nor I was involved in all discussions about implementing
extensions either. I do not have an agenda to promote LLVM changes.
> To me this sounds like clang proposing extensions because they aren't
> willing to
On 27 March 2014 10:47, Andrew Pinski wrote:
> Please don't add a close list to the CC of GCC lists it is annoying.
I didn't realise this list was closed, sorry.
--renato
On 27 March 2014 10:29, Andreas Schwab wrote:
> Depends on what you need the value for.
Mostly unwind code that uses both FP and SP, example:
http://git.linuxfoundation.org/?p=llvmlinux/kernel.git;a=commit;h=a875939682dc43bf244bd39a356bca76ac190d77
http://git.linuxfoundation.org/?p=llvmlinux/ker
On 27 March 2014 10:12, Andreas Schwab wrote:
> Can't you use __builtin_frame_address (0) instead?
That would give me the frame pointer, not the stack pointer, and the
user would have to calculate manually the offset to get the actual
stack pointer, which would be target-specific, possibly making
Hi there,
There is a common pattern on bare-metal code to refer to the value of
registers directly in a variable:
register unsigned long current_stack_pointer asm("sp");
But not only that depends on the register names (so you need to split
by arch with ifdefs), but it also uses a non-guaranteed
On 12 March 2014 15:13, lin zuojian wrote:
> Hi Chandler,
> I have looked into their "Machine Instr Scheduler", and find out
> that LLVM have not yet enable them by default.And further test find
> they are still not yet working.(e.g,-mtune=cortex-a9,a15,a53
> generates the same cod
On 20 February 2014 12:59, Ramana Radhakrishnan
wrote:
> It's not really because GAS supports it, but there exists a large body
> of code out there which uses inline assembler with pre-UAL syntax. I'm
> not sure people will appreciate a blanket break in one version of the
> toolchain and especiall
On 20 February 2014 10:11, Ramana Radhakrishnan
wrote:
> The current behaviour is that when the compiler generates code for
> Thumb1 and Thumb2 we switch back to the appropriate state after inline
> assembler is emitted. We don't switch back to ARM state on the (fairly
> robust) assumption that mo
On 19 February 2014 23:19, Andrew Pinski wrote:
> With the unified assembly format, you should not need those
> .arm/.thumb and in fact emitting them can make things even worse.
If only we could get rid or all pre-UAL inline assembly on the planet... :)
The has been the only reason why we added
On 19 February 2014 11:58, Richard Sandiford
wrote:
> I agree that having an unrecognised asm shouldn't be a hard error until
> assembly time though. Saleem, is the problem that this is being rejected
> earlier?
Hi Andrew, Richard,
Thanks for your reviews! We agree that we should actually just
On 17 February 2014 14:47, Tim Prince wrote:
> I'm continuing discussions with former Intel colleagues. If you are asking
> for insight into how Intel priorities vary over time, I don't expect much,
> unless the next beta compiler provides some inferences. They have talked
> about implementing a
On 16 February 2014 23:44, Tim Prince wrote:
> I don't think many people want to use both OpenMP 4 and older Intel
> directives together.
I'm having less and less incentives to use anything other than omp4,
cilk and whatever. I think we should be able to map all our internal
needs to those pragma
On 16 February 2014 17:23, Tobias Burnus wrote:
> As '#pragma omp simd' doesn't generate any threads and doesn't call the
> OpenMP run-time library (libgomp), I would claim that it only controls the
> tree vectorizer. (Hence, -fopenmp-simd was added as it permits this control
> without enabling th
On 15 February 2014 22:49, Tim Prince wrote:
> In my experience, the (somewhat complicated) gcc --param options work
> sufficiently well for specification of unrolling.
There is precedent for --param in LLVM, we could go this way, too.
Though, I can't see how it'd be applied to a specific functio
On 15 February 2014 19:26, Jakub Jelinek wrote:
> GCC supports #pragma GCC ivdep/#pragma simd/#pragma omp simd, the last one
> can be used without rest of OpenMP by using -fopenmp-simd switch.
Does the simd/omp have control over the tree vectorizer? Or are they
just flags for the omp implementati
Folks,
One of the things that we've been discussing for a while and there are
just too many options out there and none fits exactly what we're
looking for (obviously), is the vectorization control pragmas.
Our initial semantics is working on on a specific loop / lexical block to:
* turn vectoriz
Hi Folks,
First of all, I'd like to thank everyone for their great responses and
heart warming encouragement for such an enterprise. This will be my
last email about this subject on these lists, so I'd like to just let
everyone know what (and where) I'll be heading next with this topic.
Feel free
Now copying Rafael, which can give us some more insight on the LLVM LTO side.
cheers,
--renato
On 11 February 2014 09:55, Renato Golin wrote:
> Hi Jan,
>
> I think this is a very good example where we could all collaborate
> (including binutils).
>
> I'll leave you
On 11 February 2014 16:00, Jan Hubicka wrote:
> I basically think that binutils should have a way for installed compiler to
> register a plugin and load all plugins by default (or perhaps for performance
> or upon detecking an compatible LTO object file in some way, perhaps also by
> information g
Hi Jan,
I think this is a very good example where we could all collaborate
(including binutils).
I'll leave your reply intact, so that Chandler (CC'd) can get a bit
more context. I'm copying him because he (and I believe Diego) had
more contact with LTO than I had.
If I got it right, LTO today:
On 7 February 2014 23:30, Joseph S. Myers wrote:
> I think there are other closely related issues, as GCC people try to work
> around issues with glibc, or vice versa, rather than coordinating what
> might be the best solution involving changes to both components,
Hi Joseph,
Thanks for the huge
On 7 February 2014 22:42, Jonathan Wakely wrote:
> The sanitizers are IMHO an impressive example of collaboration. The
> process may not be perfect, but the fact is that those powerful tools
> are available in both compilers - I think that's amazing!
I agree.
> Like the Blocks extension? :-)
S
On 7 February 2014 22:33, Andrew Pinski wrote:
> I think it is going to called anything, it should be GNU and LLVM
> collaboration since GCC does not include binutils/gdb while LLVM
> includes the assembler/etc.
Good point. I do mean the whole toolchain.
cheers,
--renato
On 7 February 2014 21:53, Diego Novillo wrote:
> I think this would be worth a BoF, at the very least. Would you be
> willing to propose one? I just need an abstract to get it in the
> system. We still have some room left for presentations.
Hi Diego,
Thanks, that'd be great!
A BoF would give us
Folks,
I'm about to do something I've been advised against, but since I
normally don't have good judgement, I'll risk it, because I think it's
worth it. I know some people here share my views and this is the
reason I'm writing this.
The problem
For a long time already I've been hearing on the L
38 matches
Mail list logo
