On 17/07/2013, at 6:26 PM, lingw...@altaitechnologies.com wrote:
> Hi developers,
>
> I'm encountered a problem when I build OpenWrt's toolchain for Cavium
> Octeon,which is mips64 r2 architectural.the error message as follow:
> My toolchain units version:
> gcc: 4.7.x
> binutils: 2.22
> eg
Hi Ard,
I'd like to follow up this thread to move towards removing arm_neon.h's
dependence on stdint.h. My comments inline below.
From: Ard Biesheuvel
Date: Tue, May 21, 2013 at 10:32 AM
Subject: ARM/AAarch64: NEON intrinsics in the kernel
To: gcc@gcc.gnu.org
Cc: Christophe Lyon , Matthew Gr
On 18 July 2013 16:54, Tejas Belagod wrote:
> I'd like to follow up this thread to move towards removing arm_neon.h's
> dependence on stdint.h. My comments inline below.
>
>> As far as I can tell, the only dependency arm_neon.h has on the
>> contents of that header are the [u]int[8|16|32|64]_t typ
On 18/07/13 17:22, Ard Biesheuvel wrote:
> On 18 July 2013 16:54, Tejas Belagod wrote:
>> I'd like to follow up this thread to move towards removing arm_neon.h's
>> dependence on stdint.h. My comments inline below.
>>
>>> As far as I can tell, the only dependency arm_neon.h has on the
>>> contents
On 07/14/2013 01:24 AM, Sebastian Pop wrote:
Hi Jeff,
let's start with getting this bug fixed.
So what do you need? Just making the tiling factor won't solve the
problem AFAICT. As I've mentioned, I'm already over-booked on other
things and don't have the time to do any significant developme
For this testcase, it looks like the scop detection pass should be fixed:
it currently discards the interesting loop nest. I can help figuring out what
is needed to be fixed, though I cannot send patches to fix the problem.
On Thu, Jul 18, 2013 at 11:31 AM, Jeff Law wrote:
> On 07/14/2013 01:24
Ard Biesheuvel wrote:
On 18 July 2013 16:54, Tejas Belagod wrote:
I'd like to follow up this thread to move towards removing arm_neon.h's
dependence on stdint.h. My comments inline below.
As far as I can tell, the only dependency arm_neon.h has on the
contents of that header are the [u]int[8|
I am pleased to announce that the GCC Steering Committee has
accepted the Andes nds32 port for inclusion in GCC and appointed
Chung-Ju Wu and Shiva Chen as port maintainers. The initial patch
needs approval from a GCC GWP maintainer before it may be committed.
Please join me in co
Hello,
I'm mostly new to gcc, so I don't really have a real idea how notes are
generated. More exactly I would like to know, how types are compared during
compilation, and what makes the compiler decide to throw a message in case they
aren't equal. There is this message "note: expected `type` b
+Albert
Would there be somebody from your group Albert who could help maintaining
and pushing patches to graphite? The focus is fixing graphite to get
performance
from the isl scheduler on benchmarks that the gcc community will help identify.
Thanks,
Sebastian
On Thu, Jul 18, 2013 at 11:44 AM, S
Snapshot gcc-4.8-20130718 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20130718/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 18 July 2013 20:32, Klin Iop wrote:
> Hello,
>
> I'm mostly new to gcc, so I don't really have a real idea how notes are
> generated. More exactly I would like to know, how types are compared during
> compilation, and what makes the compiler decide to throw a message in case
> they aren't equ
Nathan Ridge writes:
>> On 3 July 2013 02:41, Nathan Ridge wrote:
./boost/bind/arg.hpp:37:22: warning: typedef ‘T_must_be_placeholder’
locally
defined but not used [-Wunused-local-typedefs]
>>
>> It was new in GCC 4.7, http://gcc.gnu.org/gcc-4.7/changes.html
>
> I've seen spews of
Windows has a feature that I've wanted on Linux forever: stack-based
(i.e. scoped) exception handling. The upshot is that you can do,
roughly, this (pseudocode):
int callback(...)
{
/* Called if code_that_may_fault faults. May return "unwind to
landing pad", "propagate the fault", or "fixup an
On 07/18/2013 05:26 PM, Andy Lutomirski wrote:
Windows has a feature that I've wanted on Linux forever: stack-based
(i.e. scoped) exception handling. The upshot is that you can do,
roughly, this (pseudocode):
int callback(...)
{
/* Called if code_that_may_fault faults. May return "unwind to
On Thu, Jul 18, 2013 at 5:40 PM, David Daney wrote:
> On 07/18/2013 05:26 PM, Andy Lutomirski wrote:
>>
>> Windows has a feature that I've wanted on Linux forever: stack-based
>> (i.e. scoped) exception handling. The upshot is that you can do,
>> roughly, this (pseudocode):
>>
>> int callback(...
On 07/18/2013 05:50 PM, Andy Lutomirski wrote:
On Thu, Jul 18, 2013 at 5:40 PM, David Daney wrote:
On 07/18/2013 05:26 PM, Andy Lutomirski wrote:
Windows has a feature that I've wanted on Linux forever: stack-based
(i.e. scoped) exception handling. The upshot is that you can do,
roughly, thi
Today I started resurrecting my old automatic dependency patch.
I decided, this time, to take a more incremental approach. Thanks to
git, I made a patch series, rather than one monster patch. Now we can
easily test various parts of the change to more easily notice if, or
when, we trip across the
On Thu, Jul 18, 2013 at 6:17 PM, David Daney wrote:
> On 07/18/2013 05:50 PM, Andy Lutomirski wrote:
>>
>> On Thu, Jul 18, 2013 at 5:40 PM, David Daney
>> wrote:
>>>
>>> On 07/18/2013 05:26 PM, Andy Lutomirski wrote:
>>>
>>>
>>> How is this different than throwing exceptions from a signal handler
On Jul 19, 2013, at 2:26 AM, Andy Lutomirski wrote:
> Windows has a feature that I've wanted on Linux forever: stack-based
> (i.e. scoped) exception handling. The upshot is that you can do,
> roughly, this (pseudocode):
[...]
Indeed Windows and OpenVMS have such a mechanism. That's clean and
l
20 matches
Mail list logo
