Re: your mail

Re: your mail

[Jan Hubicka]

> 
> Boy, this was loads of fun to track down...
> 
> This code has a thinko.
> 
> 
> revision 1.173
> date: 2001/01/07 13:37:32;  author: hubicka;  state: Exp;  lines: +27 -9
> 
>         * combine.c (combine_simplify_rtx): Recognize the unordered compares.
>         (nonzero_bits): Likewise.
>         (simplify_comparison): Likewise.
>         (num_sign_bit_copies): Likewise; return more sane value depending
>         on STORE_FLAG_VALUE.
>         (known_cond): Do not assume EQ to be always true for equivalent
>         operands.
> 
> 
> It introduced the !FLOAT_MODE_P part of the conditional below in 
> combine.c::known_cond.
> 
>   if (cond == EQ && rtx_equal_p (x, reg) && !FLOAT_MODE_P (cond))
>     return val;
> 
> Applying FLOAT_MODE_P to an RTX_CODE doesn't produce a particularly useful
> or predictable value :(  Depending on precisely where things land in memory
> the condition above can give different results for the same values of COND,
> X & REG.  Not good.
> 
> Presumably you wanted to check that neither operand of COND is a floating
> point type.  Right?
Yes, thats precisely what I was shooting for.  It is amazing that such a bug
survived so long time in the compiler.

Should I prepare patch to fix the condtiional?

Thanks for letting me know!
Honza
> 
> The net result was that I was getting different code for the following
> function between a stage1 and stage2 compiler on the PA...
> 
> int optind = 0;
> static enum
> {
>   REQUIRE_ORDER, PERMUTE, RETURN_IN_ORDER
> } ordering;
> static int first_nonopt;
> static int last_nonopt;
> int
> _getopt_internal (argc, argv, optstring, longopts, longind, long_only)
>      int argc;
>      char *const *argv;
>      const char *optstring;
>      const struct option *longopts;
>      int *longind;
>      int long_only;
> {
>           if (first_nonopt != last_nonopt && last_nonopt != optind)
>             exchange ((char **) argv);
>           else if (last_nonopt != optind)
>             first_nonopt = optind;
> }
> 
> [ Note this code is from getopt.c which is not bootstrapped when we
>   do a make bootstrap which is why it went undiscovered for so long. ]
> 
> jeff

Re: your mail

[law]

  > > Presumably you wanted to check that neither operand of COND is a floating
  > > point type.  Right?
  > Yes, thats precisely what I was shooting for.  It is amazing that such a 
bug
  > survived so long time in the compiler.
  > 
  > Should I prepare patch to fix the condtiional?
I'll take care of it (it's almost done with its testing cycle).  I just wanted
to verify your intent.

jeff

Re: your mail

[Maciej W. Rozycki]

On Mon, 25 Oct 2021, Joel Sherrill wrote:

> I am pleased to announce that the GCC Steering Committee has appointed
> Maciej W. Rozycki as maintainer of the Vax backend in GCC.

 Thank you, that's a great honour.

> Maciej, please update your listing in the MAINTAINERS file.

 Change now committed.

  Maciej

Re: your mail

[Michael Matz]

Hi,

On Mon, 23 Feb 2004, kripa shankar wrote:

> ;; Start of basic block 2, registers live: 11 [fp] 13 [sp]
> (note 62 41 45 [bb 2] NOTE_INSN_BASIC_BLOCK)
> (insn 45 62 46 (set (reg/i:SI 0 r0)        (const_int 0 [0x0])) 176 {*movsi_insn} (nil)    (expr_list:REG_EQUAL (const_int 0 [0x0])        (nil)))
> (insn 46 45 76 (use (reg/i:SI 0 r0)) -1 (insn_list 45 (nil))    (nil))
> (insn 76 46 77 (set (reg:SI 7 r7)        (plus:SI (reg:SI 5 r5)            (const_int 2 [0x2]))) -1 (nil)    (nil))
> (insn 77 76 50 (set (reg:SI 6 r6)        (plus:SI (reg:SI 4 r4)            (const_int 2 [0x2]))) -1 (nil)    (nil))
> ;; End of basic block 2
> (note 50 77 63 0 NOTE_INSN_BLOCK_END)
> (note 63 50 0 "" NOTE_INSN_DELETED)
> 
> The instructions inserted are r7 = r5 + 2;r6 = r4 + 2; But the problem
> is that the inserted instructions are not present in both asm file
> (fourth.s) and the output binary file (fourth.o).. I have inserted these
> instructions right after all the optimization passess and before the
> final pass (final.c) where RTL gets converted into Assembly. Kindly help
> me.

There is not enough information.  Where exactly have you added the code to
add those insns?  About which compiler version do you speak?  Produce all 
dump files (-da) and look which dump misses them first.  The problem is, 
that you include those instructions without updating lifeness (i.e. the 
compiler doesn't see, that r6 and r7 really are required after you've set 
them.  So, if there is any pass deleting useless insns after you inserted 
them, they will get deleted.


Ciao,
Michael.

Re: your mail

[Mumit Khan]

On Sat, 11 Jul 1998, Jonathan Williams wrote:

> How do I use uwin-egcs , I've installed it but I refused to compile!

Since uwin is not supported by egcs releases nor snapshots, I doubt if
this is the appropriate forum for it. I suggest you post to the uwin
development mailing list or email me privately with more info than
'I refused to compile'; info such as what version of uwin, where you 
installed egcs and if you've read and followed the installation 
instructions (PATH and location) will be a good start.

Regards,
Mumit

Re: your mail

[Gerald Pfeifer]

On Sun, 3 May 1998, Steven Jones wrote:
> i didnt understand what u meant by the srcdir stuff, please remember
> that lots of linux users are only semi-computer literate like me. Im
> sure 'hotshots' need all this stuff but i just want to run my machine. 
> :)

I'm currently planing some updates to the web pages which (will) 
constitute the INSTALL subdirectory of the egcs. I'll try to add
an apropriate note.

Thanks for the hint!
Gerald

PS: Please do not send e-mails both as text and HTML attachments; plain
    text is fully sufficient.
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: your mail

[Oskar Enoksson]

On Tue, 17 Mar 1998, Oskar Enoksson wrote:

I forgot to attach the offending code ... here it comes.

> Hi! I just subscribed. I have good news and bad:
> 
> First the good news: I compiled the egcs-980309 snapshot with no problems
> on a mips-sgi-irix5.3 and a i686-pc-linux-gnulibc1. Very nice!
> 
> Bad news: I've found what must be a bug. The problem is template function
> overloading. A short source file is attached to this mail. One overload
> ambiguity is resolved fine, but not the other. There is practically no
> difference between the two cases, so it must be a bug.
> 
> Exactly the same happens with gcc 2.8.0 if that is of any help.
> 
> Suggestions? Thanks!
> 
> /Oskar