On 02/13/2013 11:24 PM, Edgar E. Iglesias wrote:
On Thu, Feb 14, 2013 at 12:36:46AM +0100, Michael Eager wrote:
On 02/13/2013 02:38 PM, Vladimir Makarov wrote:
On 13-02-13 1:36 AM, Michael Eager wrote:
Hi --
I'm seeing register allocation problems and code size increases
with gcc-4.6.2 (and g
On Thu, Feb 14, 2013 at 12:36:46AM +0100, Michael Eager wrote:
> On 02/13/2013 02:38 PM, Vladimir Makarov wrote:
> > On 13-02-13 1:36 AM, Michael Eager wrote:
> >> Hi --
> >>
> >> I'm seeing register allocation problems and code size increases
> >> with gcc-4.6.2 (and gcc-head) compared with older
Hi Christophe,
Are you talking about ARM Linux?
It will be easier for us (asan developers) to fix this upstream first.
Could you please file a bug at https://code.google.com/p/address-sanitizer/ ?
On Wed, Feb 13, 2013 at 8:42 PM, Christophe Lyon
wrote:
> Hi,
>
> I am working on enabing libsanit
On 13-02-13 6:36 PM, Michael Eager wrote:
On 02/13/2013 02:38 PM, Vladimir Makarov wrote:
On 13-02-13 1:36 AM, Michael Eager wrote:
Hi --
I'm seeing register allocation problems and code size increases
with gcc-4.6.2 (and gcc-head) compared with older (gcc-4.1.2).
Both are compiled using -O3.
On 02/13/2013 02:38 PM, Vladimir Makarov wrote:
On 13-02-13 1:36 AM, Michael Eager wrote:
Hi --
I'm seeing register allocation problems and code size increases
with gcc-4.6.2 (and gcc-head) compared with older (gcc-4.1.2).
Both are compiled using -O3.
One test case that I have has a long serie
On 13-02-13 1:36 AM, Michael Eager wrote:
Hi --
I'm seeing register allocation problems and code size increases
with gcc-4.6.2 (and gcc-head) compared with older (gcc-4.1.2).
Both are compiled using -O3.
One test case that I have has a long series of nested if's
each with the same comparison an
On Wed, Feb 13, 2013 at 5:18 PM, wrote:
>
> On Feb 13, 2013, at 5:04 PM, Diego Novillo wrote:
>
>> ...
>> Ah, so if we rename a file with 'svn rename', its history will be
>> preserved across the rename? In that case, renaming files should not
>> be a problem.
>
> Yes, that's one of many ways th
On Feb 13, 2013, at 5:04 PM, Diego Novillo wrote:
> ...
> Ah, so if we rename a file with 'svn rename', its history will be
> preserved across the rename? In that case, renaming files should not
> be a problem.
Yes, that's one of many ways that SVN (or most other source control systems)
are su
On Wed, Feb 13, 2013 at 5:00 PM, Joseph S. Myers
wrote:
> On Wed, 13 Feb 2013, Philip Martin wrote:
>
>> The new file must have been explicitly added, rather than copied or
>> moved, and so the history is broken. An example of a history preserving
>
> The issue there is that cvs2svn doesn't / didn
On Wed, 13 Feb 2013, Philip Martin wrote:
> The new file must have been explicitly added, rather than copied or
> moved, and so the history is broken. An example of a history preserving
The issue there is that cvs2svn doesn't / didn't at the time support
detecting moves, so moves from before the
From: Richard Biener
Date: Wed, 13 Feb 2013 12:15:13 +0100
> On Tue, Feb 12, 2013 at 11:31 PM, David Miller wrote:
>> Maybe what we really mean to do here is check both op1 and SUBREG_REG
>> (op1) against SCALAR_INT_MODE_P instead of INTEGRAL_MODE_P?
>
> Yes.
Ok, I'll commit this after doing s
On 13/02/13 17:11, Jonathan Wakely wrote:
On 13 February 2013 17:01, Alec Teal wrote:
On 13/02/13 17:00, Jonathan Wakely wrote:
I read it. That's not debate, just ill-informed speculation ("cpp is
the recommended extension for C++ as far as I know"). We already have
C++ code in GCC, the runt
On 13 February 2013 17:01, Alec Teal wrote:
>
> On 13/02/13 17:00, Jonathan Wakely wrote:
>>
>>
>> I read it. That's not debate, just ill-informed speculation ("cpp is
>> the recommended extension for C++ as far as I know"). We already have
>> C++ code in GCC, the runtime library uses .cc and the
On 02/13/2013 05:01 PM, Alec Teal wrote:
> Why not rename them to?
See the "archaeology" discussion. This is so vitally important
to GCC maintainers that you change things at everyone's peril.
Andrew.
Diego Novillo writes:
> One problem I've noticed is that renames seem to confuse svn diff.
> For example:
>
> $ cd gcc/cp
> $ svn log -r81829 cp-gimplify.c
>
> r81829 | dnovillo | 2004-05-13 22:29:32 -0400 (Thu, 13 May 2004)
On 13/02/13 17:00, Jonathan Wakely wrote:
On 13 February 2013 16:32, Alec Teal wrote:
On 13/02/13 16:11, Jonathan Wakely wrote:
On 13 February 2013 15:33, Alec Teal wrote:
A few questions, what is this stage 1? (link to documentation please, or
a
descriptive answer).
See http://gcc.gnu.org/
On 13 February 2013 16:32, Alec Teal wrote:
> On 13/02/13 16:11, Jonathan Wakely wrote:
>>
>> On 13 February 2013 15:33, Alec Teal wrote:
>>>
>>> A few questions, what is this stage 1? (link to documentation please, or
>>> a
>>> descriptive answer).
>>
>> See http://gcc.gnu.org/develop.html
>>
>>
Hi,
I am working on enabing libsanitizer on ARM.
I have a very simple patch to enable it, and a sample program seems to
work on board.
However, I would like to use qemu as an execution engine, but I get
error messages from libsanitizer at startup:==30022== Shadow memory
range interleaves with an
On 13/02/13 16:11, Jonathan Wakely wrote:
On 13 February 2013 15:33, Alec Teal wrote:
A few questions, what is this stage 1? (link to documentation please, or a
descriptive answer).
See http://gcc.gnu.org/develop.html
for the choice of file extension, this is really a tiny thing, but I do ha
On 13/02/13 16:24, Jonathan Wakely wrote:
On 13 February 2013 15:33, Alec Teal wrote:
I'm also thinking of re-writing the C++ parser there are some interesting
todos (using lookahead rather than "try the next option") it's a topic I
enjoy and something I could (probably) do, especially given a w
On 13 February 2013 15:33, Alec Teal wrote:
> I'm also thinking of re-writing the C++ parser there are some interesting
> todos (using lookahead rather than "try the next option") it's a topic I
> enjoy and something I could (probably) do, especially given a working
> version already. thoughts and
On 13 February 2013 15:33, Alec Teal wrote:
>
> A few questions, what is this stage 1? (link to documentation please, or a
> descriptive answer).
See http://gcc.gnu.org/develop.html
> for the choice of file extension, this is really a tiny thing, but I do have
> a reason for .cpp
> http://stacko
On 02/13/2013 03:06 PM, Diego Novillo wrote:
> One problem I've noticed is that renames seem to confuse svn diff. For
> example:
>
> $ cd gcc/cp
> $ svn log -r81829 cp-gimplify.c
>
> r81829 | dnovillo | 2004-05-13 22:29:32
On 13/02/13 13:47, Diego Novillo wrote:
I feel silly now, why not use .cpp? SVN's move not good enough?
(or is it just because no one could be bothered?)
The latter. Perhaps we should start renaming the files. It will help
with this confusion and it will also be useful for tools like editors
On Wed, Feb 13, 2013 at 9:59 AM, Ian Lance Taylor wrote:
> I have no opinion on whether it is better to rename files now or later.
>
> I do think it is better to rename the files at some point.
>
> I would vote for renaming to an extension of ".cc".
Likewise.
One problem I've noticed is that re
On Wed, Feb 13, 2013 at 5:47 AM, Diego Novillo wrote:
> On Wed, Feb 13, 2013 at 8:31 AM, Alec Teal wrote:
>> On 13/02/13 12:39, Richard Biener wrote:
>>>
>>> On Wed, Feb 13, 2013 at 1:31 PM, Alec Teal wrote:
>>> It's just a filename ... we compile it with a C++ compiler.
>>>
>>> Richard.
>>
>> I
Richard Biener skribis:
> On Wed, Feb 13, 2013 at 12:13 PM, Richard Biener
> wrote:
>> On Tue, Feb 12, 2013 at 9:41 PM, Ludovic Courtès wrote:
>>> Joel Sherrill skribis:
>>>
But it still doesn't address the situation where you have multiple
cross compilers in your PATH all for differ
Hi,
I am pleased to announce the release of ODB 2.2.0.
ODB is an open source object-relational mapping (ORM) system for C++. It
allows you to persist C++ objects to a relational database without having
to deal with tables, columns, or SQL and without manually writing any of
the mapping code.
ODB
On Wed, Feb 13, 2013 at 8:31 AM, Alec Teal wrote:
> On 13/02/13 12:39, Richard Biener wrote:
>>
>> On Wed, Feb 13, 2013 at 1:31 PM, Alec Teal wrote:
>> It's just a filename ... we compile it with a C++ compiler.
>>
>> Richard.
>
> I feel silly now, why not use .cpp? SVN's move not good enough?
>
On 13/02/13 12:39, Richard Biener wrote:
On Wed, Feb 13, 2013 at 1:31 PM, Alec Teal wrote:
It's just a filename ... we compile it with a C++ compiler.
Richard.
I feel silly now, why not use .cpp? SVN's move not good enough?
(or is it just because no one could be bothered?)
Alec
I am sorry if
On Wed, Feb 13, 2013 at 1:31 PM, Alec Teal wrote:
> I've been studying/reading gccs code, watching it compile though a debugger
> and reading. Today I noticed something odd in the c++ parser's file. I saw
> what appeared to be a template in a .c file.
It's just a filename ... we compile it with
I've been studying/reading gccs code, watching it compile though a debugger and
reading. Today I noticed something odd in the c++ parser's file. I saw what
appeared to be a template in a .c file.
I am on a different computer now but it was vec< and occurred about 1/6th of
the way in, it should
On Tue, Feb 12, 2013 at 11:31 PM, David Miller wrote:
> From: David Miller
> Date: Fri, 16 Nov 2012 00:33:05 -0500 (EST)
>
>> From: Richard Sandiford
>> Date: Mon, 29 Oct 2012 10:14:53 +
>>
>>> ...given that the code is like you say written:
>>>
>>> if (SHIFT_COUNT_TRUNCATED)
>>> {
>>>
On Wed, Feb 13, 2013 at 12:13 PM, Richard Biener
wrote:
> On Tue, Feb 12, 2013 at 9:41 PM, Ludovic Courtès wrote:
>> Joel Sherrill skribis:
>>
>>> But it still doesn't address the situation where you have multiple
>>> cross compilers in your PATH all for different targets.
>>
>> Yeah, I thought
On Tue, Feb 12, 2013 at 9:41 PM, Ludovic Courtès wrote:
> Joel Sherrill skribis:
>
>> But it still doesn't address the situation where you have multiple
>> cross compilers in your PATH all for different targets.
>
> Yeah, I thought about it, but couldn’t come up with a practical use case
> where
35 matches
Mail list logo
