Hi all,
I have received no reply regarding this issue so I am still wondering
if anyone has any idea about this since I am still struggling to
understand if the tree of current_function_decl gets partially
destroyed during the expand pass where TARGET_FUNCTION_OK_FOR_SIBCALL
gets called.
If anybo
http://www.gamedev.net/community/forums/topic.asp?topic_id=559287
SOURCE
template
void foo(pTYPE arg)
{ arg.nid(); }
template
void bar()
{
pTYPE var;
foo(var);
}
void foo(int)
{}
int main()
{
int i;
foo(i); // OK: Resolves foo(int
Hi
On Mon, Jan 18, 2010 at 10:37:34PM +1300, Simon Hill wrote:
> http://www.gamedev.net/community/forums/topic.asp?topic_id=559287
>
> SOURCE
>
> template
> void foo(pTYPE arg)
> { arg.nid(); }
>
> template
> void bar()
> {
> pTYPE var;
> foo(var);
>
Hi,
As a continuation of my previous issue, what's the difference between
cfun and current_function_decl and which one should I use to walk the
tree during TARGET_FUNCTION_OK_FOR_SIBCALL?
[In the internals document I only found references to cfun and even
there was hard to understand what it actu
On Mon, Jan 18, 2010 at 11:24 AM, Paulo J. Matos wrote:
> Hi,
>
> As a continuation of my previous issue, what's the difference between
> cfun and current_function_decl and which one should I use to walk the
> tree during TARGET_FUNCTION_OK_FOR_SIBCALL?
>
> [In the internals document I only found
2010/1/18 Adam Nemet :
> Sorry for jumping in late. See make_file_assigment in combine.c.
>
> The problem usually is that:
>
> (set A (ior (and B C1) OTHER))
>
> can only be turned into a bit-insertion if A and B happen to be the same
> pseudos.
>
> Adam
>
Thank you, Adam. The problem is that be
Hi all,
I have recently run into a non-portable c-torture test
(gcc.c-torture/execute/20030128-1.c) and would like to suggest an update for
it.
The test performs division of unsigned char by (signed) short:
unsigned char x = 50;
volatile short y = -5;
int main ()
{
x /= y;
and checks that
On 01/18/2010 12:24 PM, YuGr wrote:
> I have recently run into a non-portable c-torture test
>
I have seen something similar in the past appearing on the mailing list
and maybe I can say something, briefly. A first consideration is that in
GCC we have, in general, regression testsuites, not C/
> I have seen something similar in the past appearing on the mailing list
I guess that was also from me)
> Pragmatically, I don't think people are really happy to start including
> limits.h everywhere or even conditionalizing tests for the most exotic
> combination of the limits themselves
Probabl
On 01/18/2010 12:41 PM, YuGr wrote:
>> combination of the limits themselves
>>
> Probably sizeof(char) == sizeof(short) is not that exotic...
>
Maybe you are right, I'm not arguing about that specific detail, you
know I have been using a rather limited range of different machines. So,
is th
> So, is the test *actually* failing for some targets?
We are developing our own compiler for experimental target (pure scientific
activity) and we are using c-torture to test it. Our compiler has
sizeof(char) == sizeof(short) ( == 1) and fails with this test.
--
С уважением,
Юрий
On Mon, Jan 18, 2010 at 10:30 AM, Richard Guenther
wrote:
> On Mon, Jan 18, 2010 at 11:24 AM, Paulo J. Matos wrote:
>> Hi,
>>
>> As a continuation of my previous issue, what's the difference between
>> cfun and current_function_decl and which one should I use to walk the
>> tree during TARGET_FUN
On Mon, Jan 18, 2010 at 1:40 PM, Paulo J. Matos wrote:
> On Mon, Jan 18, 2010 at 10:30 AM, Richard Guenther
> wrote:
>> On Mon, Jan 18, 2010 at 11:24 AM, Paulo J. Matos wrote:
>>> Hi,
>>>
>>> As a continuation of my previous issue, what's the difference between
>>> cfun and current_function_decl
On Mon, Jan 18, 2010 at 12:58 PM, Richard Guenther
wrote:
>
> Yes. During expansion we destroy the trees.
>
Is there a way to avoid tree destruction? Maybe through a flag?
If not, what I need is in the hook, to know if the caller, calls any
other functions besides the one we are evaluating the s
On Monday 18 January 2010 16:19:23 Joseph S. Myers wrote:
> On Mon, 18 Jan 2010, YuGr wrote:
> > But according to C99 Standard (see Usual arithmetic conversions,
> > 6.3.1.8):
>
> First the integer promotions are applied, so you need UCHAR_MAX not to be
> representable as int (not just as short).
>
On Mon, Jan 18, 2010 at 2:05 PM, Paulo J. Matos wrote:
> On Mon, Jan 18, 2010 at 12:58 PM, Richard Guenther
> wrote:
>>
>> Yes. During expansion we destroy the trees.
>>
>
> Is there a way to avoid tree destruction? Maybe through a flag?
> If not, what I need is in the hook, to know if the calle
On Mon, Jan 18, 2010 at 1:25 PM, Richard Guenther
wrote:
>
> Look at cgraph_node (cfun->decl)->callers
>
> Richard.
>
Exactly what I need. :) And the day looks brighter now!
Thank you very much.
--
Paulo Jorge Matos - pocmatos at gmail.com
http://www.pmatos.net
On Mon, 18 Jan 2010, YuGr wrote:
> But according to C99 Standard (see Usual arithmetic conversions, 6.3.1.8):
First the integer promotions are applied, so you need UCHAR_MAX not to be
representable as int (not just as short).
As previously discussed at length, many changes are needed in various
On 01/18/10 03:39, fanqifei wrote:
2010/1/18 Adam Nemet:
Sorry for jumping in late. See make_file_assigment in combine.c.
The problem usually is that:
(set A (ior (and B C1) OTHER))
can only be turned into a bit-insertion if A and B happen to be the same
pseudos.
Adam
Thank yo
Dear all,
I have a current issue on my port. Basically the stack is defined as follows :
1) CALL_USED save area
2) Local variables
3) Caller arguments passed on the stack
4) 8 words to save arguments passed in registers, even if not passed
Now, this was done because we have defined 8 output regi
Re Axel:
Quote (Axel):
"Well, I think g++ behaves correctly. As I understand the standard,
the normal function foo(int) can't be used in the template "bar",
because it is only declared afterwards."
Me:
I don't think this can be correct. Removing the template foo() but
leaving the normal one also
On Mon, Jan 18, 2010 at 4:20 PM, Simon Hill wrote:
> I'm pretty sure this is a bug but I'd like a confirmation (or
> refutation) before I submit a bug report.
>
First the issue here is what namespace does the foundental types in
C++ have? The standard says none which makes this code invalid but
Axel Quote:
"Anyways there is an already filed GCC bug about this defect report
against the standard,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29131 ."
That bug report is suspended. Is this due to the C++ standards issue
you referred to?:
http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.h
23 matches
Mail list logo
