On Mon, 11 Nov 2019, Andre Vieira (lists) wrote:
> 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 i
On 11/11/19 3:20 PM, Richard Biener wrote:
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
Hi.
There's a small follow up where I enforce the sorting via a selftest.
Ready for tr
On 11/11/19 4:25 PM, Martin Liška wrote:
I'm going to test the patch.
Martin
There's one more version where I use more references to mitigate
indirection of 'counter' vectors.
Martin
>From e3b8b3edfed1b5ba320d0fe85686908c5c37c22a Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri, 8 Nov 2
On Tue, 12 Nov 2019, Jakub Jelinek wrote:
> Hi!
>
> The testcase from the PR ICEs on rs6000. For __builtin_isunordered etc.
> the folding makes sure that there is no *ORDERED_EXPR etc. in the IL
> if !HONOR_NANS, but the complex multiplication can emit it when mixing
> -Ofast with -fno-cx-limite
On Tue, Nov 12, 2019 at 12:53 AM Thomas König wrote:
>
> 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 pr
On Mon, 11 Nov 2019, Jakub Jelinek wrote:
> 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 M
On Tue, Nov 12, 2019 at 6:59 AM Jeff Law wrote:
>
> On 11/10/19 4:05 AM, Janne Blomqvist wrote:
> > On Sun, Nov 10, 2019 at 11:43 AM Thomas Koenig
> > wrote:
> >>
> >> Hi Janne,
> >>
> >>> Bump the minimum MPFR version to 3.1.0, released 2011-10-03. With this
> >>> requirement one can still buil
Hi:
This patch is about to set X86_TUNE_AVX128_OPTIMAL as default for
all AVX target because we found there's still performance gap between
128-bit auto-vectorization and 256-bit auto-vectorization even with
epilog vectorized.
The performance influence of setting avx128_optimal as default on
SP
On 11/6/19 3:34 PM, 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 warnings for s
On Mon, Nov 11, 2019 at 3:45 AM Andreas Schwab wrote:
> Only ubsan is supported so far. This has been tested on openSUSE
> Tumbleweed, there are no testsuite failures.
>
> * configure.tgt (riscv64-*-linux*): Enable build.
I tried this on my riscv64 Fedora system, and I get a build error.
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 warnings for single-byte and multi-byte
> stores mention
On 11/10/19 4:05 AM, Janne Blomqvist wrote:
> On Sun, Nov 10, 2019 at 11:43 AM Thomas Koenig wrote:
>>
>> Hi Janne,
>>
>>> 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 sup
On 11/11/19 8:07 AM, Jakub Jelinek wrote:
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
fr
I'm not sure what semantics we might eventually want for vector <=>, but let's
give a sorry for now.
Tested x86_64-pc-linux-gnu, applying to trunk.
---
gcc/cp/typeck.c | 7 +++
gcc/testsuite/g++.dg/cpp2a/spaceship-vec1.C | 11 +++
2 files changed, 18 inse
The attached patch extends the strlen pass to detect out-of-bounds
accesses to memory allocated by calls to other allocation functions
besides calloc and malloc, as well as VLAs, and user-defined
functions declared with attribute alloc_size. There is some
overlap with the _FORTIFY_SOURCE detectio
On Sun, Nov 3, 2019 at 1:37 PM Paul Richard Thomas
wrote:
>
> The attached patch is verging on the obvious. Thanks to Tobias for
> spotting Vipul's messages on the J3 list.
>
> Regtests on FC30/x86_64 - OK for trunk and 9-branch?
>
> Paul
Paul,
Thanks for your follow-up on this issue. Would you
Part of P1327R1 is to allow typeid with an operand of polymorphic type in
constexpr. I found that we pretty much support it already, the only tweak
was to allow TYPEID_EXPR (only created in a template) in constexpr in C++20.
I also noticed this in build_typeid:
/* FIXME when integrating with c_
Hi!
The testcase from the PR ICEs on rs6000. For __builtin_isunordered etc.
the folding makes sure that there is no *ORDERED_EXPR etc. in the IL
if !HONOR_NANS, but the complex multiplication can emit it when mixing
-Ofast with -fno-cx-limited-range.
The following patch makes sure we don't emit i
Hi!
PCH remaps object addresses, so hash tables that use pointer hashing
don't work well across PCH, because the hash values can change and without
rehashing the hash tbales values might not be found.
The following patch fixes it by using DECL_UID as hash function instead,
which is stable across
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
[ 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
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
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 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.
>
> > +
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 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
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: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
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
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
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
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
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
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
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!
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!
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
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
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
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
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:
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 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
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 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 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
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
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
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/
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 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, 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, 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 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 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?
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
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
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
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 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
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
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
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,
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/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
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 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 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 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/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
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 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
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 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 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
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 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
> 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 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.
>
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 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"
> +
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/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 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/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 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 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 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 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
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
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
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
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
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
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, 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
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
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-
> 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
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
1 - 100 of 119 matches
Mail list logo
