I'm working on a gcc backend for an architecture. The architecture has
instructions for indexed array access; so, ld r0, (r1, r2) is equivalent
to r0 = r1[r2] where r1 is a int32_t*.
I'm representing this in the .md file with the following pattern:
(define_insn "*si_load_indexed"
[
(set
On 9 July 2013 11:02, David Given wrote:
> Right now all the cost macros are left as the default, which is probably
> the root of the problem; but I'm having a lot of trouble getting my head
> around them. In the interest of actually getting something to work, are
> there any ways of using a simpl
2013/7/9, David Given :
> I'm working on a gcc backend for an architecture. The architecture has
> instructions for indexed array access; so, ld r0, (r1, r2) is equivalent
> to r0 = r1[r2] where r1 is a int32_t*.
>
> I'm representing this in the .md file with the following pattern:
>
> (define_insn
When building gdb with newer gcc versions I frequently stumble across
maybe-uninitialized false positives, like the ones documented in bug
57237. Various bugs address similar issues, and in bug 56526 Jakub
Jelinek wrote:
> Maybe-uninitialized warnings have tons of known false positives, while
> t
On 07/09/2013 12:59 PM, Andreas Arnez wrote:
> With this situation at hand, I wonder whether it's a good idea to keep
> maybe-uninitialized included in -Wall. Projects which have been using
> "-Wall -Werror" successfully for many years are now forced to
> investigate non-existing bugs in their cod
On 9 July 2013 13:04, Andrew Haley wrote:
> On 07/09/2013 12:59 PM, Andreas Arnez wrote:
>> With this situation at hand, I wonder whether it's a good idea to keep
>> maybe-uninitialized included in -Wall. Projects which have been using
>> "-Wall -Werror" successfully for many years are now forced
Hi,
On Sun, 7 Jul 2013, Thierry Lavoie wrote:
> int main(int argc, char** argv)
> {
> A* ptr = 0;
> if(argc == 1)
> ptr = new B();
> else
> ptr = new A();
>
> ptr->blah();
>
> B().blah();
> C().blah();
> }
>
> The
Hi,
On Tue, 9 Jul 2013, David Given wrote:
> Trying 8, 9 -> 10:
> Successfully matched this instruction:
> (set (reg:SI 47 [ *_5 ])
> (mem:SI (plus:SI (mult:SI (reg/v:SI 43 [ b ])
> (const_int 4 [0x4]))
> (reg:SI 0 r0 [ a ])) [2 *_5+0 S4 A32]))
> rejecting combinat
On 07/09/2013 02:56 PM, Andreas Arnez wrote:
> What matters is whether *some* stages of production code development use
> this combination of options. It could certainly be argued whether it
> should also be a project's "configure" default, like currently the case
> for gdb.
It's not a problem fo
Andrew Haley writes:
> On 07/09/2013 12:59 PM, Andreas Arnez wrote:
>> With this situation at hand, I wonder whether it's a good idea to keep
>> maybe-uninitialized included in -Wall. Projects which have been using
>> "-Wall -Werror" successfully for many years are now forced to
>> investigate n
On a machine with ABI ILP32LL64:
(insn 123 122 124 (nil) (set (reg:SI 392)
(mem:SI (plus:SI (reg/v:SI 386)
(reg/v:SI 349)) [0 sec 0 space 0, cmsmode 0 S4 A32])) -1 (nil)
(nil))
If we support legitimate memory addresses like [r1+r2] (e.g. indexed
addresses), can the abo
Andrew> I would question the appropriateness of using -Wall -Werror in
Andrew> production code.
Andreas> What matters is whether *some* stages of production code
Andreas> development use this combination of options. It could
Andreas> certainly be argued whether it should also be a project's
Andre
Hi
My name is Cong Hou, and I am a Noogler working in the compiler
optimization team at Google.
When we were trying moving the vectorization from O3 to O2 in GCC 4.9,
we met a bootstrap failure from comparison between stage 2&3. This
failure is caused by a potential bug in GCC as stated below.
I
Please repost the patch to gcc-patches@ mailing list.
David
On Tue, Jul 9, 2013 at 1:10 PM, Cong Hou wrote:
> Hi
>
> My name is Cong Hou, and I am a Noogler working in the compiler
> optimization team at Google.
>
> When we were trying moving the vectorization from O3 to O2 in GCC 4.9,
> we met
I think I have found a bug. This is in stock gcc 4.8.1...
My backend does not use the 'enabled' attribute; therefore the following
code in insn-attr.h kicks in:
#ifndef HAVE_ATTR_enabled
#define HAVE_ATTR_enabled 0
#endif
Therefore the following code in gcc/lra-constraints.c is enabled:
On 07/09/2013 07:56 AM, Andreas Arnez wrote:
Andrew Haley writes:
On 07/09/2013 12:59 PM, Andreas Arnez wrote:
With this situation at hand, I wonder whether it's a good idea to keep
maybe-uninitialized included in -Wall. Projects which have been using
"-Wall -Werror" successfully for many ye
16 matches
Mail list logo