Hi!
>From
>https://www.reddit.com/r/cpp/comments/dtuov8/201911_belfast_iso_c_committee_trip_report/
I understood P1946R0 made it into C++20, so here is my attempt at
implementing it, you had most of it implemented anyway because
in system headers
friend constexpr bool
operator==(partial_o
Hi.
The patch makes debug counter more usable. In particular, one can now
list multiple closed intervals and -fdbg-cnt-list can reflect that.
Based on the discussion with Richard, I decided to leave semi-closed
intervals and make it closed, it's more intuitive.
Example:
$ g++ -O2 tramp3d-v4.ii
Hi.
The small patch is about sorting of debug counter
values.
Ready to be installed?
Thanks,
Martin
>From f9e1387c8e03d73d00d701fa9754af850424215f Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Mon, 11 Nov 2019 09:03:24 +0100
Subject: [PATCH] Sort debug counter names.
gcc/ChangeLog:
2019-1
On November 9, 2019 8:47:52 PM GMT+01:00, Janne Blomqvist
wrote:
>Bump the minimum MPFR version to 3.1.0, released 2011-10-03. With this
>requirement one can still build GCC with the operating system provided
>MPFR on old but still supported operating systems like SLES 12 (MPFR
>3.1.2) or RHEL/Ce
Hi!
On 2019-10-25T20:48:58+, Joseph Myers wrote:
> This patch is OK.
Thanks. See attached; as posted, committed to trunk in r278035,
gcc-9-branch in r278036, gcc-8-branch in r278037, gcc-7-branch omitted as
that one's frozen for the final release, and this fix isn't important
enough.
Grüß
Hi!
On 2019-10-16T18:52:55+0200, Jakub Jelinek wrote:
> On Wed, Oct 16, 2019 at 03:22:52PM +0200, Thomas Schwinge wrote:
>> Stumbled over this while reviewing Julian's "Factor out duplicate code in
>> gimplify_scan_omp_clauses":
>
>> ..., which here gets writte to...
>>
>> > +
Hi!
On 2019-05-29T09:50:42-0600, Jeff Law wrote:
> On 5/29/19 8:32 AM, Thomas Schwinge wrote:
>> On Thu, 9 May 2019 15:46:06 +0300, Ilya Verbin wrote:
>>> I have left Intel 3 years ago. If you have any questions regarding MIC
>>> offloading, you can reach me by iver...@gmail.com
>>
>> We're (a)
Hi!
On 2019-10-31T18:09:28+0100, Tobias Burnus wrote:
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.fortran/use_device_addr-3.f90
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.fortran/use_device_addr-4.f90
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.fortran/use_device_ptr-1.f90
A
Hi!
On 2019-10-30T16:48:43+0100, Tobias Burnus wrote:
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.fortran/target9.f90
As obvious; see attached, committed "Torture testing:
'libgomp.fortran/target9.f90'" to trunk in r278045.
Grüße
Thomas
From d462cbc6c489949752b4d652abec30dbb95c2855 Mo
Hi Richard,
On 11/9/19 12:44 PM, Richard Henderson wrote:
On 11/7/19 11:26 AM, Kyrill Tkachov wrote:
-;; The code sequence emitted by this insn pattern uses the Q flag, which GCC
-;; doesn't generally know about, so we don't bother expanding to individual
-;; instructions. It may be better to
Hi Tobias!
By the way, do you know what's the status is for Fortran common blocks in
OpenMP: supported vs. expected per the specification?
On 2019-10-25T16:36:10+0200, Tobias Burnus wrote:
> On 10/25/19 10:43 AM, Thomas Schwinge wrote:
>> Or, would it be easy to add an OpenACC 'kernels' test ca
Ping
Richard Sandiford writes:
> Richard Biener writes:
>> On Fri, Oct 25, 2019 at 2:37 PM Richard Sandiford
>> wrote:
>>>
>>> This is another patch in the series to remove the assumption that
>>> all modes involved in vectorisation have to be the same size.
>>> Rather than have the target prov
Hi José,
On 10/29/19 11:35 AM, José Rui Faustino de Sousa wrote:
Added the suggested check and a few touches to comments and the error
message.
Thanks.
that might be a bug in the C code of the test itself
I took a look and although there are problems with the code of the
test I do not think t
On Fri, 8 Nov 2019 at 09:57, Richard Biener wrote:
>
>
> I've been sitting on this for a few days since I'm not 100% happy
> with how the code looks like. There's possibly still holes in it
> (chains with mixed signed/unsigned adds for example might pick
> up signed adds in the epilogue), but the
On 8 November 2019 17:57:51 CET, Martin Sebor wrote:
>On 11/6/19 2:06 PM, Martin Sebor wrote:
>> On 11/6/19 1:39 PM, Jeff Law wrote:
>>> On 11/6/19 1:27 PM, Martin Sebor wrote:
On 11/6/19 11:55 AM, Jeff Law wrote:
> On 11/6/19 11:00 AM, Martin Sebor wrote:
>> The -Wstringop-overflow w
Hi Eric
On 08/11/2019 19:16, Eric Botcazou wrote:
>> I was fiddling around with the loop unrolling pass and noticed a check
>> in decide_unroll_* functions (in the patch). The comment on top of this
>> check says
>> "/* If we were not asked to unroll this loop, just return back silently.
>>*/"
Hi Alan,
On Mon, Nov 11, 2019 at 05:46:01PM +1030, Alan Modra wrote:
> On Wed, Aug 21, 2019 at 09:55:28PM +0930, Alan Modra wrote:
> > On Mon, Aug 19, 2019 at 07:45:19AM -0500, Segher Boessenkool wrote:
> > > But if you think we can remove the !TARGET_TLS_MARKERS everywhere it
> > > is relevant at
Only ubsan is supported so far. This has been tested on openSUSE
Tumbleweed, there are no testsuite failures.
* configure.tgt (riscv64-*-linux*): Enable build.
---
libsanitizer/configure.tgt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libsanitizer/configure.tgt b/libsanitizer/c
Hi Frederik!
On 2019-11-07T10:52:13+0100, Frederik Harwath wrote:
> this patch implements the OpenACC 2.6 "serial" construct.
Thanks for taking on that one.
> It has been tested by running the testsuite with nvptx-none
> offloading on x86_64-pc-linux-gnu.
This is OK for trunk with the attached
On Wed, Aug 21, 2019 at 09:55:28PM +0930, Alan Modra wrote:
> This patch removes !TARGET_TLS_MARKERS support. -mtls-markers (and
> -mno-tls-markers) disappear as valid options too, because I figure
> they haven't been used too much except by people testing the
> compiler.
Okay.
> (rs6000_c
> From: Gerald Pfeifer
> Date: Sun, 10 Nov 2019 14:53:23 +0100
> Hi H-P,
>
> it appears this download is gone. Do you have an alternate location?
Wha...? No, not at the moment.
>http://ftp.axis.se/pub/users/hp/pgccfd/";>
While I could certainly enter a ticket and hope to get it
reinstate
Hi Tobias!
Thanks for looking into this mess ;-) of Fortran optional arguments
support for OMP, based on what Kwok has already developed.
On 2019-11-08T16:41:23+0100, Tobias Burnus wrote:
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.fortran/use_device_ptr-optional-2.f90
When adding '{ dg-
Hi!
On Mon, Nov 11, 2019 at 03:40:51PM +0800, Kewen.Lin wrote:
> This is a subsequent patch to refactor the existing float point
> vector comparison operator supports. The patch to fix PR92132
> supplemented vector float point comparison by exposing the names
> for unordered/ordered/uneq/ltgt and
On Mon, Nov 11, 2019 at 05:56:47AM -0600, Segher Boessenkool wrote:
> On Wed, Aug 21, 2019 at 09:55:28PM +0930, Alan Modra wrote:
> > This patch removes !TARGET_TLS_MARKERS support. -mtls-markers (and
> > -mno-tls-markers) disappear as valid options too, because I figure
> > they haven't been used
Committed. With a one line GIT log at the top. ;-)
Gerald
2019-11-11 Gerald Pfeifer
* doc/xml/gnu/gpl-3.0.xml: Adjust link to "Why not LGPL".
Index: doc/xml/gnu/gpl-3.0.xml
===
--- doc/xml/gnu/gpl-3.0.xml (revision
On Mon, 11 Nov 2019, Christophe Lyon wrote:
> On Fri, 8 Nov 2019 at 09:57, Richard Biener wrote:
> >
> >
> > I've been sitting on this for a few days since I'm not 100% happy
> > with how the code looks like. There's possibly still holes in it
> > (chains with mixed signed/unsigned adds for exam
On Fri, Nov 8, 2019 at 5:21 PM Richard Sandiford
wrote:
>
> This PR was caused by the SLP handling in get_group_load_store_type
> returning VMAT_CONTIGUOUS rather than VMAT_CONTIGUOUS_REVERSE for
> downward groups.
>
> A more elaborate fix would be to try to combine the reverse permutation
> into
Unfortunately ISO_Fortran_binding_16.f90 contains a typo resulting in:
FAIL: gfortran.dg/ISO_Fortran_binding_16.f90 -O0 (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_16.f90 -O1 (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_16.f90 -O2 (test for excess err
There's one more refactoring patch that is about more
usage of SET_OPTION_IF_UNSET for parameters.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
>From 638a27f03c7ce06bcc02d7c5d27ba6eb794abede Mon Sep 17 00:00:00 2001
From: Martin Lis
Hi.
Current lto-dump.o relies on some FE generated files as
pre-requirement. That hover delays LTO linking of the lto-dump
and so that I adjusted the dependency to LTO_OBJS which will
work as well.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Tha
On Fri, Nov 8, 2019 at 1:41 PM Martin Jambor wrote:
>
> Hi,
>
> this patch is an attempt to implement my idea from a previous thread
> about moving -Wmaybe-uninitialized to -Wextra:
>
> https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00220.html
>
> Specifically, it attempts to split -Wmaybe-uninitia
On Mon, Nov 11, 2019 at 9:17 AM Martin Liška wrote:
>
> Hi.
>
> The patch makes debug counter more usable. In particular, one can now
> list multiple closed intervals and -fdbg-cnt-list can reflect that.
> Based on the discussion with Richard, I decided to leave semi-closed
> intervals and make it
On Mon, Nov 11, 2019 at 9:23 AM Martin Liška wrote:
>
> Hi.
>
> The small patch is about sorting of debug counter
> values.
>
> Ready to be installed?
OK
> Thanks,
> Martin
On Mon, Nov 11, 2019 at 3:06 PM Martin Liška wrote:
>
> Hi.
>
> Current lto-dump.o relies on some FE generated files as
> pre-requirement. That hover delays LTO linking of the lto-dump
> and so that I adjusted the dependency to LTO_OBJS which will
> work as well.
>
> Patch can bootstrap on x86_64-
On 11/7/19 7:37 PM, Matthew Malcomson wrote:
+@item @samp{bootstrap-hwasan}
+Compiles GCC itself using HWAddress Sanitization in order to catch invalid
+memory accesses within the GCC code. This option is only available on AArch64
+targets with a very recent linux kernel (5.4 or later).
+
Appa
On Wed, Oct 30, 2019 at 4:58 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Fri, Oct 25, 2019 at 2:37 PM Richard Sandiford
> > wrote:
> >>
> >> This is another patch in the series to remove the assumption that
> >> all modes involved in vectorisation have to be the same size.
> >>
On 11/11/19 3:19 PM, Richard Biener wrote:
On Mon, Nov 11, 2019 at 9:17 AM Martin Liška wrote:
Hi.
The patch makes debug counter more usable. In particular, one can now
list multiple closed intervals and -fdbg-cnt-list can reflect that.
Based on the discussion with Richard, I decided to leave
On Thu, Nov 7, 2019 at 1:35 PM Martin Liska wrote:
>
>
> gcc/ChangeLog:
I think I've noticed at least one long line (please double-check):
- if (tree_to_uhwi (t) < (unsigned HOST_WIDE_INT)
INTEGER_SHARE_LIMIT)
+ if (tree_to_uhwi (t) < (unsigned HOST_WIDE_INT)
param_intege
On 11/7/19 12:52 PM, Andreas Krebbel wrote:
> +; Such patterns get directly emitted by noce_emit_store_flag.
> +(define_insn_and_split "*cstorecc_z13"
> + [(set (match_operand:GPR 0 "register_operand""=&d")
> + (match_operator:GPR 1 "s390_comparison"
> +
Hi,
Fix ARC specific tests by improving the matching pattern and adding
the missing functionality in arc.exp
OK to appy?
Claudiu
gcc/tests
-xx-xx Claudiu Zissulescu
* gcc.target/arc/add_n-combine.c: Match add1/2/3 instruction in
output assembly.
* gcc.target/arc
On Thu, Nov 7, 2019 at 1:33 PM Martin Liska wrote:
>
> The email thread is follow up of a demo that I made here:
> https://gcc.gnu.org/ml/gcc-patches/2019-10/msg02220.html
>
> The patchset converts current param infrastructure to
> the option machinery. The parts 3 and 4 are quite
> mechanical.
>
> Thanks for the explanation. However, I do not understand why are we
> returning with the default value.
The regression you reported should be clear enough though: if we don't do
that, we will unroll in cases where we would not have before. Try with a
compiler that predates the pragma and com
On Mon, Nov 11, 2019 at 3:33 PM Martin Liška wrote:
>
> On 11/11/19 3:19 PM, Richard Biener wrote:
> > On Mon, Nov 11, 2019 at 9:17 AM Martin Liška wrote:
> >>
> >> Hi.
> >>
> >> The patch makes debug counter more usable. In particular, one can now
> >> list multiple closed intervals and -fdbg-cn
Hi,
On Mon, Nov 11 2019, Richard Biener wrote:
> On Fri, Nov 8, 2019 at 1:41 PM Martin Jambor wrote:
>>
>> Hi,
>>
>> this patch is an attempt to implement my idea from a previous thread
>> about moving -Wmaybe-uninitialized to -Wextra:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00220.ht
On 11/11/19 3:19 PM, Richard Biener wrote:
-static unsigned int limit_low[debug_counter_number_of_counters];
+static auto_vec
*limits[debug_counter_number_of_counters] = {NULL};
Hm, apparently it's not working. I see a stack corruption when calling
dbgcnt. I also explicitly called .create (2) f
On 11.11.19 15:39, Richard Henderson wrote:
> On 11/7/19 12:52 PM, Andreas Krebbel wrote:
>> +; Such patterns get directly emitted by noce_emit_store_flag.
>> +(define_insn_and_split "*cstorecc_z13"
>> + [(set (match_operand:GPR 0 "register_operand""=&d")
>> +(match_operator:G
On 11/11/19 4:03 PM, Andreas Krebbel wrote:
> On 11.11.19 15:39, Richard Henderson wrote:
>> On 11/7/19 12:52 PM, Andreas Krebbel wrote:
>>> +; Such patterns get directly emitted by noce_emit_store_flag.
>>> +(define_insn_and_split "*cstorecc_z13"
>>> + [(set (match_operand:GPR 0 "register_operan
On 11/11/19 3:50 PM, Richard Biener wrote:
On Mon, Nov 11, 2019 at 3:33 PM Martin Liška wrote:
On 11/11/19 3:19 PM, Richard Biener wrote:
On Mon, Nov 11, 2019 at 9:17 AM Martin Liška wrote:
Hi.
The patch makes debug counter more usable. In particular, one can now
list multiple closed inte
Add a setting for the dynamic loader to find the shared libgcc_s library
in build-tree testing, fixing a catastrophic libgo testsuite failure in
cross-compilation where the library cannot be found by the loader at run
time and consequently no test case executes, producing output (here with
the
On 11/11/19 4:30 AM, Bernhard Reutner-Fischer wrote:
On 8 November 2019 17:57:51 CET, Martin Sebor wrote:
On 11/6/19 2:06 PM, Martin Sebor wrote:
On 11/6/19 1:39 PM, Jeff Law wrote:
On 11/6/19 1:27 PM, Martin Sebor wrote:
On 11/6/19 11:55 AM, Jeff Law wrote:
On 11/6/19 11:00 AM, Martin Sebo
On 11/11/19 2:58 PM, Mark Eggleston wrote:
Unfortunately ISO_Fortran_binding_16.f90 contains a typo resulting in:
the cause is that it refers to ISO_Fortran_binding_15.c instead of
ISO_Fortran_binding_16.c in the dg-additional-sources directive.
I was sure that I tested it and committed the r
On 11/11/2019 14:30, Martin Liška wrote:
> On 11/7/19 7:37 PM, Matthew Malcomson wrote:
>> +@item @samp{bootstrap-hwasan}
>> +Compiles GCC itself using HWAddress Sanitization in order to catch
>> invalid
>> +memory accesses within the GCC code. This option is only available
>> on AArch64
>> +tar
On 07/11/2019 18:37, Matthew Malcomson wrote:
> I have rebased this series onto Martin Liska's patches that take the most
> recent libhwasan from upstream LLVM.
> https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00340.html
>
> I've also cleared up some nomenclature (I had previously used the word
>
On 11/11/2019 16:13, Matthew Malcomson wrote:
> On 07/11/2019 18:37, Matthew Malcomson wrote:
>> I have rebased this series onto Martin Liska's patches that take the most
>> recent libhwasan from upstream LLVM.
>> https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00340.html
>>
>> I've also cleared up s
On 11/8/19 5:41 AM, Martin Jambor wrote:
Hi,
this patch is an attempt to implement my idea from a previous thread
about moving -Wmaybe-uninitialized to -Wextra:
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00220.html
Specifically, it attempts to split -Wmaybe-uninitialized into those that
are
Hi,
On Mon, Nov 11 2019, Martin Sebor wrote:
> On 11/8/19 5:41 AM, Martin Jambor wrote:
>> Hi,
>>
>> this patch is an attempt to implement my idea from a previous thread
>> about moving -Wmaybe-uninitialized to -Wextra:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00220.html
>>
>> Specif
On 11/11/2019 14:50, Eric Botcazou wrote:
>> Thanks for the explanation. However, I do not understand why are we
>> returning with the default value.
>
> The regression you reported should be clear enough though: if we don't do
> that, we will unroll in cases where we would not have before. Try w
Hi,
After during my investigation into the first testcase in PR92347 I
noticed that the ICE was arising because the vectorizer was under the
assumption it knew how to vectorize the zp call for both the main and
epilogues. By the time it got to transform the epilogue
vectorizable_simd_clone_c
Fix a problem with the libffi testsuite using a method to determine the
compiler to use resulting in the tool being different from one the
library has been built with, and causing a catastrophic failure from the
inability to actually choose any compiler at all in a cross-compilation
configuratio
Fix a problem with the libgomp testsuite using a method to determine
the compiler to use resulting in the tool being different from one the
library has been built with, and causing a catastrophic failure from the
lack of a suitable `--sysroot=' option where the `--with-build-sysroot='
configura
Hi Maciej,
Go's project doesn't take mail patches for changes. Please use gerrit (
https://go-review.googlesource.com/ ).
Thanks
- ccf
On Mon, Nov 11, 2019 at 10:12 AM Maciej W. Rozycki wrote:
> Hi,
>
> This patch series addresses a problem with the testsuite compiler being
>
Fix a problem with the libatomic testsuite using a method to determine
the compiler to use resulting in the tool being different from one the
library has been built with, and causing a catastrophic failure from the
lack of a suitable `--sysroot=' option where the `--with-build-sysroot='
configu
Fix a problem with the libgo testsuite using a method to determine the
compiler to use resulting in the tool being different from one the
library has been built with, and causing a catastrophic failure from the
lack of a suitable `--sysroot=' option where the `--with-build-sysroot='
configurati
Hi,
This patch series addresses a problem with the testsuite compiler being
set up across libatomic, libffi, libgo, libgomp with no correlation
whatsoever to the target compiler being used in GCC compilation.
Consequently there in no arrangement made to set up the compilation
sysroot accordi
On 2019-11-11 10:15, Ulderico Cirello wrote:
Hi Maciej,
Go's project doesn't take mail patches for changes.
Is it that they'd have to read man pages and learn how to use common
utilities?
Or that nobody has written a "patch in Go" yet?
On Sat, 9 Nov 2019, Janne Blomqvist wrote:
> Bump the minimum MPFR version to 3.1.0, released 2011-10-03. With this
> requirement one can still build GCC with the operating system provided
> MPFR on old but still supported operating systems like SLES 12 (MPFR
> 3.1.2) or RHEL/CentOS 7.x (MPFR 3.1.
On Mon, Nov 11, 2019 at 10:15 AM Ulderico Cirello
wrote:
>
> Go's project doesn't take mail patches for changes. Please use gerrit (
> https://go-review.googlesource.com/ ).
These patches are for gccgo, not the gc toolchain. They should
probably have been sent to gofrontend-dev rather than gola
On Mon, Nov 11, 2019 at 10:31 AM Kaz Kylheku (libffi)
<382-725-6...@kylheku.com> wrote:
>
> On 2019-11-11 10:15, Ulderico Cirello wrote:
> > Hi Maciej,
> >
> > Go's project doesn't take mail patches for changes.
>
> Is it that they'd have to read man pages and learn how to use common
> utilities?
>
On Mon, 11 Nov 2019, Ulderico Cirello wrote:
> Go's project doesn't take mail patches for changes. Please use gerrit (
> https://go-review.googlesource.com/ ).
Thanks for your reply; this is however too much effort for my limited
resources and a one-off change.
The reason is I'm not actively
On Mon, 11 Nov 2019, Ian Lance Taylor wrote:
> > Go's project doesn't take mail patches for changes. Please use gerrit (
> > https://go-review.googlesource.com/ ).
>
> These patches are for gccgo, not the gc toolchain. They should
> probably have been sent to gofrontend-dev rather than golang-d
On 11/11/19 10:29 AM, Martin Jambor wrote:
Hi,
On Mon, Nov 11 2019, Martin Sebor wrote:
On 11/8/19 5:41 AM, Martin Jambor wrote:
Hi,
this patch is an attempt to implement my idea from a previous thread
about moving -Wmaybe-uninitialized to -Wextra:
https://gcc.gnu.org/ml/gcc-patches/2019-02/
For:
void
f1 (int *x, int *y)
{
for (int i = 0; i < 32; ++i)
x[i] += y[i];
}
we check at runtime whether one vector at x would overlap one vector at y.
But in cases like this, the vector code would handle x <= y just fine,
since any write to address A still happens after any rea
The two users of tree-data-ref's runtime alias checks both canonicalise
the order of the dr_with_seg_lens in a pair before passing them to
prune_runtime_alias_test_list. It's more convenient for later patches
if prune_runtime_alias_test_list does that itself.
2019-11-11 Richard Sandiford
gcc
prune_runtime_alias_test_list swapped dr_as between two dr_with_seg_len
pairs before finally deciding whether to merge them. Bailing out later
would therefore leave the pairs in an incorrect state.
IMO a better fix would be to split this out into a subroutine that
produces a temporary dr_with_seg
This patch adds a bunch of flags to dr_with_seg_len_pair_t,
for use by later patches. The update to tree-loop-distribution.c
is conservatively correct, but might be tweakable later.
2019-11-11 Richard Sandiford
gcc/
* tree-data-ref.h (DR_ALIAS_RAW, DR_ALIAS_WAR, DR_ALIAS_WAW)
prune_runtime_alias_test_list can merge dr_with_seg_len_pair_ts that
have different steps for the first reference or different steps for the
second reference. This patch adds a flag to record that.
I don't know whether the change to create_intersect_range_checks_index
fixes anything in practice.
This patch dumps the final (merged) list of alias pairs. It also adds:
- WAW and RAW versions of vect-alias-check-8.c
- a "well-ordered" version of vect-alias-check-9.c (i.e. all reads
before any writes)
- a test with mixed steps in the same alias pair
I also tweaked the test value in vect-ali
This patch prints a message to say how an alias check is being
implemented.
2019-11-11 Richard Sandiford
gcc/
* tree-data-ref.c (create_intersect_range_checks_index)
(create_intersect_range_checks): Print dump messages.
gcc/testsuite/
* gcc.dg/vect/vect-alias-check-1.
This patch rewrites the index-based alias checks to use conditions
of the form:
(unsigned T) (a - b + bias) <= limit
E.g. before the patch:
struct s { int x[100]; };
void
f1 (struct s *s1, int a, int b)
{
for (int i = 0; i < 32; ++i)
s1->x[i + a] += s1->x[i + b];
}
used:
For:
void
f1 (int *x, int *y)
{
for (int i = 0; i < 32; ++i)
x[i] += y[i];
}
we checked at runtime whether one vector at x would overlap one vector
at y. But in cases like this, the vector code would handle x <= y just
fine, since any write to address A still happens after any
On Mon, Nov 11, 2019 at 8:29 PM Joseph Myers wrote:
>
> On Sat, 9 Nov 2019, Janne Blomqvist wrote:
>
> > Bump the minimum MPFR version to 3.1.0, released 2011-10-03. With this
> > requirement one can still build GCC with the operating system provided
> > MPFR on old but still supported operating s
On Mon, Nov 11, 2019 at 09:07:08AM +0100, Jakub Jelinek wrote:
> From
> https://www.reddit.com/r/cpp/comments/dtuov8/201911_belfast_iso_c_committee_trip_report/
> I understood P1946R0 made it into C++20, so here is my attempt at
> implementing it, you had most of it implemented anyway because
> in
Hi!
I found a bug in OpenMP 5.0 examples that GCC didn't flag as an error.
The following patch implements the missing diagnostics.
Bootstrapped/regtested on powerpc64le-linux, committed to trunk.
2019-11-11 Jakub Jelinek
* c-parser.c (c_parser_translation_unit): Diagnose declare targ
Hi!
A recent unroller change results in the arg_types array initializing
loop in altivec_build_resolved_builtin being completely unrolled.
The callers ensure that for ALTIVEC_BUILTIN_VEC_VCMPGE_P all the 3
arguments are provided (i.e. n == 3), but the compiler doesn't know that
and emits -Wmaybe-u
Hi!
The finish_function change to goto cleanup; on DECL_DELETED_FN added
in the spaceship commit broke the following testcase.
The problem is that during start_preparsed_function push_nested_class
pushes a scope, but as ctype is kept NULL when goto cleanup; crosses
the setting of ctype to somethin
Hi!
The following testcase ICEs on aarch64-linux. The problem is that maxbound
is POLY_INT_CST, eltsize is INTEGER_CST, but int_const_binop for
TRUNC_DIV_EXPR returns NULL_TREE as it can't simplify it to something
usable and we later try to MINUS_EXPR the NULL_TREE.
Fixed thusly, tested using cr
OK, thanks.
On Mon, Nov 11, 2019 at 3:14 PM Jakub Jelinek wrote:
> Hi!
>
> The finish_function change to goto cleanup; on DECL_DELETED_FN added
> in the spaceship commit broke the following testcase.
> The problem is that during start_preparsed_function push_nested_class
> pushes a scope, but as
Dear all,
the attached patch prints the fully qualified path if an error occurs
during module read. E.g., instead of a less helpful error message,
pr81651.f90:2:6:
2 | use netcdf
| 1
Fatal Error: File 'netcdf.mod' opened at (1) is not a GNU Fortran module
file
gfortran will pr
Hello world,
the attached patch loads scalar INTENT(IN) variables to a local
variable at the start of a procedure, as suggested in PR 67202, in
order to aid optimization. This is controlled by front-end
optimization so it is easier to catch if any bugs should turn up :-)
This is done to make op
Am 11.11.19 um 22:55 schrieb Thomas König:
Regression-tested. OK for trunk?
Of course, better with a ChangeLog entry.
2019-11-11 Thomas Koenig
PR fortran/67202
* dump-parse-tree.c (debug): Add for gfc_namespace.
(show_code_node): Add INIT_ on dumping EXEC_INIT_ASSIG
Hi,
On Mon, Nov 11 2019, Martin Sebor wrote:
> On 11/11/19 10:29 AM, Martin Jambor wrote:
>> On Mon, Nov 11 2019, Martin Sebor wrote:
>>> On 11/8/19 5:41 AM, Martin Jambor wrote:
Hi,
this patch is an attempt to implement my idea from a previous thread
about moving -Wmaybe-unini
On Mon, Nov 11, 2019 at 11:54 PM Harald Anlauf wrote:
>
> Dear all,
>
> the attached patch prints the fully qualified path if an error occurs
> during module read. E.g., instead of a less helpful error message,
>
> pr81651.f90:2:6:
>
> 2 | use netcdf
> | 1
> Fatal Error: File 'ne
The conditional in default_ref_may_alias_errno has the function
return true even for local variables, implying that locals must
be assumed not to have been changed across calls to errno-setting
functions like malloc. This leads to both worse code and also
false negatives in the strlen pass' detec
On Mon, Nov 11, 2019 at 11:56 PM Thomas König wrote:
>
> Hello world,
>
> the attached patch loads scalar INTENT(IN) variables to a local
> variable at the start of a procedure, as suggested in PR 67202, in
> order to aid optimization. This is controlled by front-end
> optimization so it is easie
Hi Janne,
Wouldn't it be even better to pass scalar intent(in) variables by
value? The obvious objection of course is ABI, but for procedures with
an explicit interface we're not following any particular ABI anyways?
The problem with that is that we don't know when we compile a procedure
if it
On Fri, Nov 01, 2019 at 10:22:03PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Oct 16, 2019 at 09:47:41AM -0400, Michael Meissner wrote:
> > This patch fixes the stack protection insns to support stacks larger than
> > 16-bits on the 'future' system using prefixed loads and stores.
>
> > +
On Mon, Nov 11, 2019 at 10:44 AM Maciej W. Rozycki wrote:
>
> On Mon, 11 Nov 2019, Ian Lance Taylor wrote:
>
> > > Go's project doesn't take mail patches for changes. Please use gerrit (
> > > https://go-review.googlesource.com/ ).
> >
> > These patches are for gccgo, not the gc toolchain. They
On Mon, Nov 11, 2019 at 10:12 AM Maciej W. Rozycki wrote:
>
> Fix a problem with the libgo testsuite using a method to determine the
> compiler to use resulting in the tool being different from one the
> library has been built with, and causing a catastrophic failure from the
> lack of a suitable
[ moving from golang-dev to gofrontend-dev ]
On Mon, Nov 11, 2019 at 7:48 AM Maciej W. Rozycki wrote:
>
> Add a setting for the dynamic loader to find the shared libgcc_s library
> in build-tree testing, fixing a catastrophic libgo testsuite failure in
> cross-compilation where the library cannot
Hello-
Would it be appropriate to ping this patch at this point? It would be
great if someone can review it please, it's relatively short and it
fixes one of the two noticeable issues with extended identifier
diagnostics. Thanks very much!
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00766.html
1 - 100 of 119 matches
Mail list logo
