On Sat, 14 Sep 2019, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, the sqrt (x) < c optimization into x < c*c
> sometimes breaks the boundary case, if c2=c*c is inexact then in some cases
> we need to optimize it into x <= c*c rather than x < c*c. The original
> bugreport is when c is s
On Fri, Sep 13, 2019 at 2:30 PM Martin Liška wrote:
>
> On 8/20/19 8:39 AM, Richard Biener wrote:
> > Anyhow, the original patch is OK if you compare
> > OBJ_TYPE_REF_TOKEN/OBJECT irrespective of virtual_method_call_p
> > and order the types_same_for_odr last since that's most expensive.
>
> Hi.
>
In this testcase, !f.b0 was failing to call the overloaded operator because
TREE_TYPE is the magic bitfield integer type, and we weren't using
unlowered_expr_type the way we do in other places. It would be nice if we
could give bit-field COMPONENT_REFs their declared type until genericization
time
While working on C++20 operator<=>, I noticed that build_new_op_1 was doing
too much conversion when a built-in candidate was selected; the standard
says it should only perform user-defined conversions, and then leave the
normal operator semantics to handle any standard conversions. This is
import
Here, if cp_perform_integral_promotions saw that the TREE_TYPE of a
bit-field reference was the same as the type it promotes to, it didn't do
anything. But then decay_conversion saw that the bit-field reference was
unchanged, and converted it to its declared type. So I needed to add
something to
When we introduced location wrappers, we added fold_for_warn to warnings
that are interested in a constant value, or wrapper-stripping to warnings
that are interested in literal constants. This particular warning is
looking for a literal constant, but was wrongly changed to use
fold_for_warn; this
A revised patch is attached that adds proper preprocessor conditionals
around the deleted ostream inserters. Apparently I had previously
implemented a quick hack for testing purposes, neglected to add a FIXME
comment, and then forgot about the hack. Shame on me.
Tom.
On 9/15/19 3:39 PM, Tom
A revised patch is attached that modifies the tests for deleted ostream
inserters to require C++2a. This is required by the revision of patch
2/4 that adds proper preprocessor conditionals to the definitions.
Tom.
On 9/15/19 3:40 PM, Tom Honermann wrote:
This patch adds new tests to validate
If an assembler is used that supports .cfi_xxx, then (usually) GCC's
configuration will detect this and try to use it to generate frame insns.
This will not work for Darwin since the default implementation for the
personality and LSDA indirection is not correct for Mach-O ABI.
As of now we are
This patch updates existing tests to validate the new value for the
__cpp_lib_char8_t feature test macros and to exercise u8path factory
function invocations with std::string, std::string_view, and interator
pair arguments.
libstdc++-v3/ChangeLog:
2019-09-15 Tom Honermann
* libstdc++-v3
This patch adds new tests to validate new deleted overloads of wchar_t,
char8_t, char16_t, and char32_t for ordinary and wide formatted
character and string ostream inserters.
Additionally, new tests are added to validate invocations of u8path with
sequences of char8_t for both the C++17 and f
This patch increments the __cpp_lib_char8_t feature test macro, adds
deleted operator<< overloads for basic_ostream, and modifies u8path to
accept sequences of char8_t for both the C++17 implementation of
std::filesystem, and the filesystem TS implementation.
The implementation mechanism used
This patch moves helper classes and functions for std::filesystem::path
out of the class definition to a detail namespace so that they are
available to the implementations of std::filesystem::u8path. Prior to
this patch, the SFINAE constraints for those implementations were
specified via deleg
This series of patches provides an implementation of the changes for C++
proposal P1423R3 [1].
These changes do not impact default libstdc++ behavior for C++17 and
earlier; they are only active for C++2a or when the -fchar8_t option is
specified.
Tested x86_64-linux.
Patch 1: Decouple const
Hi Sandro,
This patch looks fine to me. I have a question about the comment:
"This code is obviously added because the finalizer is not trusted to
free all memory."
'obviously'? Not to me :-( Maybe you can expand on this?
As to the stat and errmsg: Leave them for the time being. However, an
attem
Committed as obvious.
The patch checks for a NULL pointer dereference. In this
case, it pointers to an error in the Fortran code, and so
gfortran now issues an informative error message.
2019-09-15 Steven G. Kargl
PR fortran/91727
* resolve.c (conformable_arrays): If array-s
On Fri, Sep 13, 2019 at 5:31 PM Sandra Loosemore
wrote:
>
> In some bare-metal environments, the tests for fp16 runtime support fail
> in a way that causes a timeout rather than immediate failure. (E.g.,
> the runtime might provide a do-nothing exception handler that just sits
> in a tight loop a
Hi Steve,
s/previusly/previously
Fixed, committed. Thanks for the review!
Do you it gfortran should skip the front-end optimization pass
if error(s) have already been reported? On entry ito this pass,
you could test for the error count and simply return.
I thought about this for doing thi
On Sun, Sep 15, 2019 at 03:55:55PM +0200, Thomas Koenig wrote:
>
> Regression-tested. OK for all affected branches (trunk, 9 and 8)?
>
OK with minor spelling fix.
> + sgn = mpz_cmp_ui (dl->ext.iterator->step->value.integer, 0);
> + /* This can happen, but then the e
On Sun, Sep 15, 2019 at 12:40:02PM +0100, Paul Richard Thomas wrote:
> The attached bootstraps and regtests on FC30/x86_64 - OK for trunk?
>
> It strikes me that this should be backported since the bug is rather
> fundamental and ispresent all the way back to version 4.8. An obvious
> question is
On 9/11/19 4:15 PM, Marek Polacek wrote:
This ICEs since r267272 - more location wrapper nodes, but not because we can't
cope with new location wrappers, but because that commit introduced a call to
maybe_constant_value in cp_build_array_ref. In this testcase we call it with
f (VIEW_CONVERT_
On 9/12/19 9:41 AM, Paolo Carlini wrote:
+ if (!valid_array_size_p (dname
+ ? declarator->id_loc : input_location,
Use the id_loc local variable?
OK with that change.
Jason
On 9/5/19 9:24 PM, Marek Polacek wrote:
They use
non_lvalue_loc, but that won't create a NON_LVALUE_EXPR wrapper around a
location
wrapper.
That seems like the bug. maybe_lvalue_p should be true for
VIEW_CONVERT_EXPR.
Jason
Hello world,
the attached patch fixes an ICE on invalid, where the fact that
the step in do i = 1, 3, .1 is actually zero slipped through.
Regression-tested. OK for all affected branches (trunk, 9 and 8)?
Regards
Thomas
2019-09-15 Thomas Koenig
PR fortran/91550
*
This patch replaces the decl_cloned_function_p function call with simpler macro
uses. As only cdtors are cloned, we can use IDENTIFIER_CDTOR_P to check.
In the process I discovered the documentation had bitrotted -- we were giving
non-function_decls to the predicate, sometimes intentionally (t
The attached bootstraps and regtests on FC30/x86_64 - OK for trunk?
It strikes me that this should be backported since the bug is rather
fundamental and ispresent all the way back to version 4.8. An obvious
question is how far back? To 8-branch?
Cheers
Paul
2019-09-15 Paul Thomas
PR for
26 matches
Mail list logo
