Re: A happy problem caused by loongson2f's div.g instruction
On 18:31 Sun 09 Nov , Andrew Haley wrote: > Zhang Le wrote: > > > > > The other would be make sure the destination register is different from > > source registers. > > I have read some docs, but still not sure how to do it. > > That's just an earlyclobber. Search for that. Thank you, Andrew! I have read about it, but maybe not fully understand it. I will read again. Zhang, Le
Re: H8SX: Bit instructions for review
Naveen H.S. wrote: causing the branch to be based on the output of the bit op rather than whatever was in cc0 from some previous operation Yes, the peepholes cause the branch to be based on the output of bit. However, the peepholes were implemented as they generate new conditional bit instructions. We realize that they do not help in any optimization. Hence, peepholes will be removed as per the suggestion and patch will be reposted when GCC returns to stage1. In the past we've created PRs to track patches waiting for the tree to return to stage1 (17652, 28177, 23111, 33702). Feel free to create a GCC 4.5 pending patches PR and attach the updated patch to that PR to ensure it doesn't get lost while we wait for the tree to return to stage1. jeff
RE: H8SX: Bit instructions for review
Hi Jeff, >> Don't forget to include the ChangeLog. Thanks a lot for verifying the patch and useful suggestions. >> causing the branch to be based on the output of the bit op rather >> than whatever was in cc0 from some previous operation Yes, the peepholes cause the branch to be based on the output of bit. However, the peepholes were implemented as they generate new conditional bit instructions. We realize that they do not help in any optimization. Hence, peepholes will be removed as per the suggestion and patch will be reposted when GCC returns to stage1. Regards, Naveen.H.S. KPIT Cummins Infosystems Ltd, Pune ( INDIA ) www.kpitgnutools.com
"__throw_logic_error" abort, but print no error message out
Hello
the file in bits/basic_string.tcc call it.
template
template
_CharT*
basic_string<_CharT, _Traits, _Alloc>::
_S_construct(_InIterator __beg, _InIterator __end, const _Alloc& __a,
forward_iterator_tag)
{
#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
if (__beg == __end && __a == _Alloc())
return _S_empty_rep()._M_refdata();
#endif // NB: Not required, but considered best practice.
if (__builtin_expect(__is_null_pointer(__beg) && __beg != __end, 0))
__throw_logic_error(__N("basic_string::_S_construct NULL not valid"));
But in libstdc++v3/src/functexcept.cc
void
__throw_logic_error(const char*)
{ std::abort(); }
this call abort and there is no string print out, because abort get no
Parameter as far i see.
How can this work ?
When i add testcode
std::__throw_logic_error("error text\n");
then also text is print out but program is quit
I have a gcc4.3.2 68k amigaos build, maybe problem is here, but i dont
understand how this can work with the current source and what i must change
in the build, without change in gcc core Files.
Please help
bye Bernd
Re: A happy problem caused by loongson2f's div.g instruction
On 19:18 Mon 10 Nov , Zhang Le wrote: > However, now I think adding a earlyclobber constraint may be the way to go. > Since it is a less intrusive and more elegant (comparing with my patch above) > change. This solution is as easy as adding two bytes (two &s's) to the original patch: @@ -11,7 +11,7 @@ Index: trunk/gcc/config/mips/loongson.md +;;new integer instructions + +(define_insn "div3" -+ [(set (match_operand:GPR 0 "register_operand" "=d") ++ [(set (match_operand:GPR 0 "register_operand" "=&d") + (any_div:GPR + (match_operand:GPR 1 "register_operand" "d") + (match_operand:GPR 2 "register_operand" "d")))] @@ -22,7 +22,7 @@ Index: trunk/gcc/config/mips/loongson.md +) + +(define_insn "mod3" -+ [(set (match_operand:GPR 0 "register_operand" "=d") ++ [(set (match_operand:GPR 0 "register_operand" "=&d") + (any_mod:GPR + (match_operand:GPR 1 "register_operand" "d") + (match_operand:GPR 2 "register_operand" "d")))] Zhang, Le
Re: A happy problem caused by loongson2f's div.g instruction
On 09:18 Mon 10 Nov , Eric Fisher wrote:
> > So I think one of the possible solution would be to reverse the div.g and
> > teq insn.
> > And I think this is not hard to do, just modify mips_output_division()
> > function.
> > Also I think this is a better solution, since we can save a register.
>
> Do you mean the modification like this?
>
> +
> +
> +/* Used to output (d)div(u).g or (d)mod(u).g instruction of loongson,
> + + which takes three operands, and put the result in the rd register.
> + + Hence emit the divide-by-zeor check before the DIVISION, in case
> + + that the rd and rt are the same one. */
> +const char *
> +mips_output_division_g (const char *division, rtx *operands)
> +{
> + if (TARGET_CHECK_ZERO_DIV)
> +{
> + output_asm_insn ("bne\t%2,%.,1f%#\n\tbreak\t7\n1:", operands);
> +}
> + return division;
> +}
> +
>
> +;; For loongson
> +
> +(define_insn "divsi3"
> + [(set (match_operand:SI 0 "register_operand" "=d")
> + (div:SI (match_operand:SI 1 "register_operand" "d")
> + (match_operand:SI 2 "register_operand" "d")))]
> + "TARGET_LOONGSON2E || TARGET_LOONGSON2F"
> + { return mips_output_division_g ("div.g\t%0,%1,%2", operands); }
> + [(set_attr "type""divg")
> + (set_attr "mode""SI")
> + (set (attr "length")
> +(if_then_else (ne (symbol_ref "TARGET_CHECK_ZERO_DIV") (const_int 0))
> + (const_int 16)
> + (const_int 4)))])
> +
> +(define_insn "udivsi3"
> + [(set (match_operand:SI 0 "register_operand" "=d")
> + (udiv:SI (match_operand:SI 1 "register_operand" "d")
> + (match_operand:SI 2 "register_operand" "d")))]
> + "TARGET_LOONGSON2E || TARGET_LOONGSON2F"
> + { return mips_output_division_g ("divu.g\t%0,%1,%2", operands); }
> + [(set_attr "type""divg")
> + (set_attr "mode""SI")
> + (set (attr "length")
> +(if_then_else (ne (symbol_ref "TARGET_CHECK_ZERO_DIV") (const_int 0))
> + (const_int 16)
> + (const_int 4)))])
Hi, Eric. This is my version:
--- trunk/gcc/config/mips/mips.c.orig 2008-11-10 02:23:33.0 +0800
+++ trunk/gcc/config/mips/mips.c2008-11-10 02:24:56.0 +0800
@@ -10359,8 +10359,15 @@
}
else if (GENERATE_DIVIDE_TRAPS)
{
- output_asm_insn (s, operands);
- s = "teq\t%2,%.,7";
+ if (TARGET_LOONGSON_2EF)
+ {
+ output_asm_insn ("teq\t%2,%.,7", operands);
+ }
+ else
+ {
+ output_asm_insn (s, operands);
+ s = "teq\t%2,%.,7";
+ }
}
else
{
I have tried it. It seems to be working.
However, now I think adding a earlyclobber constraint may be the way to go.
Since it is a less intrusive and more elegant (comparing with my patch above)
change.
Zhang, Le
Re: A happy problem caused by loongson2f's div.g instruction
Zhang Le <[EMAIL PROTECTED]> writes: > On 19:18 Mon 10 Nov , Zhang Le wrote: >> However, now I think adding a earlyclobber constraint may be the way to go. >> Since it is a less intrusive and more elegant (comparing with my patch >> above) change. > > This solution is as easy as adding two bytes (two &s's) to the original patch: > @@ -11,7 +11,7 @@ Index: trunk/gcc/config/mips/loongson.md > +;;new integer instructions > + > +(define_insn "div3" > -+ [(set (match_operand:GPR 0 "register_operand" "=d") > ++ [(set (match_operand:GPR 0 "register_operand" "=&d") > + (any_div:GPR > + (match_operand:GPR 1 "register_operand" "d") > + (match_operand:GPR 2 "register_operand" "d")))] > @@ -22,7 +22,7 @@ Index: trunk/gcc/config/mips/loongson.md > +) > + > +(define_insn "mod3" > -+ [(set (match_operand:GPR 0 "register_operand" "=d") > ++ [(set (match_operand:GPR 0 "register_operand" "=&d") > + (any_mod:GPR > + (match_operand:GPR 1 "register_operand" "d") > + (match_operand:GPR 2 "register_operand" "d")))] FWIW, I agree this is probably the best fix. Richard
Re: [MIPS]question about floating point conditional branch
"Eric Fisher" <[EMAIL PROTECTED]> writes: > In mips.md, conditional branch insns are all set with the attribute > value 'branch'. But floating point instructions such as bc1f will > reserve falu unit instead of ialu. So there's a problem when you try > to describe pipeline for 'branch' insns. Define the ialu as the > reservation for all 'branch' insns? Is it OK? It's certainly OK to split to "branch" into "ibranch" and "fbranch" if there's a use for it. The only reason we haven't done so up till now is because no-one's really needed to. That's the way things usually work the "type" attribute: it starts out as coarse-grained as possible, then we add new classifications when we need them. Richard
Passing attributes to RTX
Hello all,
While prototyping a port of gcc I think that the RTX is lacking some
information needed to generate machine dependent files. The expression
trees have the correct information and I can likely hack in a quick fix to
pass that information down to the backend. However, I just want to make
sure I am not doing something completely wrong.
Basically given the following code,
void main(T x)
{
T * pt; //pointer to type T
*pt = x
}
now I need the RTX to know about type T (specifically its qualifiers as I
am doing this for the named address space branch), I changed the backend to
encode these into the RTX generated by the VAR_DECL and PARM_DECL nodes,
however, I am not sure if it is suppose to be encoded in the INDIRECT_REF
node as pt is theoretically a pointer to T.
I just quickly hacked this information into expand_expr_real_1 in expr.c,
however this may be the incorrect approach, is there any specific location
where I should be modifying RTX attributes and when expand_expr_real_1 is
done should the RTX returned have all the attributes (that can be deduced
from the expression tree) set?
- Thanks for the help, Gobi
sparc64 .register when build != host?
We have a system where, when bootstrapping, gcc is used to output assembly on the host, and the assembly files are copied to another system, where they are assembled and linked. Whether we use GNU as and ld or native/vendor is flexible, depending on what works and what I care to build. e.g. AIX is going to require all native/vendor, Irix will require GNU as and vendor ld (until/unless I debug assertion failure in GNU ld). Solaris can probably go either way on as/ld, but currently I'm using Sun for both. I ran into a problem on sparc64-solaris where the .register psuedo op was missing. That's basically the entire problem -- .register is completely absent and the assembler gives lots of errors saying exactly that. No big mystery, no runtime errors, etc. I fixed by hand patching auto-host.h. Next run I'll set gcc_cv_as_sparc_register_op=yes. I think I can phrase this in a more mainstream way. What if build != host, without in-tree binutils/gas? You can't probe the assembler behavior, eh? Maybe gas is ok without .register? ok, if I'm going to use Sun native as? Are there actually old GNU as that target sparc64, but allow omitting .register? I have not looked at the history. More generally, all the business of probing the assembler.. Changing the assembler out from under gcc requires reconfigure/rebuild? Sometimes. In this instance, it looks like it could easily be made a runtime switch. Granted, still not turnkey -- still have to decide a default, and then leave the user to possibly fix it. Unless there is a cheap way to probe at runtime, though that's kind of exactly one of the points -- configure isn't cheap, nor even validation of it. Maybe a "first run" or "configure on host" phase would be nice. I know, it smacks of "setup" instead of just "copy". Any case where gcc needs to know the assembler's behavior..would be fixed by integrating gcc and gas... I guess this is just the general problem of non-native builds, configure done at build-time, but often wants to probe the host environment, not the build environment, and you just muddle along somehow for build != host? Having to set the cv variables isn't deemed so bad? - Jay
[ping] Re: simplify_subreg vs gen_rtx_SUBREG vis WORDS_BIG_ENDIAN
Ping? http://gcc.gnu.org/ml/gcc/2008-10/msg00491.html
Re: [BUG] pragma: attempt to use poisoned * in struct member
> "Jiri" == Jiri Slaby <[EMAIL PROTECTED]> writes: Jiri> I want to extend cpp to extract some more info (for backward Jiri> mapping from preprocessed_code into source_code+line+column) Jiri> into xml while preprocessing and I use gdome2 library. If I try Jiri> to compile it, it fails due to: [...] I would suggest just dropping the #pragma poison from your gcc. Or, I guess you could use a different XML library. Jiri> At least some option to disable these pragma checks inside cpp Jiri> would be great. (I suppose there is none, I found it neither in Jiri> gcc.info nor cpp.info nor anywhere else...) There isn't one. Tom
GCC -O error?
Hi,
I am using GCC version 4.3.0 on Linux FC 9. I found following a wired situation:
In a test.cpp there is a statement:
uint16_t so = ::htons(a); // line 168
It compiled fine if I use -g. But when I changed the -g to -O, it
broken to errors:
g++ -O -Wall -Wundef -Wabi -Wextra -Wunused -Wconversion -c -o
test.o test.cpp
test.cpp:168: error: expected id-expression before '(' token
test.cpp:168: warning: conversion to 'short unsigned int' from 'int'
may alter its value
Is it a bug, or what I am missing here?
Thank you.
Kind Regards,
Sean
apply maintainer?
Hello, Anyone could tell how to be a gcc maintainer? Is there any requirement? Actually, my previous work are all not based on the gcc trunk. So no patch submitted. Anyway, it's cool to contribute :-) Thanks. Eric Fisher 2008-11-11
Re: Passing attributes to RTX
[EMAIL PROTECTED] writes:
> While prototyping a port of gcc I think that the RTX is lacking some
> information needed to generate machine dependent files. The expression
> trees have the correct information and I can likely hack in a quick fix to
> pass that information down to the backend. However, I just want to make
> sure I am not doing something completely wrong.
>
> Basically given the following code,
>
> void main(T x)
> {
> T * pt; //pointer to type T
> *pt = x
> }
>
> now I need the RTX to know about type T (specifically its qualifiers as I
> am doing this for the named address space branch), I changed the backend to
> encode these into the RTX generated by the VAR_DECL and PARM_DECL nodes,
> however, I am not sure if it is suppose to be encoded in the INDIRECT_REF
> node as pt is theoretically a pointer to T.
>
> I just quickly hacked this information into expand_expr_real_1 in expr.c,
> however this may be the incorrect approach, is there any specific location
> where I should be modifying RTX attributes and when expand_expr_real_1 is
> done should the RTX returned have all the attributes (that can be deduced
> from the expression tree) set?
At first glance this sounds like something that should be stored in
mem_attrs.
Ian
Re: apply maintainer?
"Eric Fisher" <[EMAIL PROTECTED]> writes: > Anyone could tell how to be a gcc maintainer? Is there any > requirement? Actually, my previous work are all not based on the gcc > trunk. So no patch submitted. Anyway, it's cool to contribute :-) The usual procedure is to write a bunch of good patches which are accepted, and thereby demonstrate your thorough understanding of some part of gcc. In general maintainers are invited by the steering committee, though it is appropriate to nominate or self-nominate for specific OS and CPU ports. Ian
