gcc

Fork

wip: RX fdpic.

Signed-off-by: Yoshinori Sato <yo-satoh@sios.com>

Merge branch 'rx-pic' into rx-fdpic

WIP: rx pic cleanup.

Signed-off-by: Yoshinori Sato <yo-satoh@sios.com>

WIP: fix PLT.

Signed-off-by: Yoshinori Sato <yo-satoh@sios.com>

WIP: rx plt

Signed-off-by: Yoshinori Sato <yo-satoh@sios.com>

wip: rx pic

Signed-off-by: Yoshinori Sato <yo-satoh@sios.com>

WIP: RX pic support

Signed-off-by: Yoshinori Sato <yo-satoh@sios.com>

Daily bump.

analyzer: new warning: -Wanalyzer-tainted-assertion [PR106235]

This patch adds a new -Wanalyzer-tainted-assertion warning to
-fanalyzer's "taint" mode (which also requires -fanalyzer-checker=taint).

It complains about attacker-controlled values being used in assertions,
or in any expression affecting control flow that guards a "noreturn"
function. As noted in the docs part of the patch, in such cases:

- when assertion-checking is enabled: an attacker could trigger
a denial of service by injecting an assertion failure

- when assertion-checking is disabled, such as by defining NDEBUG,
an attacker could inject data that subverts the process, since it
presumably violates a precondition that is being assumed by the code.

For example, given:

#include <assert.h>

int __attribute__((tainted_args))
test_tainted_assert (int n)
{
assert (n > 0);
return n * n;
}

compiling with
-fanalyzer -fanalyzer-checker=taint
gives:

t.c: In function 'test_tainted_assert':
t.c:6:3: warning: use of attacked-controlled value in condition for assertion [CWE-617] [-Wanalyzer-tainted-assertion]
6 | assert (n > 0);
| ^~~~~~
'test_tainted_assert': event 1
|
| 4 | test_tainted_assert (int n)
| | ^~~~~~~~~~~~~~~~~~~
| | |
| | (1) function 'test_tainted_assert' marked with '__attribute__((tainted_args))'
|
+--> 'test_tainted_assert': event 2
|
| 4 | test_tainted_assert (int n)
| | ^~~~~~~~~~~~~~~~~~~
| | |
| | (2) entry to 'test_tainted_assert'
|
'test_tainted_assert': events 3-6
|
|/usr/include/assert.h:106:10:
| 106 | if (expr) \
| | ^
| | |
| | (3) use of attacker-controlled value for control flow
| | (4) following 'false' branch (when 'n <= 0')...
|......
| 109 | __assert_fail (#expr, __FILE__, __LINE__, __ASSERT_FUNCTION); \
| | ~~~~~~~~~~~~~
| | |
| | (5) ...to here
| | (6) treating '__assert_fail' as an assertion failure handler due to '__attribute__((__noreturn__))'
|

The testcases have various examples for BUG and BUG_ON from the
Linux kernel; there, the diagnostic treats "panic" as an assertion
failure handler, due to '__attribute__((__noreturn__))'.

gcc/analyzer/ChangeLog:
PR analyzer/106235
* analyzer.opt (Wanalyzer-tainted-assertion): New.
* checker-path.cc (checker_path::fixup_locations): Pass false to
pending_diagnostic::fixup_location.
* diagnostic-manager.cc (get_emission_location): Pass true to
pending_diagnostic::fixup_location.
* pending-diagnostic.cc (pending_diagnostic::fixup_location): Add
bool param.
* pending-diagnostic.h (pending_diagnostic::fixup_location): Add
bool param to decl.
* sm-taint.cc (taint_state_machine::m_tainted_control_flow): New.
(taint_diagnostic::describe_state_change): Drop "final".
(class tainted_assertion): New.
(taint_state_machine::taint_state_machine): Initialize
m_tainted_control_flow.
(taint_state_machine::alt_get_inherited_state): Support
comparisons being tainted, based on their arguments.
(is_assertion_failure_handler_p): New.
(taint_state_machine::on_stmt): Complain about calls to assertion
failure handlers guarded by an attacker-controller conditional.
Detect attacker-controlled gcond conditionals and gswitch index
values.
(taint_state_machine::check_control_flow_arg_for_taint): New.

gcc/ChangeLog:
PR analyzer/106235
* doc/gcc/gcc-command-options/option-summary.rst: Add
-Wno-analyzer-tainted-assertion.
* doc/gcc/gcc-command-options/options-that-control-static-analysis.rst:
Add -Wno-analyzer-tainted-assertion.

gcc/testsuite/ChangeLog:
PR analyzer/106235
* gcc.dg/analyzer/taint-assert-BUG_ON.c: New test.
* gcc.dg/analyzer/taint-assert-macro-expansion.c: New test.
* gcc.dg/analyzer/taint-assert.c: New test.
* gcc.dg/analyzer/taint-assert-system-header.c: New test.
* gcc.dg/analyzer/test-assert.h: New header.
* gcc.dg/plugin/analyzer_gil_plugin.c
(gil_diagnostic::fixup_location): Add bool param.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>

Fortran: diagnostics for actual arguments to pointer dummy arguments [PR94104]

Error message improvement. In Fortran 2008 actual procedure arguments
associated with a pointer, intent(in) attribute, dummy argument
can also have the target attribute, not just pointer.

gcc/fortran/ChangeLog:

PR fortran/94104
* interface.cc (gfc_compare_actual_formal): Improve error message
dependent on Fortran standard level.

gcc/testsuite/ChangeLog:

PR fortran/94104
* gfortran.dg/parens_2.f90: Adjust to improved error message.
* gfortran.dg/PR94104a.f90: New test.
* gfortran.dg/PR94104b.f90: New test.

Skip guality tests on hppa-hpux.

The guality check command hangs. This causes TCL errors in
other tests and slows testsuite execution.

2022-11-13 John David Anglin <danglin@gcc.gnu.org>

gcc/testsuite/ChangeLog:

* g++.dg/guality/guality.exp: Skip on hppa*-*-hpux*.
* gcc.dg/guality/guality.exp: Likewise.
* gfortran.dg/guality/guality.exp: Likewise.

RISC-V: optimize '(a >= 0) ? b : 0' to srai + andn, if compiling for Zbb

If-conversion is turning '(a >= 0) ? b : 0' into a branchless sequence
not a5,a0
srai a5,a5,63
and a0,a1,a5
missing the opportunity to combine the NOT and AND into an ANDN.

This adds a define_split to help the combiner reassociate the NOT with
the AND.

gcc/ChangeLog:

* config/riscv/bitmanip.md: New define_split.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/zbb-srai-andn.c: New test.

doc: Update Jeff Law's email-address in contrib.rst

ChangeLog:

* doc/contrib.rst: Update Jeff Law's email address.

sphinx: include todolist only if INCLUDE_TODO env. set

It is confusing that 'Indexes and tables' contains TODO. One gets
Index by clicking to the Index link.

PR web/107643

ChangeLog:

* doc/baseconf.py: Set include_todo tag if INCLUDE_TODO env
is set.
* doc/indices-and-tables.rst: Use include_todo tag.

RISC-V: costs: support shift-and-add in strength-reduction

The strength-reduction implementation in expmed.cc will assess the
profitability of using shift-and-add using a RTL expression that wraps
a MULT (with a power-of-2) in a PLUS. Unless the RISC-V rtx_costs
function recognizes this as expressing a sh[123]add instruction, we
will return an inflated cost---thus defeating the optimization.

This change adds the necessary idiom recognition to provide an
accurate cost for this for of expressing sh[123]add.

Instead on expanding to
li a5,200
mulw a0,a5,a0
with this change, the expression 'a * 200' is sythesized as:
sh2add a0,a0,a0 // *5 = a + 4 * a
sh2add a0,a0,a0 // *5 = a + 4 * a
slli a0,a0,3 // *8

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_rtx_costs): Recognize shNadd,
if expressed as a plus and multiplication with a power-of-2.
Split costing for MINUS from PLUS.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/zba-shNadd-07.c: New test.

configure: always set SPHINX_BUILD

During the Sphinx-migration development, I used
SPHINX_BUILD='' in order to skip building info and manual
pages in gcc folder. However, we've got HAS_SPHINX_BUILD
which is the correct flag for that.

With the patch, one will get a nicer error message when
sphinx-build is missing and one builds (explicitly) a target which
depends on it.

PR other/107620

gcc/ChangeLog:

* configure: Regenerate.
* configure.ac: Always set sphinx-build.

libgomp/ChangeLog:

* configure: Regenerate.
* configure.ac: Always set sphinx-build.

libiberty/ChangeLog:

* configure: Regenerate.
* configure.ac: Always set sphinx-build.

libitm/ChangeLog:

* configure: Regenerate.
* configure.ac: Always set sphinx-build.

libquadmath/ChangeLog:

* configure: Regenerate.
* configure.ac: Always set sphinx-build.

ginclude: C2x header version macros

C2x adds __STDC_VERSION_*_H__ macros to individual headers with
interface changes compared to C17. All the new header features in
headers provided by GCC have now been implemented, so define those
macros to the value given in the current working draft.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

gcc/
* ginclude/float.h [__STDC_VERSION__ > 201710L]
(__STDC_VERSION_FLOAT_H__): New macro.
* ginclude/stdarg.h [__STDC_VERSION__ > 201710L]
(__STDC_VERSION_STDARG_H__): New macro.
* ginclude/stdatomic.h [__STDC_VERSION__ > 201710L]
(__STDC_VERSION_STDATOMIC_H__): New macro.
* ginclude/stddef.h [__STDC_VERSION__ > 201710L]
(__STDC_VERSION_STDDEF_H__): New macro.
* ginclude/stdint-gcc.h [__STDC_VERSION__ > 201710L]
(__STDC_VERSION_STDINT_H__): New macro.
* glimits.h [__STDC_VERSION__ > 201710L]
(__STDC_VERSION_LIMITS_H__): New macro.

gcc/testsuite/
* gcc.dg/c11-float-8.c, gcc.dg/c11-limits-1.c,
gcc.dg/c11-stdarg-4.c, gcc.dg/c11-stdatomic-3.c,
gcc.dg/c11-stddef-1.c, gcc.dg/c11-stdint-1.c,
gcc.dg/c2x-float-13.c, gcc.dg/c2x-limits-1.c,
gcc.dg/c2x-stdarg-5.c, gcc.dg/c2x-stdatomic-1.c,
gcc.dg/c2x-stddef-1.c, gcc.dg/c2x-stdint-1.c: New tests.

doc: Remove outdated reference to "core" and front-end downloads

gcc/ChangeLog:

* doc/install/testing.rst: Remove anachronism about separate
source tarballs.

libstdc++: Add C++20 clocks

Also add the basic types for timezones, without the non-inline
definitions needed to actually use them.

The get_leap_second_info function currently uses a hardcoded list of
leap seconds, correct as of the end of 2022. That needs to be replaced
with a dynamically generated list read from the system tzdata. That will
be done in a later patch.

libstdc++-v3/ChangeLog:

* include/std/chrono (utc_clock, tai_clock, gps_clock): Define.
(clock_time_conversion, clock_cast): Define.
(sys_info, local_info): Define structs for timezone information.
(nonexistent_local_time, ambiguous_local_time): Define
exceptions for invalid times.
(time_zone, time_zone_link, leap_second, zoned_traits, tzdb)
(tzdb_list): Define classes representing time zones.
(get_leap_second_info): Define new function returning leap
second offset for a given time point.
* testsuite/std/time/clock/gps/1.cc: New test.
* testsuite/std/time/clock/tai/1.cc: New test.
* testsuite/std/time/clock/utc/1.cc: New test.

libstdc++: Implement C++20 <format> [PR104166]

This doesn't add the newer C++23 features like formatting ranges
and escaped string prsentation types.

However, C++23 extended floating-point types are supported, as are
128-bit integers.

It could do with more tests.

libstdc++-v3/ChangeLog:

PR libstdc++/104166
* include/Makefile.am (std_headers): Add <format>.
* include/Makefile.in: Regenerate.
* include/precompiled/stdc++.h: Add <format>.
* include/std/format: New file.
* python/libstdcxx/v6/printers.py (StdFormatArgsPrinter): New
printer for std::format_args.
* testsuite/std/format/arguments/args.cc: New test.
* testsuite/std/format/error.cc: New test.
* testsuite/std/format/formatter.cc: New test.
* testsuite/std/format/functions/format.cc: New test.
* testsuite/std/format/functions/format_to_n.cc: New test.
* testsuite/std/format/functions/size.cc: New test.
* testsuite/std/format/functions/vformat_to.cc: New test.
* testsuite/std/format/parse_ctx.cc: New test.
* testsuite/std/format/string.cc: New test.
* testsuite/std/format/string_neg.cc: New test.

libstdc++: Allow std::to_chars for 128-bit integers in strict mode

This allows std::format to support __int128 when __STRICT_ANSI__ is
defined, which previously failed because __int128 is not an integral
type in strict mode.

With these changes, std::to_chars still rejects 128-bit integers in
strict mode, but std::format will be able to use __detail::__to_chars_i
for unsigned __int128.

libstdc++-v3/ChangeLog:

* include/bits/charconv.h (__integer_to_chars_is_unsigned):
New variable template.
(__to_chars_len, __to_chars_10_impl): Use variable template in
assertions to allow unsigned __int128 in strict mode.
* include/std/charconv (__to_chars, __to_chars_16)
(__to_chars_10, __to_chars_8, __to_chars_2): Likewise.

Fortran: Remove unused declaration

This function was removed years ago, remove it's prototype.

gcc/fortran/ChangeLog:

* gfortran.h (gfc_check_include): Remove declaration.

Daily bump.

libstdc++: Fix up to_chars ppc64le _Float128 overloads [PR107636]

As reported, I've misplaced __extension__ keywords in these cases
(wanted not to have them on the whole inlines because _Float128 is
completely standard now while __float128 is not, but before return
it is a syntax error.
I've verified on a short testcase that both g++ and clang++ accept
__extension__ after return keyword.

2022-11-12 Jakub Jelinek <jakub@redhat.com>

PR libstdc++/107636
* include/std/charconv (to_chars): Fix up powerpc64le _Float128
overload __extension__ placement.

Fortran: fix treatment of character, value, optional dummy arguments [PR107444]

Fix handling of character dummy arguments that have the optional+value
attribute. Change name of internal symbols that carry the hidden presence
status of optional arguments to distinguish them from the internal hidden
character length. Update documentation to clarify the gfortran ABI.

gcc/fortran/ChangeLog:

PR fortran/107444
* trans-decl.cc (create_function_arglist): Extend presence status
to all intrinsic types, and change prefix of internal symbol to '.'.
* trans-expr.cc (gfc_conv_expr_present): Align to changes in
create_function_arglist.
(gfc_conv_procedure_call): Fix generation of procedure arguments for
the case of character dummy arguments with optional+value attribute.
* trans-types.cc (gfc_get_function_type): Synchronize with changes
to create_function_arglist.
* doc/gfortran/naming-and-argument-passing-conventions.rst: Clarify
the gfortran argument passing conventions with regard to OPTIONAL
dummy arguments of intrinsic type.

gcc/testsuite/ChangeLog:

PR fortran/107444
* gfortran.dg/optional_absent_7.f90: Adjust regex.
* gfortran.dg/optional_absent_8.f90: New test.

c: C2x constexpr

Implement C2x constexpr (a feature based on the C++ one but much more
minimal, with only constexpr variables, not functions).

I believe this implementation is fully functional for use of this
feature. However, there are several things that seem unclear about
the specification that I'll need to raise in NB comments. There are
also areas where there may be followup bug fixes because the
implementation doesn't reject some more obscure cases that ought to be
rejected: cases where a constexpr initializer for floating type meets
the constraints for a constant expression in initializers but not
those for an arithmetic constant expression (previously we haven't had
to track whether something is an arithmetic constant expression in
detail, unlike with integer constant expressions), and some cases
where a tag or struct or union member gets declared indirectly in the
declaration specifiers or declarator of a constexpr declaration, which
is not permitted (modulo lack of clarity in the specification) for
underspecified declarations in general (the cases of a declaration in
the initializer, or a tagged type being directly declared as a type
specifier, are already detected).

Cases of ambiguity in the specification include:

* Many questions (previously raised in WG14 discussions) over the rule
about what conversions do or do not involve a change of value that's
not allowed in a constexpr initializer, that aren't properly
addressed by the normative text (and where the footnote on the
subject isn't very clear either, and the examples don't necessarily
follow from the normative text). I've made a series of choices
there, that include disallowing all conversions between real and
complex types or between binary and decimal floating types in
constexpr initializers, that might not necessarily agree with how
things end up getting clarified.

The dfp.cc change also arises here, to allow quiet NaN initializers
of one DFP type to be used in a constexpr initializer for another
DFP type (as is possible for signaling NaNs) by ensuring the result
of such a conversion is properly marked as canonical (note that most
of the DFP code doesn't actually do anything with NaN payloads at
all).

* Various issues with what exactly counts as part of a declaration for
the purposes of the rule on underspecified declarations not
declaring any identifiers other than ordinary identifiers (and not
declaring more than one ordinary identifier, though the latter is
undefined behavior). These include cases where the declaration of a
struct / union / enum type appears inside typeof or alignas in the
declaration specifiers (the latter also applies with auto), or in
the declarator (e.g. an array size or in a parameter declaration).
The issues are similar to those involved in C90 DR#115 and C99 DRs
#277 and #341; the intent may not be the same in all the different
cases involved, but it's not clear that the normative wording in the
various places is sufficient to deduce the differences in intent.

* The wording about producing a compound literal constant using member
access is present in one place but another place only applies that
to named constants.

* It's not clear when a structure or union constant (a constexpr
variable or compound literal with structure or union type, or a
member with such type extracted by a series of member access
operations) can itself be used in an initializer (constexpr or
otherwise). Based on general wording for initializers not having
been changed, the working draft might only strictly allow it at
automatic storage duration (but elsewhere it would be undefined
behavior, not a constraint violation, so no diagnostic required) -
since that's the only case mentioned where a single expression of
structure or union type can be used to initialize an object of such
a type. But it definitely seems to be allowed in even constexpr
initializers at automatic storage duration - and since generally
constexpr initializers (any storage duration) are *more* constrained
than ordinary static storage duration initializers, it would seem
odd for it not to be allowed at static storage duration.

* When you do allow such initializers, it's then not entirely clear
how the constraint that constexpr pointer initializers must be null
pointer constants should be applied (given that a constexpr object
of pointer type is a null pointer but *not* a null pointer
constant). My guess would be that a constexpr struct or union
containing such a field should still be allowed as an initializer,
but the wording could be read otherwise.

* It also becomes important with constexpr exactly what kind of
constant expression an implicit zero initializer is; the wording for
default initialization only really deals with the value of the
initializer and not what kind of constant it is. In particular,
this affects whether {} is a valid constexpr initializer for a
pointer not of type void *, since the wording only talks about a
null pointer, not whether it's a null pointer *constant*. I assumed
that it should be a null pointer constant in that case.

* It's also not entirely clear whether constexpr can be used in the
declaration part of a for loop (which "shall only declare
identifiers for objects having storage class auto or register"). I
interpreted it as allowed (treating such objects as implicitly auto
just like those with no storage class specifiers), but it could also
be argued that constexpr is another storage class specifier and so
not allowed there.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

gcc/
* dfp.cc (decimal_from_binary): Convert a canonical NaN to a
canonical NaN.

gcc/c-family/
* c-common.cc (c_common_reswords): Use D_C2X instead of D_CXXONLY.

gcc/c/
* c-decl.cc (start_underspecified_init)
(finish_underspecified_init): Handle name == NULL_TREE for
compound literals.
(merge_decls): Merge C_DECL_DECLARED_CONSTEXPR.
(shadow_tag_warned): Check for constexpr.
(start_decl): Add parameter do_push.
(build_compound_literal): Set C_DECL_DECLARED_CONSTEXPR.
(grokdeclarator): Handle constexpr.
(finish_struct): Set C_TYPE_FIELDS_NON_CONSTEXPR.
(declspecs_add_scspec): Handle constexpr.
* c-parser.cc (c_token_starts_compound_literal)
(c_token_starts_declspecs, c_parser_declaration_or_fndef)
(c_parser_declspecs, c_parser_gnu_attribute_any_word)
(c_parser_compound_literal_scspecs)
(c_parser_postfix_expression_after_paren_type): Handle constexpr.
Update calls to start_init.
(c_parser_declaration_or_fndef, c_parser_initializer)
(c_parser_initval): Pass true for new argument of
convert_lvalue_to_rvalue. Call convert_lvalue_to_rvalue for
constexpr compound literals.
(c_parser_static_assert_declaration_no_semi)
(c_parser_enum_specifier, c_parser_struct_declaration)
(c_parser_alignas_specifier, c_parser_initelt, c_parser_label):
Call convert_lvalue_to_rvalue on expressions required to be
integer constant expressions.
(c_parser_omp_declare_reduction): Update call to start_init.
* c-tree.h (C_TYPE_FIELDS_NON_CONSTEXPR)
(C_DECL_DECLARED_CONSTEXPR): New macros.
(struct c_declspecs): Add constexpr_p.
(start_decl, convert_lvalue_to_rvalue, start_init): Update
prototypes.
* c-typeck.cc (require_constant_value, require_constant_elements):
Change to bool.
(require_constexpr_value, maybe_get_constexpr_init)
(constexpr_init_fits_real_type, check_constexpr_init): New.
(convert_lvalue_to_rvalue): Add new parameter for_init. Call
maybe_get_constexpr_init.
(store_init_value): Update call to digest_init.
(digest_init): Add parameters int_const_expr, arith_const_expr and
require_constexpr. Check constexpr initializers.
(constructor_top_level): Remove.
(struct initializer_stack): Remove top_level. Add
require_constexpr_value.
(start_init): Remove parameter top_level. Add parameters
init_require_constant and init_require_constexpr. Save
require_constexpr_value on stack.
(pop_init_level): Use a null pointer constant for zero initializer
of pointer initialized with {}.
(output_init_element): Update call to digest_init. Avoid passing
null pointer constants of pointer type through digest_init a
second time when initializing a constexpr object.

gcc/testsuite/
* gcc.dg/c11-keywords-1.c: Also test constexpr.
* gcc.dg/c2x-constexpr-1.c, gcc.dg/c2x-constexpr-2a.c,
gcc.dg/c2x-constexpr-2b.c, gcc.dg/c2x-constexpr-3.c,
gcc.dg/c2x-constexpr-4.c, gcc.dg/c2x-constexpr-5.c,
gcc.dg/c2x-constexpr-6.c, gcc.dg/c2x-constexpr-7.c,
gcc.dg/c2x-constexpr-8.c, gcc.dg/c2x-constexpr-9.c,
gcc.dg/dfp/c2x-constexpr-dfp-1.c,
gcc.dg/dfp/c2x-constexpr-dfp-2.c, gcc.dg/gnu2x-constexpr-1.c,
gcc.target/i386/excess-precision-11.c,
gcc.target/i386/excess-precision-12.c: New tests.

[frange] Avoid testing signed zero test for -fno-signed-zeros.

This patch moves a test that is meant to only work for signed zeros
into range_tests_signed_zeros.

I am not aware of any architectures where this is failing, but it is
annoying to see selftests failing when -fno-signed-zeros is used.

gcc/ChangeLog:

* value-range.cc (range_tests_signbit): Move to set from here...
(range_tests_signed_zeros): ...to here.

[range-ops] Add ability to represent open intervals in frange.

Currently we represent < and > with a closed interval. So < 3.0 is
represented as [-INF, +3.0]. This means 3.0 is included in the range,
and though not ideal, is conservatively correct. Jakub has found a
couple cases where properly representing < and > would help
optimizations and tests, and this patch allows representing open
intervals with real_nextafter.

There are a few caveats.

First, we leave MODE_COMPOSITE_P types pessimistically as a closed interval.

Second, for -ffinite-math-only, real_nextafter will saturate the
maximum representable number into +INF. However, this will still do
the right thing, as frange::set() will crop things appropriately.

Finally, and most frustratingly, representing < and > -+0.0 is
problematic because we flush denormals to zero. Let me explain...

real_nextafter(+0.0, +INF) gives 0x0.8p-148 as expected, but setting a
range to this value yields [+0.0, 0x0.8p-148] because of the flushing.

On the other hand, real_nextafter(+0.0, -INF) (surprisingly) gives
-0.0.8p-148, but setting a range to that value yields [-0.0x8p-148,
-0.0]. I say surprising, because according to cppreference.com,
std::nextafter(+0.0, -INF) should give -0.0. But that's neither here
nor there because our flushing denormals to zero prevents us from even
representing ranges involving small values around 0.0. We ultimately
end up with ranges looking like this:

> +0.0 => [+0.0, INF]
> -0.0 => [+0.0, INF]
< +0.0 => [-INF, -0.0]
< -0.0 => [-INF, -0.0]

I suppose this is no worse off that what we had before with closed
intervals. One could even argue that we're better because we at least
have the right sign now ;-).

gcc/ChangeLog:

* range-op-float.cc (build_lt): Adjust with frange_nextafter
instead of default to a closed range.
(build_gt): Same.

libgomp: Fix up build on mingw [PR107641]

Pointers should be first casted to intptr_t/uintptr_t before casting
them to another integral type to avoid warnings.
Furthermore, the function has code like
else if (upper <= UINT_MAX)
something;
else
something_else;
so it seems using unsigned type for upper where upper <= UINT_MAX is always
true is not intended.

2022-11-12 Jakub Jelinek <jakub@redhat.com>

PR libgomp/107641
* env.c (parse_unsigned_long): Cast params[2] to uintptr_t rather than
unsigned long. Change type of upper from unsigned to unsigned long.

range-op: Implement op[12]_range operators for {PLUS,MINUS,MULT,RDIV}_EXPR

On Wed, Nov 09, 2022 at 04:43:56PM +0100, Aldy Hernandez wrote:
> On Wed, Nov 9, 2022 at 3:58 PM Jakub Jelinek <jakub@redhat.com> wrote:
> >
> > On Wed, Nov 09, 2022 at 10:02:46AM +0100, Aldy Hernandez wrote:
> > > We can implement the op[12]_range entries for plus and minus in terms
> > > of each other. These are adapted from the integer versions.
> >
> > I think for NANs the op[12]_range shouldn't act this way.
> > For the forward binary operations, we have the (maybe/known) NAN handling
> > of one or both NAN operands resulting in VARYING sign (maybe/known) NAN
> > result, that is the somehow the case for the reverse binary operations too,
> > if result is (maybe/known) NAN and the other op is not NAN, op is
> > VARYING sign (maybe/known) NAN, if other op is (maybe/known) NAN,
> > then op is VARYING sign maybe NAN (always maybe, never known).
> > But then for + we have the -INF + INF or vice versa into NAN, and that
> > is something that shouldn't be considered. If result isn't NAN, then
> > neither operand can be NAN, regardless of whether result can be
> > +/- INF and the other op -/+ INF.
>
> Heh. I just ran into this while debugging the problem reported by Xi.
>
> We are solving NAN = op1 - VARYING, and trying to do it with op1 = NAN
> + VARYING, which returns op1 = NAN (incorrectly).
>
> I suppose in the above case op1 should ideally be
> [-INF,-INF][+INF,+INF]+-NAN, but since we can't represent that then
> [-INF,+INF] +-NAN, which is actually VARYING. Do you agree?
>
> I'm reverting this patch as attached, while I sort this out.

Here is a patch which reinstalls your change, add the fixups I've talked
about and also hooks up reverse operators for MULT_EXPR/RDIV_EXPR.

2022-11-12 Aldy Hernandez <aldyh@redhat.com>
Jakub Jelinek <jakub@redhat.com>

* range-op-float.cc (float_binary_op_range_finish): New function.
(foperator_plus::op1_range): New.
(foperator_plus::op2_range): New.
(foperator_minus::op1_range): New.
(foperator_minus::op2_range): New.
(foperator_mult::op1_range): New.
(foperator_mult::op2_range): New.
(foperator_div::op1_range): New.
(foperator_div::op2_range): New.

* gcc.c-torture/execute/ieee/inf-4.c: New test.