Bootstrappend on x86_64-pc-linux-gnu{-m32,}
Ok for trunk?
gcc/ChangeLog:
PR tree-optimization/103077
* doc/invoke.texi (Options That Control Optimization):
Update documentation for -ftree-loop-vectorize and
-ftree-slp-vectorize which are enabled by default at -02.
Hi,
This patch is to support cmla_optab, cmul_optab, cmla_conj_optab,
cmul_conj_optab for vector _Float16.
Ok for master?
gcc/ChangeLog:
* config/i386/sse.md (cmul3): add new define_expand.
(cmla4): Likewise
gcc/testsuite/ChangeLog:
* gcc.target/i386/avx512fp16-vector-
Hi,
This patch is to support fold _mm512_fmadd_pch (a, _mm512_set1_pch(*(b)), c) to
1 instruction vfmaddcph (%rsp){1to16}, %zmm1, %zmm2.
OK for master?
gcc/ChangeLog:
* config/i386/sse.md (fma___pair):
Add new define_insn.
(fma__fmaddc_bcst): Add new define_insn_and_spli
Hi Rasmus,
> On 3 Nov 2021, at 14:18, Rasmus Villemoes wrote:
>
> The macro TARGET_VXWORKS7 is always defined (see vxworks-dummy.h).
> Thus we need to test its value, not its definedness.
>
> Fixes aca124df (define NO_DOT_IN_LABEL only in vxworks6).
>
> gcc/ChangeLog:
>
> * config/vx-co
On Tue, Nov 02, 2021 at 04:20:01PM +0100, Andreas Schwab wrote:
> On Nov 02 2021, Stefan Schulze Frielinghaus via Gcc-patches wrote:
>
> > diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ldist-rawmemchr-1.c
> > b/gcc/testsuite/gcc.dg/tree-ssa/ldist-rawmemchr-1.c
> > index 6abfd278351..bf6335f6360 1006
On 05/11/2021 09.08, Olivier Hainque wrote:
> Hi Rasmus,
>
>> On 3 Nov 2021, at 14:18, Rasmus Villemoes wrote:
>>
>> The macro TARGET_VXWORKS7 is always defined (see vxworks-dummy.h).
>> Thus we need to test its value, not its definedness.
>>
>> Fixes aca124df (define NO_DOT_IN_LABEL only in vxwo
Hi all,
this patch enables address return signature and verification based on
Armv8.1-M Pointer Authentication [1].
To sign the return address, we use the PAC R12, LR, SP instruction
upon function entry. This is signing LR using SP and storing the
result in R12. R12 will be pushed into the stac
Hi all,
this patch enables Branch Target Identification Armv8.1-M Mechanism
[1].
This is achieved by moving and generalizing the Aarch64 "bti" pass so
it can be used also by the Arm backend.
The pass iterates through the instructions and adds the necessary BTI
instructions at the beginning of ev
On Thu, Nov 4, 2021 at 8:12 PM Segher Boessenkool
wrote:
>
> On Thu, Nov 04, 2021 at 01:22:24PM +0100, Martin Liška wrote:
> > On 11/4/21 12:55, Segher Boessenkool wrote:
> > >On Fri, Oct 29, 2021 at 09:32:21AM +0200, Richard Biener via Gcc-patches
> > >wrote:
> > >>On Fri, Oct 29, 2021 at 2:42 AM
On Thu, Nov 4, 2021 at 9:03 PM Iain Sandoe via Gcc-patches
wrote:
>
> GCC (currently) has an implementation of pre-compiled-headers, that relies
> on being able to launch the compiler executable at the same address each
> time. This constraint is not permitted by some system security models.
>
>
On Fri, Nov 5, 2021 at 3:20 AM liuhongt wrote:
>
> > Note that this is not safe with -fsignaling-nans, so needs to be disabled
> > for that option (if there isn't already logic somewhere with that effect),
> > because the extend will convert a signaling NaN to quiet (raising
> > "invalid"), but co
On Fri, Nov 5, 2021 at 6:38 AM liuhongt wrote:
>
> a and b are same type as trunc type and has less precision than
> extend type, the transformation is guarded by flag_finite_math_only.
>
> Bootstrapped and regtested under x86_64-pc-linux-gnu{-m32,}
> Ok for trunk?
>
> gcc/ChangeLog:
>
> P
On Fri, Nov 05, 2021 at 10:42:05AM +0100, Richard Biener via Gcc-patches wrote:
> I had the impression we have support for PCH file relocation to deal with ASLR
> at least on some platforms.
Unfortunately we do not, e.g. if you build cc1/cc1plus as PIE on
x86_64-linux, PCH will stop working unless
On Fri, Nov 5, 2021 at 6:38 AM liuhongt wrote:
>
> a, b, c are same type as truncation type and has less precision than
> extend type, the optimization is guarded under
> flag_unsafe_math_optimizations.
>
> Bootstrapped and regtested under x86_64-pc-linux-gnu{-m32,}
> Ok for trunk?
OK.
Thanks,
R
On Thu, Nov 04, 2021 at 01:45:38PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Thu, Nov 04, 2021 at 12:39:34PM +, Iain Sandoe wrote:
> > Bootstrap succeeded with Apple clang-503.0.40 (Xcode 5.1.1) on macOS 10.8
> > which is the earliest version I expect to work (previous xcode impl. have
On Fri, Nov 5, 2021 at 7:54 AM Jakub Jelinek via Gcc-patches
wrote:
>
> On Thu, Nov 04, 2021 at 11:05:35PM -0700, Andrew Pinski via Gcc-patches wrote:
> > > I noticed that the macro “WIDE_INT_MAX_ELTS” has different values in
> > > GCC11 and GCC12 (on the same X86 machine)
> > >
> > > For gcc11:
On Fri, Nov 5, 2021 at 8:08 AM liuhongt via Gcc-patches
wrote:
>
> Bootstrappend on x86_64-pc-linux-gnu{-m32,}
> Ok for trunk?
OK
> gcc/ChangeLog:
>
> PR tree-optimization/103077
> * doc/invoke.texi (Options That Control Optimization):
> Update documentation for -ftree-lo
On Thu, Nov 04, 2021 at 03:07:57PM +0100, Jakub Jelinek via Gcc-patches wrote:
> For the METHOD_TYPE first argument
> I use a temporary always though, that should be always is_gimple_reg_type...
Doing so regressed
+FAIL: g++.dg/cpp1z/inh-ctor23.C -std=gnu++11 scan-tree-dump gimple "V::V
.this,
As discussed this splits the analysis loop into two, first settling
on a vector mode used for the main loop and only then analyzing
the epilogue of that for possible vectorization. That makes it
easier to put in support for unrolled main loops.
On the way I've realized some cleanup opportunities,
This prevents find_cond_trap from being invoked after reload. It may
generate compares which would require reloading.
Bootstrapped and regression tested on s390x.
Ok for mainline?
gcc/ChangeLog:
PR rtl-optimization/103028
* ifcvt.c (find_if_header): Invoke find_cond_trap only b
On Thu, Nov 4, 2021 at 4:09 PM Jeff Law wrote:
>
>
>
> On 11/3/2021 2:15 AM, Richard Biener via Gcc-patches wrote:
> > On Tue, Nov 2, 2021 at 4:53 PM Jeff Law wrote:
> >>
> >> I was wandering spec chasing down instances where we should be
> >> generating bit-test, bit-set and bit-clear types of i
On Thu, Nov 4, 2021 at 4:11 PM Martin Liška wrote:
>
> On 11/4/21 14:09, Richard Biener wrote:
> > But we shouldn't start with the current global options but with ones
> > we saved for
> > optimize attribute/pragma processing, no?
>
> We hit the issue when we combine cmdline and pragma optimize op
On Thu, Nov 4, 2021 at 6:49 PM Richard Sandiford via Gcc-patches
wrote:
>
> "Andre Vieira (lists)" writes:
> > Hi,
> >
> > This should address the ubsan bootstrap build and big-endian testisms
> > reported against the last NEON load/store gimple lowering patch. I also
> > fixed a follow-up issue
On Fri, Nov 5, 2021 at 10:54 AM Jakub Jelinek wrote:
>
> On Fri, Nov 05, 2021 at 10:42:05AM +0100, Richard Biener via Gcc-patches
> wrote:
> > I had the impression we have support for PCH file relocation to deal with
> > ASLR
> > at least on some platforms.
>
> Unfortunately we do not, e.g. if y
On Fri, Nov 5, 2021 at 10:59 AM Jakub Jelinek via Gcc-patches
wrote:
>
> On Thu, Nov 04, 2021 at 01:45:38PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > On Thu, Nov 04, 2021 at 12:39:34PM +, Iain Sandoe wrote:
> > > Bootstrap succeeded with Apple clang-503.0.40 (Xcode 5.1.1) on macOS 10.8
>
On Thu, 4 Nov 2021, Jakub Jelinek wrote:
> On Thu, Nov 04, 2021 at 12:13:51PM +0100, Richard Biener wrote:
> > As a general comment I wonder whether doing this fully in the C++
> > frontend leveraging the constexpr support is a better approach, esp.
> > before we end up putting all initializers in
On Fri, Nov 05, 2021 at 11:44:53AM +0100, Richard Biener wrote:
> Agreed that we should attack it from both sides, I just had the
> impression that most bugreports complain that clang++ can do it
> and those mostly looked opportunities that could be leveraged
> by simply const-evaluating the initia
On Fri, 5 Nov 2021 at 09:35, Richard Biener via Gcc wrote:
> So just contribute updated dejagnu packages to CentOS 7 "backports" or
> whatever means exists there?
Yes, we could add a newer dejagnu to EPEL.
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, November 2, 2021 6:22 PM
> To: Richard Sandiford
> Cc: Richard Biener via Gcc-patches ; Tamar
> Christina ; nd
> Subject: Re: [PATCH]middle-end Add an RPO pass after successful
> vectorization
>
> On Tue, 2 Nov 2021, Richard
Richard Biener writes:
> As discussed this splits the analysis loop into two, first settling
> on a vector mode used for the main loop and only then analyzing
> the epilogue of that for possible vectorization. That makes it
> easier to put in support for unrolled main loops.
>
> On the way I've r
On 11/5/21 11:23, Richard Biener wrote:
OK if you add a comment like
/* Make sure to process -gtoggle only once. */
Sure, added and installed as 14c7041a1f00ef4ee9a036e0b369c97646db5b5c.
Cheers,
Martin
On Fri, 5 Nov 2021, Tamar Christina wrote:
>
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Tuesday, November 2, 2021 6:22 PM
> > To: Richard Sandiford
> > Cc: Richard Biener via Gcc-patches ; Tamar
> > Christina ; nd
> > Subject: Re: [PATCH]middle-end Add an RPO pass aft
On Fri, Nov 5, 2021 at 3:01 AM Richard Biener
wrote:
>
> On Fri, Nov 5, 2021 at 7:54 AM Jakub Jelinek via Gcc-patches
> wrote:
> >
> > On Thu, Nov 04, 2021 at 11:05:35PM -0700, Andrew Pinski via Gcc-patches
> > wrote:
> > > > I noticed that the macro “WIDE_INT_MAX_ELTS” has different values in
Tested x86-linux, in C++17 and C++20 modes, with GDB 10 and GDB 12.
Pushed to trunk.
For some reason the type printer for std::string doesn't work in C++20
mode, so std::basic_string, allocator is
printed out in full rather than being shown as std::string. It's
probably related to the fact that t
On Fri, 5 Nov 2021, Richard Sandiford wrote:
> Richard Biener writes:
> > As discussed this splits the analysis loop into two, first settling
> > on a vector mode used for the main loop and only then analyzing
> > the epilogue of that for possible vectorization. That makes it
> > easier to put i
On Thu, 4 Nov 2021 at 20:44, Bill Schmidt wrote:
> For posterity: This was discussed briefly on IRC, and Segher approved
> with some
> simplifications and a request to implement a fail/retry check.
>
>
Here's what I have now. No more assembler check in configure, and it uses
the 64-bit __builtin_
Zfinx extension[1] had already finished public review. Here is the
implementation patch set that reuse floating point pattern and ban the use of
fpr when use zfinx as a target.
Current works can be find in follow links, we will keep update zhinx and
zhinxmin after zfh extension goes upstream.
Support 'TARGET_ZFINX' with float instruction pattern and builtin function.
gcc/ChangeLog:
* config/riscv/riscv-builtins.c (AVAIL): Add TARGET_ZFINX.
(riscv_atomic_assign_expand_fenv): Ditto.
* config/riscv/riscv-c.c (riscv_cpu_cpp_builtins): Add TARGET_ZFINX.
* co
Limit zfinx abi support with 'ilp32','ilp32e','lp64' only.
Use GPR instead FPR when 'zfinx' enable, Only use even registers in RV32 when
'zdinx' enable.
gcc/ChangeLog:
* config/riscv/constraints.md
(TARGET_HARD_FLOAT ? FP_REGS : ((TARGET_ZFINX || TARGET_ZDINX) ?
GR_REGS : NO_RE
Minimal support of zfinx extension, include 'zfinx' and 'zdinx' corresponding
to 'f' and 'd', the 'zdinx' will imply 'zfinx' same as 'd' imply 'f'.
gcc/ChangeLog:
* common/config/riscv/riscv-common.c(riscv_implied_info_t): Add zdinx
imply zfinx.
(riscv_ext_version_table): Add
I tried enabling this on x86-64-linux (just for interest) and it seems to work
OK there too - but that testing revealed a thinko that didn’t show with a
a normal regstrap.
Changes from original post:
1. amended a comment
2. fixed a thinko where I was not allowing for functions declared
I mentioned that I would start a build/check on a big endian power8 system in
the last set of patches. There were no regressions with this set of patches on
a big endian system, testing both 32-bit and 64-bit code generation.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
em
On 11/5/21 7:44 AM, Jonathan Wakely wrote:
> On Thu, 4 Nov 2021 at 20:44, Bill Schmidt wrote: For posterity: This was
> discussed briefly on IRC, and Segher approved with some simplifications and a
> request to implement a fail/retry check. Here's what I have now. No more
> assembler check
>
Hi,
the check this patch removes has remained from times when ancestor
jump functions have been only used for devirtualization and also
contained BINFOs. It is not necessary now and should have been
removed long time ago.
Pre-approved by Honza and bootstrapped and tested on x86_64-linux, I am
go
sheesh … EWRONGREVISEDPATCH
> On 5 Nov 2021, at 13:08, Iain Sandoe wrote:
>
> I tried enabling this on x86-64-linux (just for interest) and it seems to work
> OK there too - but that testing revealed a thinko that didn’t show with a
> a normal regstrap.
… now with the correct patch.
[PATCH v2]
As discussed this splits the analysis loop into two, first settling
on a vector mode used for the main loop and only then analyzing
the epilogue of that for possible vectorization. That makes it
easier to put in support for unrolled main loops.
On the way I've realized some cleanup opportunities,
The stack protector implementation hides symbols in a const unspec, which means
movdi/movsi patterns must always support const on symbol operands and explicitly
strip away the unspec. Do this for the recently added GOT alternatives. Add a
test to ensure stack-protector tests GOT accesses as well.
I forgot to commit the changes done as response to Richards review
before committing.
Will push after bootstrap.
2021-11-05 Richard Biener
* tree-vect-loop.c (vect_analyze_loop): Remove obsolete
comment and expand on another one. Combine nested if.
---
gcc/tree-vect-loop.c |
> On 5 Nov 2021, at 09:48, Rasmus Villemoes wrote:
> Applied to master and pushed - hope I've done it right.
AFAICS, yes.
> How about the gcc-11 branch, can it be applied there as well,
Yes, I think so. The builds you do used to work before
the change that introduced the ifdef, IIUC, and the
On 05/11/2021 15.08, Olivier Hainque wrote:
>
>
>> On 5 Nov 2021, at 09:48, Rasmus Villemoes wrote:
>> Applied to master and pushed - hope I've done it right.
>
> AFAICS, yes.
>
>> How about the gcc-11 branch, can it be applied there as well,
>
> Yes, I think so. The builds you do used to wor
On 10/26/21 09:45, Richard Biener wrote:
On Mon, Oct 25, 2021 at 6:32 PM Segher Boessenkool
wrote:
Hi!
On Mon, Oct 25, 2021 at 03:36:25PM +0200, Martin Liška wrote:
--- a/gcc/config/rs6000/rs6000-internal.h
+++ b/gcc/config/rs6000/rs6000-internal.h
@@ -189,4 +189,13 @@ extern bool rs6000_pas
Pushed.
Martin
PR gcov-profile/102945
gcc/testsuite/ChangeLog:
* gcc.dg/gcov-info-to-gcda.c: Filter supported targets.
---
gcc/testsuite/gcc.dg/gcov-info-to-gcda.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/gcov-info-to-gcda.c
b
The code uses intentionally braced-groups within expressions:
({\
uptr pc;\
asm("lea 0(%%rip), %0" : "=r"(pc)); \
pc; \
})
And we emit gazillion of warnings now:
/home/marxi
The main path discovery function was due for a cleanup. First,
there's a nagging goto and second, my bitmap use was sloppy. Hopefully
this makes the code easier for others to read.
Regstrapped on x86-64 Linux. I also made sure there were no difference
in the number of threads with this patch.
Wilco Dijkstra writes:
> The stack protector implementation hides symbols in a const unspec, which
> means
> movdi/movsi patterns must always support const on symbol operands and
> explicitly
> strip away the unspec. Do this for the recently added GOT alternatives. Add a
> test to ensure stack-p
> On 5 Nov 2021, at 15:12, Rasmus Villemoes wrote:
>
>> Yes, I think so. The builds you do used to work before
>> the change that introduced the ifdef,
>
> Well, apart from all the other fixups, some of which are not
> upstreamable, that I also need to apply :)
Sure. My comment was only mea
This allows people to host a c-family/fortran GCC cross-compiler on
aarch64-apple-darwin (support for Ada will follow in a separate patch).
At present, there is no special action needed for aarch64-darwin;
this just pulls in generic Darwin code.
Tested on aarch64-darwin20,
OK for master?
thanks,
The D language build on hppa64 does not include pa64-hpux.h. It only includes
pa.h. As
a result PREFERRED_DEBUGGING_TYPE was not defined. This caused a build error
when defaults.h
was included.
The include issue might affect other defines but so far I haven't noticed any
problems.
Tested o
On Fri, Nov 5, 2021 at 8:00 AM Martin Liška wrote:
>
> The code uses intentionally braced-groups within expressions:
>
> ({\
Should we add __extension__ here?
>uptr pc;\
>asm("lea 0(%%rip), %0" : "=r"(pc)); \
>
On Fri, Nov 05, 2021 at 11:31:58AM +0100, Richard Biener wrote:
> On Fri, Nov 5, 2021 at 10:54 AM Jakub Jelinek wrote:
> >
> > On Fri, Nov 05, 2021 at 10:42:05AM +0100, Richard Biener via Gcc-patches
> > wrote:
> > > I had the impression we have support for PCH file relocation to deal with
> > >
On 11/5/21 16:22, H.J. Lu wrote:
Should we add __extension__ here?
I tried doing that but it didn't help me with the warning.
Maybe I did something wrong?
Cheers,
Martin
On Fri, Nov 05, 2021 at 04:25:53PM +0100, Martin Liška wrote:
> On 11/5/21 16:22, H.J. Lu wrote:
> > Should we add __extension__ here?
>
> I tried doing that but it didn't help me with the warning.
> Maybe I did something wrong?
Works for me just fine say on:
void foo ()
{
int a = ({ int d = 1;
On Fri, Nov 5, 2021 at 8:25 AM Martin Liška wrote:
>
> On 11/5/21 16:22, H.J. Lu wrote:
> > Should we add __extension__ here?
>
> I tried doing that but it didn't help me with the warning.
> Maybe I did something wrong?
[hjl@gnu-cfl-2 tmp]$ cat y.cc
#include
#define uptr uintptr_t
# define GE
Robin Dapp writes:
> Hi Richard,
>
> after giving it a second thought, and seeing that most of the changes to
> existing code are not strictly necessary anymore, I figured it could be
> easier not changing the current control flow too much like in the
> attached patch.
>
> The changes remaining
The way in which a C++20 coroutine is specified discards any value
that might be returned from the initial or final await expressions.
This PR ICE was caused by an initial await expression with an
await_resume () returning a reference, the function rewrite code
was not set up to expect this.
Fixe
The wording of the standard has been clarified to be explicit that
the the parameters to any user-defined operator-new in the promise
class should be lvalues.
tested on x86_64 darwin, linux,
OK for master and backports?
thanks
Iain
Signed-off-by: Iain Sandoe
PR c++/100772
gcc/cp/Change
When we query is_capture_proxy(), and the scope of the var is one of
the two coroutine helpers, we need to look for the scope information
that pertains to the original function (represented by the ramp now).
We can look up the ramp function from either helper (in practice, the
only caller would be
On 11/5/21 16:29, Jakub Jelinek wrote:
On Fri, Nov 05, 2021 at 04:25:53PM +0100, Martin Liška wrote:
On 11/5/21 16:22, H.J. Lu wrote:
Should we add __extension__ here?
I tried doing that but it didn't help me with the warning.
Maybe I did something wrong?
Works for me just fine say on:
void
On 8/23/21 10:54, Martin Liška wrote:
On 8/16/21 13:13, Martin Liška wrote:
I'm going to apply the following 3 tested patches.
Martin
One more patch I've just tested.
Martin
And one more backport.
MartinFrom 64fbc25cb6983725fefe313bfedd3657df795d54 Mon Sep 17 00:00:00 2001
From: Martin Li
Thanks all for the information.
Based on the information so far, my understanding is that we cannot revert
r12-979-g782e57f2c09
Since it’s for enabling YMM and ZMM registers to be used for by_pieces
operations on X86.
Let me know if I miss anything here.
FYI.
This issue was found during my wo
This is host-only support (target support will come later).
This will allow someone (with an existing Ada compiler on the
platform - which can be provided by the experimental aarch64-darwin
branch) - to build the host tools (gnatmake and friends) for a
non-native cross.
The existing provisions fo
On Fri, Nov 05, 2021 at 04:11:36PM +, Qing Zhao wrote:
> 3076 if (TREE_CODE (TREE_TYPE (lhs)) != BOOLEAN_TYPE
> 3077 && tree_fits_uhwi_p (var_size)
> 3078 && (init_type == AUTO_INIT_PATTERN
> 3079 || !is_gimple_reg_type (var_type))
> 3080 && int
> This is host-only support (target support will come later).
>
> This will allow someone (with an existing Ada compiler on the
> platform - which can be provided by the experimental aarch64-darwin
> branch) - to build the host tools (gnatmake and friends) for a
> non-native cross.
>
> The existi
> On 5 Nov 2021, at 15:25, Jakub Jelinek wrote:
>
> On Fri, Nov 05, 2021 at 11:31:58AM +0100, Richard Biener wrote:
>> On Fri, Nov 5, 2021 at 10:54 AM Jakub Jelinek wrote:
>>>
>>> On Fri, Nov 05, 2021 at 10:42:05AM +0100, Richard Biener via Gcc-patches
>>> wrote:
I had the impression w
Hi Arno,
> On 5 Nov 2021, at 16:36, Arnaud Charlet wrote:
>
>> This is host-only support (target support will come later).
>>
>> This will allow someone (with an existing Ada compiler on the
>> platform - which can be provided by the experimental aarch64-darwin
>> branch) - to build the host to
> No, I just managed to delete it when adding the post-notes to the email
> header ;-) … and then didn’t notice when git send-emailing it …
OK!
> Signed-off-by: Iain Sandoe
>
> gcc/ada/ChangeLog:
should be gcc/ada/
> * gcc-interface/Make-lang.in: Use ios signal trampoline code
> f
Hi Jakub,
On 2021/6/24 11:55 PM, Jakub Jelinek wrote:
On Fri, May 14, 2021 at 09:20:25PM +0800, Chung-Lin Tang wrote:
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index e790f08b23f..69c4a8e0a0a 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -10374,6 +10374,7 @@ gimplify_adjust_omp_clauses_
On Fri, 2021-11-05 at 00:04 -0400, Michael Meissner wrote:
> Add new constant data structure.
>
> This patch provides the data structure and function to convert a
> CONST_INT, CONST_DOUBLE, CONST_VECTOR, or VEC_DUPLICATE of a constant) to
> an array of bytes, half-words, words, and double words t
On 11/4/21 3:42 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
When users don't use constexpr everywhere in initialization of namespace
scope non-comdat vars and the initializers aren't constant when FE is
looking at them, the FE performs dynamic initialization of those variables.
But after inlini
Without TImode support on hppa64, it is necessary to disable building libgomp
with fortran.
Previously, we didn't support TImode because we need both DImode and TImode
divmod routines
from libgcc. The standard build only builds one of the two. This is nominally
determined
by MIN_UNITS_PER_WO
OK,removing the call to vec::contains() is clearly the right move.
Rather than go with the extra bitmap to track whats in the vector, I
have done a couple of things.
1 - Abstracted the update list into its own class, making it easier
to change the underlying mechaism from a stack to a breadth
As detailed in the PR, when the IL is changing between queries, the
imports and def chains of an ssa-name may change,a nd when coparing with
a newly created ssa-name, certain assumptions about presence/lack of
presence between lists may no longer be true.
This patch simply removes the offendin
Hello.
This strips .gk from aux_base_name in coverage.c.
Do you like the implementation of endswith, or do we have the functionality
somewhere?
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
PR gcov-profile/100520
gcc/Chan
> Hello.
>
> This strips .gk from aux_base_name in coverage.c.
> Do you like the implementation of endswith, or do we have the functionality
> somewhere?
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> PR gcov-p
> On Nov 5, 2021, at 11:17 AM, Jakub Jelinek wrote:
>
> On Fri, Nov 05, 2021 at 04:11:36PM +, Qing Zhao wrote:
>> 3076 if (TREE_CODE (TREE_TYPE (lhs)) != BOOLEAN_TYPE
>> 3077 && tree_fits_uhwi_p (var_size)
>> 3078 && (init_type == AUTO_INIT_PATTERN
>> 3079
On 05/11/2021 15:14, Iain Sandoe via Gcc-patches wrote:
This allows people to host a c-family/fortran GCC cross-compiler on
aarch64-apple-darwin (support for Ada will follow in a separate patch).
At present, there is no special action needed for aarch64-darwin;
this just pulls in generic Darw
On Fri, 2021-11-05 at 00:07 -0400, Michael Meissner wrote:
> Add LXVKQ support.
>
> This patch adds support to generate the LXVKQ instruction to load specific
> IEEE-128 floating point constants.
>
> Compared to the last time I submitted this patch, I modified it so that it
> uses the bit pattern
Early ping.
Am 31.10.21 um 22:35 schrieb Harald Anlauf via Fortran:
Dear Fortranners,
the fix for initialization of DT arrays caused an apparent regression for
cases where inconsistent ranks were used in such an initialization.
This caused either an ICE in subsequent uses of these arrays, or sh
On Fri, Nov 05, 2021 at 12:52:51PM -0500, will schmidt wrote:
> > diff --git a/gcc/config/rs6000/predicates.md
> > b/gcc/config/rs6000/predicates.md
> > index 956e42bc514..e0d1c718e9f 100644
> > --- a/gcc/config/rs6000/predicates.md
> > +++ b/gcc/config/rs6000/predicates.md
> > @@ -601,6 +601,14 @
On Linux/x86_64,
33f1d038708a793a498076c8647165613ec90661 is the first bad commit
commit 33f1d038708a793a498076c8647165613ec90661
Author: Richard Biener
Date: Wed Oct 27 13:14:41 2021 +0200
First refactor of vect_analyze_loop
caused
FAIL: gfortran.dg/alloc_comp_assign_2.f90 -O3 -fomit-
On Fri, Nov 05, 2021 at 12:01:43PM -0500, will schmidt wrote:
> On Fri, 2021-11-05 at 00:04 -0400, Michael Meissner wrote:
> > Add new constant data structure.
> >
> > This patch provides the data structure and function to convert a
> > CONST_INT, CONST_DOUBLE, CONST_VECTOR, or VEC_DUPLICATE of a
On Fri, 5 Nov 2021 at 13:20, Bill Schmidt wrote:
>
> On 11/5/21 7:44 AM, Jonathan Wakely wrote:
> > On Thu, 4 Nov 2021 at 20:44, Bill Schmidt wrote: For posterity: This
> was discussed briefly on IRC, and Segher approved with some simplifications
> and a request to implement a fail/retry check. H
Le 27/10/2021 à 23:11, Bernhard Reutner-Fischer via Fortran a écrit :
Delete some more declarations without definitions and make some
functions static.
Bootstrapped and regtested on x86_64-unknown-linux without regressions.
Ok for trunk?
Ok.
Thanks
Mikael
Tested x86+64-linux, pushed to trunk.
libstdc++-v3/ChangeLog:
* src/c++11/random.cc (__x86_rdrand, __x86_rdseed): Add
[[unlikely]] attribute.
---
libstdc++-v3/src/c++11/random.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libstdc++-v3/src/c++11/rando
This adds additional "getentropy" and "arc4random" tokens to
std::random_device. The former is supported on Glibc and OpenBSD (and
apparently wasm), and the latter is supported on various BSDs.
I'm trying to test this on OpenBSD but I can't bootstrap GCC using the
system clang.
libstdc++-v3/Chan
Oops sorry - this is NOT committed yet. I won't push it until I've tested
it on at least one BSD, preferably OpenBSD so I can test parts of the new
code.
On Fri, 5 Nov 2021 at 18:21, Jonathan Wakely via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> This adds additional "getentropy" and "arc4random
Le 29/10/2021 à 01:58, Bernhard Reutner-Fischer via Fortran a écrit :
On Wed, 27 Oct 2021 23:39:43 +0200
Bernhard Reutner-Fischer wrote:
Ping
[hmz. it's been a while, I'll rebase and retest this one.
Ok if it passes?]
Testing passed without any new regressions.
Ok for trunk?
thanks,
On Mon,
On 9/28/21 16:20, Marek Polacek wrote:
On Thu, Sep 23, 2021 at 02:25:16PM -0400, Jason Merrill wrote:
On 9/20/21 18:59, Marek Polacek via Gcc-patches wrote:
+ handle_ignored_attributes_option (&v);
+ /* ??? We can't free (args); here. */
Perhaps we want to copy strings in handle_ig
On Fri, 2021-11-05 at 00:09 -0400, Michael Meissner wrote:
> Generate XXSPLTIW on power10.
>
Hi,
> This patch adds support to automatically generate the ISA 3.1 XXSPLTIW
> instruction for V8HImode, V4SImode, and V4SFmode vectors. It does this by
> adding support for vector constants that can b
On Fri, 2021-11-05 at 00:10 -0400, Michael Meissner wrote:
> Generate XXSPLTIDP for vectors on power10.
>
> This patch implements XXSPLTIDP support for all vector constants. The
> XXSPLTIDP instruction is given a 32-bit immediate that is converted to a
> vector
> of two DFmode constants. The im
1 - 100 of 153 matches
Mail list logo
