Hi!
On Tue, Apr 28, 2020 at 12:25:04AM -0300, Alexandre Oliva wrote:
> On Apr 24, 2020, Segher Boessenkool wrote:
>
> >> > since all the top bits are zeros always, it will always be a subnormal
> >> > number, so all comparisons will work as expected / wanted.
> >>
> >> *nod*, as long as there's
On 4/28/20 3:19 PM, Patrick Palka wrote:
On Tue, 28 Apr 2020, Patrick Palka wrote:
On Tue, 28 Apr 2020, Jason Merrill wrote:
On 4/28/20 1:41 PM, Patrick Palka wrote:
On Tue, 28 Apr 2020, Patrick Palka wrote:
On Tue, 28 Apr 2020, Jason Merrill wrote:
On 4/28/20 9:48 AM, Patrick Palka wrote
On 4/28/20 4:13 PM, Patrick Palka wrote:
As observed in PR94719, an inherited constructor for an instantiation of
a constructor template confusingly has as its DECL_INHERITED_CTOR the
TEMPLATE_DECL of the constructor template rather than the particular
instantiation of the template.
This means t
On 4/28/20 11:57 AM, Richard Sandiford wrote:
> I was just quoting code from simplify_replace_fn_rtx as an example of
> something that handles a similar situation. The recursive calls would
> be different for cse_process_notes_1.
Ok, how about the following which adds the (const:P ...) as well, w
On Apr 28, 2020, Segher Boessenkool wrote:
> s/mmfl/mffs/
> s/mmfs/mffs/
> s/mmsl/mffsl/
Oh, my, looks like I missed some mispellings of ffmls :-P
Sorry about the typos, for some reason mffs makes it worse than usual
for me.
> Okay for trunk with such tweaks. Thank you! Also okay for the 9 b
Peter Bergner writes:
> On 4/28/20 11:57 AM, Richard Sandiford wrote:
>> I was just quoting code from simplify_replace_fn_rtx as an example of
>> something that handles a similar situation. The recursive calls would
>> be different for cse_process_notes_1.
>
> Ok, how about the following which ad
On 28/04/20 19:11 +0200, Jakub Jelinek wrote:
On Tue, Apr 28, 2020 at 12:01:15PM -0500, Segher Boessenkool wrote:
So the attribute says an object of this struct can have the same address
as another object of this struct. But that is not what the backend code
uses it for!
There is a FAQ at the
By trying to reuse the existing std::_Construct function as a wrapper
for std::construct_at I introduced regressions, because changing
std::_Construct to return non-void made it ill-formed for array types.
The solution is to revert _Construct to its former state, and change
allocator_traits::const
Remove the non-standard __cpp_lib_allocator_is_always_equal macro and
add the missing macros for P1032R1.
PR libstdc++/91480
* include/bits/allocator.h (__cpp_lib_allocator_is_always_equal):
Remove non-standard macro.
* include/bits/stl_iterator.h (__cpp_lib_conste
On 4/28/20 5:39 PM, Richard Sandiford wrote:
> If we use simplify_gen_binary then I don't think we need to validate
> each change individually. It should be enough to do something like:
>
> x0 = cse_process_notes (XEXP (x, 0), object, changed);
> x1 = cse_process_notes (XEXP (x, 1), o
On Tue, Apr 28, 2020 at 4:02 PM Jakub Jelinek wrote:
>
> On Tue, Apr 28, 2020 at 05:42:00PM +0200, Jakub Jelinek wrote:
> > Ok, below in the updated patch:
>
> This is what I've successfully bootstrapped/regtested on powerpc64le-linux
> (last posted patch with the lto-common.c addition included).
On Apr 28, 2020, Bernhard Reutner-Fischer wrote:
> ISTM the corresponding documentation hunk for sourcebuild.texi is missing.
Thanks, I wasn't aware that testsuite effective targets were documented
there.
Here's the missing documentation. Tested with 'make info' on
x86_64-linux-gnu. Ok to in
On Tue, Apr 28, 2020 at 07:15:58PM -0300, Alexandre Oliva wrote:
> On Apr 28, 2020, Segher Boessenkool wrote:
>
> > s/mmfl/mffs/
> > s/mmfs/mffs/
> > s/mmsl/mffsl/
>
> Oh, my, looks like I missed some mispellings of ffmls :-P
It helps to read the mnemonics as the full name -- the Power mnemonic
On 4/28/20 6:06 PM, Peter Bergner wrote:
> However, do you mean the change to be the following, since I don't think
> simplify_gen_binary ever returns NULL?
>
>
>validate_change (object, &XEXP (x, i),
>cse_process_notes (XEXP (x, i), object, changed), 0);
>
> +
Hi!
On Mon, Apr 27, 2020 at 05:30:24PM -0500, Peter Bergner wrote:
> rtl-optimization: ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future -mpcrel
> -O1 [PR94740]
>
> We ICE on the test case below because decompose_normal_address() doesn't
> expect to see memory operands with constant addresses
Hi!
On Tue, Apr 28, 2020 at 08:38:56AM +0100, Richard Sandiford wrote:
> Also, the (const:P ...) ought to be there even outside of a MEM. E.g. we
> ought to have:
>
> (set (reg X) (const:P (plus:P (symbol_ref:P S) (const_int D
>
> rather than:
>
> (set (reg X) (plus:P (symbol_ref:P S)
Allow -fcf-protection with external thunk since the external thunk can be
made compatible with -fcf-protection.
OK for master?
Thanks.
H.J.
---
gcc/
PR target/93654
* config/i386/i386-options.c (ix86_set_indirect_branch_type):
Allow -fcf-protection with -mindirect-branch
Hi,
This ICE appears because gcc will stream it to the function_body section when
processing the
variable with the initial value of the constructor type, and the
error_mark_node to the
decls section. When recompiling, the value obtained with DECL_INITIAL will be
error_mark.
This patch use vn
Whew, this took a while. We fail to parse "p->template A::a()"
(where p is of type A *) because since r249752 we treat the RHS of the ->
as dependent and avoid a lookup in the enclosing context: since that rev
cp_parser_template_name checks parser->context->object_type too, which
here is unknown_t
On Tue, 28 Apr 2020, Jason Merrill wrote:
> On 4/28/20 3:19 PM, Patrick Palka wrote:
> > On Tue, 28 Apr 2020, Patrick Palka wrote:
> >
> > > On Tue, 28 Apr 2020, Jason Merrill wrote:
> > >
> > > > On 4/28/20 1:41 PM, Patrick Palka wrote:
> > > > > On Tue, 28 Apr 2020, Patrick Palka wrote:
> > >
On 4/29/20 12:05 AM, Patrick Palka wrote:
On Tue, 28 Apr 2020, Jason Merrill wrote:
On 4/28/20 3:19 PM, Patrick Palka wrote:
On Tue, 28 Apr 2020, Patrick Palka wrote:
On Tue, 28 Apr 2020, Jason Merrill wrote:
On 4/28/20 1:41 PM, Patrick Palka wrote:
On Tue, 28 Apr 2020, Patrick Palka wrot
On Tue, Apr 28, 2020 at 6:14 PM Martin Sebor via Gcc-patches
wrote:
>
> On 4/27/20 10:58 AM, Stefan Schulze Frielinghaus wrote:
> > Array retval is not necessarily initialized by function is_call_safe and
> > may be used afterwards. Thus, initialize it explicitly.
> >
> > Ok for master?
>
> The c
On Tue, Apr 28, 2020 at 10:54 PM Sandra Loosemore
wrote:
>
> On 4/27/20 9:08 AM, Matthias Kretz wrote:
> >
> > @item -ffinite-math-only
> > @opindex ffinite-math-only
> > -Allow optimizations for floating-point arithmetic that assume
> > -that arguments and results are not NaNs or +-Infs.
> >
On Wed, Apr 29, 2020 at 4:22 AM H.J. Lu via Gcc-patches
wrote:
>
> Allow -fcf-protection with external thunk since the external thunk can be
> made compatible with -fcf-protection.
>
> OK for master?
OK. I guess also OK for backporting to branches where CET support is
in a reasonable
state (not
On Wed, Apr 29, 2020 at 6:04 AM lizekun (A) wrote:
>
> Hi,
>
> This ICE appears because gcc will stream it to the function_body section when
> processing the
> variable with the initial value of the constructor type, and the
> error_mark_node to the
> decls section. When recompiling, the value o
On Wed, Apr 29, 2020 at 6:04 AM lizekun (A) wrote:
>
> Hi,
>
> This ICE appears because gcc will stream it to the function_body section when
> processing the
> variable with the initial value of the constructor type, and the
> error_mark_node to the
> decls section. When recompiling, the value o
101 - 126 of 126 matches
Mail list logo
