Here's two approaches to fix the regression in 89689. Note this only
fixes the regression in the originally reported testcase. THe deeper
issue Martin raises in C#1 is not addressed. Thus if we go forward
with either patch ISTM that we would drop the regression markers, but
keep the BZ open.
S
On 1/23/20 8:07 AM, Pétur Orri Ragnarsson wrote:
> Hi.
>
> I ran into a problem with fixincludes when building GCC. Your email is
> in the README file.
>
>
> When building a crosscompiling GCC 8.3.0 for powerpc the following "fix"
> is applied:
>
> $ diff /opt/pluto-targets/powerpc-rootfs/u
On 1/25/20 9:34 AM, John David Anglin wrote:
> +/*
> + * Fix missing SCNuMAX defines in inttypes.h
> + */
> +fix = {
> +hackname = hpux_c99_inttypes4;
> +mach = "hppa*-hp-hpux11.[01]*";
> +files = inttypes.h;
> +sed = "/^[ \t]*#[ \t]*define[ \t]*SCNxMAX[ \t]*SCNx64/a
> From: Segher Boessenkool
> Date: Mon, 27 Jan 2020 23:52:21 +0100
> Hi!
>
> On Wed, Jan 22, 2020 at 07:11:27AM +0100, Hans-Peter Nilsson wrote:
> > I intend to put back as many as I find use for, of those
> > anonymous patterns in a controlled manner, with self-contained
> > test-cases proving
Hi Tobias,
On Tuesday, January 28, 2020 6:49:54 PM PST Tobias Burnus wrote:
> Thus, I do not think it is a real problem in practice. We could be nice,
> however, and add a note to the release notes (i.e.
> https://gcc.gnu.org/gcc-10/changes.html); I not completely sure whether
> it is worthwhile b
algorithms: zlib
gcc version 10.0.1 20200128 (experimental) (GCC)
$ gfortran -c test.F90 -o test.o
f951: internal compiler error: Segmentation fault
0xe1bc9f crash_signal
../../gcc-git/gcc/toplev.c:328
0x7f98119c71ef ???
/data001/abenson/Galacticus/Tools/glibc-2.12.1/signal
This PR points out an ICE with an alias template and class NTTP, but I
found that there are more issues. Trouble arise when we use a
(non-type) template parameter as an argument to the template arg list of
a template that accepts a class NTTP and a conversion to a class is
involved, e.g.
struct
On Tue, Jan 28, 2020 at 10:43:24AM +, Richard Sandiford wrote:
> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
> OK to install?
Yes, thank you.
Segher
> 2020-01-28 Richard Sandiford
>
> gcc/testsuite/
> PR testsuite/93393
> * gcc.dg/torture/pr9313
On Thu, 2019-10-17 at 16:14 +0300, Alexander Monakov wrote:
> On Tue, 8 Oct 2019, Alexander Monakov wrote:
>
> [massive snip]
>
> > So in my opinion our CFG is good enough, the real issues with -Wclobbered
> > false
> > positives are not due to phi nodes but other effects.
> >
> > If you agree:
On Tue, 2019-10-08 at 18:04 +0300, Alexander Monakov wrote:
> On Thu, 3 Oct 2019, Jeff Law wrote:
>
> > You may want to review the 2018 discussion:
> >
> > https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg185287.html
> >
> > THe 2018 discussion was primarily concerned with fixing the CFG
Done in r10-6309-g4dd27b527c503aa50909fe1eb7d308266b1e103a.
Martin
A return statement in a discarded statement is not used for return type
deduction, but we still want to do deduction for a return statement in a
lambda in a discarded statement.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/93442
* parser.c (cp_parser_lambda_expression): C
My patch for PR 91476 worked for decls that are implicitly comdat/weak due
to C++ linkage rules, but broke variables explicitly marked weak.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/93477
PR c++/91476
* decl2.c (copy_linkage): Do copy DECL_ONE_ONLY and DECL_WE
Comments 11-16 within PR analyzer/93316 discuss an ICE in some setjmp
tests seen on AIX and powerpc-darwin9.
The issue turned out to be an implicit assumption that longjmp is
marked "noreturn". There are two places in engine.cc where the code
attempted to locate the longjmp GIMPLE_CALL by finding
While looking at Pr93458, I spotted the following non-fatal, but
unhelpful diagnostic output.
If the user's coroutine return type omits the mandatory promise
type then we will currently restate that error each time we see
a coroutine keyword, which doesn't provide any new information.
This suppre
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272
The patch was successfully tested and bootstrapped on x86_64.
Unfortunately it is hard to create a test case for the patch. So there
is no test for this PR.
commit 5c8a1211b9873a1b69ef7b2fddae181535bc3b0a (HEAD ->
Hi,
I will try to reming this next stage1 since it is not regression fix.
I found it useful to have bit of sanity checking of the topn profiles to
work out the bugs in merging and updating that was there.
Honza
gcc/ChangeLog:
2020-01-28 Jan Hubicka
* profile.c (compute_value_histogra
Hi,
I comitted this ias obvious. I also wonder if the next error should be
info or should be part of the first error message.
* coverage.c (read_counts_file): Make error message lowercase.
diff --git a/gcc/coverage.c b/gcc/coverage.c
index 5e961b26f66..f29ff640c43 100644
--- a/gcc/covera
Hi,
this patch fixes dump of quality. Comitted as obvious.
* profile-count.h (profile_quality_display_names): Fix ordering.
diff --git a/gcc/profile-count.c b/gcc/profile-count.c
index 0c792297826..c89914ff8a0 100644
--- a/gcc/profile-count.c
+++ b/gcc/profile-count.c
@@ -78,9 +78,9 @@ co
When I implemented the [over.match.ref] rule that a reference conversion
function needs to match l/rvalue of the target reference type it changed our
handling of this testcase. It seems to me that our current behavior is what
the standard says, but it doesn't seem desirable, and all the other
comp
Hi,
This patch started as work to resole Richard's comment on quadratic lookups
in resolve_speculation. While doing it I however noticed multiple problems
in the new speuclative call code which made the patch quite big. In
particular:
1) Before applying speculation we consider only targets with a
On Tue, Jan 28, 2020 at 10:58 AM Jakub Jelinek wrote:
>
> On Tue, Jan 28, 2020 at 10:20:36AM -0800, H.J. Lu wrote:
> > From 66c534dedc7a9a632aa38c32e3f7c251b8f2c778 Mon Sep 17 00:00:00 2001
> > From: "H.J. Lu"
> > Date: Mon, 27 Jan 2020 09:35:11 -0800
> > Subject: [PATCH] i386: Prefer TARGET_AVX
On Tue, Jan 28, 2020 at 10:20:36AM -0800, H.J. Lu wrote:
> From 66c534dedc7a9a632aa38c32e3f7c251b8f2c778 Mon Sep 17 00:00:00 2001
> From: "H.J. Lu"
> Date: Mon, 27 Jan 2020 09:35:11 -0800
> Subject: [PATCH] i386: Prefer TARGET_AVX over TARGET_SSE_TYPELESS_STORES
>
> movaps/movups is one byte shor
On Tue, 2020-01-28 at 16:34 +0100, Jakub Jelinek wrote:
> On Tue, Jan 28, 2020 at 10:30:58AM -0500, David Malcolm wrote:
> > gcc/analyzer/ChangeLog:
> > * region-model.cc (poisoned_value_diagnostic::emit): Update for
> > renaming of warning_at overload to warning_meta.
> > * sm-file.cc
On Tue, Jan 28, 2020 at 10:04 AM Uros Bizjak wrote:
>
> On Tue, Jan 28, 2020 at 6:51 PM H.J. Lu wrote:
> >
> > On Tue, Jan 28, 2020 at 9:12 AM Uros Bizjak wrote:
> > >
> > > On Tue, Jan 28, 2020 at 4:34 PM H.J. Lu wrote:
> > >
> > > > > You could move
> > > > >
> > > > > (match_test "TARGET_AVX
Hi Tobias,
Thanks - committed as
https://gcc.gnu.org/git/gitweb.cgi?
p=gcc.git;a=commit;h=ad690d79cfbb905c5546c9333c5fd089d906505b
I'll send a separate email about changes to the release notes.
-Andrew
On Tuesday, January 28, 2020 6:49:54 PM PST Tobias Burnus wrote:
> Hi Andrew,
>
> On 1/28/
Thanks - committed as a83b5cc5828ee34471de415e8893242dd3b0a91b
https://gcc.gnu.org/git/gitweb.cgi?
p=gcc.git;a=commit;h=a83b5cc5828ee34471de415e8893242dd3b0a91b
I'll close the PR.
Thanks,
Andrew
On Tuesday, January 28, 2020 6:32:21 PM PST Tobias Burnus wrote:
> LGTM now.
>
> Thanks,
>
> Tobi
On Tue, Jan 28, 2020 at 6:51 PM H.J. Lu wrote:
>
> On Tue, Jan 28, 2020 at 9:12 AM Uros Bizjak wrote:
> >
> > On Tue, Jan 28, 2020 at 4:34 PM H.J. Lu wrote:
> >
> > > > You could move
> > > >
> > > > (match_test "TARGET_AVX")
> > > > (const_string "TI")
> > > >
> > > > up to bypass the cases b
On Tue, Jan 28, 2020 at 9:12 AM Uros Bizjak wrote:
>
> On Tue, Jan 28, 2020 at 4:34 PM H.J. Lu wrote:
>
> > > You could move
> > >
> > > (match_test "TARGET_AVX")
> > > (const_string "TI")
> > >
> > > up to bypass the cases below.
> > >
> >
> > I don't think we can do that. There are 2 cases
Hi Andrew,
On 1/28/20 5:41 PM, Andrew Benson wrote:
Can you also update the comment before the #define? It currently has:
Thanks for the suggestion. An updated patch is attached.
Thanks. LGTM now.
PS: I wonder whether there are relevant systems which will fail because they
do not handle that
On Tue, 28 Jan 2020, Uecker, Martin wrote:
> Unfortunately, this is not as simple. It is not trivial to
> define the set of objects whose "address could have participated
> in the computation"
> [...]
I am not satisfied with the response, but I'm not sure I should
continue arguing here.
Alexande
LGTM now.
Thanks,
Tobias
On 1/28/20 5:41 PM, Andrew Benson wrote:
On Tuesday, January 28, 2020 9:27:58 AM PST Tobias Burnus wrote:
On 1/28/20 12:41 AM, Andrew Benson wrote:
The problem occurs in set_syms_host_assoc() where the "parent1" and
"parent2" variables have a maximum length of GFC_MA
On Mon, Jan 27, 2020 at 06:53:51PM +0100, Jakub Jelinek wrote:
> On Mon, Jan 27, 2020 at 06:49:23PM +0100, Stefan Schulze Frielinghaus wrote:
> > some function calls trigger the stack-protector-strong although such
> > calls are later on implemented via calls to internal functions.
> > Consider the
On Tue, Jan 28, 2020 at 4:34 PM H.J. Lu wrote:
> > You could move
> >
> > (match_test "TARGET_AVX")
> > (const_string "TI")
> >
> > up to bypass the cases below.
> >
>
> I don't think we can do that. There are 2 cases where we prefer
> movaps/movups:
>
> /* Use packed single precision instru
This patch fixes an ICE compiling fast-math-pr55281.c for amdgcn.
The problem is that an "iv" is created in which both base and step are
pointer types, but the base is converted to sizetype without also
converting the step to a non-pointer type. Later in the compilation this
results in a PLUS_
Ping.
From: Delia Burduv
Sent: 22 January 2020 17:31
To: gcc-patches@gcc.gnu.org
Cc: ni...@redhat.com ; Richard Earnshaw
; Kyrylo Tkachov ; Ramana
Radhakrishnan
Subject: Re: ACLE intrinsics: BFloat16 load intrinsics for AArch32
Ping.
I will change the tests t
Ping.
From: Delia Burduv
Sent: 22 January 2020 17:29
To: gcc-patches@gcc.gnu.org
Cc: ni...@redhat.com ; Richard Earnshaw
; Kyrylo Tkachov ; Ramana
Radhakrishnan
Subject: Re: ACLE intrinsics: BFloat16 store (vst{q}_bf16) intrinsics for
AArch32
Ping.
I will ch
Ping.
From: Delia Burduv
Sent: 22 January 2020 17:26
To: gcc-patches@gcc.gnu.org
Cc: ni...@redhat.com ; Richard Earnshaw
; Ramana Radhakrishnan
; Kyrylo Tkachov
Subject: Re: [GCC][PATCH][AArch32] ACLE intrinsics bfloat16 vmmla and vfma
for AArch32 AdvSIMD
Pin
Hi Tobias,
> > The problem occurs because GFC_MAX_MANGLED_SYMBOL_LEN is set to
> > GFC_MAX_SYMBOL_LEN*2+4, which is sufficient for a module name plus
> > function name (plus the additional "_"'s that get prepended), but
> > insufficient if a submodule name is included. The name then gets
> > trunc
On Tuesday, January 28, 2020 9:27:58 AM PST Tobias Burnus wrote:
> On 1/28/20 12:41 AM, Andrew Benson wrote:
> > The problem occurs in set_syms_host_assoc() where the "parent1" and
> > "parent2" variables have a maximum length of GFC_MAX_SYMBOL_LEN+1. This
> > is insufficient when the parent names
On 24/01/2020 14:58, Andrew Stubbs wrote:
I've committed this patch to fix an ICE building the
gcc.dg/vect/fast-math-pr55281.c testcase.
Oops, I got that crossed. This was the fix for gcc.dg/pr50310-2.c. The
fast-math-pr55281.c fix will be posted shortly.
The problem was that the combine pas
Hi,
Since coroutine-ness is discovered lazily, we encounter the diagnostics
during each keyword parse. We were not handling the case where a user code
failed to include fundamental information (e.g. the traits) in a graceful
manner (nor tolerating that level of fail for subsequent diagnostics).
The clever hack of '#define __has_include __has_include' breaks -dD
and -fdirectives-only, because that emits definitions. This turns
__has_include into a proper builtin macro. Thus it's never emitted
via -dD, and because use outside of directive processing is undefined,
we can just expand it an
On Tue, 2020-01-28 at 11:13 +0100, Jakub Jelinek wrote:
> On Fri, Jan 24, 2020 at 07:53:28PM -0500, David Malcolm wrote:
> > This patch fixes various build failures seen with gcc 4.4
> >
> > gcc prior to 4.6 complains about:
> >
> > error: #pragma GCC diagnostic not allowed inside functions
> >
On 28/01/2020 14:55, Harwath, Frederik wrote:
Hi,
this patch adds full support for the OpenACC 2.6 acc_get_property and
acc_get_property_string functions to the libgomp GCN plugin. This replaces
the existing stub in libgomp/plugin-gcn.c.
Andrew: The value returned for acc_property_memory ("size
On Tue, Jan 28, 2020 at 10:30:58AM -0500, David Malcolm wrote:
> gcc/analyzer/ChangeLog:
> * region-model.cc (poisoned_value_diagnostic::emit): Update for
> renaming of warning_at overload to warning_meta.
> * sm-file.cc (file_leak::emit): Likewise.
> * sm-malloc.cc (double_
On Tue, Jan 28, 2020 at 6:45 AM Uros Bizjak wrote:
>
> On Tue, Jan 28, 2020 at 3:32 PM H.J. Lu wrote:
> >
> > On Mon, Jan 27, 2020 at 11:04 PM Uros Bizjak wrote:
> > >
> > > On Mon, Jan 27, 2020 at 11:17 PM H.J. Lu wrote:
> > > >
> > > > On Mon, Jan 27, 2020 at 12:26 PM Uros Bizjak wrote:
> >
On Tue, 2020-01-28 at 15:36 +0100, Jakub Jelinek wrote:
> On Tue, Jan 28, 2020 at 09:30:17AM -0500, David Malcolm wrote:
> > * diagnostic-core.h (warning_at): Rename overload to...
> > (warning_with_metadata_at): ...this.
>
> I think this is just too long, especially for a function used at
On 22/01/20 15:39 +, Andrew Burgess wrote:
The motivation behind this change is to make it easier for a user to
link against static libraries on a target where dynamic libraries are
the default library type (for example GNU/Linux).
Further, my motivation is really for linking libraries into
On 1/28/20 4:30 AM, Joel Hutton wrote:
On 28/01/2020 09:07, Eric Botcazou wrote:
Ping! Eric, do you have any objections to reverting?
See my comment posted in the audit trail of the TN on 01/20...
Probably missing live range splitting or somesuch, as envisioned by
Vladimir in its approval messa
Hi,
this patch adds full support for the OpenACC 2.6 acc_get_property and
acc_get_property_string functions to the libgomp GCN plugin. This replaces
the existing stub in libgomp/plugin-gcn.c.
Andrew: The value returned for acc_property_memory ("size of device memory in
bytes"
according to the spe
We just need to handle the exception specification like other properties of
a function typedef.
Tested x86_64-pc-linux-gnu, applying to trunk/9.
PR c++/90731
* decl.c (grokdeclarator): Propagate eh spec from typedef.
---
gcc/cp/decl.c| 1 +
gcc/tes
On Tue, Jan 28, 2020 at 3:32 PM H.J. Lu wrote:
>
> On Mon, Jan 27, 2020 at 11:04 PM Uros Bizjak wrote:
> >
> > On Mon, Jan 27, 2020 at 11:17 PM H.J. Lu wrote:
> > >
> > > On Mon, Jan 27, 2020 at 12:26 PM Uros Bizjak wrote:
> > > >
> > > > On Mon, Jan 27, 2020 at 7:23 PM H.J. Lu wrote:
> > > >
On Tue, Jan 28, 2020 at 09:30:17AM -0500, David Malcolm wrote:
> * diagnostic-core.h (warning_at): Rename overload to...
> (warning_with_metadata_at): ...this.
I think this is just too long, especially for a function used at least
in the analyzer pretty often, leading to lots of ugly f
On Mon, Jan 27, 2020 at 11:04 PM Uros Bizjak wrote:
>
> On Mon, Jan 27, 2020 at 11:17 PM H.J. Lu wrote:
> >
> > On Mon, Jan 27, 2020 at 12:26 PM Uros Bizjak wrote:
> > >
> > > On Mon, Jan 27, 2020 at 7:23 PM H.J. Lu wrote:
> > > >
> > > > movaps/movups is one byte shorter than movdaq/movdqu. B
On Tue, 2020-01-28 at 11:16 +0100, Jakub Jelinek wrote:
> On Wed, Dec 18, 2019 at 07:08:25PM -0500, David Malcolm wrote:
> > This patch adds support for associating a diagnostic message with
> > an
> > optional diagnostic_metadata object, so that plugins can add extra
> > data
> > to their diagnost
On Fri, 24 Jan 2020 10:58:49 +0100
Tobias Burnus wrote:
> Hi Julian,
>
> the gfortran part is rather obvious and it and the test case look
> fine to me → OK.
> The oacc-mem.c also looks okay, but I assume Thomas needs to
> rubber-stamp it.
I understand that Thomas is unavailable for the time b
PR libstdc++/93470
* include/bits/refwrap.h (reference_wrapper::operator()): Restrict
static assertion to object types.
Tested powerpc64le-linux and verified with Clang.
Committed to master. Backport to gcc-9-branch needed too.
commit 72a9fd209b6db3b5f81fbb008e22ea93c0046
It's wrong to assume that clock_gettime is unavailable on any *-*-linux*
target that doesn't have glibc 2.17 or later. Use a generic test instead
of using __GLIBC_PREREQ. Only do that test when is_hosted=yes so that we
don't get an error for cross targets without a working linker.
This ensures tha
On Tue, Jan 28, 2020 at 10:42:16AM +0100, Richard Biener wrote:
> On Mon, Jan 27, 2020 at 10:47 PM Segher Boessenkool
> wrote:
> > On Tue, Jan 21, 2020 at 02:10:21PM +, Wilco Dijkstra wrote:
> > > While code hoisting generally improves codesize, it can affect performance
> > > negatively. Benc
Autopar was doing clique bookkeeping too early when creating destination
functions but then later introducing new cliques via versioning loops.
The following moves the bookkeeping to the actual outlining process.
Bootstrapped & tested on x86_64-unknown-linux-gnu, pushed.
Richard.
2020-01-28 Ric
Am Dienstag, den 28.01.2020, 11:01 +0100 schrieb Richard Biener:
> On Tue, Jan 28, 2020 at 8:20 AM Alexander Monakov wrote:
> >
> > On Tue, 28 Jan 2020, Uecker, Martin wrote:
> >
> > > > (*) this also shows the level of "obfuscation" needed to fool compilers
> > > > to lose provenance knowledge
Hi!
On Mon, Jan 27, 2020 at 04:28:29PM +, Wilco Dijkstra wrote:
> > On Thu, Jan 16, 2020 at 12:50:14PM +, Wilco Dijkstra wrote:
> >> The separate shrinkwrapping pass may insert stores in the middle
> >> of atomics loops which can cause issues on some implementations.
> >> Avoid this by del
Am Dienstag, den 28.01.2020, 10:20 +0300 schrieb Alexander Monakov:
> On Tue, 28 Jan 2020, Uecker, Martin wrote:
>
> > > (*) this also shows the level of "obfuscation" needed to fool compilers
> > > to lose provenance knowledge is hard to predict.
> >
> > Well, this is exactly the problem we want
On Tue, Jan 28, 2020 at 05:09:36PM +0530, Prathamesh Kulkarni wrote:
> On Tue, 28 Jan 2020 at 17:00, Jakub Jelinek wrote:
> >
> > On Tue, Jan 28, 2020 at 04:56:59PM +0530, Prathamesh Kulkarni wrote:
> > > Thanks for the suggestions. In the attached patch I bumped up value of
> > > ERF_RETURNS_ARG_
On Tue, Nov 26, 2019 at 3:18 PM Wilco Dijkstra wrote:
>
> Hi,
>
> While code hoisting generally improves codesize, it can affect performance
> negatively. Benchmarking shows it doesn't help SPEC and negatively affects
> embedded benchmarks. Since the impact is relatively small with -O2 and mainly
On Fri, Jan 24, 2020 at 7:04 AM Prathamesh Kulkarni
wrote:
>
> On Mon, 20 Jan 2020 at 15:44, Richard Biener
> wrote:
> >
> > On Wed, Jan 8, 2020 at 11:20 AM Prathamesh Kulkarni
> > wrote:
> > >
> > > On Tue, 5 Nov 2019 at 17:38, Richard Biener
> > > wrote:
> > > >
> > > > On Tue, Nov 5, 2019
On Tue, 28 Jan 2020 at 17:00, Jakub Jelinek wrote:
>
> On Tue, Jan 28, 2020 at 04:56:59PM +0530, Prathamesh Kulkarni wrote:
> > Thanks for the suggestions. In the attached patch I bumped up value of
> > ERF_RETURNS_ARG_MASK
> > to UINT_MAX >> 2, and use highest two bits for ERF_NOALIAS and
> > ER
On Tue, Jan 28, 2020 at 04:56:59PM +0530, Prathamesh Kulkarni wrote:
> Thanks for the suggestions. In the attached patch I bumped up value of
> ERF_RETURNS_ARG_MASK
> to UINT_MAX >> 2, and use highest two bits for ERF_NOALIAS and
> ERF_RETURNS_ARG.
> And use fn spec "Z" to store the argument numbe
On Mon, 27 Jan 2020 at 17:36, Richard Biener wrote:
>
> On Fri, Jan 24, 2020 at 11:53 PM Joseph Myers wrote:
> >
> > On Fri, 24 Jan 2020, Prathamesh Kulkarni wrote:
> >
> > > The middle-end representation issue of ERF_RETURNS_ARG still remains,
> > > which restricts the attribute till first four
Jeff Law writes:
> On Mon, 2020-01-27 at 16:41 +, Richard Sandiford wrote:
>> In the gcc.target/aarch64/lsl_asr_sbfiz.c part of this PR, we have:
>>
>> Failed to match this instruction:
>> (set (reg:SI 95)
>> (ashift:SI (subreg:SI (sign_extract:DI (subreg:DI (reg:SI 97) 0)
>>
(This was a GCC 10 regression, affecting both OpenMP and OpenACC.)
In gfc_omp_check_optional_argument:
DECL_LANG_SPECIFIC is always available (check at the top). However, if
decl is not a PARM_DECL, it can have two reasons: Either it is no
parameter (C sense; Fortran: dummy argument) at all or
Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
OK to install?
Richard
2020-01-28 Richard Sandiford
gcc/testsuite/
PR testsuite/93393
* gcc.dg/torture/pr93133.c: XFAIL for powerpc*-*-*.
---
gcc/testsuite/gcc.dg/torture/pr93133.c | 2 +-
1 file change
Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
Pushed as obvious.
Richard
2020-01-28 Richard Sandiford
gcc/testsuite/
PR testsuite/93460
* gcc.dg/torture/pr93170.c: Add -Wpsabi.
---
gcc/testsuite/gcc.dg/torture/pr93170.c | 1 +
1 file changed, 1 ins
Hi Stam,
On 1/8/20 3:18 PM, Stam Markianos-Wright wrote:
On 12/10/19 5:03 PM, Kyrill Tkachov wrote:
Hi Stam,
On 11/15/19 5:26 PM, Stam Markianos-Wright wrote:
Pinging with more correct maintainers this time :)
Also would need to backport to gcc7,8,9, but need to get this approved
first!
S
Hi Andrew,
Andrew Burgess wrote:
* Jeff Law [2020-01-22 13:52:27 -0700]:
On Wed, 2020-01-22 at 15:39 +, Andrew Burgess wrote:
The motivation behind this change is to make it easier for a user to
link against static libraries on a target where dynamic libraries are
the default library t
On Wed, Dec 18, 2019 at 07:08:25PM -0500, David Malcolm wrote:
> This patch adds support for associating a diagnostic message with an
> optional diagnostic_metadata object, so that plugins can add extra data
> to their diagnostics (e.g. mapping a diagnostic to a taxonomy or coding
> standard such a
On Fri, Jan 24, 2020 at 07:53:28PM -0500, David Malcolm wrote:
> This patch fixes various build failures seen with gcc 4.4
>
> gcc prior to 4.6 complains about:
>
> error: #pragma GCC diagnostic not allowed inside functions
>
> for various uses of PUSH_IGNORE_WFORMAT and POP_IGNORE_WFORMAT.
>
On Tue, Jan 28, 2020 at 10:49 AM Richard Sandiford
wrote:
>
> Richard Sandiford writes:
> > predcom has the following code to stop one rogue load from
> > interfering with other store-load opportunities:
> >
> > /* If A is read and B write or vice versa and there is unsuitable
> >de
On Tue, Jan 28, 2020 at 8:20 AM Alexander Monakov wrote:
>
> On Tue, 28 Jan 2020, Uecker, Martin wrote:
>
> > > (*) this also shows the level of "obfuscation" needed to fool compilers
> > > to lose provenance knowledge is hard to predict.
> >
> > Well, this is exactly the problem we want to addres
Most items in the @menu do not end with a period; all of them do not end
with one when used as @section. Hence, it make sense to unify the style
to w/o tailing '.'.
Committed.
Tobias
commit 4593f60558474983c79cbbdedc31b4c19e63b671
Author: Tobias Burnus
Date: Tue Jan 28 10:58:00 2020 +0100
Richard Sandiford writes:
> predcom has the following code to stop one rogue load from
> interfering with other store-load opportunities:
>
> /* If A is read and B write or vice versa and there is unsuitable
>dependence, instead of merging both components into a component
>th
On Mon, Jan 27, 2020 at 10:47 PM Segher Boessenkool
wrote:
>
> Hi!
>
> On Tue, Jan 21, 2020 at 02:10:21PM +, Wilco Dijkstra wrote:
> > While code hoisting generally improves codesize, it can affect performance
> > negatively. Benchmarking shows it doesn't help SPEC and negatively affects
> > e
predcom has the following code to stop one rogue load from
interfering with other store-load opportunities:
/* If A is read and B write or vice versa and there is unsuitable
dependence, instead of merging both components into a component
that will certainly not pass suitabl
On 28/01/2020 09:07, Eric Botcazou wrote:
>> Ping! Eric, do you have any objections to reverting?
>
> See my comment posted in the audit trail of the TN on 01/20...
> Probably missing live range splitting or somesuch, as envisioned by
> Vladimir in its approval message. Feel free to eventually re
Hi.
It's a simple documentation fix.
I'm going to install the patch.
Martin
libstdc++-v3/ChangeLog:
2020-01-28 Martin Liska
PR libstdc++/93478
* include/std/atomic: Fix typo.
* include/std/optional: Likewise.
---
libstdc++-v3/include/std/atomic | 2 +-
libstdc++-
> Ping! Eric, do you have any objections to reverting?
See my comment posted in the audit trail of the TN on 01/20...
--
Eric Botcazou
*PING*
Those two patches bump the OpenACC version number from 2.0 (alias
201306) to OpenACC 2.6 (alias 201711). I believe except for bugs and
known omissions (e.g. PR93225+93226), the OpenACC 2.6 support is complete.
Additionally, it updates the documentation accordingly, no longer marks
Ope
(CC: fortran@ as it relates to Fortran.)
Hi all,
On 1/7/20 12:16 PM, Tobias Burnus wrote:
in terms of the check, it looks fine to me – but I am not sure about
the spec.
* [OpenACC] Actually, I simply missed the bit (here: OpenACC 3; OpenACC
2.6 is same): “Any array or subarray in a data clau
On Mon, 27 Jan 2020, Richard Sandiford wrote:
> For the 2s failures in the PR, we have a V4SF VEC_PERM_EXPR in
> which the first two elements are duplicates of one element and
> the other two are don't-care:
>
> v4sf_b = VEC_PERM_EXPR ;
>
> The heuristic was to extend this with a blend:
>
>
On 1/28/20 12:41 AM, Andrew Benson wrote:
The problem occurs in set_syms_host_assoc() where the "parent1" and "parent2"
variables have a maximum length of GFC_MAX_SYMBOL_LEN+1. This is insufficient
when the parent names are a module+submodule name concatenated with a ".". The
patch above fixes th
Hi Andrew,
On 1/27/20 9:57 PM, Andrew Benson wrote:
The problem occurs because GFC_MAX_MANGLED_SYMBOL_LEN is set to
GFC_MAX_SYMBOL_LEN*2+4, which is sufficient for a module name plus function name
(plus the additional "_"'s that get prepended), but insufficient if a submodule
name is included. T
92 matches
Mail list logo
