public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "schlie at comcast dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/18065] usual arithmetic conversion not applying correctly
Date: Wed, 20 Oct 2004 21:19:00 -0000	[thread overview]
Message-ID: <20041020211940.4754.qmail@sourceware.org> (raw)
In-Reply-To: <20041019202143.18065.schlie@comcast.net>


------- Additional Comments From schlie at comcast dot net  2004-10-20 21:19 -------
Subject: Re:  usual arithmetic conversion not applying
 correctly

Andrew,

Yes, and with respect to / and % operations:

- the modulo/reminder result can always be represented in the same type
  and size as its divisor/modulus operand, regardless of the dividend's
  type and size.

- the quotient result can always be represented in the same type and size
  as it's dividend, if it's divisor/modulus operand is unsigned, otherwise
  ideally to be promoted to it's next larger signed type to preserve
  accuracy if useful, but typically irrelevant, as operator result
  precision is in most practical circumstances determined by the precision
  of the result's need, therefore in typical cases like int = int / int
  no value is derived from pretending to preserve idealized accuracy,
  therefore CPU's typically implement instructions to yield the equivalent
  results that would have been attained if the precision were maintained,
  and then simply truncated when assigned to it's destination type for
  typical integer operations but mark an under or overflow flag, just as
  int = int + int; would overflow; therefore for all practical purposes,
  integer operands should never be promoted beyond their need, nor should
  operation precision be required beyond it's result's need.

(and just to double check, this needs to get fixed on 3.4.3 too, which
 I honestly suspect is related to the rtl interpretation, as other QI
 mode instruction specifications are properly matched as expected.)

(also it's likely that these type of problems predominantly express
 themselves on small target machines, as on larger 32/64 bit machines,
 operations physically occur on correspondingly wide cpu's, therefore
 don't enable inappropriate operand promotion errors to be easily
 observable.)

-paul-

> From: pinskia at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org>
> Reply-To: <gcc-bugzilla@gcc.gnu.org>
> Date: 20 Oct 2004 19:29:13 -0000
> To: <schlie@comcast.net>
> Subject: [Bug c/18065] usual arithmetic conversion not applying correctly
> 
> 
> ------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-20
> 19:29 -------
> And the reason why we don't shoten back to signed char % signed char:
> 
>  /* Although it would be tempting to shorten always here, that loses
>     on some targets, since the modulo instruction is undefined if the
>     quotient can't be represented in the computation mode.  We shorten
>     only if unsigned or if dividing by something we know != -1.  */
> 
> So maybe this is correct.
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18065
> 
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18065


  parent reply	other threads:[~2004-10-20 21:19 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-19 20:22 [Bug c/18065] New: wrong built-in functions selected schlie at comcast dot net
2004-10-19 20:27 ` [Bug c/18065] " schlie at comcast dot net
2004-10-19 20:39 ` [Bug target/18065] " pinskia at gcc dot gnu dot org
2004-10-19 21:18 ` schlie at comcast dot net
2004-10-19 21:31 ` schlie at comcast dot net
2004-10-19 21:39 ` [Bug target/18065] not using qi version of divmod pinskia at gcc dot gnu dot org
2004-10-19 21:53 ` schlie at comcast dot net
2004-10-19 22:08 ` ericw at evcohs dot com
2004-10-19 22:31 ` schlie at comcast dot net
2004-10-19 23:13 ` ericw at evcohs dot com
2004-10-20 18:34 ` schlie at comcast dot net
2004-10-20 18:50 ` [Bug c/18065] usual arithmetic conversion not applying correctly pinskia at gcc dot gnu dot org
2004-10-20 19:14 ` schlie at comcast dot net
2004-10-20 19:18 ` pinskia at gcc dot gnu dot org
2004-10-20 19:25 ` pinskia at gcc dot gnu dot org
2004-10-20 19:29 ` pinskia at gcc dot gnu dot org
2004-10-20 19:33 ` schlie at comcast dot net
2004-10-20 19:54 ` pinskia at gcc dot gnu dot org
2004-10-20 21:19 ` schlie at comcast dot net [this message]
2004-10-20 21:25 ` pinskia at gcc dot gnu dot org
2004-10-20 21:31 ` jsm at polyomino dot org dot uk
2004-10-20 21:46 ` schlie at comcast dot net
2004-10-20 22:27 ` schlie at comcast dot net
2004-10-20 22:31 ` [Bug tree-optimization/18065] " pinskia at gcc dot gnu dot org
2004-10-20 22:42 ` jsm at polyomino dot org dot uk
2004-10-20 23:03 ` jsm at polyomino dot org dot uk
2004-10-20 23:28 ` schlie at comcast dot net
2004-10-21  1:04 ` schlie at comcast dot net
2004-10-21  1:28 ` schlie at comcast dot net
2004-10-21 12:47 ` bangerth at dealii dot org
2004-12-21 20:50 ` schlie at comcast dot net
2005-01-16  1:39 ` pinskia at gcc dot gnu dot org
2005-01-16  7:17 ` schlie at comcast dot net
2005-01-16 17:39 ` schlie at comcast dot net

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=20041020211940.4754.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).