On Wed, Aug 4, 2021 at 7:28 PM Richard Biener
wrote:
>
> On Wed, Aug 4, 2021 at 4:39 AM Hongtao Liu wrote:
> >
> > On Mon, Aug 2, 2021 at 2:31 PM liuhongt wrote:
> > >
> > > gcc/ChangeLog:
> > >
> > > * config/i386/i386-modes.def (FLOAT_MODE): Define ieee HFmode.
> > > * config/i
On Thu, Aug 5, 2021 at 3:31 PM Hongtao Liu wrote:
>
> On Wed, Aug 4, 2021 at 7:28 PM Richard Biener
> wrote:
> >
> > On Wed, Aug 4, 2021 at 4:39 AM Hongtao Liu wrote:
> > >
> > > On Mon, Aug 2, 2021 at 2:31 PM liuhongt wrote:
> > > >
> > > > gcc/ChangeLog:
> > > >
> > > > * config/i386/
Hi!
I've noticed in ucnid.h two adjacent lines that had all flags and combine
values identical and as such were supposed to be merged.
This is due to a bug in makeucnid.c, which records last_flag,
last_combine and really_safe of what has just been printed, but
because of a typo mishandles it for
Hi!
The following patch (incremental to the makeucnid.c fix) regenerates
ucnid.h with https://www.unicode.org/Public/13.0.0/ucd/ files.
Bootstrapped/regtested on top of the previous patch (which has also
been bootstrapped/regtested alone) on x86_64-linux and i686-linux,
ok for trunk?
2021-08-04
This is a regression present on the mainline, caused by an oversight of mine
in an earlier fix for SRA, whereby I forgot to exclude cases for reverse SSO.
Tested on x86-64/Linux, applied on the mainline as obvious.
2021-08-05 Eric Botcazuo
PR tree-optimization/101626
* tree-
Hi,
V2 of this change implements the same approach as for the multiply
and add-widen patches.
Regression tested and bootstrapped on aarch64-none-linux-gnu - no
issues.
Ok for master?
Thanks,
Jonathan
---
gcc/ChangeLog:
2021-07-28 Jonathan Wright
* config/aarch64/aarch64.c: Traver
On 2021/8/3 8:22 PM, Thomas Schwinge wrote:
Hi Chung-Lin!
On 2021-08-02T21:10:57+0800, Chung-Lin Tang wrote:
--- a/libgomp/fortran.c
+++ b/libgomp/fortran.c
+int32_t
+omp_get_device_num_ (void)
+{
+ return omp_get_device_num ();
+}
Missing 'ialias_redirect (omp_get_device_num)'?
Grü
Hello.
I noticed the patch caused new Clang warnings:
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-clang/build/gcc/tree-ssa-phiopt.c:2586:10:
warning: comparison of different enumeration types in switch statement
('combined_fn' and 'built_in_function') [-Wenum-compare-switch]
/home/marx
I'm going to push the commit to all active branches (except master).
The patch is needed in order to support recent glibc (2.34).
libsanitizer/ChangeLog:
PR sanitizer/101749
* sanitizer_common/sanitizer_posix_libcdep.cpp: Prevent
generation of dependency on _cxa_guard fo
on 2021/8/4 下午8:04, Richard Biener wrote:
> On Wed, Aug 4, 2021 at 12:47 PM Kewen.Lin wrote:
>>
>> on 2021/8/4 下午6:01, Richard Biener wrote:
>>> On Wed, Aug 4, 2021 at 4:36 AM Kewen.Lin wrote:
on 2021/8/3 下午8:08, Richard Biener wrote:
> On Fri, Jul 30, 2021 at 7:20 AM Kewen.Lin wro
On Wed, Aug 4, 2021 at 7:55 PM David Faust via Gcc-patches
wrote:
>
> Expose the function lookup_type_die in dwarf2out, so that it can be used
> by CTF/BTF when adding BPF CO-RE information. The function is now
> non-static, and an extern prototype is added in dwarf2out.h.
OK.
> gcc/ChangeLog:
>
Ping.
On Thu, Jul 29, 2021 at 9:36 PM Christoph Müllner wrote:
>
> On Thu, Jul 29, 2021 at 8:54 PM Palmer Dabbelt wrote:
> >
> > On Tue, 27 Jul 2021 02:32:12 PDT (-0700), cmuell...@gcc.gnu.org wrote:
> > > Ok, so if I understand correctly Palmer and Andrew prefer
> > > overlap_op_by_pieces to be
Ping.
On Thu, Jul 29, 2021 at 4:33 PM Christoph Muellner
wrote:
>
> The RISC-V cpymemsi expansion is called, whenever the by-pieces
> infrastructure will not be taking care of the builtin expansion.
> Currently, that's the case for e.g. memcpy() with n <= 24 bytes.
> The code emitted by the by-pi
On Thu, Aug 5, 2021 at 9:25 AM Hongtao Liu wrote:
>
> On Wed, Aug 4, 2021 at 7:28 PM Richard Biener
> wrote:
> >
> > On Wed, Aug 4, 2021 at 4:39 AM Hongtao Liu wrote:
> > >
> > > On Mon, Aug 2, 2021 at 2:31 PM liuhongt wrote:
> > > >
> > > > gcc/ChangeLog:
> > > >
> > > > * config/i386/
On Wed, Aug 4, 2021 at 12:33 PM Richard Biener wrote:
> The following avoids vectorizing MIN/MAX reductions on bools which,
> when ending up as vector(2) would need to be
> adjusted because of the sign change. The fix instead avoids any
> reduction vectorization where the result isn't compatibl
On Thu, 5 Aug 2021, Christophe Lyon wrote:
> On Wed, Aug 4, 2021 at 12:33 PM Richard Biener wrote:
>
> > The following avoids vectorizing MIN/MAX reductions on bools which,
> > when ending up as vector(2) would need to be
> > adjusted because of the sign change. The fix instead avoids any
> >
On Wed, Aug 4, 2021 at 2:08 PM Richard Biener wrote:
> On Wed, 4 Aug 2021, Richard Sandiford wrote:
>
> > Richard Biener writes:
> > > This adds a gather vectorization capability to the vectorizer
> > > without target support by decomposing the offset vector, doing
> > > sclar loads and then bui
On Thu, Aug 5, 2021 at 5:24 PM Richard Biener
wrote:
>
> On Thu, Aug 5, 2021 at 9:25 AM Hongtao Liu wrote:
> >
> > On Wed, Aug 4, 2021 at 7:28 PM Richard Biener
> > wrote:
> > >
> > > On Wed, Aug 4, 2021 at 4:39 AM Hongtao Liu wrote:
> > > >
> > > > On Mon, Aug 2, 2021 at 2:31 PM liuhongt wrot
At this point I don't see any use for the legacy mode, which I had
originally left in place during the transition.
This patch removes the legacy back threader, and cleans up the code a
bit. There are no functional changes to the non-legacy code.
Tested on x86-64 Linux.
OK?
gcc/ChangeLog:
On Thu, 5 Aug 2021, Christophe Lyon wrote:
> On Wed, Aug 4, 2021 at 2:08 PM Richard Biener wrote:
>
> > On Wed, 4 Aug 2021, Richard Sandiford wrote:
> >
> > > Richard Biener writes:
> > > > This adds a gather vectorization capability to the vectorizer
> > > > without target support by decomposi
On Thu, 29 Jul 2021 at 19:58, Prathamesh Kulkarni
wrote:
>
> Hi,
> The attached patch replaces builtins in vld1_dup intrinsics with call
> to corresponding vdup_n intrinsic and removes entry for vld1_dup from
> arm_neon_builtins.def.
> Bootstrapped+tested on arm-linux-gnueabihf.
> OK to commit ?
p
On Thu, Aug 5, 2021 at 11:43 AM Hongtao Liu wrote:
>
> On Thu, Aug 5, 2021 at 5:24 PM Richard Biener
> wrote:
> >
> > On Thu, Aug 5, 2021 at 9:25 AM Hongtao Liu wrote:
> > >
> > > On Wed, Aug 4, 2021 at 7:28 PM Richard Biener
> > > wrote:
> > > >
> > > > On Wed, Aug 4, 2021 at 4:39 AM Hongtao L
On Mon, 12 Jul 2021 at 15:24, Prathamesh Kulkarni
wrote:
>
> On Mon, 12 Jul 2021 at 15:23, Prathamesh Kulkarni
> wrote:
> >
> > On Mon, 5 Jul 2021 at 14:47, Prathamesh Kulkarni
> > wrote:
> > >
> > > Hi,
> > > This patch replaces builtins with __a * __b for signed variants of
> > > vmul_n intrin
As per $SUBJECT. OK to install?
Richard
gcc/
PR middle-end/101787
* doc/md.texi (cond_ashl, cond_ashr, cond_lshr): Document.
---
gcc/doc/md.texi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index f6d1bc1ad0f..f8047aefccc 100
Jonathan Wright writes:
> Hi,
>
> V2 of this patch uses the same approach as that just implemented
> for the multiply high-half cost patch.
>
> Regression tested and bootstrapped on aarch64-none-linux-gnu - no
> issues.
>
> Ok for master?
>
> Thanks,
> Jonathan
>
> ---
>
> gcc/ChangeLog:
>
> 2021-
On Thu, Aug 5, 2021 at 12:37 PM Richard Sandiford via Gcc-patches
wrote:
>
> As per $SUBJECT. OK to install?
OK.
> Richard
>
>
> gcc/
> PR middle-end/101787
> * doc/md.texi (cond_ashl, cond_ashr, cond_lshr): Document.
> ---
> gcc/doc/md.texi | 11 +++
> 1 file changed,
Jonathan Wright writes:
> Hi,
>
> V2 of this change implements the same approach as for the multiply
> and add-widen patches.
>
> Regression tested and bootstrapped on aarch64-none-linux-gnu - no
> issues.
>
> Ok for master?
>
> Thanks,
> Jonathan
>
> ---
>
> gcc/ChangeLog:
>
> 2021-07-28 Jonatha
Hi,
Loops containing long long shifts fail to vectorize due to the vectorizer
not being able to recognize long long right shifts. This is due to a bug
in the iterator used for the vashr and vlshr patterns in aarch64-simd.md.
Tested and bootstrapped on aarch64-linux. OK?
2021-08-05 Tejas Belagod
Thanks, Christophe, I've updated the testsuite to fix all the issues I could
see from your test runs.
This is what I've finally committed, but if there's any more fallout, please
let me know.
R.
Richard Earnshaw (3):
arm: ensure the arch_name is always set for the build target
arm: Don't rec
This should never happen now if GCC is invoked by the driver, but in
the unusual case of calling cc1 (or its ilk) directly from the command
line the build target's arch_name string can remain NULL. This can
complicate later processing meaning that we need to check for this
case explicitly in some
arm_configure_build_target is usually used to reconfigure the
arm_active_target structure, which is then used to reconfigure a
number of other global variables describing the current target.
Occasionally, however, we need to use arm_configure_build_target to
construct a temporary target structure
A change to the way gas interprets the .fpu directive in binutils-2.34
means that issuing .fpu will clear any features set by .arch_extension
that apply to the floating point or simd units. This unfortunately
causes problems for more recent versions of the architecture because
we currently emit .
Richard Biener writes:
> On Tue, Aug 3, 2021 at 2:09 PM Richard Sandiford via Gcc-patches
> wrote:
>>
>> When the vectoriser scalarises a strided store, it counts one
>> scalar_store for each element plus one vec_to_scalar extraction
>> for each element. However, extracting element 0 is free on
On 7/23/21 7:57 PM, Segher Boessenkool wrote:
Hi!
On Fri, Jul 23, 2021 at 07:47:54AM +0200, Martin Liška wrote:
On 7/12/21 7:20 PM, Segher Boessenkool wrote:
+static __attribute__ ((optimize ("-fno-stack-protector"))) __typeof
(f) *
-fno-stack-protector is default.
Yes, but one needs an op
Hi Jonathan,
On Wed, Aug 4, 2021 at 2:04 PM Jonathan Wakely via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> On 04/08/21 12:56 +0100, Jonathan Wakely wrote:
> >... and container adaptors.
> >
> >This adds the [[nodiscard]] attribute to functions with no side-effects
> >for the sequence contain
On Thu, Aug 5, 2021 at 2:04 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Tue, Aug 3, 2021 at 2:09 PM Richard Sandiford via Gcc-patches
> > wrote:
> >>
> >> When the vectoriser scalarises a strided store, it counts one
> >> scalar_store for each element plus one vec_to_scalar ext
On Thu, 5 Aug 2021 at 15:11, Christophe Lyon via Libstdc++
wrote:
>
> Hi Jonathan,
>
> On Wed, Aug 4, 2021 at 2:04 PM Jonathan Wakely via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
>
> > On 04/08/21 12:56 +0100, Jonathan Wakely wrote:
> > >... and container adaptors.
> > >
> > >This adds the
On Tue, 3 Aug 2021 at 20:52, Christophe Lyon
wrote:
>
>
>
> On Tue, Aug 3, 2021 at 12:57 PM Prathamesh Kulkarni
> wrote:
>>
>> On Tue, 3 Aug 2021 at 14:59, Christophe Lyon
>> wrote:
>> >
>> >
>> >
>> > On Tue, Jul 6, 2021 at 11:26 AM Prathamesh Kulkarni via Gcc-patches
>> > wrote:
>> >>
>> >>
On Thu, Aug 5, 2021 at 2:28 PM Prathamesh Kulkarni <
prathamesh.kulka...@linaro.org> wrote:
> On Tue, 3 Aug 2021 at 20:52, Christophe Lyon
> wrote:
> >
> >
> >
> > On Tue, Aug 3, 2021 at 12:57 PM Prathamesh Kulkarni <
> prathamesh.kulka...@linaro.org> wrote:
> >>
> >> On Tue, 3 Aug 2021 at 14:59,
Hi!
When building gcc with some specific LDFLAGS_FOR_TARGET, e.g.
LDFLAGS_FOR_TARGET=-Wl,-z,relro,-z,now
those flags propagate info linking of target shared libraries,
e.g.
lib{ubsan,tsan,stdc++,quadmath,objc,lsan,itm,gphobos,gdruntime,gomp,go,gfortran,atomic,asan}.so.*
but there is one important
On 7/23/21 11:39 AM, Sebastian Huber wrote:
Add __gcov_info_to_gcda() to libgcov to get the gcda data for a gcda info in a
freestanding environment. It is intended to be used with the
-fprofile-info-section option. A crude test program which doesn't use a linker
script is (use "gcc -coverage -f
Richard Biener writes:
> On Thu, Aug 5, 2021 at 2:04 PM Richard Sandiford
> wrote:
>>
>> Richard Biener writes:
>> > On Tue, Aug 3, 2021 at 2:09 PM Richard Sandiford via Gcc-patches
>> > wrote:
>> >>
>> >> When the vectoriser scalarises a strided store, it counts one
>> >> scalar_store for each
On Thu, Aug 5, 2021 at 11:53 AM Richard Biener wrote:
> On Thu, 5 Aug 2021, Christophe Lyon wrote:
>
> > On Wed, Aug 4, 2021 at 2:08 PM Richard Biener wrote:
> >
> > > On Wed, 4 Aug 2021, Richard Sandiford wrote:
> > >
> > > > Richard Biener writes:
> > > > > This adds a gather vectorization ca
Hi Segher,
On 8/4/21 5:29 PM, Segher Boessenkool wrote:
On Thu, Jul 29, 2021 at 08:30:48AM -0500, Bill Schmidt wrote:
+rs6000-gen-builtins: rs6000-gen-builtins.o rbtree.o
+ $(LINKER_FOR_BUILD) $(BUILD_LINKERFLAGS) $(BUILD_LDFLAGS) -o $@ \
+ $(filter-out $(BUILD_LIBDEPS), $^) $(B
On Wed, Jul 28, 2021 at 2:45 PM Roger Sayle
wrote:
>
> Hi Marc,
>
> Thanks for the feedback. After some quality time in gdb, I now appreciate
> that
> match.pd behaves (subtly) differently between generic and gimple, and the
> trees actually being passed to tree_nonzero_bits were not quite what
On 04/08/21 12:55 +0100, Jonathan Wakely wrote:
This adds [[nodiscard]] throughout , as proposed by P2377R0
(with some minor corrections).
The attribute is added for all modes from C++11 up, using
[[__nodiscard__]] or _GLIBCXX_NODISCARD where C++17 [[nodiscard]] can't
be used directly.
This ch
On Thu, 5 Aug 2021 at 13:14, Ville Voutilainen
wrote:
>
> On Thu, 5 Aug 2021 at 15:11, Christophe Lyon via Libstdc++
> wrote:
> >
> > Hi Jonathan,
> >
> > On Wed, Aug 4, 2021 at 2:04 PM Jonathan Wakely via Gcc-patches <
> > gcc-patches@gcc.gnu.org> wrote:
> >
> > > On 04/08/21 12:56 +0100, Jonath
On Thu, 5 Aug 2021 at 17:21, Jonathan Wakely via Libstdc++
wrote:
>
> On 04/08/21 12:55 +0100, Jonathan Wakely wrote:
> >This adds [[nodiscard]] throughout , as proposed by P2377R0
> >(with some minor corrections).
> >
> >The attribute is added for all modes from C++11 up, using
> >[[__nodiscard__
On 04/08/21 13:00 +0100, Jonathan Wakely wrote:
On 04/08/21 12:56 +0100, Jonathan Wakely wrote:
... and container adaptors.
This adds the [[nodiscard]] attribute to functions with no side-effects
for the sequence containers and their iterators, and the debug versions
of those containers, and th
On 05/08/21 15:19 +0100, Jonathan Wakely wrote:
On 04/08/21 12:55 +0100, Jonathan Wakely wrote:
This adds [[nodiscard]] throughout , as proposed by P2377R0
(with some minor corrections).
The attribute is added for all modes from C++11 up, using
[[__nodiscard__]] or _GLIBCXX_NODISCARD where C++1
Sorry (again) for the disruption. Hopefully, Jakub agrees, but I’d like to
think that this
isn’t a problem with my recent patch, but a slightly fragile test case. PR
target/100056 concerned
an issue where the compiler would generate three instructions for a given idiom
when
this could op
On 8/5/2021 6:41 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
When building gcc with some specific LDFLAGS_FOR_TARGET, e.g.
LDFLAGS_FOR_TARGET=-Wl,-z,relro,-z,now
those flags propagate info linking of target shared libraries,
e.g.
lib{ubsan,tsan,stdc++,quadmath,objc,lsan,itm,gphobos,gdruntim
On 8/5/2021 2:17 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
The following patch (incremental to the makeucnid.c fix) regenerates
ucnid.h with https://www.unicode.org/Public/13.0.0/ucd/ files.
Bootstrapped/regtested on top of the previous patch (which has also
been bootstrapped/regtested al
On 2021/8/3 8:07 PM, Thomas Schwinge wrote:
Really suggest to have intelmic support be re-worked as an offload plugin inside
libgomp, rather than floating outside by itself.
Well, it is a regular libgomp plugin, just its sources are not in
'libgomp/plugin/' and it's not built during libgomp bu
On Thu, Aug 05, 2021 at 02:05:24PM +0200, Martin Liška wrote:
> On 7/23/21 7:57 PM, Segher Boessenkool wrote:
> >Hi!
> >
> >On Fri, Jul 23, 2021 at 07:47:54AM +0200, Martin Liška wrote:
> >>On 7/12/21 7:20 PM, Segher Boessenkool wrote:
> >>+static __attribute__ ((optimize ("-fno-stack-protector
On Thu, Aug 05, 2021 at 08:47:54AM -0500, Bill Schmidt wrote:
> Hi Segher,
>
> On 8/4/21 5:29 PM, Segher Boessenkool wrote:
> >On Thu, Jul 29, 2021 at 08:30:48AM -0500, Bill Schmidt wrote:
> >+rs6000-gen-builtins: rs6000-gen-builtins.o rbtree.o
> >>+ $(LINKER_FOR_BUILD) $(BUILD_LINKERFLAGS) $(BU
Hi,
As subject, this patch uses __builtin_memcpy to copy vector structures
instead of using a union - or constructing a new opaque structure one
vector at a time - in each of the vst4[q]_lane Neon intrinsics in
arm_neon.h.
It also adds new code generation tests to verify that superfluous move
ins
Hello,
This is the second submit of a patch series whose first version[1] was not
welcome because of its C++ usage.
After some thought I figured out that rewriting the series without C++
features would not be that impacting after all.
So here you go, the (not so) good old-fashioned way.
The prob
Introduce a new wrapper class gfc_dummy_arg that provides a common
interface to both dummy arguments of user-defined procedures (which
have type gfc_formal_arglist) and dummy arguments of intrinsic procedures
(which have type gfc_intrinsic_arg).
gcc/fortran/
* gfortran.h (gfc_dummy_arg_ki
Preliminary refactoring to make further changes more obvious.
No functional change.
gcc/fortran/
* intrinsic.c (sort_actual): initialise variable and use it earlier.
---
gcc/fortran/intrinsic.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/gcc/fortran/intrins
There was originally no way from an actual argument to get
to the corresponding dummy argument, even if the job of sorting
and matching actual with dummy arguments was done.
The closest was a field named actual in gfc_intrinsic_arg that was
used as scratch data when sorting arguments of one specif
This adds two functions working with the wrapper class gfc_dummy_arg
and makes usage of them to simplify a bit the walking of elemental
procedure arguments for scalarization. As information about dummy arguments
can be obtained from the actual argument through the just-introduced
associated_dummy
Now that we can get information about an actual arg's associated
dummy using the associated_dummy attribute, the field missing_arg_type
contains redundant information.
This removes it.
gcc/fortran/
* gfortran.h (gfc_actual_arglist::missing_arg_type): Remove.
* interface.c (gfc_com
This reverts commit d09847357b965a2c2cda063827ce362d4c9c86f2 except for
its testcase.
gcc/fortran/
* intrinsic.c (add_sym_4ind): Remove.
(add_functions): Use add_sym4 instead of add_sym4ind.
Don’t special case the index intrinsic.
* iresolve.c (gfc_resolve_index_fu
The KIND argument of the INDEX intrinsic is a compile time constant
that is used at compile time only to resolve to a kind-specific library
method. It is otherwise completely ignored at runtime, and there is
no code generated for it as the library procedure has no kind argument.
This confuses the
Hi,
As subject, this patch uses __builtin_memcpy to copy vector structures
instead of using a union - or constructing a new opaque structure one
vector at a time - in each of the vst3[q]_lane Neon intrinsics in
arm_neon.h.
It also adds new code generation tests to verify that superfluous move
ins
On 8/5/21 5:39 PM, Segher Boessenkool wrote:
On Thu, Aug 05, 2021 at 02:05:24PM +0200, Martin Liška wrote:
On 7/23/21 7:57 PM, Segher Boessenkool wrote:
Hi!
On Fri, Jul 23, 2021 at 07:47:54AM +0200, Martin Liška wrote:
On 7/12/21 7:20 PM, Segher Boessenkool wrote:
+static __attribute__ ((opt
Hi,
As subject, this patch uses __builtin_memcpy to copy vector structures
instead of using a union - or constructing a new opaque structure one
vector at a time - in each of the vst2[q]_lane Neon intrinsics in
arm_neon.h.
It also adds new code generation tests to verify that superfluous move
ins
Hi,
As subject, this patch uses __builtin_memcpy to copy vector structures
instead of using a union - or constructing a new opaque structure one
vector at a time - in each of the vst[234][q] and vst1[q]_x[234] bfloat
Neon intrinsics in arm_neon.h.
It also adds new code generation tests to verify
On Wed, Aug 04, 2021 at 02:14:07PM -0600, Sandra Loosemore wrote:
> I was trying last week to run my not-yet-committed TS29113 testsuite
> on a powerpc64le-linux-gnu target and ran into some problems with
> the kind constants c_float128 and c_float128_complex from the
> ISO_C_BINDING module; per th
On 05/08/21 15:40 +0100, Jonathan Wakely wrote:
On 05/08/21 15:19 +0100, Jonathan Wakely wrote:
On 04/08/21 12:55 +0100, Jonathan Wakely wrote:
This adds [[nodiscard]] throughout , as proposed by P2377R0
(with some minor corrections).
The attribute is added for all modes from C++11 up, using
[
On 8/5/21 11:33 AM, Michael Meissner wrote:
At the moment, we only fully support C and C++ when changing the long double
format (between IEEE 128-bit, IBM 128-bit, and 64-bit) when the compiler is
invoked (and assuming you are using GLIBC 2.32 or newer).
For Fortran and the other languages, the
This Go patch extends the internal runtime/internal/atomic package to
match the externally visible sync/atomic package. This is the
gofrontend version of https://golang.org/cl/289152. Bootstrapped and
ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
a6b138f257a431f3337f3c6bf5
On Thu, Aug 05, 2021 at 06:49:21PM +0200, Martin Liška wrote:
> On 8/5/21 5:39 PM, Segher Boessenkool wrote:
> >>>If -mbork is the default, the coompiler whould behave the same if you
> >>>invoke it with -mbork as when you do not. And the optimize attribute
> >>>should work exactly the same as com
On Thu, Aug 05, 2021 at 12:19:37PM -0600, Sandra Loosemore wrote:
> On 8/5/21 11:33 AM, Michael Meissner wrote:
> >At the moment, we only fully support C and C++ when changing the long double
> >format (between IEEE 128-bit, IBM 128-bit, and 64-bit) when the compiler is
> >invoked (and assuming you
As I mentioned in the description of the access warning pass when
I submitted it in July(*), I planned to change the -Wstringop-xxx
code in the pass to run on the GIMPLE IL instead of on trees in
builtins.c (and elsewhere). The attached patch implements this
change along with moving more warning
-Wmismatched-new-delete partly relies on valid_new_delete_pair_p()
to detect matching calls to operator new and delete. The function
returns a conservative result which, when indicating a mismatch,
the warning then works to make more accurate before it triggers.
As it turns out, the logic is inad
On 7/30/21 9:06 AM, Jason Merrill wrote:
On 7/27/21 2:56 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575690.html
Are there any other suggestions or comments or is the latest revision
okay to commit?
OK.
I had to make a few more adjustments to fix up cod
[PATCH] Fix typo in fold-vec-load-builtin_vec_xl-* tests.
When I checked in the fix for running tests on power10 systems with
power10 code generation, I had a typo in the
fold-vec-load-builtin_vec_xl-* tests, swapping 'x' and 'v' in the p?lxv
pattern.
I checked this patch on a little endian power
Hi:
---
OK, I think sth is amiss here upthread. insv/extv do look like they
are designed
to work on integer modes (but docs do not say anything about this here).
In fact the caller of extract_bit_field_using_extv is named
extract_integral_bit_field. Of course nothing seems to check what kind of
m
On Thu, Aug 5, 2021 at 8:33 PM liuhongt via Gcc-patches
wrote:
>
> Hi:
> ---
> OK, I think sth is amiss here upthread. insv/extv do look like they
> are designed
> to work on integer modes (but docs do not say anything about this here).
> In fact the caller of extract_bit_field_using_extv is name
On Fri, Aug 6, 2021 at 11:44 AM Andrew Pinski via Gcc-patches
wrote:
>
> On Thu, Aug 5, 2021 at 8:33 PM liuhongt via Gcc-patches
> wrote:
> >
> > Hi:
> > ---
> > OK, I think sth is amiss here upthread. insv/extv do look like they
> > are designed
> > to work on integer modes (but docs do not say
On Thu, Aug 5, 2021 at 5:20 AM Segher Boessenkool
wrote:
>
> On Wed, Aug 04, 2021 at 11:22:53AM +0100, Richard Sandiford wrote:
> > Segher Boessenkool writes:
> > > On Wed, Aug 04, 2021 at 10:10:36AM +0100, Richard Sandiford wrote:
> > >> Richard Biener writes:
> > >> > Alternatively only enable
On 05/08/2021 14:53, Martin Liška wrote:
On 7/23/21 11:39 AM, Sebastian Huber wrote:
Add __gcov_info_to_gcda() to libgcov to get the gcda data for a gcda
info in a
freestanding environment. It is intended to be used with the
-fprofile-info-section option. A crude test program which doesn't us
On Fri, Aug 6, 2021 at 12:59 PM Hongtao Liu wrote:
>
> On Fri, Aug 6, 2021 at 11:44 AM Andrew Pinski via Gcc-patches
> wrote:
> >
> > On Thu, Aug 5, 2021 at 8:33 PM liuhongt via Gcc-patches
> > wrote:
> > >
> > > Hi:
> > > ---
> > > OK, I think sth is amiss here upthread. insv/extv do look like
On Tue, Aug 3, 2021 at 10:44 AM Hongtao Liu wrote:
>
> On Tue, Aug 3, 2021 at 3:34 AM Joseph Myers wrote:
> >
> > On Mon, 2 Aug 2021, liuhongt via Gcc-patches wrote:
> >
> > > diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> > > index 7979e240426..dc673c89bc8 100644
> > > --- a/gcc/
On Wed, Jul 14, 2021 at 8:38 PM H.J. Lu wrote:
>
> On Tue, Jul 13, 2021 at 9:35 PM Hongtao Liu wrote:
> >
> > On Wed, Jul 14, 2021 at 10:34 AM liuhongt wrote:
> > >
> > > By optimizing vector movement to broadcast in ix86_expand_vector_move
> > > during pass_expand, pass_reload/LRA can automatic
On Thu, Aug 5, 2021 at 3:26 PM Christophe Lyon via Gcc-patches
wrote:
>
> On Thu, Aug 5, 2021 at 11:53 AM Richard Biener wrote:
>
> > On Thu, 5 Aug 2021, Christophe Lyon wrote:
> >
> > > On Wed, Aug 4, 2021 at 2:08 PM Richard Biener wrote:
> > >
> > > > On Wed, 4 Aug 2021, Richard Sandiford wrot
On Fri, Aug 6, 2021 at 12:01 AM Martin Sebor via Gcc-patches
wrote:
>
> As I mentioned in the description of the access warning pass when
> I submitted it in July(*), I planned to change the -Wstringop-xxx
> code in the pass to run on the GIMPLE IL instead of on trees in
> builtins.c (and elsewher
On Fri, Aug 6, 2021 at 5:32 AM liuhongt wrote:
>
> Hi:
> ---
> OK, I think sth is amiss here upthread. insv/extv do look like they
> are designed
> to work on integer modes (but docs do not say anything about this here).
> In fact the caller of extract_bit_field_using_extv is named
> extract_inte
On Fri, Aug 6, 2021 at 6:54 AM Hongtao Liu via Gcc-patches
wrote:
>
> On Fri, Aug 6, 2021 at 11:44 AM Andrew Pinski via Gcc-patches
> wrote:
> >
> > On Thu, Aug 5, 2021 at 8:33 PM liuhongt via Gcc-patches
> > wrote:
> > >
> > > Hi:
> > > ---
> > > OK, I think sth is amiss here upthread. insv/ex
91 matches
Mail list logo
