Re: Problem with static linking
On 07/16/2009 09:08 PM, Zachary Turner wrote: > > There's also much less to deal with from a Q/A and tech support > perspective if you use static linking with a closed source > application, since you can produce 1 binary which works across > multiple distributions and kernels without the user compiling it, > which is what I'm dealing with. That's more of an assumption than an advantage. It may well appply to some libraries, but libc is really part of the host OS. Anyone linking statically with libc on GNU/Linux is probably making a mistake. Andrew.
bootstrapping and regtesting 4.5 is much slower than 4.4.1
Since 4.4.1 is closed to be released, I have bootstrapped and regtested 4.4.1 in the 4_4 branch at revision 149690. It took ~2h30 to bootstrap and ~5+h to regtest (single thread) on my macbook. The typical times for trunk are between 3h30 and 4h for bootstrap and ~8h to regtest. Is this known or am I the only to see that? Any explaination? TIA Dominique
Re: bootstrapping and regtesting 4.5 is much slower than 4.4.1
On Fri, Jul 17, 2009 at 11:08 AM, Dominique Dhumieres wrote: > Since 4.4.1 is closed to be released, I have bootstrapped and regtested > 4.4.1 in the 4_4 branch at revision 149690. It took ~2h30 to bootstrap > and ~5+h to regtest (single thread) on my macbook. The typical times > for trunk are between 3h30 and 4h for bootstrap and ~8h to regtest. > > Is this known or am I the only to see that? Any explaination? I guess we got more checking (at least EH checking was added, also we do type verification everywhere now). To confirm this you could compare bootstrap/testing numbers with checking disabled. Richard. > TIA > > Dominique >
Re: Preserve registers across function call (Re: CALL_USED_REGISTERS)
Richard, thanks for great help,
I think it'been more than serveral weeks :-) to figure out why.
Now I am in good mood. thanks a lot, really appreciate.
The fragments of the code for mine is like follows.
(It is 4.2.1 based)
(save)
+ for (regno = 0; regno < FIRST_PSEUDO_REGISTER ; regno++)
+{
+ if (!fixed_regs[regno] && regs_ever_live[regno] &&
!call_used_regs[regno])
+{
+ insn = emit_insn (gen_pushqi (gen_rtx_REG (Pmode, regno)));
+ // RTX_FRAME_RELATED_P (insn) = 1;
+}
+}
(restore)
+ for (regno = FIRST_PSEUDO_REGISTER ; regno-- > 0; ) {
+ if ((!fixed_regs[regno] )&& regs_ever_live[regno] &&
(!call_used_regs[regno])) {
+ insn = emit_insn (gen_popqi (gen_rtx_REG (QImode, regno)));
+ // RTX_FRAME_RELATED_P (insn) = 1;
+ }
+ }
Why QImode ? Don't ask that for the moment,
Thanks again,
---
Makoto Fujiwara,
Chiba, Japan, Narita Airport and Disneyland prefecture.
Re: can_throw_internal affected by inlining?
> I'm committing the following test case that displays the bug. It does > in fact pass with mainline, and does in fact fail with gcc 4.4.0. > > I spent two days trying to come up with some cleaner way to fix this bug > than the inlinable flag you pass around, but to no avail. The only > thing better I could think of is some global flag (or state variable) > that indicates whether or not inlining is complete. At least then we > would not have to pass around that flag. But I wouldn't want to > introduce yet another boolean state variable; I'd much prefer all of the > existing state variables we have be consolidated, and I can't justify > spending the time on that just now. There is cfun->after_inlinng that says you this info on per-function basis. I will run the tests on C++ benchmarks this weekend whether simply assuming all calls to be possibly inlined throws before this flag is set is producing noticeable degradation in memuse/compile time. Honza > > >Well, we can either teach inlinable_call_p to handle your new indirect > >calls as "for sure uninlinable" > > This is the approach I'll take. I've already hacked on an extra bit in > the gimple call subcode to indicate whether an indirect call is nothrow; > I might as well add another bit to say an indirect call is noinline. Yep, it seems sort of resonable too. Honza
The C++ FE drops qualifiers on pointer dereference
The C++ frontend drops qualifiers when performing pointer dereference:
void foo(int * __restrict p, int * __restrict__ q, int i)
{
*q = p[i];
}
;; Function void foo(int*, int*, int) (null)
;; enabled by -tree-original
<>>
>>;
while this isn't a big issue for the plain *q (the cast is stripped
as useless during gimplification), the second cast results in the
gimplifier generating an unqualified temporary to do the dereference:
void foo(int*, int*, int) (int * restrict p, int * restrict q, int i)
{
long unsigned int D.2088;
long unsigned int D.2089;
int * D.2090;
int D.2091;
D.2088 = (long unsigned int) i;
D.2089 = D.2088 * 4;
D.2090 = p + D.2089;
D.2091 = *D.2090;
*q = D.2091;
}
The C frontend seems to get away without doing this conversion, the
C++ frontend does it here:
typeck.c:decay_conversion
/* [basic.lval]
Non-class rvalues always have cv-unqualified types. */
type = TREE_TYPE (exp);
if (!CLASS_TYPE_P (type) && cp_type_quals (type))
exp = build_nop (TYPE_MAIN_VARIANT (type), exp);
called from
#1 0x00657c35 in cp_build_indirect_ref (ptr=0x77edcf30,
errorstring=0x120f491 "unary *", complain=3)
at /space/rguenther/src/svn/trunk/gcc/cp/typeck.c:2493
2490 if (ptr == current_class_ptr)
2491return current_class_ref;
2492
2493 pointer = (TREE_CODE (TREE_TYPE (ptr)) == REFERENCE_TYPE
2494 ? ptr : decay_conversion (ptr));
2495 type = TREE_TYPE (pointer);
The C++ frontend in this way currently pessimizes code by emitting
dereferences of non-restrict qualified pointers where the user
used a restrict qualified pointer.
Where can this be fixed? I currently have a hack to not strip
restrict qualifiers in decay_conversion, but that feels a little
too hackish. What's the important piece of decay_conversion
that is necessary for indirect refs?
Thanks,
Richard.
Re: The C++ FE drops qualifiers on pointer dereference
On 07/17/2009 03:26 PM, Richard Guenther wrote: Where can this be fixed? I currently have a hack to not strip restrict qualifiers in decay_conversion, but that feels a little too hackish. What's the important piece of decay_conversion that is necessary for indirect refs? Well, I'd start by making a function called something like "cv_unqualified" that strips only cv-quals from the type, and look at replacing a lot of uses of TYPE_MAIN_VARIANT with that. I imagine that removing the cv-quals is important for overload resolution, but feel free to try removing that and see what breaks. :) Jason
