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
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 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 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 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, 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:
> > >
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
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
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!
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)
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
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);
>
> +
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 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 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 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
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
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
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
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 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
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 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
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
This is a minor H8 specific bugfix. The H8/SX multiply instructions are all 4
bytes in length, but the machine description claims they are 2 bytes in length.
This can cause GCC to emit a short branch when a long branch was actually
needed.
Sadly the assembler didn't complain and instead the bra
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 two inherited constructors for two different
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).
Jason has already approved the non-rs6000 parts, so are those ok
On Tue, Apr 28, 2020 at 11:44:58AM +0200, Richard Biener wrote:
> On Tue, Apr 28, 2020 at 11:28 AM Stefan Schulze Frielinghaus via
> Gcc-patches wrote:
> >
> > While bootstrapping GCC on S/390 the following warning/error is raised:
> >
> > gcc/var-tracking.c:10239:34: error: 'pre' may be used unin
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.
+Assume that floating-point types in the language do not have representations
for
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 28/04/2020 20:43, Iain Buclaw wrote:
> On 28/04/2020 20:25, Segher Boessenkool wrote:
>> Hi!
>>
>> On Tue, Apr 28, 2020 at 07:58:37PM +0200, Iain Buclaw wrote:
>>>
>>> +#if defined( __ppc__ ) || defined( __PPC__ ) || defined( __powerpc__ )
>>
>> What is this for? Everything in libphobos/libdr
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:
> > > > > When printing the substituted parameter list of a requi
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:
When printing the substituted parameter list of a requires-expression as
part of the "in requirements with ..." context line du
On 28/04/2020 20:25, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Apr 28, 2020 at 07:58:37PM +0200, Iain Buclaw wrote:
>> This patch should fix builds on PPC with multilib enabled.
>>
>> Multilibs should not have been split up as two logically different CPU,
>> so at configure time, powerpc64 was b
On 4/25/20 6:54 PM, Marek Polacek wrote:
On Sat, Apr 25, 2020 at 12:17:18AM -0400, Jason Merrill via Gcc-patches wrote:
P2085 clarified that a defaulted comparison operator must be the first
declaration of the function. Rejecting that avoids the ICE trying to
compare the noexcept-specifications
My last patch rejected a namespace-scope declaration of the
implicitly-declared friend operator== before the class, but redeclaring it
after the class should be OK.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog
2020-04-28 Jason Merrill
PR c++/94583
* decl.c (
This adds mentioning of Marvell ThunderX3 chip to
the list of supported processors.
---
htdocs/gcc-10/changes.html | 1 +
1 file changed, 1 insertion(+)
diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 41c2dc0..b37b74d 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdo
On Tue, Apr 28, 2020 at 11:33:31AM +0200, Richard Biener wrote:
> On Tue, Apr 28, 2020 at 10:03 AM Stefan Schulze Frielinghaus via
> Gcc-patches wrote:
> >
> > In function handle_vector_size_attribute local variable nunits is
> > supposed to be initialized by function type_valid_for_vector_size.
>
Hi!
On Tue, Apr 28, 2020 at 07:58:37PM +0200, Iain Buclaw wrote:
> This patch should fix builds on PPC with multilib enabled.
>
> Multilibs should not have been split up as two logically different CPU,
> so at configure time, powerpc64 was being detected, but none of the
> 32-bit support files we
On Sun, Apr 26, 2020 at 10:43:53PM +0200, Iain Buclaw wrote:
> +// The layout of the type is:
> +//
> +// [1| 7 | 56 ][ 8| 56 ]
> +// [S| Exp | Fraction (hi) ][ Unused | Fraction (low) ]
> +
Hi,
This patch should fix builds on PPC with multilib enabled.
Multilibs should not have been split up as two logically different CPU,
so at configure time, powerpc64 was being detected, but none of the
32-bit support files were being compiled in.
Segher, is this OK?
Immediately to hand, I only
PR analyzer/94816 reports an ICE when attempting to copy a struct
containing a field for which add_region_for_type for fails (on
an OFFSET_TYPE): the region for the src field comes from
make_region_for_unexpected_tree_code which gives it a NULL type, and
then the copy calls add_region_for_type whic
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:
> > > When printing the substituted parameter list of a requires-expression as
> > > part of the "in requirements with ..." context line during concepts
> > > diagnost
Hi!
On Sun, Apr 26, 2020 at 11:35:21AM +0200, Iain Buclaw wrote:
> This patch adds power*-*-linux* as a supported target for libphobos.
Many thanks for doing this!
A problem though: libphobos/libdruntime is built for -m32 as well, but
that builds libphobos/libdruntime/config/powerpc64/callwithst
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 start of the paper that says various intent
On Tue, Apr 28, 2020 at 06:45:05PM +0200, Jakub Jelinek wrote:
> On Tue, Apr 28, 2020 at 11:32:02AM -0500, Segher Boessenkool wrote:
> > > G++ 9 -std=c++14 A, B, C passed in fprs, the rest in gprs
> > > G++ 9 -std=c++17 A passed in fprs, the rest in gprs
> > > current trunk -std=c
Peter Bergner writes:
> On 4/28/20 2:38 AM, Richard Sandiford wrote:
>> case RTX_BIN_ARITH:
>> case RTX_COMM_ARITH:
>> op0 = simplify_replace_fn_rtx (XEXP (x, 0), old_rtx, fn, data);
>> op1 = simplify_replace_fn_rtx (XEXP (x, 1), old_rtx, fn, data);
>> if (op0 == XEXP (x,
On Tue, Apr 28, 2020 at 11:32:02AM -0500, Segher Boessenkool wrote:
> > testcase on powerpc64-linux. Results:
>
> You mean powerpc64le-linux here (I hope!)
Yes, sorry.
> > G++ 9 -std=c++14A, B, C passed in fprs, the rest in gprs
> > G++ 9 -std=c++17A passed in fprs, the
On Tue, Apr 28, 2020 at 10:37 AM David Malcolm via Gcc-patches
wrote:
> I'm working on a rewrite of the region_model code for GCC 11 that I
> hope will fix these issues, and allow this warning to be reintroduced.
If that's the case, why remove the warning just to add it back? You
could leave it
Hi!
On Tue, Apr 28, 2020 at 01:38:52PM +0200, Jakub Jelinek wrote:
> Ok, I've tried:
> struct X { };
> struct Y { int : 0; };
> struct Z { int : 0; Y y; };
> struct U : public X { X q; };
> struct A { float a, b, c, d; };
> struct B : public X { float a, b, c, d; };
> struct C : public Y { float a
On 27/04/20 17:34 -0400, Patrick Palka via Libstdc++ wrote:
This implements the proposed resolution of LWG 3433, which fixes
subrange::advance when called with a negative argument.
Tested on x86_64-pc-linux-gnu, does this look OK to commit?
libstdc++-v3/ChangeLog:
LWG 3433 subrange::ad
On Mon, 27 Apr 2020 at 22:58, Mike Stump wrote:
>
> On Apr 27, 2020, at 12:43 PM, Christophe Lyon via Gcc-patches
> wrote:
> > It seems it's not possible to write these tests so that they works in
> > all combinations of toolchain configuration and options used for testing :-(
>
> So, generally,
On Tue, 2020-04-28 at 17:51 +0200, Jakub Jelinek wrote:
> Hi!
>
> Untested. If the rs6000+generic change makes it in, is this ok for trunk
> too?
>
> 2020-04-28 Jakub Jelinek
>
> PR target/94706
> * config/ia64/ia64.c (hfa_element_mode): Use DECL_FIELD_ABI_IGNORED
> instead
Hi,
On Thu, 16 Apr 2020 at 09:50, Martin Liška wrote:
>
> On 4/14/20 1:43 PM, Jakub Jelinek wrote:
> > Roughly, yes. A few extra in testcases don't hurt necessarily, but say 160
> > chars or more is clearly too much.
>
> All right, I made a limit of 120 characters for the changes.
>
> Patch can
On 4/28/20 2:38 AM, Richard Sandiford wrote:
> case RTX_BIN_ARITH:
> case RTX_COMM_ARITH:
> op0 = simplify_replace_fn_rtx (XEXP (x, 0), old_rtx, fn, data);
> op1 = simplify_replace_fn_rtx (XEXP (x, 1), old_rtx, fn, data);
> if (op0 == XEXP (x, 0) && op1 == XEXP (x, 1))
>
On 4/28/20 10:42 AM, Jakub Jelinek wrote:
On Tue, Apr 28, 2020 at 10:16:24AM -0500, Bill Schmidt via Gcc-patches wrote:
I think this looks good. My only comment would be to please add some
comments in the test cases about the purpose, or at least to explain
the regexes in the scan-assembler-*
On Tue, Apr 28, 2020 at 05:47:27PM +0200, Richard Biener wrote:
> On April 28, 2020 4:04:58 PM GMT+02:00, Jakub Jelinek via Gcc-patches
> wrote:
> >Hi!
> >
> >On Tue, Apr 28, 2020 at 08:53:31AM -0400, Jason Merrill wrote:
> >> That sounds good.
> >
> >So like this? Or better name for the new mac
> -Original Message-
> From: Szabolcs Nagy
> Sent: 28 April 2020 16:51
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Kyrylo Tkachov
> ; Sudakshina Das
> Subject: [PATCH] aarch64: don't emit bti j after NOTE_INSN_DELETED_LABEL
> [PR94748]
>
> It was previously discussed that in
Hi!
Untested. If the rs6000+generic change makes it in, is this ok for trunk
too?
2020-04-28 Jakub Jelinek
PR target/94706
* config/ia64/ia64.c (hfa_element_mode): Use DECL_FIELD_ABI_IGNORED
instead of cxx17_empty_base_field_p.
--- gcc/config/ia64/ia64.c.jj 2020-04
It was previously discussed that indirect branches cannot go to
NOTE_INSN_DELETED_LABEL so inserting a landing pad is unnecessary.
See https://gcc.gnu.org/pipermail/gcc-patches/2019-May/522625.html
Before the patch a bti j was inserted after the label in
__attribute__((target("branch-protection
On April 28, 2020 4:04:58 PM GMT+02:00, Jakub Jelinek via Gcc-patches
wrote:
>Hi!
>
>On Tue, Apr 28, 2020 at 08:53:31AM -0400, Jason Merrill wrote:
>> That sounds good.
>
>So like this? Or better name for the new macro?
I think you miss a hunk for lto/ to compare the flag for tree merging.
>T
On Tue, Apr 28, 2020 at 04:23:24PM +0200, Andreas Krebbel via Gcc-patches wrote:
> Given that this is something which hasn't been covered by the ABI so far I'm
> not sure we really need
> a -Wpsabi warning for that.
Attached are two (updated) versions of the patch on top of the
powerpc+middle-end
On Tue, Apr 28, 2020 at 10:16:24AM -0500, Bill Schmidt via Gcc-patches wrote:
> I think this looks good. My only comment would be to please add some
> comments in the test cases about the purpose, or at least to explain
> the regexes in the scan-assembler-* directives, to save us all some
> mental
On 4/28/20 6:38 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
Ok, I've tried:
struct X { };
struct Y { int : 0; };
struct Z { int : 0; Y y; };
struct U : public X { X q; };
struct A { float a, b, c, d; };
struct B : public X { float a, b, c, d; };
struct C : public Y { float a, b, c, d; };
struct
Hi all,
Turns out for consistency with LLVM the +nofp option shouldn't remove ALL of FP
and MVE, just the FP part of MVE.
This requires more surgery with feature bits so for GCC 10 I'd rather just not
support +nofp for -mcpu=cortex-m55
and implement it properly for GCC 11.
Committing to trunk.
On Tue, 28 Apr 2020, Jason Merrill wrote:
> On 4/28/20 9:48 AM, Patrick Palka wrote:
> > When printing the substituted parameter list of a requires-expression as
> > part of the "in requirements with ..." context line during concepts
> > diagnostics, we weren't considering that substitution into a
On 4/28/20 10:57 AM, Jakub Jelinek wrote:
Hi!
On Tue, Apr 28, 2020 at 10:18:44AM -0400, Jason Merrill wrote:
I would think it would make sense to set it here:
else if (might_overlap && is_empty_class (type))
layout_empty_base_or_field (rli, field, empty_base_offsets);
That w
Jakub, thanks for continuing to track down and fix all these cases.
I think this looks good. My only comment would be to please add some
comments in the test cases about the purpose, or at least to explain
the regexes in the scan-assembler-* directives, to save us all some
mental cycles in the f
On 4/28/20 10:38 AM, Jakub Jelinek wrote:
On Tue, Apr 28, 2020 at 04:23:24PM +0200, Andreas Krebbel wrote:
Our ABI doesn't specify anything regarding C++ so there is nothing in there
which really conflicts
with that. I assume these things will be part of a cross-platform C++ ABI
instead? I don
Hi Stefan,
I prefer Jakub's suggestion – his change LGTM.
Cheers,
Tobias
On 4/28/20 2:30 PM, Jakub Jelinek via Gcc-patches wrote:
On Tue, Apr 28, 2020 at 01:53:07PM +0200, Stefan Schulze Frielinghaus via
Gcc-patches wrote:
gcc/fortran/ChangeLog:
2020-04-28 Stefan Schulze Frielinghaus
On 4/28/20 9:48 AM, Patrick Palka via Gcc-patches wrote:
When printing the substituted parameter list of a requires-expression as
part of the "in requirements with ..." context line during concepts
diagnostics, we weren't considering that substitution into a parameter
pack can yield zero or multi
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 change looks (even obviously) good to me but strictly speaking
it needs the approval of a
On Tue, Apr 28, 2020 at 4:55 PM Jakub Jelinek wrote:
>
> On Tue, Apr 28, 2020 at 04:48:31PM +0200, Dmitry Vyukov wrote:
> > FWIW this is:
> >
> > Acked-by: Dmitry Vyukov
> >
> > We just landed a similar change to llvm:
> > https://github.com/llvm/llvm-project/commit/5a2c31116f412c3b6888be361137ef
Hi!
On Tue, Apr 28, 2020 at 10:18:44AM -0400, Jason Merrill wrote:
> I would think it would make sense to set it here:
>
> > else if (might_overlap && is_empty_class (type))
> > layout_empty_base_or_field (rli, field, empty_base_offsets);
That works too, plus on the IRC suggested c
On Tue, Apr 28, 2020 at 04:48:31PM +0200, Dmitry Vyukov wrote:
> FWIW this is:
>
> Acked-by: Dmitry Vyukov
>
> We just landed a similar change to llvm:
> https://github.com/llvm/llvm-project/commit/5a2c31116f412c3b6888be361137efd705e05814
>
> Do you have any objections?
I don't have objections
On Thu, Apr 23, 2020 at 5:43 PM Marco Elver wrote:
>
> Add support to optionally emit different instrumentation for accesses to
> volatile variables. While the default TSAN runtime likely will never
> require this feature, other runtimes for different environments that
> have subtly different memo
While looking up C++14 information, I noticed that some links in
current navigation pages refer to cxx1y.html instead of
cxx-status.html. This patch changes the NEWS item to refer to
cxx-status.html#cxx14 and the Projects index to refer to C++ language
features instead of C++14 language features.
On Tue, Apr 28, 2020 at 04:23:24PM +0200, Andreas Krebbel wrote:
> Our ABI doesn't specify anything regarding C++ so there is nothing in there
> which really conflicts
> with that. I assume these things will be part of a cross-platform C++ ABI
> instead? I don't see a way
> to add this to our pla
On 4/28/20 5:12 AM, Manfred Schwarb wrote:
Hi,
first, I do not have commit rights, so please somebody check and commit,
I guess this goes under the obvious and trivial rules.
There are several malformed dejagnu directives in the gcc.dg testsuite.
Below I fixed some of them following these crite
On 4/28/20 9:48 AM, Patrick Palka wrote:
When printing the substituted parameter list of a requires-expression as
part of the "in requirements with ..." context line during concepts
diagnostics, we weren't considering that substitution into a parameter
pack can yield zero or multiple parameters.
On 28.04.20 14:13, Jakub Jelinek wrote:
> Hi!
>
> So, based on the yesterday's discussions, similarly to powerpc64le-linux
> I've done some testing for s390x-linux too.
>
> First of all, I found a bug in my patch from yesterday, it was printing
> the wrong type like 'double' etc. rather than the
On 4/28/20 10:04 AM, Jakub Jelinek wrote:
Hi!
On Tue, Apr 28, 2020 at 08:53:31AM -0400, Jason Merrill wrote:
That sounds good.
So like this? Or better name for the new macro?
The calls.h macro is there only after all the backends are converted
to use ABI_IGNORED_FIELD_P.
Not sure if I shou
On Tue, Apr 28, 2020 at 3:23 PM Jakub Jelinek via Gcc-patches
wrote:
>
> On Tue, Apr 28, 2020 at 01:53:07PM +0200, Stefan Schulze Frielinghaus via
> Gcc-patches wrote:
> > gcc/fortran/ChangeLog:
> >
> > 2020-04-28 Stefan Schulze Frielinghaus
> >
> > PR fortran/94769
> > * io.c
Hi!
On Tue, Apr 28, 2020 at 08:53:31AM -0400, Jason Merrill wrote:
> That sounds good.
So like this? Or better name for the new macro?
The calls.h macro is there only after all the backends are converted
to use ABI_IGNORED_FIELD_P.
Not sure if I shouldn't
if (lookup_attribute ("no_unique_addre
When printing the substituted parameter list of a requires-expression as
part of the "in requirements with ..." context line during concepts
diagnostics, we weren't considering that substitution into a parameter
pack can yield zero or multiple parameters.
Since this patch affects only concepts dia
>From what I can tell -Wanalyzer-use-of-uninitialized-value has not
yet found a true diagnostic in real-world code, and seems to be
particularly susceptible to false positives. These relate to bugs in
the region_model code.
For GCC 10 it seems best to remove this warning, which this patch does.
I
On Tue, Apr 28, 2020 at 12:04 PM Richard Sandiford
wrote:
>
> Matthias Kretz writes:
> > On Dienstag, 28. April 2020 09:21:38 CEST Richard Biener wrote:
> >> On Mon, Apr 27, 2020 at 11:26 PM Matthias Kretz wrote:
> >> > * Why not disable NaN and Inf independently? Inf is just a reciprocal 0.
> >
On Tue, Apr 28, 2020 at 2:44 PM Stefan Schulze Frielinghaus via
Gcc-patches wrote:
>
> While bootstrapping GCC on S/390 the following warning occurs:
>
> gcc/fortran/io.c: In function 'bool gfc_resolve_dt(gfc_code*, gfc_dt*,
> locus*)':
> gcc/fortran/io.c:3857:7: error: 'num' may be used uninitia
On 4/28/20 7:54 AM, Jakub Jelinek wrote:
On Tue, Apr 28, 2020 at 07:44:26AM -0400, Jason Merrill via Gcc-patches wrote:
Or do we have to further check that it
really doesn't contain any fields other than empty classes?
E.g. some of the ABIs pass differently:
struct A {};
struct B { A a; float b,
While working on PR57359 I noticed that a change during GCC 9
development broke a pointer equality check in ref_always_accessed.
The following corrects this - the way LIM works it is enough
to check for store vs. load.
The issue leads to more conditional SMs than necessary.
Bootstrap / regtest
On Tue, Apr 28, 2020 at 01:53:07PM +0200, Stefan Schulze Frielinghaus via
Gcc-patches wrote:
> gcc/fortran/ChangeLog:
>
> 2020-04-28 Stefan Schulze Frielinghaus
>
> PR fortran/94769
> * io.c (check_io_constraints): Initialize local variable num.
> ---
> gcc/fortran/io.c | 2 +
On 4/28/20 2:38 AM, Richard Sandiford wrote:
> I think we should do this in cse_process_notes_1, both to avoid creating
> an invalid MEM in the first place, and so that we handle embedded MEMs
> correctly too.
>
> Also, the (const:P ...) ought to be there even outside of a MEM. E.g. we
> ought to
> -Original Message-
> From: Andre Vieira (lists)
> Sent: 28 April 2020 13:23
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH][GCC-8][Aarch64]: Fix for PR target/9481
>
> Hi,
>
> Backport of PR target/94518: Fix memmodel index in
> aarch64_store_exclusive_pair
>
Hi,
Backport of PR target/94518: Fix memmodel index in
aarch64_store_exclusive_pair
This fixes bootstrap with --enable-checking=yes,rtl for aarch64.
OK for gcc-8?
Cheers,
Andre
gcc/ChangeLog:
2020-04-28 Andre Vieira
PR target/94814
Backport from gcc-9.
2020-04-07 Kyrylo Tka
Hi!
So, based on the yesterday's discussions, similarly to powerpc64le-linux
I've done some testing for s390x-linux too.
First of all, I found a bug in my patch from yesterday, it was printing
the wrong type like 'double' etc. rather than the class that contained such
the element. Fix below.
Fo
While bootstrapping GCC on S/390 the following warning occurs:
gcc/fortran/io.c: In function 'bool gfc_resolve_dt(gfc_code*, gfc_dt*, locus*)':
gcc/fortran/io.c:3857:7: error: 'num' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
3857 | if (num == 0)
|
On Tue, Apr 28, 2020 at 07:44:26AM -0400, Jason Merrill via Gcc-patches wrote:
> > Or do we have to further check that it
> > really doesn't contain any fields other than empty classes?
> > E.g. some of the ABIs pass differently:
> > struct A {};
> > struct B { A a; float b, c, d; };
> > struct C {
On 4/27/20 5:23 PM, Jakub Jelinek wrote:
On Mon, Apr 27, 2020 at 05:11:38PM -0400, Jason Merrill wrote:
struct empty { };
struct X { [[no_unique_address]] empty e; };
and have them be layout compatible, otherwise the attribute is useless
to the standard library.
Why are zero-size fields chang
1 - 100 of 126 matches
Mail list logo
