All Windows Servers till 2019 correcting the socket timeout for 500ms.
Tested on x86_64-pc-linux-gnu, committed on trunk
2020-06-08 Dmitriy Anisimkov
gcc/ada/
* socket.c (__gnat_minus_500ms): Remove
IsWindowsVersionOrGreater from condition.--- gcc/ada/socket.c
+++ gcc/ada/soc
Add a Depends contract to Delete procedures of formal containers to
state that the output value of the Position cursor depends on no inputs
(it is No_Element). This now ensures that no warnings will be emitted
by GNATprove if this value is not used after a call to Delete.
Tested on x86_64-pc-linux
This patch fixes a bug in which the messages produced by
gnatbind could be nondeterministic. In particular, the message:
info: use pragma Restrictions (No_Entry_Calls_In_Elaboration_Code)
could be missing, depending on details that should be irrelevant.
Tested on x86_64-pc-linux-gnu, commit
Clean up Analyze_Object_Renaming and Is_Object_Reference while
implementing this new AI and recognize value conversion of objects as an
object reference.
Tested on x86_64-pc-linux-gnu, committed on trunk
2020-06-08 Arnaud Charlet
gcc/ada/
* sem_ch8.adb (Analyze_Object_Renaming): Simp
Recognize (no-ops for now) new check names Program_Error_Check,
Tasking_Check.
Tested on x86_64-pc-linux-gnu, committed on trunk
2020-06-08 Arnaud Charlet
gcc/ada/
* snames.ads-tmpl (Name_Program_Error_Check,
Name_Tasking_Check): New constants.
* types.ads (Program_Er
This completes the implementation of AI12-0282, which allows variable
control aspects to apply to formal types. This patch extends the
implementation to handle properly formal derived types.
Tested on x86_64-pc-linux-gnu, committed on trunk
2020-06-08 Ed Schonberg
gcc/ada/
* par-ch12
Expansion of attribute Enum_Rep applied to First and Last attributes,
both in the standard compilation mode and in the GNATprove mode, relies
on those First and Last attributes being already expanded. However, they
were only expanded in the standard compilation mode; now they are also
expanded in t
In the special expander that is only applied in GNATprove mode we had a
code that duplicated Get_Index_Subtype routine from the standard
expander. Now this routine is properly reused. Behaviour of both GNAT
and GNATprove remains unchanged.
Tested on x86_64-pc-linux-gnu, committed on trunk
2020-06
For aggregate components that are aggregates the frontend has been
enhanced to evaluate if the inner aggregate depends on the variable
being assigned to. This enhancement allows the compiler to avoid the
generation of a temporary and thus generate better code for large nested
aggregates.
Tested on
This disables the warning given in the specific case of an atomic
composite object subject to an address clause accessed partially,
when the code is compiled in Ada 2020 mode, on the grounds that
the semantics of these accesses to components of atomic composite
objects is perfectly defined in Ada 2
If we're doing 'First or 'Last on a renamed variable, the backend may
look at either the Etype of the variable or that of what it was
renaming, so check both to see if we need to place it into the
activation record.
Tested on x86_64-pc-linux-gnu, committed on trunk
2020-06-08 Richard Kenner
g
Predicate checks are required by AI12-0100 when evaluating qualified
expressions where the qualifying subtype has such checks. Errors rather
than warnings must be issued on static qualified expressions and type
conversions that violate a static predicate, so that's corrected here.
There were also c
Use pragma Warnings to silence a spurious warning that may occur in
instances of formal vectors.
Tested on x86_64-pc-linux-gnu, committed on trunk
2020-06-08 Claire Dross
gcc/ada/
* libgnat/a-cofove.adb (Insert_Space): The computation of Index
generates a spurious compiler wa
The Name_SPARK constant is no longer used in GNAT to implement the
SPARK_05 restriction, but is still used in GNATprove to detect whether
the SPARK.Heap unit has been explicitly WITH-ed.
Tested on x86_64-pc-linux-gnu, committed on trunk
2020-06-08 Piotr Trojanek
gcc/ada/
* snames.ads
This patch corrects an issue whereby calls to controlled primitives for
types which extend generic formals may be flagged at compile-time as
being non-visible.
Tested on x86_64-pc-linux-gnu, committed on trunk
2020-06-08 Justin Squirek
gcc/ada/
* sem_ch4.adb (Analyze_One_Call): Add e
The Jorvik profile is a newly defined profile, similar to the Ravenscar
profile but less restrictive in some cases. It differs from the
Ravenscar profile only in the removal of six restrictions and the
relaxation of one (Ravenscar's Simple_Barriers restriction is replaced
with a Pure_Barriers restr
This change adds a missing check on setting aspects Storage_Size and
Storage_Pool on remote access-to-class-wide types.
Tested on x86_64-pc-linux-gnu, committed on trunk
2020-06-08 Arnaud Charlet
gcc/ada/
* sem_cat.ads: Fix typo.
* sem_cat.adb (Validate_Remote_Access_To_Class
Most cases were actually handled fine thanks to some special handling in
exp_attr.adb, but cases of e.g. a renaming of renaming were not handled
properly. Taking this opportunity to simplify the code and remove
special cases by actually adding support for 'Enum_Rep directly in
Eval_Type_Conversion.
Change the existing implementation of the Simple_Barriers restriction to
conform to the rules given in AI12-0290. Note that the new rules are in
some cases more restrictive than the old rules (so that previously
accepted barriers might now be rejected). For example, references to
non-component subc
Expansion of Enum_Rep in GNATprove is meant to be a subset of the
expansion in GNAT, so it needs to be kept in sync with the frontend.
Semantics of the compiler is not affected.
Tested on x86_64-pc-linux-gnu, committed on trunk
2020-06-08 Piotr Trojanek
gcc/ada/
* exp_spark.adb (Expa
AI12-0204 clarified that the prefix of a prefixed view that is renamed
or passed as a formal subprogram must be renamable as an object and
similarly (was already checked by GNAT), the prefix of a prefixed view
that has an implicit 'Access must be legal for 'Access and a
generalized_indexing is ille
The flag was made obsolete some time ago and no fallout has been
detected since then, so this change finally removes it.
Tested on x86_64-pc-linux-gnu, committed on trunk
2020-06-08 Eric Botcazou
gcc/ada/
* atree.adb (New_Copy): Do not clear Has_Dynamic_Range_Check.
* checks.
In Ada2020 the Ravenscar profile (but not the Jorvik profile) includes
a "No_Dependence => Ada.Synchronous_Barriers" restriction. This is a
binding interpretation so it applies also to earlier Ada versions, but
the unit Ada.Synchronous_Barriers did not exist before Ada 2012.
Tested on x86_64-pc-li
Hi!
As mentioned in the PR, the problem is that at least the x86 backend asumes
that the vec_unpack* and vec_pack* optabs with integral modes are for the
AVX512-ish vector masks rather than for very small vectors done in GPRs.
The only other target that seems to have a scalar mode vec_{,un}pack* o
Hi All,
This expands the comment on an assert we have in aarch64_layout_frame
and points to an existing comment somewhere else that has a much longer
explanation of what's going on.
Committed under the GCC Obvious rule.
Thanks,
Tamar
gcc/ChangeLog:
* config/aarch64/aarch64.c (aarch64_l
> OK, but all I was saying is that looking at the pointed-to type of
> the address argument to the memcpy looks fragile to me. For the
> case cited above it would be better to look at the actual
> reference we are looking up and not allowing memcpy handling
> when that reference contains a storage
On Sat, Jun 06, 2020 at 10:21:31PM +0200, Jan Hubicka wrote:
> diff --git a/gcc/testsuite/g++.dg/torture/pr95548.C
> b/gcc/testsuite/g++.dg/torture/pr95548.C
> new file mode 100644
> index 000..bca4f753f7e
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/torture/pr95548.C
> @@ -0,0 +1,8 @@
> +
Hi!
MD patterns extended for unary ops ABS, CLS, CLZ, CNT, NEG and NOT
to support unpacked vectors. Also extended patterns for BIC to
support unpacked vectors where input elements are of the same width.
Tested on x86_64-linux and aarch64-linux hosts.
Thanks,
Joe
gcc/ChangeLog:
2020-05-27 Joe
On June 8, 2020 10:14:40 AM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>As mentioned in the PR, the problem is that at least the x86 backend
>asumes
>that the vec_unpack* and vec_pack* optabs with integral modes are for
>the
>AVX512-ish vector masks rather than for very small vectors done in
>GPRs.
>T
Hi
The PR reports that we fail to destroy the object initially created from
the get-return-object call. Fixed by adding a cleanup when the DTOR is
non-trivial. In addition, to meet the specific wording that the call to
get_return_object creates the glvalue for the return, we must construct
that
Hi Joe,
Joe Ramsay writes:
> Hi!
>
> MD patterns extended for unary ops ABS, CLS, CLZ, CNT, NEG and NOT
> to support unpacked vectors. Also extended patterns for BIC to
> support unpacked vectors where input elements are of the same width.
Thanks for the patch. Looks good, but...
> @@ -2848,12
> The only case handled specially is TYPE_DECL; other DECL_EXPRs fall
> through to the default case, where we WALK_SUBTREE over all the operands
> of the expression, which for DECL_EXPR is the decl.
It seems hard to believe that the inliner relies on this to copy DECLs though,
see the calls to re
Hi Samuel!
On 2020-05-29T13:46:50+0200, Samuel Thibault wrote:
> libgcc is currently missing the support for unwinding over signal
> trampolines on GNU/Hurd.
ACK. Has been on my long TODO list for a long time. ;-)
> The attached patch implements it.
Thanks!
I'm not intimately familiar with
In the latest PR95551, the issue came up with a Fortran array
constructor ("if ((any (array /= [(-i, i=1, 10)])") used
in a target section within a host procedure. The constructor
is converted into a static local variable
A.10 = [-1, -2, ...]
ends up in omp-offload.c's offload_vars.
With -O3 op
Hi,
On Fri, May 15 2020, Jason Merrill via Gcc-patches wrote:
> commit f466a9f3f121f16b97071162806255fb464718f2
> Author: Jason Merrill
> Date: Fri May 15 17:15:38 2020 -0400
>
> bootstrap: Update requirement to C++11.
>
> There was general agreement last November that we would mov
As side-remark or follow up: I have also experimented
with the attached patch.
On the host side, the omp_finish_file call in toplev.c comes
late enough that the the variables is gone and one no longer
writes it to the var table.
However, the write_lto() → output_offload_tables() call is
that ear
Hello.
Thank you for the approval. There's the patch that defines 4 new
DEF_INTERNAL_OPTAB_FN.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
It also builds on ppc64le-linux-gnu.
Ready to be installed?
Thanks,
Martin
>From ae67d31e1ea7e03bbba216a7b9404009b2dea070 Mon Se
On 6/4/20 1:44 AM, Gerald Pfeifer wrote:
On Wed, 3 Jun 2020, Martin Liška wrote:
Sorry for the breakage. Can you please paste full build output for the
problematic .o file?
I bet it's a C file compilation, where we should use:
__sync_val_compare_and_swap (counter, 0, (intptr_t)node);
Can you
On Mon, Jun 08, 2020 at 12:44:31PM +0200, Tobias Burnus wrote:
> As side-remark or follow up: I have also experimented
> with the attached patch.
>
> On the host side, the omp_finish_file call in toplev.c comes
> late enough that the the variables is gone and one no longer
> writes it to the var t
Thomas Schwinge, le lun. 08 juin 2020 12:15:12 +0200, a ecrit:
> I'm not currently set up to test this, but I'll assume you have.
Sure :)
> Which GCC branches would you like this on?
Ideally it's be backported to gcc 9 and 10, so that it lands naturally
in the Debian packages without having to b
Hi,
On Tue, Jun 02 2020, Richard Biener wrote:
> On Thu, 28 May 2020, Martin Jambor wrote:
>
>> PR 93385 reveals that if the user explicitely disables DCE, IPA-SRA
>> can leave behind statements which are useless because their results
>> are eventually not used but can have problematic side effect
Hi,
On Thu, May 28 2020, Martin Jambor wrote:
> This patch arguably finishes what I was asked to do in bugzilla PR
> 93385 and remaps *all* occurrences of SSA names discovered to be dead
> in the process of parameter removal during clone materialization
> either to error_mark_node or to DEBUG_EXPR
Samuel Thibault, le lun. 08 juin 2020 13:36:55 +0200, a ecrit:
> Thomas Schwinge, le lun. 08 juin 2020 12:15:12 +0200, a ecrit:
> > Which GCC branches would you like this on?
>
> Ideally it's be backported to gcc 9 and 10, so that it lands naturally
> in the Debian packages without having to bothe
Hi Szabolcs,
Just to confirm, this is a "unwinder debugger hook ABI" change only in
the sense that the generated DWARF will be changed, right? So no further
action from DWARF consumers will be needed. Is that understanding correct?
On 6/5/20 1:51 PM, Szabolcs Nagy wrote:
Mangling, currently
The 06/08/2020 09:12, Luis Machado wrote:
> Hi Szabolcs,
>
> Just to confirm, this is a "unwinder debugger hook ABI" change only in the
> sense that the generated DWARF will be changed, right? So no further action
> from DWARF consumers will be needed. Is that understanding correct?
the _Unwind_D
On Sat, 6 Jun 2020 at 22:30, Martin Sebor via Gcc-patches
wrote:
>
> A recent enhancement to the uninitialized access coverage to include
> dynamically allocated objects, including alloca and VLAs, triggers
> an expected instance of -Wmaybe-uninitialized on powerpc64-linux
> in reload_cse_simplify
On 5 June 2020 17:12:58 CEST, Thomas Koenig via Fortran
wrote:
>Hi Tom,
>
>> My earlier patch to add case handling to the spell checker caused a
>> Fortran regression. I believe I must have misread the test results.
>>
>> This patch fixes the problem by changing the cutoff. I chose this
>> val
Hi,
I just observe that this patch causes our *nonbootstrap* builds
to fail; I have not yet looked into this nor tried a bootstrap
build.
gcc-mainline/gcc/expr.c: In function 'rtx_insn* emit_move_insn(rtx, rtx)':
gcc-mainline/gcc/expr.c:3830:3: warning: 'auto' changes meaning in C++11;
please r
Forgot to mention that this was an accelerator build:
-DHOST_MACHINE=\"x86_64-pc-linux-gnu\" -DTARGET_MACHINE=\"nvptx-unknown-none\"
build which failed.
Tobias
On 6/8/20 3:49 PM, Tobias Burnus wrote:
Hi,
I just observe that this patch causes our *nonbootstrap* builds
to fail; I have not yet
On Mon, Jun 08, 2020 at 03:49:17PM +0200, Tobias Burnus wrote:
> Hi,
>
> I just observe that this patch causes our *nonbootstrap* builds
> to fail; I have not yet looked into this nor tried a bootstrap
> build.
>
> gcc-mainline/gcc/expr.c: In function 'rtx_insn* emit_move_insn(rtx, rtx)':
> gcc-m
Hi All,
The cost model is currently treating multiplication by element as being more
expensive than 3 same multiplication. This means that if the value is on the
SIMD side we add an unneeded DUP. If the value is on the genreg side we use the
more expensive DUP instead of fmov.
This patch correc
Sending to list as well.. not sure why it was stripped from the reply all.
> -Original Message-
> From: Tamar Christina
> Sent: Monday, June 8, 2020 3:25 PM
> To: Jakub Jelinek ; Tobias Burnus
>
> Cc: Uros Bizjak ; nd
> Subject: RE: [PATCH PR95254] aarch64: gcc generate inefficient code
Hi.
Thank you for the report. It's caused by fact that LLVM switch in 4d474e078ac7
to c++14. So that I suggest to use gnu++14.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I also verified that abidiff is equal for all libsanitizer shared libraries.
I'm going to install
Hi,
A new speculative cache side-channel vulnerability has been published at
the link below, named "straight-line speculation" (SLS in this patch series).
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation
This vulnerabili
This patch introduces the mitigation for Straight Line Speculation past
the BLR instruction.
This mitigation replaces BLR instructions with a BL to a stub which
simply consists of a BR to the original register. These function stubs
are then appended with a speculation barrier to ensure no straigh
Here we introduce the flags that will be used for straight line speculation.
The new flag introduced is `-mharden-sls=`.
This flag can take arguments of `none`, `all`, or a comma seperated list of one
or more of `retbr` or `blr`.
`none` indicates no special mitigation of the straight line speculat
Instructions following RET or BR are not necessarily executed. In order
to avoid speculation past RET and BR we can simply append a speculation
barrier.
Since these speculation barriers will not be architecturally executed,
they are not expected to add a high performance penalty.
The speculation
Hi Jakub,
how about the following patch, which is kind of a combination of the
two? Namely, avoiding of the output of artificial,read-only nonglobal
variables – and marking all remaining variables and all functions with
node->force_output. As the LTO writing happens earlier, I only do it
there. T
On Mon, Jun 08, 2020 at 05:20:16PM +0200, Tobias Burnus wrote:
> how about the following patch, which is kind of a combination of the
> two? Namely, avoiding of the output of artificial,read-only nonglobal
> variables – and marking all remaining variables and all functions with
> node->force_output
Tamar Christina writes:
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index
> 97da60762390db81df9cffaf316b909cd1609130..9cc8da338125afa01bc9fb645f4112d2d7ef548c
> 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -11279,6 +11279,
On 6/3/20 9:57 PM, Asher Gordon via Gcc-patches wrote:
Hello,
I accidentally wrote 'free(loc)' instead of 'free (loc)'. Please see the
fixed patch attached below (contrib/check_GNU_style.sh says it's OK
now):
0001-Treat-0-specially-for-structs-with-the-designated_in.patch
From 0445fba96ee903
On 05/06/20 22:24 +0200, François Dumont via Libstdc++ wrote:
Hi
   Here is the last of my algo patches this time to extend the memcmp
optimization to std::deque iterators and _GLIBCXX_DEBUG mode.
   To do so I had to return int in implementation details of
lexicographical_compare t
On Mon, Jun 8, 2020 at 6:54 AM Martin Jambor wrote:
> Hi,
>
> On Fri, May 15 2020, Jason Merrill via Gcc-patches wrote:
> > commit f466a9f3f121f16b97071162806255fb464718f2
> > Author: Jason Merrill
> > Date: Fri May 15 17:15:38 2020 -0400
> >
> > bootstrap: Update requirement to C++11.
> >
In a parallel make check-fortran there was a race condition due to a
file "test.dat" not being cleaned up. Adjust testcase to use a
separate filename, and instead of failing catch error message within
the program.
Committed as obvious.
Thanks,
Harald
PR fortran/95195 - Fortran testcase should
On 6/8/20 5:17 AM, Iain Sandoe wrote:
Hi
The PR reports that we fail to destroy the object initially created from
the get-return-object call. Fixed by adding a cleanup when the DTOR is
non-trivial. In addition, to meet the specific wording that the call to
get_return_object creates the glvalu
On 5/22/20 8:27 AM, Iain Sandoe wrote:
Hi,
We didn’t quite have time to push this through before the 10.1
deadline, but (since it’s a correctness issue) it should be applied
to the branch too.
tested on x86_64-darwin, linux
OK for master?
10.2 after some bake time?
thanks
Iain
===
It was
On 5/22/20 7:19 AM, Iain Sandoe wrote:
Hi
This is almost obvious - except perhaps I’m missing some more
efficient way of doing it; it seems less than ideal to have to build the
ctor call twice with exactly the same inputs.
If there’s no better way ….
ok.
nathan
--
Nathan Sidwell
Hi Jakub,
On 6/8/20 5:30 PM, Jakub Jelinek wrote:
I really don't see what is special exactly on TREE_READONLY DECL_ARTIFICIAL
I have now split-off the missed-optimization task to a new
PR, PR95583, to be handled in a proper way instead of trying
to cook-up a hackish special-case version.
Thi
Nathan Sidwell wrote:
On 6/8/20 5:17 AM, Iain Sandoe wrote:
Hi
The PR reports that we fail to destroy the object initially created from
the get-return-object call. Fixed by adding a cleanup when the DTOR is
non-trivial. In addition, to meet the specific wording that the call to
get_return_o
On Mon, Jun 08, 2020 at 09:36:29PM +0200, Tobias Burnus wrote:
> I have now split-off the missed-optimization task to a new
> PR, PR95583, to be handled in a proper way instead of trying
> to cook-up a hackish special-case version.
>
> This patch now simply sets the force_output flag.
>
> (a) As
Hi,
This patch merges the D front-end implementation with upstream dmd
955b8b36f. Merges AndAndExp and OrOrExp into a LogicalExp AST node.
Bootstrapped and regression tested on x86_64-linux-gnu, and committed to
mainline.
Regards
Iain.
gcc/d/ChangeLog:
* dmd/MERGE: Merge upstream dmd
On 05/06/20 22:24 +0200, François Dumont via Libstdc++ wrote:
diff --git a/libstdc++-v3/include/debug/safe_iterator.tcc
b/libstdc++-v3/include/debug/safe_iterator.tcc
index 888ac803ae5..ca4e2d52d1d 100644
--- a/libstdc++-v3/include/debug/safe_iterator.tcc
+++ b/libstdc++-v3/include/debug/safe_i
Hi,
This parch merges the D front-end implementation with upstream dmd
5041e56f1. Fixing a small regression made by one of the refactorings.
Bootstrapped and regression tested on x86_64-linux-gnu, and committed to
mainline.
Regards
Iain.
gcc/d/ChangeLog:
PR d/95573
* dmd/MERG
On 6/8/20 5:46 AM, Eric Botcazou wrote:
The only case handled specially is TYPE_DECL; other DECL_EXPRs fall
through to the default case, where we WALK_SUBTREE over all the operands
of the expression, which for DECL_EXPR is the decl.
It seems hard to believe that the inliner relies on this to co
libstdc++-v3/ChangeLog:
* include/bits/unique_ptr.h (operator<<): Define for C++20.
* testsuite/20_util/unique_ptr/io/lwg2948.cc: New test.
Tested powerpc64le-linux, committed to master.
commit 187da2ce31f13b2f75d5bb780e30ee364ead9d1d
Author: Jonathan Wakely
Date: Mon Jun 8 1
Steve did the digging on another of Gerhard's "torture tests" involving
NULL() arguments to intrinsics. I have mainly cleaned up his patch and
packaged and regtested on x86_64-pc-linux-gnu.
OK for master?
Thanks,
Harald
PR fortran/95544 - Fix ICE in NULL() argument to intrinsics
Fortran 2018:
On 08/06/20 21:22 +0100, Jonathan Wakely wrote:
libstdc++-v3/ChangeLog:
* include/bits/unique_ptr.h (operator<<): Define for C++20.
* testsuite/20_util/unique_ptr/io/lwg2948.cc: New test.
Oops, I forgot to add the test adjustments.
Tested x86_64-linux, committed to master.
co
On 6/8/20 4:19 PM, Jason Merrill wrote:
On 6/8/20 5:46 AM, Eric Botcazou wrote:
The only case handled specially is TYPE_DECL; other DECL_EXPRs fall
through to the default case, where we WALK_SUBTREE over all the operands
of the expression, which for DECL_EXPR is the decl.
It seems hard to beli
On 08/06/20 21:07 +0100, Jonathan Wakely wrote:
On 05/06/20 22:24 +0200, François Dumont via Libstdc++ wrote:
diff --git a/libstdc++-v3/include/debug/safe_iterator.tcc
b/libstdc++-v3/include/debug/safe_iterator.tcc
index 888ac803ae5..ca4e2d52d1d 100644
--- a/libstdc++-v3/include/debug/safe_ite
On 08/06/20 19:20 +0100, Jonathan Wakely wrote:
On 05/06/20 22:24 +0200, François Dumont via Libstdc++ wrote:
Hi
   Here is the last of my algo patches this time to extend the
memcmp optimization to std::deque iterators and _GLIBCXX_DEBUG mode.
   To do so I had to return int in imp
We're seeing some failures due to the local-alignment pass. For example on sh4:
Tests that now fail, but worked before (16 tests):
gcc.dg/pr48335-1.c (test for excess errors)
gcc.dg/pr48335-2.c (test for excess errors)
gcc.dg/pr48335-5.c (test for excess errors)
gcc.dg/pr48335-6.c (test for exc
PR 95581 reports an ICE in a call to gimple_call_arg() with
an out-of-bounds argument number (2). The attached patch avoids
the ICE but I'm not sure it's the right fix. Other than verifying
the ICE is gone with a powerpc64 cross-compiler I couldn't come up
with a generic test cases to exercise t
Bernhard> Yes, this is probably OK although Fortran is case-
Bernhard> insensitive. I think we lowercase names coming in from the
Bernhard> source (at least for the internal identifier nodes), so we
Bernhard> should not be affected by any case change.
I already checked it in, but FWIW it would be
On 08/06/20 22:08 +0100, Jonathan Wakely wrote:
On 08/06/20 19:20 +0100, Jonathan Wakely wrote:
On 05/06/20 22:24 +0200, François Dumont via Libstdc++ wrote:
Hi
   Here is the last of my algo patches this time to extend the
memcmp optimization to std::deque iterators and _GLIBCXX_DEBUG
An asm operand with a "VIEW_CONVERT_EXPR" will output the definition of the struct as asm code. Oops.
I hoped setting print_rtx_head would affect print_mem_expr, just
because it's in print-rtl rather than tree-pretty-print, but it didn't
help. I've thus arranged for print_mem_expr to "obey" pr
When the linker plugin is not available, dump outputs in lto runs are
different from those outputs.exp tests expect, so skip them for now.
Regstrapped on x86_64-linux-gnu. Ok to install?
for gcc/testsuite/ChangeLog
* outputs.exp (skip_lto): Set when missing the linker plugin.
---
t
Some testcases failed (esp. with --with-cpu=power9) after my change to
prefer xxperm over vperm when all else is equal. Fix that. (This also
tightens the relevant REs somewhat).
Tested on way too many configurations. Committed to trunk.
Segher
2020-06-09 Segher Boessenkool
gcc/testsuite
Hi Martin,
Thanks for your helpful comments.
Martin Sebor writes:
> As an aside, the bug number should be referenced in the change
> message so that when the patch is committed it's automatically
> reflected in the bug entry. The contrib/mklog.py script should
> do that automatically based on
Hi!
On Mon, Jun 01, 2020 at 03:53:36PM -0400, Michael Meissner wrote:
> +# Return 1 if the target generates PC-relative instructions automatically for
> +# the PowerPC 'future' machine.
"... automatically, for configurations that allow it"?
If the selector was only for the "future" target, that
Hi!
On Mon, Jun 08, 2020 at 02:22:23PM +0800, luoxhu wrote:
> On 2020/6/3 04:32, Segher Boessenkool wrote:
> > On Tue, Jun 02, 2020 at 04:41:50AM -0500, Xionghu Luo wrote:
> >> + if (TREE_CODE (type) == RECORD_TYPE
> >> + && rs6000_discover_homogeneous_aggregate (TYPE_MODE (type), type,
> >
Rewrite uw_install_context without function calls to avoid register
spilling in _Unwind_RaiseException during return context installation.
2020-06-08 Max Filippov
gcc/testsuite/
* g++.target/xtensa/pr95571.C: New test.
* g++.target/xtensa/xtensa.exp: New testsuite.
libgcc/
On 6/8/20 7:07 PM, Asher Gordon wrote:
Hi Martin,
Thanks for your helpful comments.
Martin Sebor writes:
As an aside, the bug number should be referenced in the change
message so that when the patch is committed it's automatically
reflected in the bug entry. The contrib/mklog.py script shou
Hi Tom,
Bernhard> Yes, this is probably OK although Fortran is case-
Bernhard> insensitive. I think we lowercase names coming in from the
Bernhard> source (at least for the internal identifier nodes), so we
Bernhard> should not be affected by any case change.
I already checked it in, but FWIW i
Hi!
The following patch implements various optimizations of __builtin_ffs*
against constants.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2020-06-08 Jakub Jelinek
PR tree-optimization/95527
* match.pd (__builtin_ffs (X) cmp CST): New optimizations.
Hi!
The C FE in the MEM_REF printing ICEs if the type of the first argument
(which due to useless pointer conversions can be an arbitrary type) is a
pointer to an incomplete type. The code just wants to avoid printing a cast
if it is a pointer to single byte elements.
Bootstrapped/regtested on x
On Tue, 9 Jun 2020, Jakub Jelinek wrote:
> Hi!
>
> The following patch implements various optimizations of __builtin_ffs*
> against constants.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
Richard.
> 2020-06-08 Jakub Jelinek
>
> PR tree-optimization/95
On Tue, 9 Jun 2020, Jakub Jelinek wrote:
> Hi!
>
> The C FE in the MEM_REF printing ICEs if the type of the first argument
> (which due to useless pointer conversions can be an arbitrary type) is a
> pointer to an incomplete type. The code just wants to avoid printing a cast
> if it is a pointer
On Thu, Jun 04, 2020 at 01:52:53PM +0200, Richard Biener wrote:
> * g++.dg/torture/pr95493.C: New testcase.
> +using K [[gnu::vector_size(16)]] = int;
...
> +int a = [](K y) {
> + for (int j = 0; j < 4; ++j)
> +if (y[j] != 0)
> + return j;
> +
On Tue, 9 Jun 2020 08:14:55 +0200
Thomas Koenig wrote:
> Hi Tom,
>
> > Bernhard> Yes, this is probably OK although Fortran is case-
> > Bernhard> insensitive. I think we lowercase names coming in from the
> > Bernhard> source (at least for the internal identifier nodes), so we
> > Bernhard> shou
99 matches
Mail list logo
