public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: David Edelsohn <dje.gcc@gmail.com>
Cc: luisgpm@linux.vnet.ibm.com, Andrew Pinski <pinskia@gmail.com>,
	        sje@cup.hp.com, Richard Henderson <rth@redhat.com>,
	        Peter Bergner <bergner@vnet.ibm.com>,
	gcc-patches@gcc.gnu.org,         paolo.carlini@oracle.com
Subject: Re: Patch to fix gcc.c-torture/compile/20010102-1.c on IA64 HP-UX
Date: Thu, 06 Nov 2008 23:48:00 -0000	[thread overview]
Message-ID: <49137ABC.309@redhat.com> (raw)
In-Reply-To: <303e1d290811061452g1dae05efg7e6e52a112c32f5f@mail.gmail.com>

David Edelsohn wrote:
>
>   
>>> find_base_term() either could check for non-zero base before returning
>>> in the lo_sum/plus/minus case statement or could handle lo_sum
>>> explicitly, like find_base_value().
>>>       
>> I think my suggestion will accomplish the same thing -- and it makes logical
>> sense too -- if we can't determine something from the pointer reg, then we
>> look at other info, such as the symbol_ref within a lo_sum.
>>     
>
> Yes, it will accomplish the same thing for this particular case.
>
> Currently find_base_value and find_base_term differ in their handling
> of LO_SUM.  My question is whether this fix should maintain the difference
> in algorithms. 
I suspect the differences are unintentional and  one could easily argue 
that find_base_value's handling of LO_SUM is better since LO_SUM has 
pretty well defined semantics.  One could also argue that both functions 
shouldn't be so eager to return the results of the recursive call when 
the recursive call returns NULL.

>  Also, RTL alias analysis is very fragile and your suggestion
> may produce more accurate information in other situations, which could
> expose other latent bugs or unexpected behavior.
>   
Part of the intent was to get the more accurate info in the presence of 
registers marked with REG_POINTER.  While it could expose latent bugs, I 
think it's the right thing to do -- though we might look for a change 
with a smaller impact for the upcoming release since I think we're in 
stage3.

jeff

  reply	other threads:[~2008-11-06 23:21 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-06 20:43 David Edelsohn
2008-11-06 22:05 ` Jeff Law
2008-11-06 23:29   ` David Edelsohn
2008-11-06 23:48     ` Jeff Law [this message]
2008-11-07 18:58       ` Luis Machado
2008-11-27 14:34       ` Luis Machado
2008-11-27 15:46         ` Richard Guenther
2008-11-27 20:32         ` Jeff Law
2008-11-27 21:07           ` Luis Machado
2008-11-27 23:24             ` Jeff Law
2009-05-26 16:50               ` Luis Machado
2009-06-01  3:55                 ` Ian Lance Taylor
2009-06-01 15:21                   ` Luis Machado
  -- strict thread matches above, loose matches on Subject: below --
2008-09-16 18:21 Steve Ellcey
2008-09-16 19:00 ` Peter Bergner
2008-09-16 19:20   ` Steve Ellcey
2008-09-16 19:40     ` Peter Bergner
2008-09-16 21:55       ` Jakub Jelinek
2008-09-17  1:22         ` Peter Bergner
2008-09-16 19:44     ` Jeff Law
2008-09-16 20:20       ` Peter Bergner
2008-09-16 20:49         ` Jeff Law
2008-09-16 20:49           ` Steve Ellcey
2008-09-16 21:31             ` Jeff Law
2008-09-16 21:40               ` Steve Ellcey
2008-09-17  1:54                 ` Peter Bergner
2008-09-17 17:31                   ` Steve Ellcey
2008-09-18 16:03                   ` Steve Ellcey
2008-09-18 20:38                     ` Peter Bergner
2008-09-16 21:48             ` Jeff Law
2008-09-16 22:00               ` Steve Ellcey
2008-09-18 20:59                 ` Richard Henderson
2008-09-19 18:56                   ` Steve Ellcey
2008-09-23 20:55                     ` Jeff Law
2008-09-23 21:08                       ` Steve Ellcey
2008-10-03 19:35                         ` Luis Machado
2008-10-04  0:47                           ` Jeff Law
2008-10-04  1:09                             ` Andrew Pinski
2008-10-16 21:46                               ` Luis Machado
2008-10-16 22:02                                 ` Jeff Law
2008-10-30 22:27                                   ` Luis Machado
2008-10-31  2:23                                     ` Steve Ellcey
2008-10-31  2:17                                       ` Peter Bergner
2008-10-31  2:03                                         ` Jeff Law
2008-10-31  1:50                                           ` Steve Ellcey
2008-11-06 18:00                                             ` Jeff Law
2008-10-31 10:53                                           ` Jakub Jelinek
2008-10-31 20:29                                           ` Peter Bergner
2008-10-31 20:50                                             ` Luis Machado
2008-10-31 21:27                                             ` Jakub Jelinek
2008-11-06 18:25                                     ` Jeff Law

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49137ABC.309@redhat.com \
    --to=law@redhat.com \
    --cc=bergner@vnet.ibm.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=luisgpm@linux.vnet.ibm.com \
    --cc=paolo.carlini@oracle.com \
    --cc=pinskia@gmail.com \
    --cc=rth@redhat.com \
    --cc=sje@cup.hp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).