This approach seems reasonable. The current structure of the code
in simplify_replace_rtx is intended to handle RTL expressions rather
than patterns, so normally it would be passed just SET_SRC (pat),
instead of the whole set.
Which is why, OTOH, I would be *extremely* cautious doing such a
Maybe everyone else manages to get good code without something like
TER.
That's because we lack other things that people have, like a sane
instruction selection and expression reordering pass: other compilers
probably have something akin to TER as part of instruction selection.
Like many ot
1. Can you please give me an example of something bad that can happen to
the LHS. Maybe I'm missing something here.
In this case nothing, but if NEW were a subreg, it can change a lot.
3. Isn't it reasonable to expect that every instance on old_rtx will be
replaced by new_rtx even if it can
The following code:
#include
void Switch4(int x) {
switch (x & 7) {
case 0: printf("0\n"); break;
case 1: printf("1\n"); break;
case 2: printf("2\n"); break;
case 3: printf("3\n"); break;
case 4: printf("4\n"); break;
case 5: printf("5\n"); break;
case 6: printf("
On 8/19/05, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> WU Yongwei wrote:
> > Well, I see this in the gcc error message. Can someone here kindly
> > point to me which part of the Standard specified this behaviour? I
> > thought it should be in 5.3.4, but was not able to find the words
> > there.
Hi,
i just built GCC 4.0.1 on AIX 5.1 using the following commands:
../gcc-4.0.1/configure --with-libiconv-prefix=/usr --disable-nls
--disable-multilib
make bootstrap-lean
make install
$ config.guess
powerpc-ibm-aix5.1.0.0
$ gcc -v
Using built-in specs.
Target: powerpc
It looks like Jan's patch at
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg02021.html is causing a
code size regression in i686. I'll consider a 32-bit target, and this
testcase
char **
VTallocbuf(char **allbuf, unsigned long savelines)
{
return &allbuf[savelines];
}
For i686 we p
I disbelieve you can get this in C or C++. The fragment above is a
syntax error. AFAIK, all of this is simple laziness in the Ada front
end: generating & is how things were done at the
beginning of time, and it was easier to change this in the gimplifier
than to modify the cod
Piotr Fusik <[EMAIL PROTECTED]> wrote:
> void Switch4(int x) {
> switch (x & 7) {
> case 0: printf("0\n"); break;
> case 1: printf("1\n"); break;
> case 2: printf("2\n"); break;
> case 3: printf("3\n"); break;
> case 4: printf("4\n"); break;
> case 5: printf("5\n"); bre
void Switch4(int x) {
switch (x & 7) {
}
}
>>
.globl _Switch4
.def _Switch4; .scl 2; .type 32; .endef
_Switch4:
pushl %ebp
movl %esp, %ebp
movl 8(%ebp), %eax
andl $7, %eax
cmpl $7, %eax
ja L12
jmp *L11(,%eax,4)
cmpl+ja are redundant in both cases.
Do you think it is possible for gcc t
Haren Visavadia wrote:
You missed "The GCC team has been urged to drop
support for SCO Unix from GCC, as a protest against
SCO's irresponsible aggression against free software".
When starting my Unix learnings with SCO Xenix/286,
SCO Xenix/386 and SCO Unix (all some kind of trademarks),
I hav
On Aug 22, 2005, at 1:27 AM, Mark Mitchell wrote:
(Quite a few of the diagnostic messages
stem from the design decision to issue warnings from the
optimizers...)
Only 8 out of 49 at that, though some are very minor as two are just
complaining wording of the warning. And almost all are uninit
Hello,
I would like to know if someone knows a suitable branch for the sign
extension optimization pass.
This pass stands for itself. There are not many changes to the other
parts of the gcc.
For details see:
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01087.html
Thanks,
Leehod.
> > 1. Can you please give me an example of something bad that can happen
to
> > the LHS. Maybe I'm missing something here.
>
> In this case nothing, but if NEW were a subreg, it can change a lot.
Why?
Do I always need to recognize the result?
If the answer is yes, than I suppose that if som
Do I always need to recognize the result?
validate_change and apply_change_group will take care of that.
If the answer is yes, than I suppose that if something bad happens,
the recognition will fail.
No, the problem is when recognition passes, and you have a SUBREG on the
LHS that will
On Sun, 21 Aug 2005, Leehod Baruch wrote:
> >>(insn 1 0 2 0 (set (reg/v:Xmode r)
> >>(sign_extend:Xmode (op:Ymode (...
> >>(insn 2 1 3 0 (set (lhs) (rhs)))
>
> 1. Can you please give me an example of something bad that can happen to
> the LHS. Maybe I'm missing something here.
(set
Paolo Bonzini <[EMAIL PROTECTED]> wrote on 22/08/2005 10:10:40:
> > > I tried to use simplify_replace_rtx to replace any use of (reg r)
with[in]
> > > the right-hand-side of the extension and simplify the result.
>
> If he want to replace uses within the RHS of the extension, he should
> pass SE
On Monday 22 August 2005 09:28, Paolo Bonzini wrote:
> I think Zdenek's patch is fine, because *everything* in TER is a hack.
My thoughts exactly ;-)
> > Zdenek, maybe you could you try and see if enabling pre-regalloc
> > scheduling would also make this particular problem you're seeing go
> > aw
On Monday 22 August 2005 14:46, Leehod Baruch wrote:
> Hello,
>
> I would like to know if someone knows a suitable branch for the sign
> extension optimization pass.
Why not just maintain it in a local tree and post refined
versions every now and then, until stage 1 for GCC 4.2 opens?
Branches are
Andrew Pinski wrote:
On Aug 22, 2005, at 1:27 AM, Mark Mitchell wrote:
(Quite a few of the diagnostic messages
stem from the design decision to issue warnings from the
optimizers...)
Only 8 out of 49 at that, though some are very minor as two are just
complaining wording of the warning.
I
Note that I don't want to replace any *def* and uses may appear in the
LHS.
Ok, I see. But you have to cope with *def*s appearing in the LHS: you
don't want to replace them, yet your modified simplify_replace_rtx will!
My plan was to use: replace_regs () to replace every use of (reg r)
w
On Mon, Aug 22, 2005 at 03:37:27PM +0200, Paolo Bonzini wrote:
> It may still make sense changing the default case of
> simplify_replace_rtx to invoke replace_rtx rather than returning x. But
> this is unrelated, because nobody is currently passing a SET to
> simplify_replace_rtx (only expressi
Mark Mitchell <[EMAIL PROTECTED]> writes:
> My first comment is that we had a lot of bugs targeted at 4.1.0 that
> should never have been so targeted. Please remember that bugs that do
> not effect primary or secondary targets should not have a target
> milestone. There are several PRs that seem
Ling-hua Tseng wrote:
> It's only correct if the two RISC insns reserved the same RISC function
> unit.
Try defining two separate reservations for each pipe, e.g. a
risc_data_processing_r0 and a risc_data_processing_r1. Then you can
write the bypass rule in the obvious way.
--
Jim Wilson, GNU To
Piotr Wyderski wrote:
> I have disassembled my program produced by g++ 4.0.0
> and I see a very strange behaviour -- the compiler doesn't
> generate cmov-s (-O3 -march=pentium3). G++ 3.4 generates
> them. So, how can I reactivate cmov-s in the newest version
> of the compiler? fif-conversion doesn'
This is the beta release of binutils 2.16.91.0.3 for Linux, which is
based on binutils 2005 0821 in CVS on sources.redhat.com plus various
changes. It is purely for Linux.
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location
While researching who is really using flow's computed LOG_LINKS, I found
a define_split in the rs6000 back-end that uses them through
find_single_use. It turns out the only users are combine, this split,
and a function in regmove.
The split dates back to revision 1.5 of old-gcc.
;; If we are
[EMAIL PROTECTED] wrote:
> 1. bootstrapping the gcc 4.0.1 under Sparc/Solaris I found that the
> building in "fixincludes" uses the gcc (with no PATH specification)
> instead of the xgcc build by the last stage. It may crash, it happens on
> my environment, because I've migrated from Solaris 9 to S
> Paolo Bonzini writes:
Paolo> I'm testing a patch that does this replacement, and I can post it
Paolo> tomorrow morning. It has triggered only a dozen times so far (half in
Paolo> libgcc, half in the compiler), but it may be worth keeping it.
It would be nice to keep this type of
Ian Lance Taylor wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
My first comment is that we had a lot of bugs targeted at 4.1.0 that
should never have been so targeted. Please remember that bugs that do
not effect primary or secondary targets should not have a target
milestone. There are s
I think that the structure 'struct loop_info' in loop.c could be shrinked a
bit if all the 'int has_XXX' fields where turned into a bitfield just as in
'struct iv_class' or 'struct induction' in the same file.
I don't know if it worse it (in term of memory usage reduction) neither the
impact in pe
On Sun, 2005-08-21 at 20:32 +0200, Falk Hueffner wrote:
> Hi,
>
> I'm trying to implement a tree pass that warns about bad array
> accesses as suggested for PR 8268 by Jeff Law. However, I have trouble
> with the following:
>
> char digit_vector[5];
> const char *ggc_alloc_string(int length) {
>
> Warning for pointer generation is going to be a *lot* harder and I
> suspect will always result in more false positives.
In order to increase the accuracy of the data dependence analysis, i do,
at some point, plan on tracking the sizes of malloc sites, and giving an
upper bound on them (for cas
There is some clever code in convert_to_real that converts
double d;
(float)floor(d)
to
floorf((float)d)
(on targets where floor and floorf are considered builtins.)
This is wrong, because the (float)d conversion normally uses
round-to-nearest and can round up to the next integer. For example
This test assumes that integer constants passed as varargs are
promoted to a type at least as big as "long", which is not valid on 16
bit hosts. For example:
void
f1 (int i, ...)
{
va_start (gap, i);
x = va_arg (gap, long);
int
main (void)
{
f1 (1, 79);
if (x != 79)
abort ();
Sho
I'm porting a back-end for gcc.
My back-end crached in the compile test pattern 990203-1.c, and
the error message is
main.c:7: internal compiler error: in purge_addressof, at
function.c:3423
for (insn = insns; insn; insn = NEXT_INSN (insn))
if (INSN_P (insn))
{
if (! pu
Hello,
How come the following code would not be considered a Warning?
Surely there is no possible way this would be intentional?
if (x<4);
x++;
Cheers,
Ivan
Ivan Novick wrote:
Hello,
How come the following code would not be considered a Warning?
Surely there is no possible way this would be intentional?
if (x<4);
x++;
When you consider macro expansion, it could:
#if SIZEOF_LONG == 4
#define WARN_FOR_BIG_VALUES \
printf ("hey, x is too
38 matches
Mail list logo
