Thanks Jonathan!
On Sun, Jan 23, 2022 at 5:51 PM Jonathan Wakely wrote:
> I thought I'd CC'd Maged on this patch, but apparently not. I've
> pushed it to trunk now.
>
> On Fri, 21 Jan 2022 at 13:50, Jonathan Wakely wrote:
> >
> > Tested powerpc64le-linux. Does anybody see a problem with this cha
Committed, thanks!
On Wed, Jan 19, 2022 at 5:18 PM Martin Liška wrote:
>
> On 1/19/22 10:15, shi...@iscas.ac.cn wrote:
> > |From: LiaoShihua After commit
> > 591b6e00d1bfe12932ca31530d5859f95db8a35a " riscv: fix -Wformat-diag errors
> > ", some strings in implement was changed. This patch upda
On 1/20/22 04:02, Richard Sandiford wrote:
Thanks for the patch and sorry for the (very) slow review.
Thanks for the review, Richard :).
+/* Handle a "no_sanitize_shadow_call_stack" attribute; arguments as in
+ struct attribute_spec.handler. */
+static tree
+handle_no_sanitize_shadow_ca
On Sun, Jan 23, 2022 at 4:35 PM Hongtao Liu wrote:
>
> On Sun, Jan 23, 2022 at 8:28 PM H.J. Lu via Gcc-patches
> wrote:
> >
> > Return false for invalid mode on memory broadcast in bcst_mem_operand:
> >
> > (vec_duplicate:V16SF (mem/j:V4SF (reg/v/f:DI 109 [ b ])))
> >
> Yes, thanks.
I will also
On Sun, Jan 23, 2022 at 8:28 PM H.J. Lu via Gcc-patches
wrote:
>
> Return false for invalid mode on memory broadcast in bcst_mem_operand:
>
> (vec_duplicate:V16SF (mem/j:V4SF (reg/v/f:DI 109 [ b ])))
>
Yes, thanks.
> gcc/
>
> PR target/104188
> * config/i386/predicates.md (bcst_mem
I thought I'd CC'd Maged on this patch, but apparently not. I've
pushed it to trunk now.
On Fri, 21 Jan 2022 at 13:50, Jonathan Wakely wrote:
>
> Tested powerpc64le-linux. Does anybody see a problem with this change?
>
>
> The non-atomic store that sets both reference counts to zero uses a
> type-
Tested powerpc64le-linux, pushed to trunk.
libstdc++-v3/ChangeLog:
PR libstdc++/104032
* include/std/spanstream (basic_spanbuf(basic_spanbuf&&)): Use
mem-initializer for _M_buf.
(basic_spanbuf::Operator=(basic_spanbuf&&)): Fix ill-formed
member access.
Tested powerpc64le-linux, pushed to trunk.
We can use the new from_chars implementation when long double and double
have the same representation.
libstdc++-v3/ChangeLog:
* src/c++17/floating_from_chars.cc (USE_STRTOD_FOR_FROM_CHARS):
Define macro for case where std::from_chars i
Tested powerpc64le-linux, pushed to trunk.
I broke this unintentionally in r12-4259.
libstdc++-v3/ChangeLog:
PR libstdc++/104174
* include/bits/hashtable_policy.h (_Map_base): Add partial
specialization for maps with const key types.
* testsuite/23_containers/uno
On 1/22/22 16:24, Patrick Palka wrote:
Here the call to the &&-qualified toLower() is incorrectly rejected
because the object expression is deemed to be an lvalue, even though it's
really a prvalue. The object expression, instance()->applicationName(),
is expressed as an INDIRECT_REF of a COMPOU
On 1/17/22 14:29, will wray wrote:
Attached
(the cut n paste looks like it removed some whitespace formatting)
Pushed, thanks! I incorporated the introduction from your initial email
in the commit message.
Jason
From: Andrew Pinski
This is a simple patch which simplifies the __builtin_aarch64_sqrt* builtins
into the internal function SQRT which allows for constant folding and other
optimizations at the gimple level. It was originally suggested we do to
__builtin_sqrt just for __builtin_aarch64_sqrtdf whe
On Tue, 18 Jan 2022, Palmer Dabbelt wrote:
> Yep. Seeing this go by, though, I think there's some English issues with the
> original messages. I'd write it more like this, but I'm never 100% sure on
> these things:
>
>diff --git a/gcc/common/config/riscv/riscv-common.cc
> b/gcc/common/confi
Dear Fortranners,
conversions between different character kinds using TRANSFER exhibit
inconsistencies that can occur between expr->representation.string
(which is char*) on the one hand, and expr->->value.character.string.
One issue (in target-memory.cc) is easily fixed by simply passing
a conve
Thanks for the review.
Here's the updated patch.
Le mardi 18 janvier 2022 à 18:22 -0500, David Malcolm a écrit :
> On Mon, 2022-01-17 at 21:02 -0500, Antoni Boucher via Gcc-patches
> wrote:
> > Hi.
> > This option will be useful for rustc_codegen_gcc to hide the error
> > about unsupported 128-bit
Hello,
Le 21/01/2022 à 00:59, David Malcolm via Gcc-patches a écrit :
diff --git a/gcc/analyzer/constraint-manager.cc
b/gcc/analyzer/constraint-manager.cc
index 568e7150ea7..7c4a85bbb24 100644
--- a/gcc/analyzer/constraint-manager.cc
+++ b/gcc/analyzer/constraint-manager.cc
@@ -301,6 +301,80 @@
Le 23/01/2022 à 11:05, FX a écrit :
Hi Mikael,
I spotted two unexpected things (to me at least) related to x86 extended type:
- You check for endianness, so the format is not x86-specific?
- Is it expected that the padding bits are in the middle of the data in the
big-endian case?
IEEE speci
Am Sa., 15. Jan. 2022 um 14:56 Uhr schrieb Marc Nieper-Wißkirchen
:
>
> Jeff, David, do you need any more input from my side?
>
> -- Marc
>
> Am Sa., 8. Jan. 2022 um 17:32 Uhr schrieb Jeff Law :
> >
> >
> >
> > On 1/6/2022 6:53 AM, David Malcolm via Gcc-patches wrote:
> > > On Sun, 2021-12-19 at 22
Return false for invalid mode on memory broadcast in bcst_mem_operand:
(vec_duplicate:V16SF (mem/j:V4SF (reg/v/f:DI 109 [ b ])))
gcc/
PR target/104188
* config/i386/predicates.md (bcst_mem_operand): Also check mode
of memory broadcast.
gcc/testsuite/
PR target/1
On Sun, Jan 23, 2022 at 10:06:24AM +0100, Uros Bizjak wrote:
> > 2022-01-22 Jakub Jelinek
> >
> > * config/linux.h (OPTION_GLIBC_P, OPTION_UCLIBC_P,
> > OPTION_BIONIC_P, OPTION_MUSL_P): Define.
> > (OPTION_GLIBC, OPTION_UCLIBC, OPTION_BIONIC, OPTION_MUSL): Redefine
> >
Hi Mikael,
> I spotted two unexpected things (to me at least) related to x86 extended type:
> - You check for endianness, so the format is not x86-specific?
> - Is it expected that the padding bits are in the middle of the data in the
> big-endian case?
IEEE specifies that extended precision typ
在 2022/1/23 下午5:00, Xi Ruoyao 写道:
On Sun, 2022-01-23 at 16:39 +0800, 程璐璐 wrote:
在 2022/1/22 下午4:42, Xi Ruoyao 写道:
On Sat, 2022-01-22 at 15:55 +0800, Chenghua Xu wrote:
+mstrict-align
+Target Var(TARGET_STRICT_ALIGN) Init(0)
+Do not generate unaligned memory accesses.
Section 2.1.8 o
> Does anyone know the reasoning behind this?
Solaris preserves the full 64-bit registers in 32-bit mode.
--
Eric Botcazou
> While playing around with the compiler options trying to find a solution, I
> made an interesting discovery which is that GCC support 64-bit compare and
> swap on SPARCv8plus but not on 32-bit SPARCv9:
>
> glaubitz@gcc202:~$ echo | gcc -mv8plus -E -dM -|grep -i SWAP
> #define __GCC_HAVE_SYNC_COM
On Sat, Jan 22, 2022 at 7:04 PM Jakub Jelinek via Gcc-patches
wrote:
>
> On Sat, Jan 22, 2022 at 01:16:38PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > Actually, I suspect we either need something like following patch,
> > or need to change gcc/config/{linux,rs6000/linux{,64},alpha/linux}.h
>
On Sun, 2022-01-23 at 16:39 +0800, 程璐璐 wrote:
>
> 在 2022/1/22 下午4:42, Xi Ruoyao 写道:
>
>
> > On Sat, 2022-01-22 at 15:55 +0800, Chenghua Xu wrote:
> >
> >
> > > +mstrict-align
> > > +Target Var(TARGET_STRICT_ALIGN) Init(0)
> > > +Do not generate unaligned memory accesses.
> > Section 2.1.8 of
在 2022/1/22 下午4:42, Xi Ruoyao 写道:
On Sat, 2022-01-22 at 15:55 +0800, Chenghua Xu wrote:
+mstrict-align
+Target Var(TARGET_STRICT_ALIGN) Init(0)
+Do not generate unaligned memory accesses.
Section 2.1.8 of LoongArch spec says "load/store instruction *may* be
implemented to allow unaligned memo
在 2022/1/22 下午5:31, Jakub Jelinek 写道:
On Sat, Jan 22, 2022 at 05:05:00PM +0800, Xi Ruoyao wrote:
On Sat, 2022-01-22 at 16:56 +0800, 程璐璐 wrote:
Under the MIPS architecture, *.opt files are also generated in
$(srcdir).
Well, but then you should put the commands for generating those files
into
28 matches
Mail list logo
