Hello,
thank you for your answer, it was very useful.
In my source code I have some useful informations about variables (for
example a variable which is a real time attribute) and I would like to
know it in the intermediate representation to do what I have to about
it. Is there a way to have s
Thanks, that worked. I ended up using:
(define_insn "cmpcc_xor"
[(set (match_operand:CC 0 "register_operand" "=C")
(compare:CC
(not:SI (xor:SI (match_operand:SI 1 "register_operand" "%r")
(match_operand:SI 2 "register_operand" "b")))
(const_int
Michael Eager wrote:
> I'll reverse-engineer the table unless I can find something
> more descriptive than the comments in gcc or gdb.
FWIW, I did a similar exercise long ago and synthesized my
understanding in ada/raise-gcc.c, where the Ada personality routine
is implemented.
Olivier
Ian,
I would like to come back to this issue after being away for two weeks (if you
still
can remember the problem :-)). I tried to track the problem with other target
(ARM),
and it doesn't show up. After some investigation, I found the pseudo register
is accepted by constrain_operands function e
Thanks.
Now I have a few questions.
You mentioned that the "make -k # check" is broken on Solaris.
I built the compiler using the -k option, is that a concern?
or is it just the "check" target is broken?
IOW, should I build the compiler without the "-k" option?
At this point, should I do the n
As follows:
> cc1: warnings being treated as errors
> /usr/test/gcc/gcc/fortran/intrinsic.c: In function 'add_sym':
> /usr/test/gcc/gcc/fortran/intrinsic.c:306: error: enum conversion in
> assignment is invalid in C++
> gmake[3]: *** [fortran/intrinsic.o] Error 1
> gmake[3]: Leaving directory `/u
Dear Gerald,
> /usr/test/gcc/gcc/fortran/intrinsic.c: In function 'add_sym':
> /usr/test/gcc/gcc/fortran/intrinsic.c:306: error: enum conversion in
> assignment is invalid in C++
Can you try whether the following patch works? If so, you can
commit it as obvious. (I cannot test/commit it until th
On Mon, May 18, 2009 at 3:00 PM, Tobias Burnus wrote:
> Dear Gerald,
>
>> /usr/test/gcc/gcc/fortran/intrinsic.c: In function 'add_sym':
>> /usr/test/gcc/gcc/fortran/intrinsic.c:306: error: enum conversion in
>> assignment is invalid in C++
>
> Can you try whether the following patch works? If so,
Nicolas COLLIN wrote:
> In my source code I have some useful informations about variables (for
> example a variable which is a real time attribute) and I would like to
> know it in the intermediate representation to do what I have to about
> it. Is there a way to have some informations in the inte
Richard Guenther writes:
> On Mon, May 18, 2009 at 3:00 PM, Tobias Burnus wrote:
>> Index: intrinsic.c
>> ===
>> --- intrinsic.c (revision 147659)
>> +++ intrinsic.c (working copy)
>> @@ -303,7 +303,7 @@
>> type = (bt) va_arg
2009/5/18 Tobias Burnus :
> Can you try whether the following patch works? If so, you can
> commit it as obvious. (I cannot test/commit it until this evening.)
>
> Tobias
>
> Index: intrinsic.c
> ===
> --- intrinsic.c (revision 147659)
2009/5/18 Janus Weil :
> 2009/5/18 Tobias Burnus :
>> Can you try whether the following patch works? If so, you can
>> commit it as obvious. (I cannot test/commit it until this evening.)
>>
>> Tobias
>>
>> Index: intrinsic.c
>> ===
>>
"Bingfeng Mei" writes:
> In our porting, "movm" is implemented as define_expand. Register move and
> memory
> move are implmeneted in different define_insn. Register move pattern has no
> "m" alternative, and thus causes the "asm operand requires impossible reload".
> I should merge these two pa
Mikolaj Golub writes:
> The problem is in libgomp/team.c. gomp_thread_start() does gomp_sem_init()
> but gomp_sem_destroy() is never called. FreeBSD implementation of sem_init()
> allocates some memory for semaphore. This patch solves the problem for me:
Thanks for tracking that down, and filin
Amitava Dutta writes:
> You mentioned that the "make -k # check" is broken on Solaris.
You mean -j, not -k. There is no problem with -k.
> I built the compiler using the -k option, is that a concern?
> or is it just the "check" target is broken?
> IOW, should I build the compiler without the "
Olivier Hainque wrote:
Michael Eager wrote:
I'll reverse-engineer the table unless I can find something
more descriptive than the comments in gcc or gdb.
FWIW, I did a similar exercise long ago and synthesized my
understanding in ada/raise-gcc.c, where the Ada personality routine
is impleme
On Mon, 2009-05-18 at 19:58 +1200, Michael Hope wrote:
> (set (match_operand:SI 3 "register_operand" "=1")
> (not:SI (xor:SI (match_dup 1) (match_dup 2]
not xor is aka xnor. You probably want this without the two "not"
operations.
Jim
On Mon, 18 May 2009, Richard Guenther wrote:
> > - intent = va_arg (argp, int);
> > + intent = (sym_intent) va_arg (argp, int);
>
> intent = va_arg (argp, sym_intent);
>
> instead?
You can't use va_arg with an enum type on short-enums hosts, though we may
not presently support any
On Sat, 2009-05-16 at 10:45 -0400, Diego Novillo wrote:
> On the LTO branch, I am brute-forcing LTO compilation on all the
> testsuite directories. This causes many spurious failures because we
> are not going to support LTO compiles on everything. For instance,
> LTO is not supported for fortran
Yip, picked that up after I sent it. Thanks.
2009/5/19 Jim Wilson :
> On Mon, 2009-05-18 at 19:58 +1200, Michael Hope wrote:
>> (set (match_operand:SI 3 "register_operand" "=1")
>> (not:SI (xor:SI (match_dup 1) (match_dup 2]
>
> not xor is aka xnor. You probably want this without the
On Sat, May 16, 2009 at 5:49 AM, Richard Guenther
wrote:
> On Sat, May 16, 2009 at 11:41 AM, VandeVondele Joost
> wrote:
>>
> I think it is useful to have a bugzilla here.
will do.
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40168
>>
>>>
>>> Btw, complete unrolling is also hi
Hi Ian
In the last couple of days, I have started seeing the following warnings
when building target-libiberty:
/home/bje/source/gcc-clean/libiberty/cp-demangle.c:723: warning: logical ‘and’
of mutually exclusive tests is always false
/home/bje/source/gcc-clean/libiberty/cp-demangle.c:742: warni
On Tue, 2009-05-19 at 10:28 +1000, Ben Elliston wrote:
> Hi Ian
>
> In the last couple of days, I have started seeing the following warnings
> when building target-libiberty:
>
> /home/bje/source/gcc-clean/libiberty/cp-demangle.c:723: warning: logical
> ‘and’ of mutually exclusive tests is alway
On Mon, May 18, 2009 at 5:34 PM, Janis Johnson wrote:
>> The code around line 723 is:
>>
>> if (p == NULL
>> || name == NULL
>> || (kind < gnu_v3_complete_object_ctor
>> && kind > gnu_v3_complete_object_allocating_ctor))
>> return 0;
>>
>> (and similarly for line 742).
On Mon, May 18, 2009 at 5:28 PM, Ben Elliston wrote:
> Hi Ian
>
> In the last couple of days, I have started seeing the following warnings
> when building target-libiberty:
>
> /home/bje/source/gcc-clean/libiberty/cp-demangle.c:723: warning: logical
> ‘and’ of mutually exclusive tests is always f
On Mon, 2009-05-18 at 17:40 -0700, H.J. Lu wrote:
> We have
>
> enum gnu_v3_ctor_kinds {
> gnu_v3_complete_object_ctor = 1,
> gnu_v3_base_object_ctor,
> gnu_v3_complete_object_allocating_ctor
> };
>
> What does
>
> (kind < gnu_v3_complete_object_ctor
> && kind > gnu_v3_complete_o
Ben Elliston writes:
> In the last couple of days, I have started seeing the following warnings
> when building target-libiberty:
>
> /home/bje/source/gcc-clean/libiberty/cp-demangle.c:723: warning: logical
> ‘and’ of mutually exclusive tests is always false
> /home/bje/source/gcc-clean/libibert
Hello,
I have the libelf installed in a non-standard path, so when I build
the lto branch, I set the such env variables,
$ export CPPFLAGS="-I" <- Only needed if
libelf is in a non-standard path
$ export LDFLAGS="-L" <- Only needed if
libelf is in a non-standard path
But, lto-plugin is fa
28 matches
Mail list logo
