On Wed, Sep 11, 2019 at 06:44:50AM +0100, Paul Richard Thomas wrote:
> ===
> *** gcc/testsuite/gfortran.dg/dependency_55.f90 (nonexistent)
> --- gcc/testsuite/gfortran.dg/dependency_55.f90 (working copy)
> ***
Hi All,
I nearly committed this patch as 'obvious' but noticed a fair number
of changes in 10-branch in dependency analysis. This is in fact a
10-regression. I'll wait for an OK.
Bootstrapped and regtested on FC30/x86_64 - OK to commit?
Paul
2019-09-11 Paul Thomas
PR fortran/91717
On Mon, 12 Aug 2019, Lewis Hyatt wrote:
> Hello-
>
> The attached patch for libcpp adds support for extended characters (e.g.
> UTF-8)
> in identifiers. A preliminary version of the patch was posted on PR c/67224 as
> Comment 26 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224#c26) and
>
This patchset fixes some latent problems in cmpstrn* patterns for x86,
and introduces cmpmemsi for short fixed-size memcmp.
I've verified that repz cmpsb is not a good choice for memcmp,
performance-wise, so I turned to movbe/bswapped loads and unsigned
compares. Those have performed better than
On 9/10/19 1:51 PM, Bernd Edlinger wrote:
> Hi!
>
> This ICE happens when compiling real_nextafter in real.c.
> CSE sees this:
>
> (insn 179 178 180 11 (set (reg:SI 319)
> (reg/v/f:SI 273 [ rD.73757 ])) "../../gcc-trunk-1/gcc/real.c":120:10
> 643 {*thumb2_movsi_vfp}
> (nil))
>
On 9/6/19 1:27 PM, Martin Sebor wrote:
> Recent enhancements to -Wstringop-overflow improved the warning
> to the point that it detects a superset of the problems -Warray-
> bounds is intended detect in character accesses. Because both
> warnings detect overlapping sets of problems, and because
We were (still) not correctly marking the C++ tree structs. This patch
fixes that and
1) adds MARK_TS_TYPE_NON_COMMON, because we needed it.
2) sorts the order of marking nodes, so it's a little easier to figure
where to put new ones.
3) reformats & sorts the common
On Tue, 10 Sep 2019 at 19:05, Matthew Malcomson
wrote:
>
> Resending because I forgot to avoid the disclaimer and hence my email
> didn't go to the gcc-patches list.
>
>
>
> On 09/09/19 21:55, Prathamesh Kulkarni wrote:
> > On Mon, 9 Sep 2019 at 22:06, Prathamesh Kulkarni
> > wrote:
> >>
> >> On
On 9/10/19 11:18 AM, Marek Polacek wrote:
We started to reject this testcase with r269078, whereby we perform constexpr
evaluation on pre-cp_fold_function bodies. In this test that causes a problem
because the offset argument of a PREINCREMENT_EXPR was a FLOAT_EXPR, and then
the call to
On 9/10/19 1:25 PM, Marek Polacek wrote:
@@ -21870,10 +21873,16 @@ cp_parser_type_id_1 (cp_parser *parser,
cp_parser_flags flags,
/* There might or might not be an abstract declarator. */
cp_parser_parse_tentatively (parser);
+ /* Reset the flags, but remember if we should perform
On Mon, Sep 9, 2019 at 2:00 PM Andreas Schwab wrote:
>
> ../../../libgo/go/golang.org/x/sys/cpu/cpu.go:17:30: error: reference to
> undefined name ‘cacheLineSize’
>17 | type CacheLinePad struct{ _ [cacheLineSize]byte }
> | ^
>
On Mon, Sep 9, 2019 at 1:26 AM Rainer Orth
wrote:
>
> > I've committed a patch to update libgo to the Go 1.13beta1 release.
> > As is usual with these updates, the patch is too large to include
> > here; I've included the diffs of the various GCC-specific configury
> > and other files.
This patch to the mksysinfo script changes from using test == to using
test =. This fixes GCC PR 91621. Bootstrapped and ran Go tests on
x86_64-pc-linux-gnu. Committed to mainline and GCC 9 branch.
Ian
Index: gcc/go/gofrontend/MERGE
This libgo patch fixes the go/internal/gccgoimporter package to
support an embedded field in a pointer loop. This is a backport of
https://golang.org/cl/194440 in the master repository. Original
description:
If an embedded field refers to a type via a pointer, the parser needs
to know
Hi!
This ICE happens when compiling real_nextafter in real.c.
CSE sees this:
(insn 179 178 180 11 (set (reg:SI 319)
(reg/v/f:SI 273 [ rD.73757 ])) "../../gcc-trunk-1/gcc/real.c":120:10
643 {*thumb2_movsi_vfp}
(nil))
[...]
(insn 181 180 182 11 (set (mem:SI (reg:SI 319) [0 MEM
On 9/10/19 10:36 AM, Richard Sandiford wrote:
> After previous patches, it's now possible for call_used_regs to be
> the "real" set of call-clobbered registers, without any special
> handling for fixed registers. This patch therefore removes the
> separate call_really_used_regs and updates the
On 9/10/19 10:34 AM, Richard Sandiford wrote:
> Now that tests of call_used_regs go through call_used_or_fixed_reg_p,
> we can hide call_used_regs from target-independent code. (It still
> needs to be available to targets for the conditional register usage
> hooks.)
>
>
> 2019-09-10 Richard
On 9/10/19 10:33 AM, Richard Sandiford wrote:
> This patch removes redundant fixed_regs tests in things like:
>
> !fixed_regs[i] && !call_used_or_fixed_reg_p (i)
>
>
> 2019-09-10 Richard Sandiford
>
> gcc/
> * config/alpha/alpha.c (alpha_compute_frame_layout): Remove redundant
>
On 9/10/19 10:32 AM, Richard Sandiford wrote:
> Similarly to the call_used_or_fixed_regs patch, this one replaces
> tests of call_used_regs[i] with call_used_or_fixed_reg_p (i).
> The only remaining direct uses of call_used_regs are in reginfo.c
> and in the conditional register usage hooks.
>
>
On 9/10/19 10:31 AM, Richard Sandiford wrote:
> This cleans up a couple of places in which the previous patch had:
>
> call_used_or_fixed_regs & ~fixed_reg_set
>
> In that context, regs_invalidated_by_call is IMO more obvious.
>
>
> 2019-09-10 Richard Sandiford
>
> gcc/
> *
On 9/10/19 10:31 AM, Richard Sandiford wrote:
> CALL_USED_REGISTERS and call_used_regs infamously contain all fixed
> registers (hence the need for CALL_REALLY_USED_REGISTERS etc.).
> We try to recover from this to some extent with:
>
> /* Contains 1 for registers that are set or clobbered by
On 9/10/19 10:30 AM, Richard Sandiford wrote:
> Reusing the reasoning from the call_fixed_reg_set patch:
>
> for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
> for (j = 1; j <= MOVE_MAX_WORDS; j++)
> if (reg_save_code (i,regno_save_mode[i][j]) == -1)
>
> should be true whenever
On 9/10/19 10:29 AM, Richard Sandiford wrote:
> On targets that use reload, call_fixed_reg_set is structurally:
>
> fixed_reg_set -- reginfo.c
> | (call_used_reg_set & ~have_save_mode) -- first loop in init_caller_save
> | ~have_save_insn --
On Mon, Sep 09, 2019 at 04:56:18PM -0400, Jason Merrill wrote:
> On 9/7/19 3:37 PM, Marek Polacek wrote:
> > * parser.c (CP_PARSER_FLAGS_NO_DELAY_NOEXCEPT): New parser flag.
>
> Is it feasible to reverse this, and specifically delay parsing of
> noexcept-specifications on member function
On 9/10/19 10:27 AM, Richard Sandiford wrote:
> I have a series of patches that hides call_used_regs from target-
> independent code, a knock-on effect of which is that (public) target
> macros can't use call_used_regs either. This patch fixes the only
> case in which that was a problem.
>
>
>
This patch cleans up some struct fields that are unused in the GCN plugin
(leftover from the HSA plugin) that I noticed when working on debugging
other problems.
Tested with offloading to AMD GCN. I will apply to the
openacc-gcc-9-branch shortly.
Thanks,
Julian
ChangeLog
gcc/
This patch fixes a typo in the GOMP_OFFLOAD_openacc_async_host2dev
function that bypassed the temporary buffer used to hold source data
for asynchronous host-to-device copies.
Tested with offloading to AMD GCN. I will apply to the
openacc-gcc-9-branch shortly.
Thanks,
Julian
ChangeLog
This patch replaces the implementation of the
GOMP_OFFLOAD_openacc_async_serialize plugin entry point for AMD GCN
to use a genuinely-asynchronous scheme, rather than the previous
host-synchronous approach.
Also included are fixes for the data-2-lib.c and data-2.c libgomp C/C++
tests, which had
On Tue, Sep 10, 2019 at 05:46:14PM +0100, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > On Tue, Sep 10, 2019 at 06:14:11PM +0200, Martin Liška wrote:
> >> On 9/9/19 11:14 PM, Joseph Myers wrote:
> >> > On Mon, 9 Sep 2019, Jakub Jelinek wrote:
> >> >
> >> > > > "IgnoreWarn" reads as
On Tue, Sep 10, 2019 at 05:46:14PM +0100, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > On Tue, Sep 10, 2019 at 06:14:11PM +0200, Martin Liška wrote:
> >> On 9/9/19 11:14 PM, Joseph Myers wrote:
> >> > On Mon, 9 Sep 2019, Jakub Jelinek wrote:
> >> >
> >> > > > "IgnoreWarn" reads as
Jakub Jelinek writes:
> On Tue, Sep 10, 2019 at 06:14:11PM +0200, Martin Liška wrote:
>> On 9/9/19 11:14 PM, Joseph Myers wrote:
>> > On Mon, 9 Sep 2019, Jakub Jelinek wrote:
>> >
>> > > > "IgnoreWarn" reads as "ignore the warning".
>> > > >
>> > > > If we want it named as two things, can we
The aarch64_vector_pcs handling in aarch64_hard_regno_call_part_clobbered
checks whether the mode might be bigger than 16 bytes, since on SVE
targets the (non-SVE) vector PCS only guarantees that the low 16 bytes
are preserved. But for multi-register modes, we should instead test
whether each
After previous patches, it's now possible for call_used_regs to be
the "real" set of call-clobbered registers, without any special
handling for fixed registers. This patch therefore removes the
separate call_really_used_regs and updates the targets that define
CALL_REALLY_USED_REGISTERS so that
Now that tests of call_used_regs go through call_used_or_fixed_reg_p,
we can hide call_used_regs from target-independent code. (It still
needs to be available to targets for the conditional register usage
hooks.)
2019-09-10 Richard Sandiford
gcc/
* hard-reg-set.h (call_used_regs):
This patch removes redundant fixed_regs tests in things like:
!fixed_regs[i] && !call_used_or_fixed_reg_p (i)
2019-09-10 Richard Sandiford
gcc/
* config/alpha/alpha.c (alpha_compute_frame_layout): Remove redundant
fixed_regs test.
* config/bpf/bpf.c
Similarly to the call_used_or_fixed_regs patch, this one replaces
tests of call_used_regs[i] with call_used_or_fixed_reg_p (i).
The only remaining direct uses of call_used_regs are in reginfo.c
and in the conditional register usage hooks.
Again, this is purely mechanical. A later patch will
This cleans up a couple of places in which the previous patch had:
call_used_or_fixed_regs & ~fixed_reg_set
In that context, regs_invalidated_by_call is IMO more obvious.
2019-09-10 Richard Sandiford
gcc/
* config/frv/frv.c (frv_ifcvt_modify_tests): Use
CALL_USED_REGISTERS and call_used_regs infamously contain all fixed
registers (hence the need for CALL_REALLY_USED_REGISTERS etc.).
We try to recover from this to some extent with:
/* Contains 1 for registers that are set or clobbered by calls. */
/* ??? Ideally, this would be just
Reusing the reasoning from the call_fixed_reg_set patch:
for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
for (j = 1; j <= MOVE_MAX_WORDS; j++)
if (reg_save_code (i,regno_save_mode[i][j]) == -1)
should be true whenever regno_save_mode[i][j] == VOIDmode,
which it is for:
* include/std/type_traits (__do_common_type_impl): Implement
additional COND-RES(CREF(D1), CRED(D2)) condition for C++20.
(basic_common_reference, common_reference, common_reference_t): Define
for C++20.
*
On targets that use reload, call_fixed_reg_set is structurally:
fixed_reg_set -- reginfo.c
| (call_used_reg_set & ~have_save_mode) -- first loop in init_caller_save
| ~have_save_insn -- final loop in init_caller_save
(where "have_save_mode"
I have a series of patches that hides call_used_regs from target-
independent code, a knock-on effect of which is that (public) target
macros can't use call_used_regs either. This patch fixes the only
case in which that was a problem.
2019-09-10 Richard Sandiford
gcc/
*
This series is another step towards supporting multiple ABIs in the
same translation unit. It reduces the amount of global state that
depends on the call-clobbered/call-preserved split, and also tries to
deal with the historic decision to make call_used_regs strictly include
all fixed registers,
Only one caller (in dwarf2out.c) was preventing get_call_rtx_from
from taking an rtx_insn *. Since that caller just passes a PATTERN,
it's a trivial change to make.
Tested on aarch64-linux-gnu and x86_64-linux-gnu, applied as obvious.
Richard
2019-09-10 Richard Sandiford
gcc/
*
We started to reject this testcase with r269078, whereby we perform constexpr
evaluation on pre-cp_fold_function bodies. In this test that causes a problem
because the offset argument of a PREINCREMENT_EXPR was a FLOAT_EXPR, and then
the call to fold_build2 doesn't produce a REAL_CST and
On Tue, Sep 10, 2019 at 06:14:11PM +0200, Martin Liška wrote:
> On 9/9/19 11:14 PM, Joseph Myers wrote:
> > On Mon, 9 Sep 2019, Jakub Jelinek wrote:
> >
> > > > "IgnoreWarn" reads as "ignore the warning".
> > > >
> > > > If we want it named as two things, can we just make it two things?
> > > >
On 9/9/19 11:14 PM, Joseph Myers wrote:
On Mon, 9 Sep 2019, Jakub Jelinek wrote:
"IgnoreWarn" reads as "ignore the warning".
If we want it named as two things, can we just make it two things?
"Ignore WarnDeleted" or something. Which also says what it is warning
about.
Or WarnRemoved. Both
On 9/10/19 1:36 AM, Uros Bizjak wrote:
> On Mon, Sep 9, 2019 at 8:44 PM Jeff Law wrote:
>>
>> On 9/4/19 12:16 PM, Rafael Tsuha wrote:
>>> Hi, Jeff
>>>
>>> Em seg, 29 de abr de 2019 às 18:22, Jeff Law escreveu:
On 1/22/19 12:31 PM, Rafael Tsuha wrote:
> This patch simplifies the
Committed to OG9 on behalf of Kwok ...
The list of struct gomp_threads allocated in gomp_gcn_enter_kernel was
not being freed in gomp_gcn_exit_kernel, leading to a small memory leak
every time a kernel is run. Runs with a lot of teams or many kernels
were running out of heap space.
Andrew
This patch improves out-of-the-box benchmark results by ensuring that we
don't launch 64 gangs on a device that only has 60 compute units, such
as consumer Vega 20.
It's not suitable for upstream mainline yet because we need to update
hsa.h with definitions from Radeon Open Compute Runtime
Resending because I forgot to avoid the disclaimer and hence my email
didn't go to the gcc-patches list.
On 09/09/19 21:55, Prathamesh Kulkarni wrote:
> On Mon, 9 Sep 2019 at 22:06, Prathamesh Kulkarni
> wrote:
>>
>> On Mon, 9 Sep 2019 at 16:45, Richard Sandiford
>> wrote:
>>>
>>>
>>> Thanks
Hi all,
This is a minor patch that fixes the entry for the fp16fml feature in
GCC's aarch64-option-extensions.def.
As can be seen in the Linux sources here
https://github.com/torvalds/linux/blob/master/arch/arm64/kernel/cpuinfo.c#L69
the correct string is "asimdfhm", not "asimdfml".
Prathamesh Kulkarni writes:
> On Mon, 9 Sep 2019 at 22:06, Prathamesh Kulkarni
> wrote:
>>
>> On Mon, 9 Sep 2019 at 16:45, Richard Sandiford
>> wrote:
>> >
>> > Prathamesh Kulkarni writes:
>> > > With patch, the only following FAIL remains for aarch64-sve.exp:
>> > > FAIL:
Dear gcc-patches@gcc.gnu.org,
lsFSοme7YvhL9one logged in to 7668yοurlsF AρρIe ID lsFFrοmwGmkx5GFZE a diffrent
lsFlοcatіοn country and IP address :
Date and Time : 9/10/2019 11:34:20 AM
22872Brο7YvhL9wserwGmkx5GFZE
Hi Tom,
this is a completely new implementation of an earlier optimization
that Cesar submitted:
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01202.html
The objective is to transform the original single-record-pointer argument
form (OpenMP/pthreads originated) to multiple scalar parameters,
This patches adjusts the "granulated sgpr count" kernel settings for
GFX9 devices.
I followed the description I found here:
http://llvm.org/docs/AMDGPUUsage.html
Basically, GFX9 allocates in blocks of 16, not 8, so there was some
danger of requesting too many registers, which would hurt
(some quick comments, I didn't check in details)
+(and:c (code1 @0 INTEGER_CST@1) (code2 @0 INTEGER_CST@2))
[...]
+ (if (code1 == NE_EXPR && !val) (code2 @0 @2
How about
(and:c (code1 @0 INTEGER_CST@1) (code2@3 @0 INTEGER_CST@2))
[...]
(if (code1 == NE_EXPR && !val) @3)))
This patches fixes a bug in which the relocations would not get fixed up
if the same kernel was loaded to more than one device.
There was a race condition if the loads occurred in parallel, but
basically the first device would get loaded correctly, and the second
would get no relocations at all.
On 10/09/2019 12:17, Arnaud Charlet wrote:
It seems there's a problem with this patch:
/snapshots/gcc.git~master/gcc/doc/install.texi:2730: @ref reference to
nonexistent node `GNAT-prerequisite'
Makefile:3300: recipe for target
> > > It seems there's a problem with this patch:
> > > /snapshots/gcc.git~master/gcc/doc/install.texi:2730: @ref reference to
> > > nonexistent node `GNAT-prerequisite'
> > > Makefile:3300: recipe for target
> > >
On Mon, 2019-09-09 at 19:05 +0100, Richard Sandiford wrote:
>
> Yeah. I might come back to this later and look at a fuller
> transition
> to C++ (or at least to try to get rid of CLEAR_HARD_REG_SET).
>
Maybe you can just typedef it to std::bitset ;)
Cheers,
Oleg
The standard requires overloads of std::to_chars for char and (un)signed
integer types. This means that our constrained function template is
non-conforming, because the difference is observable when using types
that convert to an integer (e.g. wchar_t, which promotes).
As well as defining the
On 9 September 2019 15:41:05 CEST, "Martin Liška" wrote:
>On 9/9/19 2:24 PM, Martin Liška wrote:
>> Hi.
>>
>> The patch is about transition of and_comparisons_1 matching
>> into match.pd.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression
>tests.
>>
>> Ready to be installed?
On September 10, 2019 9:45:28 AM GMT+02:00, Jakub Jelinek
wrote:
>Hi!
>
>The following patch optimizes (A / (cast) (1 << B)) -> (A >> B)
>in addition to already supported (A / (1 << B)) -> (A >> B).
>
>The patch only supports same precision cast (i.e. a sign change),
>or widening cast, in that
Hi!
The following patch optimizes (A / (cast) (1 << B)) -> (A >> B)
in addition to already supported (A / (1 << B)) -> (A >> B).
The patch only supports same precision cast (i.e. a sign change),
or widening cast, in that case either zero extension (then the extended
value is known to be a power
On 9/9/19 3:41 PM, Martin Liška wrote:
On 9/9/19 2:24 PM, Martin Liška wrote:
Hi.
The patch is about transition of and_comparisons_1 matching
into match.pd.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
Updated version (as
On 9/9/19 3:55 PM, Richard Biener wrote:
On Mon, 9 Sep 2019, Martin Liška wrote:
On 9/9/19 3:42 PM, Richard Biener wrote:
There is no newly created GIMPLE?
Hm, I thought from the beginning that maybe_fold_comparisons_from_match_pd
can come up with new temporary expressions that need to be
On Mon, Sep 9, 2019 at 8:44 PM Jeff Law wrote:
>
> On 9/4/19 12:16 PM, Rafael Tsuha wrote:
> > Hi, Jeff
> >
> > Em seg, 29 de abr de 2019 às 18:22, Jeff Law escreveu:
> >>
> >> On 1/22/19 12:31 PM, Rafael Tsuha wrote:
> >>> This patch simplifies the expression sinh (x) / cosh (x) to tanh (x).
>
PR libstdc++/91711
* testsuite/23_containers/span/get_neg.cc: Avoid ambiguity due to
0ul being a valid null pointer constant.
Tested x86-linux, committed to trunk.
commit 7c30df0f9caea5ad48484bc72a984c09fc6513fa
Author: Jonathan Wakely
Date: Mon Sep 9 22:31:26 2019
Define partial specializations for std::remove_cv so that
std::remove_const and std::remove_volatile don't need to be
instantiated.
* include/std/type_traits (__remove_cv_t): New alias template.
(is_void, is_integral, is_floating_point, is_pointer)
70 matches
Mail list logo
