[Bug preprocessor/112701] New: wrong type inference for ternary operator in preprocessing context

[Bug preprocessor/112701] New: wrong type inference for ternary operator in preprocessing context

[amonakov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701

            Bug ID: 112701
           Summary: wrong type inference for ternary operator in
                    preprocessing context
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

In the following snippet, the result of the ternary operator is (-1, cast to an
unsigned type), so the comparison yields false, and both conditional inclusions
must come out empty:

#if (0 ? 0u : -1) < 0
int foo = (0 ? 0u : -1) < 0;
#endif

#if (0 ? 0/0u : -1) < 0
int bar = (0 ? 0/0u : -1) < 0;
#endif

However, GCC emits:

bar:
        .zero   4

So clearly the evaluation of the second expression is inconsistent between
preprocessing context (where it incorrectly yields 1) vs. initializer context
(where it is zero as it should be, as seen from the resulting asm).

[Bug preprocessor/112701] wrong type inference for ternary operator with `0/0u` in preprocessing context

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Interesting is MSVC emits both. clang emits none.

[Bug preprocessor/112701] wrong type inference for ternary operator with `0/0u` in preprocessing context

[mikpelinux at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701

--- Comment #2 from Mikael Pettersson <mikpelinux at gmail dot com> ---
gcc-2.95.3 generates neither, gcc-3.0.4 and up generate the bar: .long 0 (or
.zero 4) one.

[Bug preprocessor/112701] wrong type inference for ternary operator with `0/0u` in preprocessing context

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Heh, I didn't know ?: is valid as preprocessor conditional.

[Bug preprocessor/112701] wrong type inference for ternary operator with `0/0u` in preprocessing context

[lhyatt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701

Lewis Hyatt <lhyatt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-11-27
     Ever confirmed|0                           |1
                 CC|                            |lhyatt at gcc dot gnu.org

--- Comment #4 from Lewis Hyatt <lhyatt at gcc dot gnu.org> ---
Here is the fix. Not sure if it needs to wait for GCC 15 by now, but I can
submit it with the testcase.

diff --git a/libcpp/expr.cc b/libcpp/expr.cc
index 825d2c2369d..4f4a9722ac7 100644
--- a/libcpp/expr.cc
+++ b/libcpp/expr.cc
@@ -2216,6 +2216,7 @@ num_div_op (cpp_reader *pfile, cpp_num lhs, cpp_num rhs,
enum cpp_ttype op,
       if (!pfile->state.skip_eval)
        cpp_error_with_line (pfile, CPP_DL_ERROR, location, 0,
                             "division by zero in #if");
+      lhs.unsignedp = unsignedp;
       return lhs;
     }

[Bug preprocessor/112701] wrong type inference for ternary operator with `0/0u` in preprocessing context

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Lewis Hyatt from comment #4)
> Here is the fix. Not sure if it needs to wait for GCC 15 by now, but I can
> submit it with the testcase.

Bugs can be fixed during stage 3 (just no new __major__ features), only during
stage 4 is when regression only fixes can happen. Note this might even be
considered a regression since it worked in GCC 2.95.3.

[Bug preprocessor/112701] wrong type inference for ternary operator with `0/0u` in preprocessing context

[lhyatt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701

Lewis Hyatt <lhyatt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch
                URL|                            |https://gcc.gnu.org/piperma
                   |                            |il/gcc-patches/2023-Novembe
                   |                            |r/638346.html

--- Comment #6 from Lewis Hyatt <lhyatt at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Lewis Hyatt from comment #4)
> > Here is the fix. Not sure if it needs to wait for GCC 15 by now, but I can
> > submit it with the testcase.
> 
> Bugs can be fixed during stage 3 (just no new __major__ features), only
> during stage 4 is when regression only fixes can happen. Note this might
> even be considered a regression since it worked in GCC 2.95.3.

Thanks for the clarification! Patch is at:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638346.html

[Bug preprocessor/112701] wrong type inference for ternary operator with `0/0u` in preprocessing context

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701

--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Lewis Hyatt <lhyatt@gcc.gnu.org>:

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

commit r14-5898-gce52f1f7074d96c4d9ce63b1169c11087757e926
Author: Lewis Hyatt <lhyatt@gmail.com>
Date:   Mon Nov 27 12:08:41 2023 -0500

    libcpp: Fix unsigned promotion for unevaluated divide by zero [PR112701]

    When libcpp encounters a divide by zero while processing a constant
    expression "x/y", it returns "x" as a fallback. The value of the fallback
is
    not normally important, since an error will be generated anyway, but if the
    expression appears in an unevaluated context, such as "0 ? 0/0u : -1", then
    there will be no error, and the fallback value will be meaningful to the
    extent that it may cause promotion from signed to unsigned of an operand
    encountered later. As the PR notes, libcpp does not do the unsigned
    promotion correctly in this case; fix it by making the fallback return
value
    unsigned as necessary.

    libcpp/ChangeLog:

            PR preprocessor/112701
            * expr.cc (num_div_op): Set unsignedp appropriately when returning
a
            stub value for divide by 0.

    gcc/testsuite/ChangeLog:

            PR preprocessor/112701
            * gcc.dg/cpp/expr.c: Add additional tests to cover divide by 0 in
an
            unevaluated context, where the unsignedness still matters.

[Bug preprocessor/112701] wrong type inference for ternary operator with `0/0u` in preprocessing context

[lhyatt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701

Lewis Hyatt <lhyatt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #8 from Lewis Hyatt <lhyatt at gcc dot gnu.org> ---
Fixed for GCC 14.

[Bug preprocessor/112701] wrong type inference for ternary operator with `0/0u` in preprocessing context

[sjames at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0