> My script to check for PR79475-like issues discovered what looks like a bug
> in the Ada FE. I actually have no idea how it can work properly for any
> entries after the last US entry or "United-States", because it will only
> match United-StatesUY to US or UZ to Uruguay etc., rather than
> Unit
On 10/1/19 11:16 AM, Martin Sebor wrote:
> Attached is an implementation of the __has_builtin special
> preprocessor operator/macro analogous to __has_attribute and
> (hopefully) compatible with the synonymous Clang feature (I
> couldn't actually find tests for it in the Clang test suite
> but if s
On 9/29/19 1:51 PM, Martin Sebor wrote:
> -Wstringop-overflow detects a subset of past-the-end read and write
> accesses by built-in functions such as memcpy and strcpy. It relies
> on the functions' effects the knowledge of which is hardwired into
> GCC. Although it's possible for users to creat
On 10/5/19 5:29 AM, Richard Sandiford wrote:
>
> Sure. This message is going to go to the other extreme, sorry, but I'm
> not sure which part will be the most convincing (if any).
No worries. Worst case going to the other extreme is I have to read it
more than once after nodding off halfway thro
The user-visible effect of this change is for std::future::wait_until to
use CLOCK_MONOTONIC when passed a timeout of std::chrono::steady_clock
type. This makes it immune to any changes made to the system clock
CLOCK_REALTIME.
Add an overload of __atomic_futex_unsigned::_M_load_and_text_until_imp
The futex system call supports waiting for an absolute time if
FUTEX_WAIT_BITSET is used rather than FUTEX_WAIT. Doing so provides two
benefits:
1. The call to gettimeofday is not required in order to calculate a
relative timeout.
2. If someone changes the system clock during the wait then th
The user-visible effect of this change is that std::future::wait_for now
uses std::chrono::steady_clock to determine the timeout. This makes it
immune to changes made to the system clock. It also means that anyone
using their own clock types with std::future::wait_until will have the
timeout conv
Add tests for waiting for the future using both std::chrono::steady_clock
and std::chrono::system_clock in preparation for dealing with those clocks
properly in futex.cc.
* libstdc++-v3/testsuite/30_threads/async/async.cc (test02): Test
steady_clock with std::future::wait_until.
v1 of this series was originally posted back in September 2017 (see
https://gcc.gnu.org/ml/libstdc++/2017-09/msg00083.html )
v2 of this series was originally posted back in January 2018 (see
https://gcc.gnu.org/ml/libstdc++/2018-01/msg00035.html )
v3 of this series was originally posted back in A
These tests show that changing the system clock has an effect on
std::future::wait_until when using std::chrono::system_clock but not when
using std::chrono::steady_clock. Unfortunately these tests have a number
of downsides:
1. Nothing that is attempting to keep the clock set correctly (ntpd,
Convert the specified duration to the target clock's duration type before
adding it to the current time. This avoids the situation described in PR
libstdc++/68519 when the specified duration type lacks sufficient
precision.
* libstdc++-v3/include/bits/atomic_futex.h:
(__atomic_fut
If std::future::wait_until is passed a time point measured against a clock
that is neither std::chrono::steady_clock nor std::chrono::system_clock
then the generic implementation of
__atomic_futex_unsigned::_M_load_when_equal_until is called which
calculates the timeout based on __clock_t and calls
On 10/23/19 11:37 AM, Jozef Lawrynowicz wrote:
> For MSP430 in some configurations, GCC will generate code for mulhisi3 by
> inserting instructions to widen each 16-bit operand before calling a library
> routine for mulsi3.
> However, there exists a hardware multiply routine to perform this widenin
On 10/18/19 3:06 AM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on x86_64-redhat-linux, s390x-redhat-linux
> and ppc64le-redhat-linux. The offending patch is in gcc-9_1_0-release
> and gcc-9_2_0-release - do I need to backport this fix to gcc-9-branch?
>
>
> r266734 has introduced a ne
Robin Dapp writes:
> When then and else are reversed, we would swap new_val and old_val.
> The same has to be done for our new code paths.
> Also, emit_conditional_move may perform swapping. In case we need to
> swap, the cc comparison also needs to be swapped and for this we pass
> the reversed
Robin Dapp writes:
> This patch duplicates the previous noce_emit_cmove logic. First it
> passes the canonical comparison emits the sequence and costs it.
> Then, a second, separate sequence is created by passing the cc compare
> we extracted before. The costs of both sequences are compared and
Robin Dapp writes:
> This patch extracts a cc comparison from the initial compare/jump
> insn and allows it to be passed to noce_emit_cmove and
> emit_conditional_move.
> ---
> gcc/ifcvt.c | 68
> gcc/optabs.c | 7 --
> gcc/optabs.h | 2
Coming back to this just in time for it not to be three months later,
sorry...
I still think it would be better to consolidate ifcvt a bit more,
rather than effectively duplicate bits of cond_move_process_if_block
in noce_convert_multiple_sets. But perhaps it was a historical
mistake to have two
Prathamesh Kulkarni writes:
> @@ -10288,6 +10261,23 @@ vectorizable_condition (stmt_vec_info stmt_info,
> gimple_stmt_iterator *gsi,
> vect_finish_stmt_generation (stmt_info, new_stmt, gsi);
> vec_compare = vec_compare_name;
> }
> +
> + if (
> Hi,
> this patch makes ipa-prop to free edge summaries (jump functions) for
> calls which has been inlined because they are no longer useful.
> The main change is to change IPA_EDGE_REF from get_create to get
> and thus we need to watch for missing summaires at some places so
> combining -O0 and
Applied as obvious
Johann
PR target/85969
* config/avr/gen-avr-mmcu-specs.c (str_prefix_p): Remove unused
static function.
--- trunk/gcc/config/avr/gen-avr-mmcu-specs.c 2019/10/25 14:39:06 277454
+++ trunk/gcc/config/avr/gen-avr-mmcu-specs.c 2019/10/25 15:13:23
On 26.10.2019 23:57, Andreas Tobler wrote:
> On 04.10.19 19:04, Jeff Law wrote:
>> On 9/30/19 12:47 PM, Andreas Tobler wrote:
>>> On 30.09.19 20:37, Kamil Rytarowski wrote:
On 30.09.2019 19:47, Jakub Jelinek wrote:
> On Mon, Sep 30, 2019 at 07:41:00PM +0200, Andreas Tobler wrote:
>> --
On Oct 26, 2019, Alexandre Oliva wrote:
> E.g., the reason we gather expanded calls rather than just use
> cgraph_edges is that the latter would dump several "calls" that are
> builtins expanded internally by the compiler, and would NOT dump other
> ops that are expanded as (lib)calls.
It occurr
Ping...
I'd like to ping for this patch:
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01459.html
Thanks
Bernd.
On 10/20/19 9:58 PM, Bernd Edlinger wrote:
> Hi,
>
> this fixes an issue with the gdb step-over aka. "n" command.
>
> It can be seen when you debug an optimized stage-3 cc1
> it doe
Hi,
this patch makes ipa-prop to free edge summaries (jump functions) for
calls which has been inlined because they are no longer useful.
The main change is to change IPA_EDGE_REF from get_create to get
and thus we need to watch for missing summaires at some places so
combining -O0 and -O2 code wor
Hi,
this is similar to previous patch - when expanding thunk summaries needs
to be recomputed. Bootstrapped/regtested x86_64-linux, comitted.
Honza
* ipa-inline-transform.c (inline_call): update function summaries
after expanidng thunk.
Index: ipa-inline-transform.c
=
Hi Tobias,
Thanks for taking care of this. OK for trunk and 9-branch.
Cheers
Paul
On Wed, 23 Oct 2019 at 14:07, Tobias Burnus wrote:
>
> With the trunk, there are three issues:
>
> (a) With bind(C), the callee side handles deallocation with intent(out).
>
> This should produce the code:
>
On Fri, 21 Jun 2019, Marek Polacek wrote:
>> 2019-06-20 Matthew Beliveau
>>
>> PR c++/90875 - added -Wswitch-outside-range option
>> * doc/invoke.texi (Wswitch-outside-range): Document.
I noticed this is not yet covered in the GCC 10 release notes at
https://gcc.gnu.org/gcc-10/change
28 matches
Mail list logo
