public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Pierre-Marie de Rodat <pmderodat@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc r13-309] [Ada] Fix spurious ambiguity for if_expression containing operator
Date: Wed, 11 May 2022 08:56:15 +0000 (GMT)	[thread overview]
Message-ID: <20220511085615.151F838845FF@sourceware.org> (raw)

https://gcc.gnu.org/g:c63b798f88aa82de32789b6a2ae5f387e58165c7

commit r13-309-gc63b798f88aa82de32789b6a2ae5f387e58165c7
Author: Eric Botcazou <ebotcazou@adacore.com>
Date:   Wed Feb 2 21:04:18 2022 +0100

    [Ada] Fix spurious ambiguity for if_expression containing operator
    
    It comes from a discrepancy in the analysis of binary operators, between
    the predefined ones for which we register an interpretation with the base
    type and the user-defined ones for which we register an interpretation
    with the subtype directly.
    
    This is harmless in almost all cases because the two interpretations do not
    differ by this type property only, but is problematic when the operation is
    the dependent expression of a conditional expression, because it causes two
    interpretations of the conditional expression to be registered, which this
    time differ by this type property only, thus making them impossible to be
    disambiguated later.
    
    gcc/ada/
    
            * sem_ch4.adb (Analyze_User_Defined_Binary_Op): Use the base type
            in the interpretation of the operator.

Diff:
---
 gcc/ada/sem_ch4.adb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/ada/sem_ch4.adb b/gcc/ada/sem_ch4.adb
index c913e8b69d5..ca8e1cd1f24 100644
--- a/gcc/ada/sem_ch4.adb
+++ b/gcc/ada/sem_ch4.adb
@@ -5934,7 +5934,7 @@ package body Sem_Ch4 is
            and then (Has_Compatible_Type (Right_Opnd (N), Etype (F2))
                       or else Etype (F2) = Any_Type)
          then
-            Add_One_Interp (N, Op_Id, Etype (Op_Id));
+            Add_One_Interp (N, Op_Id, Base_Type (Etype (Op_Id)));
 
             --  If the operands are overloaded, indicate that the current
             --  type is a viable candidate. This is redundant in most cases,


                 reply	other threads:[~2022-05-11  8:56 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20220511085615.151F838845FF@sourceware.org \
    --to=pmderodat@gcc.gnu.org \
    --cc=gcc-cvs@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).