Hi,
I would like to commit the attached patch to trunk and after a settling
period also to all open branches.
Is this ok?
TIA,
Andreas
From a8a602620917efad2579c0dc24b178c0f2b18ff3 Mon Sep 17 00:00:00 2001
From: Andreas Tobler
Date: Thu, 12 Aug 2021 22:35:52 +0200
Subject: [PATCH] FreeBSD: S
Move xx* builtins to vsx.md.
I originally posted this patch in May. It needed a slight tune up as the
souces have changed, so I'm reposting it now.
I noticed that the xx built-in functions (xxspltiw, xxspltidp, xxsplti32dx,
xxeval, xxblend, and xxpermx) were all defined in altivec.md. However,
Fix xxeval predicates (PR 99921).
I originally posted this patch in May and in June. I'm reposting it now.
I noticed that the xxeval built-in function used the altivec_register_operand
predicate. Since it takes vsx registers, this might force the register
allocate to issue a move when it could
Fix tests that require IBM 128-bit long double
I posted an earlier version of this patch on July 7th, and Segher had some
comments about it on July 14th. This is a revised version of the patch
* My patch: Message-ID: <20210707195837.ga28...@ibm-toto.the-meissners.org>
* Seger's reply: Message-
This patch updates libgo from the Go1.16.5 release to the Go 1.17rc2
release. As usual with these version updates, the patch itself is too
large to attach to this e-mail message. I've attached the changes to
files that are specific to gccgo. Bootstraped and ran Go testsuite on
x86_64-pc-linux-gn
on 2021/8/12 下午11:51, Segher Boessenkool wrote:
> On Thu, Aug 12, 2021 at 10:10:10AM +0800, Kewen.Lin wrote:
>>> + enum rs6000_builtins vname = RS6000_BUILTIN_COUNT;
>>>
>>> Using this as a flag value looks unnecessary. Is this just being done to
>>> silence a warning?
>>
>> Good question!
Hi Segher,
Thanks for the review!
on 2021/8/12 下午11:10, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Aug 11, 2021 at 02:56:11PM +0800, Kewen.Lin wrote:
>> * config/rs6000/rs6000.c (rs6000_builtin_md_vectorized_function): Add
>> support for some built-in functions vectorized on Power10.
— Jojo
在 2021年8月11日 +0800 PM6:44，Richard Biener ，写道：
> On Wed, Aug 11, 2021 at 11:28 AM Richard Sandiford
> wrote:
> >
> > Richard Biener writes:
> > > On Tue, Aug 10, 2021 at 10:33 AM Jojo R via Gcc-patches
> > > wrote:
> > > >
> > > > Some target like RISC-V allow to group vector register as
Hi Bill,
on 2021/8/12 上午12:24, Bill Schmidt wrote:
> Hi Kewen,
>
> On 8/11/21 12:44 AM, Kewen.Lin wrote:
>> Hi,
>>
>> This patch is to make prototypes of some Power10 built-in
>> functions consistent with what's in the documentation, as
>> well as the vector version. Otherwise, useless conversio
On Thu, Aug 12, 2021 at 5:23 PM Jakub Jelinek wrote:
>
> On Thu, Aug 12, 2021 at 01:43:23PM +0800, liuhongt wrote:
> > Hi:
> > This is another patch to optimize vec_perm_expr to match vpmov{dw,dq,wb}
> > under AVX512.
> > For scenarios(like pr101846-2.c) where the upper half is not used, this
Sorry for the typo, scan-assembler should be
+/* { dg-final { scan-assembler "leal\[\\t \]\[^\\n\]*eax" } } */
+/* { dg-final { scan-assembler-not "movl\[\\t \]\[^\\n\]*eax" } } */
Hongyu Wang via Gcc-patches 于2021年8月13日周五 上午8:49写道：
>
> Hi,
>
> For lea + zero_extendsidi insns, if dest of lea and
Hi,
For lea + zero_extendsidi insns, if dest of lea and src of zext are the
same, combine them with single leal under 64bit target since 32bit
register will be automatically zero-extended.
Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
Ok for master?
gcc/ChangeLog:
PR target/101
This patch to the Go frontend and libgo stores pointers to
go:notinheap types indirectly. This provides better support for using
cgo with incomplete types. This is the gofrontend version of
https://golang.org/cl/264480. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committed to main
On Thu, Aug 12, 2021 at 3:34 PM Sergei Trofimovich via Gcc-patches
wrote:
>
> From: Sergei Trofimovich
>
> I noticed test failures when ran gcc test suite from under mc shell.
> mc opens fd=9 and exposes it to child processes. As a result a few
> tests failes:
> FAIL: b2test_buildid
> FAI
On Thu, Aug 12, 2021 at 3:35 PM Sergei Trofimovich via Gcc-patches
wrote:
>
> From: Sergei Trofimovich
>
> On LANG=ru_RU.UTF-8 'b2test_buildid' test fails due to localized readelf
> output:
>
> $ LANG=ru_RU.UTF-8 readelf -n b2test | fgrep 4e37e8f
> ID сборки: 4e37e8fead8d6e8b0a9dc95ea25cd784d
Hi,
Although I kept my previous "use_register_for_decl(lhs)” to decide “memset”
expansion or “assign” expansion when expanding .DEFERRED_INIT
When generating “pattern” for “assign” expansion, I found that
“can_native_interpret_type_p(var_type)” combined with “native_interpret_expr”
make
the i
On Aug 12 2021, Patrick McGehearty via Gcc-patches wrote:
> diff --git a/libgcc/config/rs6000/_divkc3.c b/libgcc/config/rs6000/_divkc3.c
> index a1d29d2..2b229c8 100644
> --- a/libgcc/config/rs6000/_divkc3.c
> +++ b/libgcc/config/rs6000/_divkc3.c
> @@ -38,10 +38,10 @@ see the files COPYING3 and CO
From: Sergei Trofimovich
On LANG=ru_RU.UTF-8 'b2test_buildid' test fails due to localized readelf
output:
$ LANG=ru_RU.UTF-8 readelf -n b2test | fgrep 4e37e8f
ID сборки: 4e37e8fead8d6e8b0a9dc95ea25cd784dff3a393
$ LANG=C readelf -n b2test | fgrep 4e37e8f
Build ID: 4e37e8fead8d6e8b0a9dc95e
From: Sergei Trofimovich
I noticed test failures when ran gcc test suite from under mc shell.
mc opens fd=9 and exposes it to child processes. As a result a few
tests failes:
FAIL: b2test_buildid
FAIL: btest_gnudebuglink
FAIL: btest
FAIL: btest_lto
FAIL: btest_alloc
FAIL:
I see I have more to learn about gcc's interactions with IEEE-128 format
vs IBM-128 format.
As we discovered here, using the IBM-128 version of LDBL_EPSILON will
not yield correct answers as currently coded.
If _divkc3.c is not intended to provide a version of complex divide
that handles IBM-128
On Thu, Aug 12, 2021 at 04:03:13PM +, Patrick McGehearty wrote:
> This patch resolves the failure of powerpc64 long double complex divide
> in native ibm long double format after the patch "Practical improvement
> to libgcc complex divide".
[ etc. ]
Nothing in here says what has changed in v3
On Thu, Aug 12, 2021 at 04:47:42PM +, Joseph Myers wrote:
> On Thu, 12 Aug 2021, Patrick McGehearty via Gcc-patches wrote:
> > My understanding of ibm FP mode build procedure is minimal,
> > but it seems that the _divkc3.c routine is built for both IEEE128
> > and IBM128 modes.
>
> If built fo
Hi!
This construct has been introduced as a replacement for master
construct, but unlike that construct is slightly more general,
has an optional clause which allows to choose which thread
will be the one running the region, it can be some other thread
than the master (primary) thread with number
Per discussion with Martin, I'm also changing the post-increment to
pre-increment in safe_inc_pos. That's what I'm regstrapping at the moment.
Thanks,
Bill
On 8/12/21 3:28 PM, Bill Schmidt via Gcc-patches wrote:
Although safe_inc_pos avoids buffer overruns in rs6000-gen-builtins.c,
there are
Although safe_inc_pos avoids buffer overruns in rs6000-gen-builtins.c,
there are some other routines where we fail to detect the possibility.
Clean those up!
Regstrap in progress on powerpc64le-linux-gnu. OK for trunk if that
passes?
Thanks,
Bill
2021-08-12 Bill Schmidt
gcc/
* confi
Hi, Richard,
For RTL expansion of call to .DEFERRED_INIT, I changed my code per your
suggestions like following:
==
#define INIT_PATTERN_VALUE 0xFE
static void
expand_DEFERRED_INIT (internal_fn, gcall *stmt)
{
tree lhs = gimple_call_lhs (stmt);
tree var_size = gimple_cal
On Thu, Aug 12, 2021 at 6:40 AM Hongtao Liu wrote:
> > > > Hi:
> > > > AVX512F supported vscalefs{s,d} which is the same as ldexp except the
> > > > second operand should be floating point.
> > > > Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
> > > >
> > > > gcc/ChangeLog:
> > > >
Hi,
this patch add EAF_NOREAD (as disucssed on IRC earlier) and fixes meaning
of EAF_UNUSED to be really unused and not "does not escape, is not clobbered,
read or returned" since we have separate flags for each of the properties
now.
Number of flags has grown and I thus I refactored the code a bi
Hi,
while looking into the code I noticed the following thinko.
VOID_TYPE_P (TREE_TYPE (current_function_decl)) is always false since
TREE_TYPE (current_function_decl) is either function_type or
method_type. One extra TREE_TYPE is needed to get to type of return
value.
Bootstrapped/regtested x86_
The [cmath.syn] p1 wording about additional overloads sufficient to
handle any arithmetic types also applies to std::lerp. This adds a new
overload of std::lerp that does the required promotions to support
arguments of arbitrary arithmetic types.
A new __promoted_t alias template is added, which t
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/lerp.cc: Add header name to #error.
* testsuite/26_numerics/midpoint/integral.cc: Likewise.
* testsuite/26_numerics/midpoint/version.cc: New test.
Tested powerpc64le-linux. Committed to trunk.
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
* include/experimental/random (experimental::randint): Add
nodiscard attribute.
Tested powerpc64le-linux. Committed to trunk.
commit 20ce14c7991fbb498e32a0f5e3b01ae88c9f5e9a
Author: Jonathan Wakely
Date: Thu Aug 12 18:05
On Tue, Aug 10, 2021 at 7:37 PM Peter Bergner wrote:
>
> PR101849 shows we ICE on a test case when we pass a non __vector_pair *
> pointer to the __builtin_vsx_lxvp and __builtin_vsx_stxvp built-ins
> that is cast to __vector_pair *. The problem is that when we expand
> the built-in, the cast has
On Sun, Aug 08, 2021 at 03:21:02PM -0500, Segher Boessenkool wrote:
> On Thu, Aug 05, 2021 at 10:44:36PM -0400, Michael Meissner wrote:
> > * gcc.target/powerpc/fold-vec-load-builtin_vec_xl-char.c: Fix
> > typo in regular expression.
> > * gcc.target/powerpc/fold-vec-load-builtin_vec_xl
On 8/12/2021 8:34 AM, Aldy Hernandez wrote:
PING
On Thu, Aug 5, 2021 at 11:48 AM Aldy Hernandez wrote:
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
bi
On Thu, Aug 12, 2021 at 8:31 AM Martin Liška wrote:
>
> On 8/12/21 5:26 PM, H.J. Lu wrote:
> > Will it hurt if they have proper feature_priorities you added?
>
> No. They are unused, by we should use the proper priorities.
>
> Martin
+ const char *arch_name = attrs_str + strlen ("arch=");
+
On Thu, Aug 12, 2021 at 12:06:33PM -0400, Jason Merrill wrote:
> Yes; if the standard says something nonsensical, I prefer to figure out
> something more sensible to propose as a change.
Ok, so here it is implemented, so far tested only on the new testcases
(but nothing else really uses the code t
On Mon, 24 May 2021, Uecker, Martin wrote:
> - else if (VOID_TYPE_P (TREE_TYPE (type1))
> -&& !TYPE_ATOMIC (TREE_TYPE (type1)))
> - {
> - if ((TREE_CODE (TREE_TYPE (type2)) == ARRAY_TYPE)
> - && (TYPE_QUALS (strip_array_types (TREE_TYPE (type2)))
> -
On Thu, 12 Aug 2021, Patrick McGehearty via Gcc-patches wrote:
> > This file includes quad-float128.h, which does some remapping from TF to
> > KF depending on __LONG_DOUBLE_IEEE128__.
> >
> > I think you probably need to have a similar __LONG_DOUBLE_IEEE128__
> > conditional here. If __LONG_DOUB
The key code in _divkc3.c is:
#ifndef __LONG_DOUBLE_IEEE128__
#define RBIG (__LIBGCC_DF_MAX__ / 2)
#define RMIN (__LIBGCC_DF_MIN__)
#define RMIN2 (__LIBGCC_DF_EPSILON__)
#define RMINSCAL (1 / __LIBGCC_DF_EPSILON__)
#define RMAX2 (RBIG * RMIN2)
#else
#define RBIG (__LIBGCC_TF_MAX__ / 2)
#d
On Thu, 12 Aug 2021, Patrick McGehearty via Gcc-patches wrote:
> This patch resolves the failure of powerpc64 long double complex divide
> in native ibm long double format after the patch "Practical improvement
> to libgcc complex divide".
This description is not consistent with the patch.
__div
Hi Segher,
On 8/3/21 7:34 PM, Segher Boessenkool wrote:
Whoops, I forgot some stuff:
On Tue, Jul 27, 2021 at 04:06:49PM -0500, will schmidt wrote:
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
static rtx
ldv_expand_builtin (rtx target, insn_code icode, rtx *op, ma
On Thu, 12 Aug 2021, Martin Uecker wrote:
> Evaluate type arguments of sizeof that are structs of variable size [PR101838]
>
> Evaluate type arguments of sizeof for all types of variable size
> and not just for VLAs. This fixes PR101838 and some issues related
> to PR29970 where statement expres
On Thu, 12 Aug 2021, Sebastian Huber wrote:
> If -fprofile-update=atomic is used, then the target must provide atomic
> operations for the counters of the type returned by get_gcov_type().
> This is a 64-bit type for targets which have a 64-bit long long type.
> On 32-bit targets this could be an
On 8/12/21 11:16 AM, Jakub Jelinek wrote:
On Thu, Aug 12, 2021 at 10:33:20AM -0400, Jason Merrill wrote:
The following patch implements __is_layout_compatible trait and
__builtin_is_corresponding_member helper function for the
std::is_corresponding_member template function.
For now it implements
This patch resolves the failure of powerpc64 long double complex divide
in native ibm long double format after the patch "Practical improvement
to libgcc complex divide".
The new code uses the following macros which are intended to be mapped
to appropriate values according to the underlying hardwa
On Thu, Aug 12, 2021 at 10:10:10AM +0800, Kewen.Lin wrote:
> > + enum rs6000_builtins vname = RS6000_BUILTIN_COUNT;
> >
> > Using this as a flag value looks unnecessary. Is this just being done to
> > silence a warning?
>
> Good question! I didn't notice there is a warning or not, just ge
On 8/12/21 5:26 PM, H.J. Lu wrote:
Will it hurt if they have proper feature_priorities you added?
No. They are unused, by we should use the proper priorities.
Martin
>From 5a2f40394390f8bfca0724d6e371b5105d01c027 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Thu, 12 Aug 2021 15:20:43 +020
Commit r12-1328 enabled DT_INIT_ARRAY/DT_FINI_ARRAY for all Linux
targets, but this does not work for arm-none-uclinuxfdpiceabi: it
makes all the execution tests fail.
This patch restores the original behavior for uclinuxfdpiceabi.
2021-08-12 Christophe Lyon
gcc/
PR target/100
On Thu, Aug 12, 2021 at 8:22 AM Martin Liška wrote:
>
> On 8/12/21 4:51 PM, H.J. Lu wrote:
> > On Thu, Aug 12, 2021 at 7:39 AM Martin Liška wrote:
> >>
> >> On 8/12/21 4:25 PM, H.J. Lu wrote:
> >>> Please send out the v2 patch with the enclosed patch. I added some tests.
> >>
> >> Thanks, there'
When we have a target_clone *declaration*, it does not make sense doing
the default version local. The use-case in the PR is that the reporter
wants to implement the function in assembly.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
On 8/12/21 4:51 PM, H.J. Lu wrote:
On Thu, Aug 12, 2021 at 7:39 AM Martin Liška wrote:
On 8/12/21 4:25 PM, H.J. Lu wrote:
Please send out the v2 patch with the enclosed patch. I added some tests.
Thanks, there's patch which includes your changes.
Martin
diff --git a/gcc/common/config/i3
On Thu, Aug 12, 2021 at 10:46:23AM -0400, Jason Merrill wrote:
> > --- libcpp/expr.c 2021-05-07 10:34:46.345122608 +0200
> > +++ libcpp/expr.c 2021-08-12 09:54:01.837556365 +0200
> > @@ -783,13 +783,13 @@ cpp_classify_number (cpp_reader *pfile,
> > /* Traditional C only accepted the 'L'
On Thu, Aug 12, 2021 at 10:33:20AM -0400, Jason Merrill wrote:
> > The following patch implements __is_layout_compatible trait and
> > __builtin_is_corresponding_member helper function for the
> > std::is_corresponding_member template function.
> > For now it implements the IMHO buggy but
> > stand
Hi!
On Wed, Aug 11, 2021 at 02:56:11PM +0800, Kewen.Lin wrote:
> * config/rs6000/rs6000.c (rs6000_builtin_md_vectorized_function): Add
> support for some built-in functions vectorized on Power10.
Say which, not "some" please?
> + machine_mode in_vmode = TYPE_MODE (type_in);
> + mac
On Thu, Aug 12, 2021 at 7:39 AM Martin Liška wrote:
>
> On 8/12/21 4:25 PM, H.J. Lu wrote:
> > Please send out the v2 patch with the enclosed patch. I added some tests.
>
> Thanks, there's patch which includes your changes.
>
> Martin
diff --git a/gcc/common/config/i386/i386-isas.h
b/gcc/common/
On 8/12/21 3:57 AM, Jakub Jelinek wrote:
Hi!
The following testcase ICEs in cpp_sys_macro_p, because cpp_sys_macro_p
is called for a builtin macro which doesn't use node->value.macro union
member but a different one and so dereferencing it ICEs.
As the testcase is distilled from contemporary gli
On 8/12/21 4:25 PM, H.J. Lu wrote:
Please send out the v2 patch with the enclosed patch. I added some tests.
Thanks, there's patch which includes your changes.
Martin
>From 22ab27eab643d99addd00c11f62eca891e11ac08 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Thu, 12 Aug 2021 15:20:43 +0
On 8/11/21 6:36 PM, Sergei Trofimovich wrote:
On Wed, 11 Aug 2021 15:19:58 -0400
Jason Merrill wrote:
On 8/6/21 11:34 AM, Sergei Trofimovich wrote:
On Thu, 29 Jul 2021 11:41:39 -0400
Jason Merrill wrote:
On 7/22/21 7:15 PM, Sergei Trofimovich wrote:
From: Sergei Trofimovich
r12-1804
PING
On Thu, Aug 5, 2021 at 11:48 AM Aldy Hernandez wrote:
>
> 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
On 8/3/21 3:05 AM, Jakub Jelinek wrote:
Hi!
The following patch implements __is_layout_compatible trait and
__builtin_is_corresponding_member helper function for the
std::is_corresponding_member template function.
For now it implements the IMHO buggy but
standard definition of layout-compatible
On Thu, Aug 12, 2021 at 7:12 AM Martin Liška wrote:
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> I modified the H.J. patch draft.
Please send out the v2 patch with the enclosed patch. I added some tests.
> @H.J. Can you please verify the newly added 'feature_prio
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I modified the H.J. patch draft.
@H.J. Can you please verify the newly added 'feature_priority'?
As mentioned in the PR, we do miss supports target micro-architectures
in target and target_clone attribute. While the levels
x86
Give more explicit errors if these files are not built with the correct
-std options.
libstdc++-v3/ChangeLog:
* src/c++98/locale_init.cc: Require C++11.
* src/c++98/localename.cc: Likewise.
* src/c++98/misc-inst.cc: Require C++98.
Tested powerpc64le-linux. Committed to tr
On Thu, Aug 12, 2021 at 1:54 PM Prathamesh Kulkarni <
prathamesh.kulka...@linaro.org> wrote:
> On Wed, 11 Aug 2021 at 22:23, Christophe Lyon
> wrote:
> >
> >
> >
> > On Thu, Jun 24, 2021 at 6:29 PM Kyrylo Tkachov via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
> >>
> >>
> >>
> >> > -Origi
On 8/10/21 11:02 AM, Bill Schmidt wrote:
Hm, is this code ever executed? How does this not result in assignment
through null pointers?
It would be good to figure out whether this code is reachable at all,
and just yank it out if not. Otherwise we need a test case that hits it.
I seem to hav
I will commit the attached patch in a while – unless last-minute
comments or other issues show up.
On 12.08.21 13:31, Jakub Jelinek wrote:
LGTM, some nits below.
Maybe in tree-core.h do:
- OMP_CLAUSE_PROC_BIND_MASTER = 2,
+ OMP_CLAUSE_PROC_BIND_PRIMARY = 2,
+ OMP_CLAUSE_PROC_BIND_MASTER = OMP
On 12.08.21 14:13, Hans-Peter Nilsson via Fortran wrote:
I'd call it obvious, so i dare to approve it.
OK.
thanks!
Thanks, but not coming from a testsuite or fortran
maintainer I'm not sure I can actually rely on that.
OTOH, damn the torpedoes. Committed.
If it helps: A post-commit LGTM from
On 8/11/21 9:10 PM, Kewen.Lin wrote:
Hi Bill,
Thanks for your prompt review!
on 2021/8/12 上午12:34, Bill Schmidt wrote:
Hi Kewen,
FWIW, it's easier on reviewers if you include the patch inline instead of as an
attachment.
On 8/11/21 1:56 AM, Kewen.Lin wrote:
Hi,
This patch is to add the su
Joseph,
here is the patch for c_expr_sizeof_type you had suggested.
Best,
Martin
Evaluate type arguments of sizeof that are structs of variable size [PR101838]
Evaluate type arguments of sizeof for all types of variable size
and not just for VLAs. This fixes PR101838 and some issues relat
ARC backend is defaulting to -fcommon. This is not anylonger needed, remove it.
gcc/
2021-08-12 Claudiu Zissulescu
* common/config/arc/arc-common.c (arc_option_init_struct): Remove
fno-common reference.
* config/arc/arc.c (arc_override_options): Remove overriding of
On 12/08/2021 13:19, Martin Liška wrote:
One small nit, once you sent a new patch version, can you please
describe what has changed
since the previous one?
Yes, sorry.
In v4 I changed the target macro to a target hook. Also the
TARGET_GCOV_TYPE_SIZE is now redefined in sparc.c using an
arch
> From: Bernhard Reutner-Fischer
> Date: Thu, 12 Aug 2021 09:03:50 +0200
> On Thu, 12 Aug 2021 00:09:21 +0200
> Hans-Peter Nilsson via Fortran wrote:
>
> > I had a file-path to sources with the substring "new" in it,
> > and (only) this test regressed compared to results from
> > another build
On Wed, 11 Aug 2021 at 22:23, Christophe Lyon
wrote:
>
>
>
> On Thu, Jun 24, 2021 at 6:29 PM Kyrylo Tkachov via Gcc-patches
> wrote:
>>
>>
>>
>> > -Original Message-
>> > From: Prathamesh Kulkarni
>> > Sent: 24 June 2021 12:11
>> > To: gcc Patches ; Kyrylo Tkachov
>> >
>> > Subject: [A
On Thu, Aug 12, 2021 at 12:52:17PM +0200, Tobias Burnus wrote:
> gcc/c/ChangeLog:
>
> * c-parser.c (c_parser_omp_clause_proc_bind): Accept
> 'primary' as alias for 'master'.
>
> gcc/cp/ChangeLog:
>
> * parser.c (cp_parser_omp_clause_proc_bind): Accept
> 'primary' as alias
Hello.
One small nit, once you sent a new patch version, can you please describe what
has changed
since the previous one?
Cheers,
Martin
The attached patch adds another (very) low-hanging fruit of OpenMP 5.1
to GCC, given that we already have one OpenMP 5.1 feature and another
one also related to 'master'/'masked' construct might be added soon.
OK?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Ar
If -fprofile-update=atomic is used, then the target must provide atomic
operations for the counters of the type returned by get_gcov_type().
This is a 64-bit type for targets which have a 64-bit long long type.
On 32-bit targets this could be an issue since they may not provide
64-bit atomic operat
This patch improves the bit bounds for MINUS_EXPR during tree-ssa's
conditional constant propagation (CCP) pass (and as an added bonus
adds support for POINTER_DIFF_EXPR).
The pessimistic assumptions made by the current algorithm are
demonstrated by considering 1 - (x&1). Intuitively this should
On Thu, Aug 12, 2021 at 11:22:48AM +0200, Jakub Jelinek via Gcc-patches wrote:
> So, I wonder if your new routine shouldn't be instead done after
> in ix86_expand_vec_perm_const_1 after vec_perm_1 among other 2 insn cases
> and handle the other vpmovdw etc. cases in combine splitters (see that we
>
On Thu, Aug 12, 2021 at 01:43:23PM +0800, liuhongt wrote:
> Hi:
> This is another patch to optimize vec_perm_expr to match vpmov{dw,dq,wb}
> under AVX512.
> For scenarios(like pr101846-2.c) where the upper half is not used, this
> patch
> generates better code with only one vpmov{wb,dw,qd} ins
Hi all,
On 19.07.21 17:28, Jakub Jelinek via Gcc-patches wrote:
On Mon, Jul 19, 2021 at 05:17:10PM +0200, Tobias Burnus wrote:
Update the OpenMP feature list.
Comments? Remarks?
I'd defer mentioning it until I actually finish it
With today's commits by Jakub, the implementation is rather co
On Thu, Aug 12, 2021 at 3:49 PM Jakub Jelinek wrote:
>
> Hi!
>
> My patch from yesterday apparently broke some V32HImode permutations
> as the testcase shows.
> The first function assumed it would never be called in d->testing_p mode
> and so went right away into emitting the code.
> And the secon
Hi!
The following testcase ICEs in cpp_sys_macro_p, because cpp_sys_macro_p
is called for a builtin macro which doesn't use node->value.macro union
member but a different one and so dereferencing it ICEs.
As the testcase is distilled from contemporary glibc headers, it means
basically -Wtraditiona
Hi!
My patch from yesterday apparently broke some V32HImode permutations
as the testcase shows.
The first function assumed it would never be called in d->testing_p mode
and so went right away into emitting the code.
And the second one assumed V32HImode would never reach it, which now
can for the !
Hi!
OpenMP 5.1 says:
For any directive that has a paired end directive, including those with a begin
and end pair, both directives must use either the attribute syntax or the
pragma syntax.
The following patch enforces it with the only pair so far recognized in C++
(Fortran has many, but on the o
Hi!
This patch diagnoses cases like:
#pragma omp parallel
[[omp::directive (declare simd)]] int foo ();
or
#pragma omp taskgroup
int bar [[omp::directive (declare simd)]] (int);
where the pragma is on the same declaration statement as the declare simd
attribute.
Bootstrapped/regtested on
Hi!
With the using-directive parsing changes, we now emit only a warning
for [[omp::directive (...)]] on using-directive. While that is right
without -fopenmp/-fopenmp-simd, when OpenMP is enabled, that should
be an error as OpenMP (is going to) disallow such attributes there
as they do not apper
> Looks good to me. Do you have push permissions?
Thanks. Yes, see the preceding message on gcc-patches@, so applied.
--
Eric Botcazou
On Thu, 12 Aug 2021 00:09:21 +0200
Hans-Peter Nilsson via Fortran wrote:
> I had a file-path to sources with the substring "new" in it,
> and (only) this test regressed compared to results from
> another build without "new" in the name.
>
> The test does
> ! { dg-final { scan-tree-dump-times "n
90 matches
Mail list logo
