> No. This example was working in 4.6 and broken in 4.7 and 4.8.
Note that it probably broke in 4.7.1 because the DECL_BIT_FIELD_REPRESENTATIVE
stuff was backported after the initial 4.7.0 release.
--
Eric Botcazou
I'd arrange for avoiding code 0 instead because this disables the cache.
--
Eric Botcazou
> Agreed, but the assert in caller-save is still wrong and ought to be fixed.
Not clear to me: if you just fix it, you won't realize that the cache is
disabled for the code 0 insn. And there might be other parts of the RTL
middle-end expecting non-zero codes.
--
Eric Botcazou
Remove int casts.
Revert to treating the insn_code field as "insn_code".
--
Eric Botcazou
solution?
What kind of generic solution? Eliminating paradoxical subregs altogether?
That's very likely not doable if you define WORD_REGISTER_OPERATIONS anyway.
You need to pinpoint where things start to go wrong, for example in combine.
--
Eric Botcazou
ical subreg is correct and there is bug in reload or it is wrong and
there is a bug in combine.
--
Eric Botcazou
combine but that code is opaque to me.
If it appears in .reload, then it's reload and not combine. Most likely the
MEM is the equivalent memory location of (reg:SI 137) thanks to the REG_EQUIV
note and gets substituted for it at the end of reload; that's done in place so
gen_rtx_SUBREG is not called. Try and see whether find_reloads_subreg_address
is invoked on it and, if so, what happens then.
--
Eric Botcazou
really wins anything. A message earlier in
> this same thread bears out that many technical decisions on GCC were, in
> fact, made for political reasons and that GCC should carefully consider
> which ones should be rescinded.
Why do you think that there is a war? It's at most a competition between
projects with a different focus and different strengths.
--
Eric Botcazou
essible?
It's PR middle-end/36043 in GCC's bugzilla.
--
Eric Botcazou
ould teach GCC to not remove constant RTXs in
> flush_hash_table() but this is probably very naive and won't cover some
> corner-cases.
That could be a good starting point though.
--
Eric Botcazou
ASM_OPERANDS || MEM_VOLATILE_P (x))
reg_pending_barrier = TRUE_BARRIER;
--
Eric Botcazou
ink that everyone more or less agrees that this behavior of RTL CSE is
overly conservative and ought to be relaxed. The question is whether this can
be done in a sensible way without totally getting rid of the barrier.
--
Eric Botcazou
> Of course if the GIMPLE level doesn't care about the barrier then it doesn't
> make sense to be overly conservative at the RTL CSE level. Thus I think we
> can just remove this barrier completely.
Not clear to me, what happens e.g. for register variables?
--
Eric Botcazou
elib.c and dse.c which
have been changed by the patch.
--
Eric Botcazou
E_EXPR, "annotate_expr", tcc_expression, 3)
The current way of attaching the ANNOTATE_EXPR to the condition of the loop is
a bit awkward since it doesn't naturally permit multiple annotations for a
given loop. Any suggestion about how to overcome that?
--
Eric Botcazou
> You can certainly nest them, no?
>
> ANNOTATE_EXPR , unroll, 2>
Yes, that works, thanks.
--
Eric Botcazou
ery likely not, there should be no SUBREGs of MEMs after expand.
--
Eric Botcazou
ns STORE_FLAG_VALUE when both
> operands of 'eq' are equal. Otherwise, it returns 0. This is exactly
> opposite of what assembly semantics is.
No, that's wrong, the semantics of the comparison operators applied to the CC
register have nothing to do with STORE_FLAG_VALUE (see manual section 13.10).
Eric Botcazou
rison operation is identical to `(eq X Y)'. Usually only one style
of comparisons is supported on a particular machine, but the combine
pass will try to merge the operations to produce the `eq' shown in case
it exists in the context of the particular insn involved."
--
Eric Botcazou
unwind.h from VxWorks 7 contain exactly? Is it something
that is derived from the original ICC implementation?
--
Eric Botcazou
, but it is meant to implement the common C++ ABI.
--
Eric Botcazou
ust know" that $sp isn't a
> valid choice for the CFA?
Presumably the rx back-end and more precisely TARGET_FRAME_POINTER_REQUIRED,
which needs to return true if cfun->calls_alloca.
--
Eric Botcazou
e frame
pointer, which thus becomes the CFA register, which means that subsequent
stack adjustments are irrelevant for the CFI.
--
Eric Botcazou
rame-related (fp = sp - 4)
mov.L r6, r0 ; marked frame-related (sp = fp)
. . .; stack checking code goes here
add #0xc000, r0 ; not marked frame-related
The "mov.L r6, r0" instruction must never be marked as frame-related, for any
function.
--
Eric Botcazou
must not be marked; of course, if sp is the CFA
register throughout the function because there is no frame pointer, then all
insns modifying sp must be marked.
--
Eric Botcazou
ve more than one libgcc_eh in an
entire link, otherwise you cannot propagate exceptions across modules.
--
Eric Botcazou
se libgcc_s.so, at least on those platforms.
--
Eric Botcazou
e car before the horses to me.
--
Eric Botcazou
sed though.
It was agreed that a set of Coding Conventions would be published before the
switch to C++. If you think that the above conventions are in good enough a
shape to be proposed, then propose them for inclusion in
http://gcc.gnu.org/codingconventions.html
--
Eric Botcazou
operands, one would need to have the chain live "during the
instruction" or right after, so that you have a conflict with the other dest
register operands for the instruction. This looks awkward though.
--
Eric Botcazou
> Here, I think the problem is that we have an in-out operand whose chain
> is closed prematurely due to a bogus REG_DEAD note which shouldn't be
> there for a register set in the instruction.
IIRC I didn't see a REG_DEAD note, but I might be misremembering.
--
Eric Botcazou
ler has zero value if you don't use C++ in
the code. It probably even has a negative value, since it gratuitously makes
it harder to build the compiler on exotic platforms.
--
Eric Botcazou
and stores
from/to the stack aren't.
--
Eric Botcazou
> The trouble is that most users find it an annoyance and don't
> remember. And they ask: if it is so simple, why isn't it included by
> default?
Huh? -Wall is supposed to be simple to remember, but its implementation and
effects are of course not simple at all.
--
Eric Botcazou
g.) The way we have to approach this
> is how can we satisfy persistent demands and still remain competitive.
I personally don't buy the "can't remember" argument. When you use GCC, you
just have to remember -g, -O, -W and that's pretty much it.
--
Eric Botcazou
e
> to learn yet another GCC switch.
Why to introduce a new switch then? Just select a few -W switches and enable
them by default, keeping in mind that -w will disable them in any cases.
--
Eric Botcazou
> Something like -Wdefault-warnings is a reasonable choice, for the
> reasons already mentioned in this sub-thread.
Purists will find that -Wdefault-warnings is redundant though, since -W is
supposed to mean "warning" already, e.g. it's -Wall and not -Wall-warnings.
--
Eric Botcazou
s structure is easier to see, and if I would have to put
> the spaghetti tag on something, then the latter.
Spaghetti isn't really the best wording, gratuitous obfuscation is better. :-)
--
Eric Botcazou
_F_D
> (exp) then? ;)
The number of tokens. GET_FIELD_DECL has 2 tokens (GET and FIELD_DECL) while
exp->as_component_ref().get_field() has 3x more.
--
Eric Botcazou
ely of DJ's opinion here: C vs C++ is not the same argument as style A
vs style B. I don't think that it would be desirable to fundamentally change
the current style, at least to start adding -> and . all over the place.
--
Eric Botcazou
the barrier now for
> all sorts of random but uncoordinated conversion efforts.
IMO the killer conversion would be vec.[ch], which is a very clever piece of
code but is almost impossible to use without copy-and-pasting existing cases.
I think that a proper C++ implementation would be a very convincing argument.
--
Eric Botcazou
th a C++-native style of usage.
I don't think that implementing vec.[ch] in C++ would necessarily entail that
big a change of style; adding 1 -> per line is OK, adding 3 is something else.
--
Eric Botcazou
that there is no long term goal towards a complete rewrite
of the compiler in full-blown C++, so that people don't waste time making big
plans for such a rewrite.
--
Eric Botcazou
> Expressing an idea in C takes me more lines (roughly 2-3 fold) than
> in C++, so I am a bit puzzled by your observation.
We're specifically discussing vec.[ch] here, which is a clever attempt at
implementing vectors in C, with macro magic all over the place.
--
Eric Botcazou
> So, you only know it's 2 tokens once you know all of tree.def? I'm
> aware that this is just some arbitrary example, but I believe this
> actually strengthens the concern I had.
Well, if you don't know of FIELD_DECL, you won't go very far, really.
--
Eric Botcazou
pre-combine passes propagate register 172 in insn79 and delete
> insn78, the resulting instructions will not be combined.
The example doesn't seem to illustrate to the problem though, since propagating
reg 172 into insn 179 is a purely local change. In any case, you first need to
understand why combine fails, then find out whether this is generic problem or
a problem more specific to the port, in which case you can try to add patterns
and/or splitters to help combine.
--
Eric Botcazou
case I think you need to find out why no local pass before the
problematic global pass does the obvious constant propagation into insn 79.
--
Eric Botcazou
> Yes, the reason here should be the pattern for insn 79 has predicates on
> its operands and does not allow constant here.
And there is no way to get rid of the 2 pluses and thus change the pattern?
--
Eric Botcazou
(match_operand:SI 4 "thumb1_cmp_operand" "lI"]
> "TARGET_THUMB1"
> "cmp\\t%3, %4\;adc\\t%0, %1, %2"
> [(set_attr "length" "4")]
> )
Can't you use cstoresi_nltu_thumb1 instead?
--
Eric Botcazou
Is it a bug (unexpected with O1 compilation) that it is not optimized to
> direct call?
I'd think so, IA-64 uses a specific construct for its vtables because of the
ABI requirements.
--
Eric Botcazou
\
&& GET_MODE_SIZE (FROM) == 4 \
&& GET_MODE_SIZE (TO) != 4 \
? reg_classes_intersect_p (CLASS, FP_REGS) : 0)
--
Eric Botcazou
at least. I guess this should be reasonably fixable by
specialists, but there probably has been a lack of real incentive to do so.
--
Eric Botcazou
re
> registers which are not splittable in word_mode? Any thoughts?
Yes, this looks like a bug, since the SET in insn 99 doesn't modify the high
part of the multi-word (reg:SI 106), as per the documented rules for SUBREG.
--
Eric Botcazou
> Isn't SJLJ used by default for Ada on all targets?
Nope, Ada uses the same EH scheme as the other compilers, except for a few
cases where it uses its own __builtin_setjmp/__builtin_longjmp based scheme.
--
Eric Botcazou
, but bugs cannot of course
be ruled out like in any other piece of code.
--
Eric Botcazou
t; need 'fixed'. I'm trying to ascertain what things the script in
> particular is 'fixing' and which way is more technically sound in our
> build scenario.
In my experience, bugs in fixincludes are very rare. Every fix that is applied
is documented in the sources.
--
Eric Botcazou
es look like premature optimization to me, but I don't really
> understand the comment, or the effect of this code. Eric, could you
> please have a look at this and help me out?
Sure, but I don't understand what you don't understand... the comment seems
clear enough to m
) and
determining if they still matter nowadays.
> I was hoping maybe you know how to rewrite that piece of code such that you
> get that uninitialized variable into BSS without DECL_COMMON.
This is probably low-level trickery on exotic platforms so I'm not sure I want
to start this kind of endeavor.
--
Eric Botcazou
> It's not necessary for XCOFF. I think it was only useful for a.out,
> which doesn't support .bss.
No, the 2004 change wasn't for an a.out target, but most probably Mach-O.
--
Eric Botcazou
> Hmm, Mach-O does have BSS.
OK, bad memory, this was for Tru64.
--
Eric Botcazou
is code in utils.c?
Put this in a p.ads file:
package P is
Bigarray : array (1..1024*1024*256) of Character;
end P;
--
Eric Botcazou
.
Attached. We never submitted it because it introduced regressions in C++ IIRC.
> The same happens for rs6000-ibm-aix6.1, which also doesn't have
> BSS_SECTION_ASM_OP, even though there should be BSS support for XCOFF
> (http://pic.dhe.ibm.com/infocenter/aix/v6r1/index.jsp?topic=%2
> BSS was a later addition and there is no ".bss" pseudo-op directive,
> unlike the ".comm" directive. There only is the BSS storage class.
OK, thanks, this looks similar to the Tru64 situation.
--
Eric Botcazou
esn't modify the order of the special switches wrt the -m
switches. As a result, gnat1 knows that any -m switch before the prepended
special switch or after the appended special switch comes from the driver.
--
Eric Botcazou
the
> output of `make check' into a file and look at the `Running ... .exp'
> lines.
>
> --
>
> The target is called "check-c++" these days.
At toplevel, but not if you are in the gcc/ subdir, as is implicit above.
--
Eric Botcazou
> I guess my question is what would I need to change to make it work like the
> ARM port? I can't see how this is being controlled.
Try TARGET_PROMOTE_PROTOTYPES.
--
Eric Botcazou
#x27;t needed in the callee. It could also be said that it makes worse code
> on other machines :)
Yes, that's a bit counter-intuitive, but might have been intended and hinted at
by the "avoiding errors in certain cases of mismatch". In any case, the hook
should probably not be set to true if the ABI already promotes arguments.
--
Eric Botcazou
rk around
> for this? Am I allowed to put this function back in?
Sure, if you use it; but you are thus encouraged to trim down the number of
operands of your new tree codes. ;-)
--
Eric Botcazou
.
Oops. Yes, I would think that that is incorrect. We shouldn't be converting it
to anything with the host, but to the target UINT.
>
> Please file a bug report.
>
Agreed. Sentil, please put my email address in the CC field of the bug report.
Thanks!
Eric Weddington
there are no nops being emitted, which results in wrong asm code.
The delay slot isn't filled unless you enable optimization. In any case, the
nops are never emitted by the middle-end, it's up to the back-end to do it in
its TARGET_PRINT_OPERAND routine.
See the canonical examples of architectures with delay slots (SPARC, MIPS).
--
Eric Botcazou
-07/msg00408.html
which should catch more complex cases.
I guess someone should gather the various missed optimization cases, draw a
global picture of the situation and see how the various approaches could be
fitted together.
--
Eric Botcazou
deferring deletion of insn with uid = 52.
> modifying insn i313 r0:SI=0
> deferring rescan insn with uid = 13.
>
>
> So double middle-end bug or do I miss something?
Probably a similar issue. I guess the code expects to have subregs of pseudos
here and isn't prepared for (arithmetic) operations on double-word hard regs.
--
Eric Botcazou
> I'd like to get the Sparc cbcond stuff in (3 revisions posted) which
> is waiting for Eric B. to do some Solaris specific work.
>
> I'd also like to enable LRA for at least 32-bit sparc, even if I can't
> find the time to work on auditing 64-bit completely.
End
> I'll have a look.
I cannot reproduce, but this might come from missing dependencies in Make-
lang.in for the affected files.
--
Eric Botcazou
Diego got a brand new box. :-)
> I guess we should in any case go ahead and add explicit deps for seh_init.o?
> Eric, would you mind have a shot at it?
OK, I'm going to audit the dependencies (env.o is missing, initialize.o is
incomplete, etc) and install something shortly.
--
Eric Botcazou
4
>
> .L5 : movi $r1, 0
> jump .L4
>
> .L2 : movi $r1, 2
>
> .L4:
> ret
While poor code is expected at -O0, wrong code isn't of course. Could you
post a compilable testcase instead of an excerpt and the contents of the
.expand dump file (compile with -fdump-rtl-expand to get it)?
--
Eric Botcazou
make_extraction can be passed the position either as a HOST_WIDE_INT or as a
RTX, and canonicalizes to the former if the latter is CONST_INT_P. But this
is done slightly too late for one of the supported cases.
Tested on x86_64-suse-linux, applied on the mainline.
2012-11-04 Eric Botcazou
> Any pointers at all as to the error of my ways ?
http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2
--
Eric Botcazou
compile everything with a 64-bit compiler, i.e. all compilers ever invoked
must generate 64-bit code *by default*. This can mean setting CC and CXX to
appropriate values, e.g. "gcc -m64" and "g++ -m64" or the Sun equivalent.
--
Eric Botcazou
> I can not see my error here and am wondering what the issue is.
Obviously, if you have 32-bit object files in your build tree, you're using a
32-bit compiler. Which very likely means that you didn't set CC and CXX.
--
Eric Botcazou
gcc-4.7.2-src/configure
> --prefix=$HOME/apps/gcc-4.7.2 --build=sparc64-sun-solaris2.10
> --disable-multilib --with-{gmp,mpfr,mpc}=$HOME/apps/gcc-4.7.2
> --without-gnu-{as,ld}
> make {CFLAGS_FOR_TARGET,BOOT_CFLAGS}='-m64 -O2'
No, don't mess with CFLAGS_FOR_TARGET or BOOT_CFLAGS, just type 'make'.
--
Eric Botcazou
is2.10
Totally puzzled here why on Earth are you using all these flags? Just use
the configure lines posted by Ryan.
> The result however, is that the gcc build dir is polluted with objects from
> the gmp build.
>
> Not what I want most likely.
Then do not build them in the GCC build dir!
--
Eric Botcazou
gement bugs again? IMO it's better spent on more interesting things.
--
Eric Botcazou
alternatives).
One of the arguments put forward to advocate the transition to C++ was the
competition. Where do the other compilers stand when it comes to PCHs?
--
Eric Botcazou
emcpy(d, s, n) bcopy ((s), (d), (n))
-# endif
+#if USE_UNLOCKED_IO
+# include "unlocked-io.h"
#endif
-#include "md5.h"
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
igure script?
Maybe, but whether it's the right thing to do for the problem at hand is not
clear. libada is for the target while gnattools are for the host. The libada
configury should bear a ressemblance to the other target libraries.
--
Eric Botcazou
> Ok, I will do a full build tonight with the testuite and take this "test
> $build = $target" out of the build. I can only do a x86_64 linux test,
> should I send the results to the list?
You obviously need to test on a configuration that exercises the path.
--
Eric Botcazou
> The Mac OS 9 ABI is very similar to the AIX ABI. So you should be
> able to start with the AIX ABI and go from there.
Are you sure that you're talking about the same OS-9 as Thomas here?
--
Eric Botcazou
interesting to have figures with
(1) -fno-var-tracking-assignments
and
(2) -fno-var-tracking
then.
--
Eric Botcazou
ot; a comparison in C, one of the branches is always taken,
which means that npx_dr11_inverse_tangent_series can never return -NAN.
--
Eric Botcazou
he
comparison rules of IEEE-754. I'd suggest reading page 8 of "Lecture Notes on
the Status of IEEE 754" by Kahan:
http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF
--
Eric Botcazou
e (and while you're at it, you could also test the value of
HAVE_window_save, which can be 0 if -mflat is passed on the SPARC), so
#ifdef HAVE_window_save
if (HAVE_window_save && !crtl->uses_only_leaf_regs)
{
}
#endif
--
Eric Botcazou
af function.
Please put it on the 4.7 branch as well if approved, this worked (by chance)
before my change. TIA.
--
Eric Botcazou
(const_int 0 [0]))) 4.c:17 -1
> (expr_list:REG_SETJMP (const_int 0 [0])
> (expr_list:REG_EH_REGION (const_int 0 [0])
> (nil)))
> (expr_list:REG_FRAME_RELATED_EXPR (use (reg:DI 5 di))
> (nil)))
Isn't the REG_SETJMP note sufficient for this purpose?
--
Eric Botcazou
eturn value.
Yes, TREE_ADDRESSABLE types cannot be returned by value. Either you return
them via the invisible parameter manually or you set DECL_BY_REFERENCE on the
RESULT_DECL and the middle-end should do it for you. The C++ and Ada FEs use
the latter mechanism.
--
Eric Botcazou
s not a register set, so I think a patch like
> the one below is necessary.
>
> Thoughts?
This looks more like a small oversight in the DF implementation than a real
design decision, so I'd go ahead with your patch.
--
Eric Botcazou
me.c for example uses
these CLOBBER/REG_UNUSED pairs to compute live ranges for non-operands (the
pass does its own forward scan of the insn stream). So DF's choice might have
been made explicitly after all...
--
Eric Botcazou
REGNO (XEXP (note, 0)));
So (7) also closes the live ranges of hard regs opened in (1).
--
Eric Botcazou
machinery could be avoided.
--
Eric Botcazou
rand:SI 0 "nonimmediate_operand" "=rm,rm,rS,rm")
>(plus:SI (match_operand:SI 1 "nonimmediate_operand" "%0, 0, 0,rm")
> (match_operand:SI 2 "general_operand" "QI, K,i,rm")))]
,
> )
... why is there no clobber in the pattern if the instruction clobbers CC?
--
Eric Botcazou
1201 - 1300 of 1858 matches
Mail list logo
