On Thu, 2014-02-06 at 20:06 -0800, Paul E. McKenney wrote:
> On Thu, Feb 06, 2014 at 11:58:22PM +0100, Torvald Riegel wrote:
> > On Thu, 2014-02-06 at 13:55 -0800, Paul E. McKenney wrote:
> > > On Thu, Feb 06, 2014 at 10:09:25PM +0100, Torvald Riegel wrote:
> > > > On Thu, 2014-02-06 at 18:59 +
Hello,
This is a followup of
http://gcc.gnu.org/ml/gcc/2014-01/msg00120.html
and
http://gcc.gnu.org/ml/gcc/2014-01/msg00055.html
This is a slightly long patch that attempts to simplify the niter and infinite
expressions by recursively looking through the dominant basic blocks for
register defi
Hello Torvald,
It looks like Paul clarified most of the points I was trying to make
(thanks Paul!), so I won't go back over them here.
On Thu, Feb 06, 2014 at 09:09:25PM +, Torvald Riegel wrote:
> Are you familiar with the formalization of the C11/C++11 model by Batty
> et al.?
> http://www.c
Hi Richard,
I've been trying to determine for some time whether the MIPS backend has
successfully guaranteed that even when compiling with hard-float enabled there
is no floating point code emitted unless you use floating point types.
My most recent reason for looking at this is because I am st
On Thu, Feb 06, 2014 at 05:21:00PM -0500, Tim Prince wrote:
> I'm seeing vectorization but no output from
> -ftree-vectorizer-verbose, and no dot product vectorization inside
> omp parallel regions, with gcc g++ or gfortran 4.9. Primary targets
> are cygwin64 and linux x86_64.
> I've been unable
On 02/07/2014 10:22 AM, Jakub Jelinek wrote:
On Thu, Feb 06, 2014 at 05:21:00PM -0500, Tim Prince wrote:
I'm seeing vectorization but no output from
-ftree-vectorizer-verbose, and no dot product vectorization inside
omp parallel regions, with gcc g++ or gfortran 4.9. Primary targets
are cygwi
On Fri, Feb 07, 2014 at 10:13:40AM +0100, Torvald Riegel wrote:
> On Thu, 2014-02-06 at 20:06 -0800, Paul E. McKenney wrote:
> > On Thu, Feb 06, 2014 at 11:58:22PM +0100, Torvald Riegel wrote:
> > > On Thu, 2014-02-06 at 13:55 -0800, Paul E. McKenney wrote:
> > > > On Thu, Feb 06, 2014 at 10:09:25P
On Fri, Feb 07, 2014 at 12:01:25PM +, Will Deacon wrote:
> Hello Torvald,
>
> It looks like Paul clarified most of the points I was trying to make
> (thanks Paul!), so I won't go back over them here.
>
> On Thu, Feb 06, 2014 at 09:09:25PM +, Torvald Riegel wrote:
> > Are you familiar with
On Fri, Feb 07, 2014 at 08:44:05AM +0100, Peter Zijlstra wrote:
> On Thu, Feb 06, 2014 at 08:20:51PM -0800, Paul E. McKenney wrote:
> > Hopefully some discussion of out-of-thin-air values as well.
>
> Yes, absolutely shoot store speculation in the head already. Then drive
> a wooden stake through
On Fri, Feb 07, 2014 at 05:06:54PM +, Peter Zijlstra wrote:
> On Fri, Feb 07, 2014 at 04:55:48PM +, Will Deacon wrote:
> > Hi Paul,
> >
> > On Fri, Feb 07, 2014 at 04:50:28PM +, Paul E. McKenney wrote:
> > > On Fri, Feb 07, 2014 at 08:44:05AM +0100, Peter Zijlstra wrote:
> > > > On Thu
On Fri, Feb 07, 2014 at 05:13:36PM +, Will Deacon wrote:
> Understood, but that doesn't explain why Paul wants to add ISB/isync
> instructions which affect the *CPU* rather than the compiler!
I doubt Paul wants it, but yeah, I'm curious about that proposal as
well, sounds like someone took a b
On Fri, Feb 07, 2014 at 04:55:48PM +, Will Deacon wrote:
> Hi Paul,
>
> On Fri, Feb 07, 2014 at 04:50:28PM +, Paul E. McKenney wrote:
> > On Fri, Feb 07, 2014 at 08:44:05AM +0100, Peter Zijlstra wrote:
> > > On Thu, Feb 06, 2014 at 08:20:51PM -0800, Paul E. McKenney wrote:
> > > > Hopefull
On Fri, Feb 07, 2014 at 04:55:48PM +, Will Deacon wrote:
> Hi Paul,
>
> On Fri, Feb 07, 2014 at 04:50:28PM +, Paul E. McKenney wrote:
> > On Fri, Feb 07, 2014 at 08:44:05AM +0100, Peter Zijlstra wrote:
> > > On Thu, Feb 06, 2014 at 08:20:51PM -0800, Paul E. McKenney wrote:
> > > > Hopefull
On Fri, Feb 07, 2014 at 05:13:36PM +, Will Deacon wrote:
> On Fri, Feb 07, 2014 at 05:06:54PM +, Peter Zijlstra wrote:
> > On Fri, Feb 07, 2014 at 04:55:48PM +, Will Deacon wrote:
> > > Hi Paul,
> > >
> > > On Fri, Feb 07, 2014 at 04:50:28PM +, Paul E. McKenney wrote:
> > > > On Fr
Hi Paul,
On Fri, Feb 07, 2014 at 04:50:28PM +, Paul E. McKenney wrote:
> On Fri, Feb 07, 2014 at 08:44:05AM +0100, Peter Zijlstra wrote:
> > On Thu, Feb 06, 2014 at 08:20:51PM -0800, Paul E. McKenney wrote:
> > > Hopefully some discussion of out-of-thin-air values as well.
> >
> > Yes, absolu
On Fri, 2014-02-07 at 18:06 +0100, Peter Zijlstra wrote:
> On Fri, Feb 07, 2014 at 04:55:48PM +, Will Deacon wrote:
> > Hi Paul,
> >
> > On Fri, Feb 07, 2014 at 04:50:28PM +, Paul E. McKenney wrote:
> > > On Fri, Feb 07, 2014 at 08:44:05AM +0100, Peter Zijlstra wrote:
> > > > On Thu, Feb 0
On Fri, 2014-02-07 at 08:50 -0800, Paul E. McKenney wrote:
> On Fri, Feb 07, 2014 at 08:44:05AM +0100, Peter Zijlstra wrote:
> > On Thu, Feb 06, 2014 at 08:20:51PM -0800, Paul E. McKenney wrote:
> > > Hopefully some discussion of out-of-thin-air values as well.
> >
> > Yes, absolutely shoot store
On Fri, 7 Feb 2014, Matthew Fortune wrote:
> My most recent reason for looking at this is because I am starting to
> understand/look at mips ld.so from glibc and it appears to make such an
> assumption. I.e. I cannot see it using any specific options to prevent
> the use of floating point but t
On Fri, 7 Feb 2014, Peter Zijlstra wrote:
> There's further problems where things like memset() can write outside
> the specified address range. Examples are memset() using single
> instructions to wipe entire cachelines and then 'restoring' the tail
> bit.
If memset (or any C library function) m
> > My most recent reason for looking at this is because I am starting to
> > understand/look at mips ld.so from glibc and it appears to make such
> > an assumption. I.e. I cannot see it using any specific options to
> > prevent the use of floating point but the path into the dynamic linker
> > for
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
On Fri, Feb 7, 2014 at 4:33 PM, Renato Golin wrote:
> I'll be at the GNU Cauldron this year, feel free to come and discuss
> this and other ideas. I hope to participate more in the GCC side of
> things, and I wish some of you guys would do the same on our side. And
> hopefully, in a few years, we
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
On Fri, Feb 7, 2014 at 1:33 PM, Renato Golin wrote:
> 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.
>
On Fri, Feb 7, 2014 at 1:53 PM, Diego Novillo wrote:
> On Fri, Feb 7, 2014 at 4:33 PM, Renato Golin wrote:
>
>> I'll be at the GNU Cauldron this year, feel free to come and discuss
>> this and other ideas. I hope to participate more in the GCC side of
>> things, and I wish some of you guys would
On Fri, Feb 7, 2014 at 2:07 PM, Renato Golin wrote:
> 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.
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:33, Renato Golin wrote:
>
> Worst still, with Clang and LLVM getting more traction recently, and
> with a lot of very interesting academic work being done, a lot of new
> things are getting into LLVM first (like the sanitizers, or some
> specialized pragmas) and we're dangerou
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 Fri, 7 Feb 2014, Renato Golin wrote:
> For a long time already I've been hearing on the LLVM list people
> saying: "oh, ld should not accept this deprecated instruction, but we
> can't change that", "that would be a good idea, but we need to talk to
> the GCC guys first", and to be honest, nobo
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
31 matches
Mail list logo
