On Tue, 28 Apr 2020, Xionghu Luo wrote:
> From: Xionghu Luo
>
> Get and propagate value range info to convert expressions with convert
> operation on PLUS_EXPR/MINUS_EXPR/MULT_EXPR when not overflow. i.e.:
>
> (long unsigned int)((unsigned int)n * 10 + 1)
> =>
> (long unsigned int)((unsigned
Ensure that CF does not equal NULL in function output_stack_usage_1
before calling fprintf. This fixes the following warning/error:
gcc/toplev.c:976:13: error: argument 1 null where non-null expected
[-Werror=nonnull]
976 | fprintf (cf, "\\n" HOST_WIDE_INT_PRINT_DEC " bytes (%s)",
|
Hi,
Gentle ping for this patch.
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543701.html
BR,
Kewen
on 2020/4/10 下午5:28, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> This is one fix following Richi's comments here:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542232.html
>
> I
In function handle_vector_size_attribute local variable nunits is
supposed to be initialized by function type_valid_for_vector_size.
However, in case ARGS is null the function may return with a non-null
value and leave nunits uninitialized. This results in warning/error:
gcc/poly-int.h: In functi
On Mon, Apr 27, 2020 at 11:26 PM Matthias Kretz wrote:
>
> On Montag, 27. April 2020 21:39:17 CEST Richard Sandiford wrote:
> > "Dr. Matthias Kretz" writes:
> > > On Montag, 27. April 2020 18:59:08 CEST Richard Sandiford wrote:
> > >> Richard Biener via Gcc-patches writes:
> > >> > On Mon, Apr 2
On Fri, Apr 10, 2020 at 11:28 AM Kewen.Lin wrote:
>
> Hi,
>
> This is one fix following Richi's comments here:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542232.html
>
> I noticed the current half vector support for no peeling gaps
> handled some cases which never check the half size v
Peter Bergner writes:
> 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 like below without
> a (const:DI ...) wrapped
On Tue, Apr 28, 2020 at 08:54:42AM +0200, Richard Biener wrote:
> > @@ -1311,7 +1311,7 @@ (define_operator_list COND_TERNARY
> > We combine the above two cases by using a conditional convert. */
> > (for bitop (bit_and bit_ior bit_xor)
> > (simplify
> > - (bitop (convert @0) (convert? @1))
Hi!
On the following testcase, match.pd during GENERIC folding
changes the -1U / x < y into __imag__ .MUL_OVERFLOW (x, y),
but unfortunately unlike for normal calls nothing sets TREE_SIDE_EFFECTS on
the call. There is the process_call_operands function that non-internal
call creation calls and it
On Dienstag, 28. April 2020 09:21:38 CEST Richard Biener wrote:
> On Mon, Apr 27, 2020 at 11:26 PM Matthias Kretz wrote:
> > On Montag, 27. April 2020 21:39:17 CEST Richard Sandiford wrote:
> > > "Dr. Matthias Kretz" writes:
> > > > On Montag, 27. April 2020 18:59:08 CEST Richard Sandiford wrote:
While bootstrapping GCC on S/390 the following warning/error is raised:
gcc/var-tracking.c:10239:34: error: 'pre' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
10239 | VTI (bb)->out.stack_adjust += pre;
| ^
The lines of inte
Hi Anton,
> -Original Message-
> From: Anton Youdkevitch
> Sent: 27 April 2020 18:21
> To: Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw
> ; James Greenhalgh
> ; Richard Sandiford
> ; jjo...@marvell.com
> Subject: Re: [PATCH v5] aarch64: Add TX3 machine model
>
> On Mon
On 28.4.2020 12:02 , Kyrylo Tkachov wrote:
Hi Anton,
-Original Message-
From: Anton Youdkevitch
Sent: 27 April 2020 18:21
To: Kyrylo Tkachov
Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw
; James Greenhalgh
; Richard Sandiford
; jjo...@marvell.com
Subject: Re: [PATCH v5] aarch64: Add T
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 criteria:
- fix mis-typed directives
- require tha
Stefan Schulze Frielinghaus via Gcc-patches writes:
> While bootstrapping GCC on S/390 the following warning/error is raised:
>
> gcc/var-tracking.c:10239:34: error: 'pre' may be used uninitialized in this
> function [-Werror=maybe-uninitialized]
> 10239 | VTI (bb)->out.stack_adjust += pre;
On Tue, 28 Apr 2020, Jakub Jelinek wrote:
> On Tue, Apr 28, 2020 at 08:54:42AM +0200, Richard Biener wrote:
> > > @@ -1311,7 +1311,7 @@ (define_operator_list COND_TERNARY
> > > We combine the above two cases by using a conditional convert. */
> > > (for bitop (bit_and bit_ior bit_xor)
> > >
On Tue, 28 Apr 2020, Jakub Jelinek wrote:
> Hi!
>
> On the following testcase, match.pd during GENERIC folding
> changes the -1U / x < y into __imag__ .MUL_OVERFLOW (x, y),
> but unfortunately unlike for normal calls nothing sets TREE_SIDE_EFFECTS on
> the call. There is the process_call_operand
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.
> However, in case ARGS is null the function may return with a non-null
> v
On Tue, Apr 28, 2020 at 10:15 AM Matthias Kretz wrote:
>
> On Dienstag, 28. April 2020 09:21:38 CEST Richard Biener wrote:
> > On Mon, Apr 27, 2020 at 11:26 PM Matthias Kretz wrote:
> > > On Montag, 27. April 2020 21:39:17 CEST Richard Sandiford wrote:
> > > > "Dr. Matthias Kretz" writes:
> > >
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 uninitialized in this
> function [-Werror=maybe-uninitialized]
> 10239 |
On 24 April 2020 11:59:50 CEST, Alexandre Oliva wrote:
>On Apr 23, 2020, Martin Sebor wrote:
>
>> Sure. I'd go with _fileio but that's just a suggestion.
>
>Okiedokie, here's the patch using fileio instead of tmpnam for the
>effective target name. I'm going to check it in shortly.
>
>
>introduc
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.
>> > Inf is as far away from numeric_limits::max as 0 is from
>> > numer
On 2020/4/28 15:01, Richard Biener wrote:
> On Tue, 28 Apr 2020, Xionghu Luo wrote:
>
>> From: Xionghu Luo
>>
>> Get and propagate value range info to convert expressions with convert
>> operation on PLUS_EXPR/MINUS_EXPR/MULT_EXPR when not overflow. i.e.:
>>
>> (long unsigned int)((unsigned
Hi Matthew,
> -Original Message-
> From: Matthew Malcomson
> Sent: 27 April 2020 16:32
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; ni...@redhat.com; Richard Earnshaw
> ; Ramana Radhakrishnan
> ; Kyrylo Tkachov
> ; ja...@redhat.com
> Subject: [Arm] Account for C++17 artificial field determini
On Tue, 28 Apr 2020, luoxhu wrote:
>
>
> On 2020/4/28 15:01, Richard Biener wrote:
> > On Tue, 28 Apr 2020, Xionghu Luo wrote:
> >
> >> From: Xionghu Luo
> >>
> >> Get and propagate value range info to convert expressions with convert
> >> operation on PLUS_EXPR/MINUS_EXPR/MULT_EXPR when not o
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 D : public Z { float a, b, c, d; };
struct E : public U {
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
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 {
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)
|
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
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
> -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
>
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
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 +
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 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,
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 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.
> >
>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
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
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
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
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 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 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 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 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
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 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
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
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 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
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 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
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 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
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: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
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
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 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
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 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 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
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
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
> -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
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
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 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))
>
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 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
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 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
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 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
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
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 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
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
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, 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
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
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
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!
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 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.
>
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
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 (
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
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/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 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 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, 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/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, 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 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
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
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
1 - 100 of 126 matches
Mail list logo
