On Thu, May 5, 2022 at 8:59 PM Iain Sandoe via Gcc-patches
wrote:
>
>
>
> > On 5 May 2022, at 19:50, Martin Liška wrote:
> >
> > On 5/5/22 20:35, Andrew Pinski wrote:
> >> GCC_VERSION will be 0 if GCC is not being used.
> >> So you need to audit these better really.
> >
> > Ah, I see. So it basic
On Thu, May 5, 2022 at 8:12 PM Martin Liška wrote:
>
> On 5/5/22 17:31, Segher Boessenkool wrote:
> > On Thu, May 05, 2022 at 09:06:45AM -0400, Marek Polacek via Gcc-patches
> > wrote:
> >> On Thu, May 05, 2022 at 02:31:05PM +0200, Martin Liška wrote:
> >>> Some parts of the compiler already defi
On Thu, May 5, 2022 at 7:11 PM Joseph Myers wrote:
>
> On Thu, 5 May 2022, Richard Biener via Gcc-patches wrote:
>
> > MIN/MAX_EXPR shouldn't even appear with -fsignalling-nans for this
> > reason, at least that's what I thought. But yes, you might have a point
> > here (but maybe it's also not s
On May 5, 2022, Segher Boessenkool wrote:
> On Thu, May 05, 2022 at 03:52:01AM -0300, Alexandre Oliva wrote:
>> + else if (reg && MEM_P (reg)
>> + && STRICT_ALIGNMENT && MEM_ALIGN (reg) < GET_MODE_ALIGNMENT (omode))
>> +return false;
> Please fix the line breaks? Either do a break b
On Thu, May 5, 2022 at 8:27 AM Richard Biener via Gcc-patches
wrote:
>
> On Thu, May 5, 2022 at 2:19 PM Martin Liška wrote:
> >
> > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> >
> > Ready to be installed?
> > Thanks,
> > Martin
> >
> > include/ChangeLog:
> >
> >
On 5/4/22 10:03 AM, David Faust wrote:
On 5/3/22 15:32, Joseph Myers wrote:
On Mon, 2 May 2022, David Faust via Gcc-patches wrote:
Consider the following example:
#define __typetag1 __attribute__((btf_type_tag("tag1")))
#define __typetag2 __attribute__((btf_type_tag("tag2")))
On 5/5/22 5:51 PM, Michael Meissner wrote:
> On Thu, May 05, 2022 at 02:35:34PM -0500, Segher Boessenkool wrote>> A patch
> like that is pre-approved, even for trunk.
>
> And as I said, logically we should do the same for p10 fusion. I.e.
>
>callee_isa &= ~(OPTION_MASK_P8_FUSION
>
On Thu, May 05, 2022 at 02:35:34PM -0500, Segher Boessenkool wrote:
> On Thu, May 05, 2022 at 01:59:05PM -0500, Peter Bergner wrote:
> > If we cannot get this in soonish, maybe we can at least get approval for
> > applying Mike's simpler patch to the release branches, specifically GCC 10?
> >
> >
I've checked in this one-liner to note that OpenMP support for
non-rectangular loops is now complete in the feature checklist. Thanks
to Tobias for pointing me at this.
-Sandracommit 2d8752c5923e2ed4dc33b95038fed82b46526feb
Author: Sandra Loosemore
Date: Thu May 5 14:45:29 2022 -0700
l
On Thu, May 05, 2022 at 04:21:21PM -0400, Michael Meissner wrote:
> On Thu, May 05, 2022 at 02:12:43PM -0500, Segher Boessenkool wrote:
> > On Tue, Apr 12, 2022 at 09:14:55PM -0400, Michael Meissner wrote:
> > > This is V4 of the patch. Compared to V3 of the patch, GCC will just
> > > ignore -m{,n
On 5/5/22 4:27 PM, Segher Boessenkool wrote:
> On Thu, May 05, 2022 at 02:59:07PM -0500, Peter Bergner wrote:
>> On 5/5/22 2:35 PM, Segher Boessenkool wrote:
>>> A patch like that is pre-approved, even for trunk.
>>
>> That works for me! I will apply this directly to GCC 10 and regtest and
>> push
On Thu, May 05, 2022 at 02:59:07PM -0500, Peter Bergner wrote:
> On 5/5/22 2:35 PM, Segher Boessenkool wrote:
> > On Thu, May 05, 2022 at 01:59:05PM -0500, Peter Bergner wrote:
> >> If we cannot get this in soonish, maybe we can at least get approval for
> >> applying Mike's simpler patch to the re
On 5/5/22 16:57, Marek Polacek wrote:
On Wed, May 04, 2022 at 09:29:46PM -0400, Jason Merrill wrote:
On 5/4/22 19:20, Marek Polacek wrote:
On Wed, May 04, 2022 at 05:44:45PM -0400, Jason Merrill wrote:
On 5/4/22 16:03, Marek Polacek wrote:
This patch fixes the second half of 64679. Here we i
cherry-pick:
b226894d475b [sanitizer] [sanitizer] Correct GetTls for x32
---
libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp | 4
1 file changed, 4 insertions(+)
diff --git a/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp
b/libsanitizer/sanitizer_common/sanitizer_linux
On Wed, May 04, 2022 at 09:29:46PM -0400, Jason Merrill wrote:
> On 5/4/22 19:20, Marek Polacek wrote:
> > On Wed, May 04, 2022 at 05:44:45PM -0400, Jason Merrill wrote:
> > > On 5/4/22 16:03, Marek Polacek wrote:
> > > > This patch fixes the second half of 64679. Here we issue a wrong
> > > > "re
On Thu, May 05, 2022 at 02:12:43PM -0500, Segher Boessenkool wrote:
> On Tue, Apr 12, 2022 at 09:14:55PM -0400, Michael Meissner wrote:
> > This is V4 of the patch. Compared to V3 of the patch, GCC will just
> > ignore -m{,no-}power8-fusion and -m{,no-}power8-fusion-sign.
>
> But incorrectly :-(
Tested x86_64-linux -frtti/-fno-rtti, pushed to trunk.
-- >8 --
This disables a use of dynamic_cast that is not valid for -fno-rtti and
adjusts some tests so they don't FAIL with -fno-rtti. Some tests are
skipped completely, and others just make use of typeid conditional on
the __cpp_rtti macro.
On 5/5/22 2:35 PM, Segher Boessenkool wrote:
> On Thu, May 05, 2022 at 01:59:05PM -0500, Peter Bergner wrote:
>> If we cannot get this in soonish, maybe we can at least get approval for
>> applying Mike's simpler patch to the release branches, specifically GCC 10?
>>
>>https://gcc.gnu.org/bugzi
Use conditional compilation for ia32 target istead.
2022-05-05 Uroš Bizjak
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr103611-2.c (dg-do): Compile for target ia32.
(dg-options): Remove -m32.
* gcc.target/i386/pr105032.c (dg-do): Compile for taget ia32.
(dg-additional-options)
On Thu, May 05, 2022 at 01:59:05PM -0500, Peter Bergner wrote:
> If we cannot get this in soonish, maybe we can at least get approval for
> applying Mike's simpler patch to the release branches, specifically GCC 10?
>
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059#c31
Just an unconditio
Hi!
Ping^2.
Grüße
Thomas
On 2022-04-28T15:48:13+0200, I wrote:
> Hi!
>
> Ping.
>
> On 2022-04-06T11:20:47+0200, I wrote:
>> On 2021-01-14T15:50:23+0100, I wrote:
>>> I'm raising here an issue with HSA libgomp plugin code changes from a
>>> while ago. While HSA is now no longer relevant for G
Hi!
Ping.
Grüße
Thomas
On 2022-04-28T15:45:20+0200, I wrote:
> Hi Tom!
>
> On 2022-04-08T09:35:44+0200, Tom de Vries wrote:
>> On 4/8/22 00:27, Thomas Schwinge wrote:
>>> On 2017-01-13T19:11:23+0100, Jakub Jelinek wrote:
Especially for distributions it is undesirable to need to have pr
On Tue, Apr 12, 2022 at 09:14:55PM -0400, Michael Meissner wrote:
> This is V4 of the patch. Compared to V3 of the patch, GCC will just
> ignore -m{,no-}power8-fusion and -m{,no-}power8-fusion-sign.
But incorrectly :-(
> The splitting of signed halfword and word loads into unsigned load and
> si
Hi,
This patch merges the D front-end with upstream dmd 88de5e369,
synchronizing the latest regression fixes from the stable v2.100.0
branch that were found in production and industry codebases.
D front-end changes:
- Merge regression fixes in v2.100.0 branch.
Bootstrapped and regression te
On 5/2/22 8:06 PM, Michael Meissner wrote:
> Ping #5:
>
> | Date: Tue, 12 Apr 2022 21:14:55 -0400
> | From: Michael Meissner
> | Subject: [PATCH, V4] Eliminate power8 fusion options, use power8 tuning, PR
> target/102059
> | Message-ID:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-April/
> On 5 May 2022, at 19:50, Martin Liška wrote:
>
> On 5/5/22 20:35, Andrew Pinski wrote:
>> GCC_VERSION will be 0 if GCC is not being used.
>> So you need to audit these better really.
>
> Ah, I see. So it basically means all the non-GCC conditional
> code needs to remain and I can replace
>
On 5/5/22 20:35, Andrew Pinski wrote:
> GCC_VERSION will be 0 if GCC is not being used.
> So you need to audit these better really.
Ah, I see. So it basically means all the non-GCC conditional
code needs to remain and I can replace
#if GCC_VERSION >= X_Y_Z with #ifdef __GNUC__
Am I correct?
Marti
On Thu, May 05, 2022 at 06:33:20PM +0800, jiawei wrote:
> Some compiler target like arm-linux\riscv\power\s390x\xtensa-gcc handle
> char as unsigned char, then there are no warnings occur and got FAIL cases.
> Just change the type char into explicit signed char to keep the feature
> consistency.
>
On Thu, May 5, 2022 at 11:28 AM Martin Liška wrote:
>
> On 5/5/22 18:21, H.J. Lu wrote:
> > On Thu, May 5, 2022 at 4:24 AM Martin Liška wrote:
> >>
> >> On 5/5/22 01:07, H.J. Lu wrote:
> >>> On Wed, May 4, 2022 at 1:59 AM Martin Liška wrote:
>
> Hello.
>
> I'm going to do mer
On Thu, May 5, 2022 at 5:19 AM Martin Liška wrote:
>
> Right now, the minimal required version of GCC is 4.8.x
> that is a version that well supports c++11.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
No. This is broken as GCC_VERSION is u
On 5/5/22 18:21, H.J. Lu wrote:
> On Thu, May 5, 2022 at 4:24 AM Martin Liška wrote:
>>
>> On 5/5/22 01:07, H.J. Lu wrote:
>>> On Wed, May 4, 2022 at 1:59 AM Martin Liška wrote:
Hello.
I'm going to do merge from upstream.
Patch can bootstrap on x86_64-linux-gnu and s
On 5/5/22 14:24, Richard Biener wrote:
> Hmm, but we support C++11 host compilers that are not GCC but
> may claim to be, with GCC_VERSION 4.2.x for example. Are we sure
> all those liars implement what we guard with the version checks?
Do you know about any real example of such a liars?
Why shou
On 5/5/22 15:49, Jan Hubicka wrote:
> Hi,
>> The patch simplifies usage of the profile_{count,probability} types.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> Ready to be installed?
>
> The reason I intentionally did not add * and / to the original API was
> t
On 5/5/22 17:31, Segher Boessenkool wrote:
> On Thu, May 05, 2022 at 09:06:45AM -0400, Marek Polacek via Gcc-patches wrote:
>> On Thu, May 05, 2022 at 02:31:05PM +0200, Martin Liška wrote:
>>> Some parts of the compiler already define:
>>> #define likely(cond) __builtin_expect ((cond), 1)
>>>
>>> S
In my patch for PR100545 I added an assert to check for broken typedefs in
set_underlying_type, and it found one in this case:
rs6000_handle_altivec_attribute had the same problem as
handle_mode_attribute. So let's move the fixup into decl_attributes.
Tested that this fixes the ICE on a cross com
Hi
Renewing my patch to fix PR 56112 but for the insert methods, I totally
change it, now works also with move-only key types.
I let you Jonathan find a better name than _ValueTypeEnforcer as usual :-)
libstdc++: [_Hashtable] Insert range of types convertible to value_type
PR 56112
Fix ins
On Thu, 5 May 2022, Richard Biener via Gcc-patches wrote:
> MIN/MAX_EXPR shouldn't even appear with -fsignalling-nans for this
> reason, at least that's what I thought. But yes, you might have a point
> here (but maybe it's also not strictly enough specified). One option would
> be to do (minmax
On Thu, May 5, 2022 at 4:24 AM Martin Liška wrote:
>
> On 5/5/22 01:07, H.J. Lu wrote:
> > On Wed, May 4, 2022 at 1:59 AM Martin Liška wrote:
> >>
> >> Hello.
> >>
> >> I'm going to do merge from upstream.
> >>
> >> Patch can bootstrap on x86_64-linux-gnu and survives regression
> >> tests. I've
On Thu, 5 May 2022 14:40:38 +0200
Jakub Jelinek via Gcc-patches wrote:
> On Thu, May 05, 2022 at 12:46:29PM +0100, Julian Brown wrote:
> > All the above (at least) has been done as part of the patch series
> > posted here:
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591973.html
On Thu, May 05, 2022 at 09:06:45AM -0400, Marek Polacek via Gcc-patches wrote:
> On Thu, May 05, 2022 at 02:31:05PM +0200, Martin Liška wrote:
> > Some parts of the compiler already define:
> > #define likely(cond) __builtin_expect ((cond), 1)
> >
> > So the patch should unify it.
> That's funny,
On Thu, 5 May 2022, Jan Hubicka wrote:
> > It follows from how local-dynamic model is defined: we call __tls_get_addr
> > with an argument that identifies the current DSO (not the individual
> > thread-local variable), and then compute the address of the variable with
> > a simple addition, so whe
On Thu, May 05, 2022 at 03:52:01AM -0300, Alexandre Oliva wrote:
> The testcase for pr100106, compiled with optimization for 32-bit
> powerpc -mcpu=604 with -mstrict-align expands the initialization of a
> union from a float _Complex value into a load from an SCmode
> constant pool entry, aligned t
On 5/5/22 14:58, Iain Buclaw wrote:
> This D front-end change doesn't look right to me, besides the slight
Hello.
Sorry, I've re-read the patch and fixed some places where the macro usage
was wrong.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
MartinFrom 8d9630e411321c
On Wed, Feb 23, 2022 at 05:01:45PM +0100, Marcel Vollweiler wrote:
> gcc/cp/ChangeLog:
>
> * pt.cc (tsubst_omp_clauses): Add OMP_CLAUSE_HAS_DEVICE_ADDR.
> * semantics.cc (finish_omp_clauses): Handle PARM_DECL and
> NON_LVALUE_EXPR.
>
> gcc/ChangeLog:
>
> * gimplify.cc (gi
On Thu, May 05, 2022 at 08:59:21AM +0100, Richard Sandiford wrote:
> Alexandre Oliva via Gcc-patches writes:
> I know this is the best being the enemy of the good, but given
> that we're at the start of stage 1, would it be feasible to try
> to get rid of (subreg (mem)) altogether for GCC 13?
Yes
Hi,
> The patch simplifies usage of the profile_{count,probability} types.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
The reason I intentionally did not add * and / to the original API was
to detect situations where values that should be
Hi!
On Thu, May 05, 2022 at 05:30:58PM +0800, HAO CHEN GUI wrote:
> On 5/5/2022 下午 4:30, Kewen.Lin wrote:
> > on 2022/5/5 16:09, Richard Biener via Gcc-patches wrote:
> >> On Thu, May 5, 2022 at 10:07 AM HAO CHEN GUI via Gcc-patches
> >> wrote:
> >>>This patch skips constant folding for fmin/
On Thu, May 5, 2022 at 2:41 PM Martin Liška wrote:
>
> On 5/5/22 14:29, Richard Biener wrote:
> > Can we then use static_assert (...) instead and remove the
> > macro?
>
> Oh yes, we can ;)
>
> > Do we have C compiled code left (I think we might,
> > otherwise we'd not have __cplusplus guards in s
On Thu, May 05, 2022 at 02:31:05PM +0200, Martin Liška wrote:
> Some parts of the compiler already define:
> #define likely(cond) __builtin_expect ((cond), 1)
>
> So the patch should unify it.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
>
On Thu, May 5, 2022 at 2:44 PM Martin Liška wrote:
>
> The code is dead and can be removed.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
OK.
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> * genautomata.cc (create_composed_state): Remove
Excerpts from Martin Liška's message of Mai 5, 2022 2:16 pm:
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/d/ChangeLog:
>
> * longdouble.h: Use ARRAY_SIZE.
>
> diff --git a/gcc/d/longdouble.h b/gcc/d/longdoub
On 5/5/22 14:51, Pedro Alves wrote:
> On 2022-05-05 13:41, Martin Liška wrote:
>> On 5/5/22 14:29, Richard Biener wrote:
>>> Can we then use static_assert (...) instead and remove the
>>> macro?
>>
>> Oh yes, we can ;)
>>
>>> Do we have C compiled code left (I think we might,
>>> otherwise we'd not
The patch unifies names used for profiling.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Thanks,
Martin
gcc/ChangeLog:
* tree-profile.cc (gimple_gen_ic_profiler): Prefix names with
PROF_*.
(gimple_gen_time_profiler): Likewise.
---
gcc/tree-prof
On 2022-05-05 13:41, Martin Liška wrote:
> On 5/5/22 14:29, Richard Biener wrote:
>> Can we then use static_assert (...) instead and remove the
>> macro?
>
> Oh yes, we can ;)
>
>> Do we have C compiled code left (I think we might,
>> otherwise we'd not have __cplusplus guards in system.h),
>> in
On 5/5/22 12:52, Alexander Monakov wrote:
> Feels a bit weird to ask, but before entertaining such an API extension,
> can we step back and understand the v3 variant of get_symbols? It is not
> documented, and from what little I saw I did not get the "motivation" for
> its existence (what it is doi
The patch is pre-approved by Honza.
Cheers,
Martin
gcc/ChangeLog:
* value-prof.cc (stream_out_histogram_value): Remove sanity
checking.
---
gcc/value-prof.cc | 12
1 file changed, 12 deletions(-)
diff --git a/gcc/value-prof.cc b/gcc/value-prof.cc
index c240a186336.
The code is dead and can be removed.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
* genautomata.cc (create_composed_state): Remove dead code.
* graphite-poly.cc (print_pdrs): Likewise.
* lto-w
On 5/5/22 14:29, Richard Biener wrote:
> Can we then use static_assert (...) instead and remove the
> macro?
Oh yes, we can ;)
> Do we have C compiled code left (I think we might,
> otherwise we'd not have __cplusplus guards in system.h),
> in which case the #if should change to #ifdef __cplusplu
This adds the capability to value-numbering of treating complex
address expressions where the offset becomes invariant as equal
to a POINTER_PLUS_EXPR. This restores CSE that is now prevented
by early lowering of &MEM[ptr + CST] to a POINTER_PLUS_EXPR.
Unfortunately this regresses gcc.dg/asan/pr9
On Thu, May 05, 2022 at 12:46:29PM +0100, Julian Brown wrote:
> All the above (at least) has been done as part of the patch series
> posted here:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591973.html
Ah, ok, so is this patch superseded by that series, or do you want to apply
it jus
Some parts of the compiler already define:
#define likely(cond) __builtin_expect ((cond), 1)
So the patch should unify it.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/c/ChangeLog:
* c-parser.cc (c_parser_conditional_e
On Thu, May 5, 2022 at 2:20 PM Martin Liška wrote:
>
> As we require a c++11 compliant compiler, the #if __cplusplus >= 201103L
> conditional build is always true.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
Can we then use static_assert (
Although the automated regression testing scripts for powerpc64 appear
to be somewhat garbled at the moment, they've correctly identified that
my new test case for pr102950.c is failing on powerpc64, as char by
default is unsigned on this target. This patch tweaks the new testcase
by explicitly u
On Thu, May 5, 2022 at 2:19 PM Martin Liška wrote:
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> include/ChangeLog:
>
> * ansidecl.h (PTR): Remove Not ANCI C part.
> ---
> include/ansidecl.h | 16 +-
On Thu, May 5, 2022 at 2:19 PM Martin Liška wrote:
>
> Right now, the minimal required version of GCC is 4.8.x
> that is a version that well supports c++11.
Hmm, but we support C++11 host compilers that are not GCC but
may claim to be, with GCC_VERSION 4.2.x for example. Are we sure
all those li
As we require a c++11 compliant compiler, the #if __cplusplus >= 201103L
conditional build is always true.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
* basic-block.h (STATIC_ASSERT): Use normal STATIC_ASSER
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
include/ChangeLog:
* ansidecl.h (PTR): Remove Not ANCI C part.
---
include/ansidecl.h | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/include
Right now, the minimal required version of GCC is 4.8.x
that is a version that well supports c++11.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
* bitmap.cc (bitmap_popcount):
Fold GCC_VERSION >= $old
The patch simplifies usage of the profile_{count,probability} types.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
* bb-reorder.cc (find_traces_1_round): Add operators / and * and
use them.
(be
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ada/ChangeLog:
* locales.c (iso_639_1_to_639_3): Use ARRAY_SIZE.
(language_name_to_639_3): Likewise.
(country_name_to_3166): Likewise.
gcc/analyzer/ChangeLog:
> On Thu, 5 May 2022, Jan Hubicka wrote:
>
> > Also note that visibility pass is run twice (once at compile time before
> > early optimizations and then again at LTO). Since LTO linking may
> > promote public symbols to local/hidden, perhaps we want to do this only
> > second time the pass is exec
On Thu, 5 May 2022, Jan Hubicka wrote:
> Also note that visibility pass is run twice (once at compile time before
> early optimizations and then again at LTO). Since LTO linking may
> promote public symbols to local/hidden, perhaps we want to do this only
> second time the pass is executed?
The f
On Thu, 5 May 2022 10:52:57 +0200
Jakub Jelinek via Gcc-patches wrote:
> On Mon, Feb 21, 2022 at 11:18:57PM +0800, Chung-Lin Tang wrote:
> > as encountered in cases where a program constructs its own
> > deep-copying for arrays-of-pointers, e.g:
> >
> >#pragma omp target enter data map(to:le
On 5/5/22 01:07, H.J. Lu wrote:
> On Wed, May 4, 2022 at 1:59 AM Martin Liška wrote:
>>
>> Hello.
>>
>> I'm going to do merge from upstream.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression
>> tests. I've also tested on ppc64le-linux-gnu and verified the ABI.
>>
>> The onl
Hello,
This patch teaches the DWARF support in gcc about RA_AUTH_CODE pseudo
hard-register and also
.save {ra_auth_code} and .cfi_offset ra_auth_code dwarf directives for
the PAC feature
in Armv8.1-M architecture.
RA_AUTH_CODE register number is 107 and it's dwarf register number is 143.
Whe
On Thu, 5 May 2022, Richard Biener via Gcc-patches wrote:
> > I think they should simply try to not register LDPT_GET_SYMBOLS or
> > LDPT_GET_SYMBOLS_V2 with the plugin in the onload hook and if
> > that fails they will know the plugin doesn't support V3 only. I suppose
> > it should work to call
> > @@ -872,6 +872,22 @@ function_and_variable_visibility (bool whole_program)
> > }
> > }
> > }
> > + FOR_EACH_VARIABLE (vnode)
> > +{
> > + tree decl = vnode->decl;
> > +
> > + /* Optimize TLS model based on visibility (taking into account
> > + optim
Some compiler target like arm-linux\riscv\power\s390x\xtensa-gcc handle
char as unsigned char, then there are no warnings occur and got FAIL cases.
Just change the type char into explicit signed char to keep the feature
consistency.
gcc/testsuite/ChangeLog:
* c-c++-common/Wconversion-1.c
On 05.05.22 10:30, Jakub Jelinek via Fortran wrote:
+ memcpy_t *a = args;
+ int ret = omp_target_memcpy_copy (a->dst, a->src, a->length, a->dst_offset,
+a->src_offset, a->dst_devicep,
+a->src_devicep);
+ if (ret)
+gomp_fatal (
On Thu, May 05, 2022 at 11:45:19AM +0200, Tobias Burnus wrote:
> > On Mon, Mar 14, 2022 at 04:42:14PM +0100, Marcel Vollweiler wrote:
> > > +interface
> > > + function omp_target_is_accessible (ptr, size, device_num)
> > > bind(c)
> > > +use, intrinsic :: iso_c_binding
On Thu, May 05, 2022 at 11:44:59AM +0200, Richard Biener wrote:
> When we make stmts to execute unconditionally in ifcombine we have
> to make sure to rewrite stmts that can invoke undefined behavior
> on overflow into a form with defined overflow. That's possible
> for all but signed division for
Hi,
On 05.05.22 11:33, Jakub Jelinek via Gcc-patches wrote:
On Mon, Mar 14, 2022 at 04:42:14PM +0100, Marcel Vollweiler wrote:
+interface
+ function omp_target_is_accessible (ptr, size, device_num) bind(c)
+use, intrinsic :: iso_c_binding, only : c_ptr, c_size_t, c_
When we make stmts to execute unconditionally in ifcombine we have
to make sure to rewrite stmts that can invoke undefined behavior
on overflow into a form with defined overflow. That's possible
for all but signed division for which we have to avoid the transform.
Bootstrapped and tested on x86_6
Marc Poulhiès writes:
> Require effective target fpic for newly added test.
>
> gcc/testsuite/
> * g++.dg/ext/visibility/visibility-local-extern1.C: Add missing
> dg-require-effective-target fpic.
>
> Tested on x86_64-linux. Ok for master?
>
> ---
> gcc/testsuite/g++.dg/ext/visibilit
On Mon, Mar 14, 2022 at 04:42:14PM +0100, Marcel Vollweiler wrote:
> --- a/libgomp/libgomp.map
> +++ b/libgomp/libgomp.map
> @@ -226,6 +226,11 @@ OMP_5.1 {
> omp_get_teams_thread_limit_;
> } OMP_5.0.2;
>
> +OMP_5.1.1 {
> + global:
> + omp_target_is_accessible;
> +} OMP_5.1;
> +
You'v
On 5/5/2022 下午 4:30, Kewen.Lin wrote:
> on 2022/5/5 16:09, Richard Biener via Gcc-patches wrote:
>> On Thu, May 5, 2022 at 10:07 AM HAO CHEN GUI via Gcc-patches
>> wrote:
>>>
>>> Hi,
>>>This patch skips constant folding for fmin/max when either argument
>>> is sNaN. According to C standard,
On Wed, Mar 09, 2022 at 07:04:24PM +0800, Chung-Lin Tang wrote:
> Now in OpenMP 5.x, static members are supposed to be not a barrier for a class
> to be target-mapped.
>
> There is the related issue of actually providing access to static
> const/constexpr
> members on the GPU (probably a case of
On Mon, Feb 21, 2022 at 11:18:57PM +0800, Chung-Lin Tang wrote:
> as encountered in cases where a program constructs its own deep-copying
> for arrays-of-pointers, e.g:
>
>#pragma omp target enter data map(to:level->vectors[:N])
>for (i = 0; i < N; i++)
> #pragma omp target enter data
This properly aligns data, increasing test coverage.
Tested on x86_64-unknown-linux-gnu, pushed.
2022-05-05 Richard Biener
PR testsuite/105486
* gcc.dg/vect/bb-slp-pr104240.c: Align all data.
---
gcc/testsuite/gcc.dg/vect/bb-slp-pr104240.c | 3 +++
1 file changed, 3 insertion
On Thu, May 5, 2022 at 10:30 AM Kewen.Lin wrote:
>
> on 2022/5/5 16:09, Richard Biener via Gcc-patches wrote:
> > On Thu, May 5, 2022 at 10:07 AM HAO CHEN GUI via Gcc-patches
> > wrote:
> >>
> >> Hi,
> >>This patch skips constant folding for fmin/max when either argument
> >> is sNaN. Accordi
When the IL representation of VEC_SET is marked as throwing
(unnecessarily), we need to clean that when replacing it with
the .VEC_SET internal function call which cannot throw.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
2022-05-05 Richard Biener
PR tree-optimizati
On Mon, Feb 21, 2022 at 12:19:20PM +0100, Marcel Vollweiler wrote:
> gcc/ChangeLog:
>
> * omp-low.cc (omp_runtime_api_call): Added target_memcpy_async and
> target_memcpy_rect_async to omp_runtime_apis array.
>
> libgomp/ChangeLog:
>
> * libgomp.map: Added omp_target_memcpy_asy
on 2022/5/5 16:09, Richard Biener via Gcc-patches wrote:
> On Thu, May 5, 2022 at 10:07 AM HAO CHEN GUI via Gcc-patches
> wrote:
>>
>> Hi,
>>This patch skips constant folding for fmin/max when either argument
>> is sNaN. According to C standard,
>>fmin(sNaN, sNaN）= qNaN, fmin(sNaN, NaN) =
On Thu, May 5, 2022 at 10:23 AM Hongtao Liu wrote:
>
> On Thu, May 5, 2022 at 4:09 PM Uros Bizjak via Gcc-patches
> wrote:
> >
> > On Thu, May 5, 2022 at 9:50 AM Richard Biener via Gcc-patches
> > wrote:
> > >
> > > On Thu, May 5, 2022 at 9:37 AM liuhongt via Gcc-patches
> > > wrote:
> > > >
>
On Thu, May 5, 2022 at 7:04 AM liuhongt wrote:
>
> Optimize
>
> _1 = *srcp_3(D);
> _4 = VEC_PERM_EXPR <_1, _1, { 4, 5, 6, 7, 4, 5, 6, 7 }>;
> _5 = BIT_FIELD_REF <_4, 128, 0>;
>
> to
>
> _1 = *srcp_3(D);
> _5 = BIT_FIELD_REF <_1, 128, 128>;
>
> the upper will finally be optimized to
>
> _
On Thu, May 5, 2022 at 4:09 PM Uros Bizjak via Gcc-patches
wrote:
>
> On Thu, May 5, 2022 at 9:50 AM Richard Biener via Gcc-patches
> wrote:
> >
> > On Thu, May 5, 2022 at 9:37 AM liuhongt via Gcc-patches
> > wrote:
> > >
> > > Enable optimization for TImode only under 32-bit target, for 64-bit
On Thu, May 5, 2022 at 10:08 AM Uros Bizjak wrote:
>
> On Thu, May 5, 2022 at 9:50 AM Richard Biener via Gcc-patches
> wrote:
> >
> > On Thu, May 5, 2022 at 9:37 AM liuhongt via Gcc-patches
> > wrote:
> > >
> > > Enable optimization for TImode only under 32-bit target, for 64-bit
> > > target th
On Thu, May 5, 2022 at 10:07 AM HAO CHEN GUI via Gcc-patches
wrote:
>
> Hi,
>This patch skips constant folding for fmin/max when either argument
> is sNaN. According to C standard,
>fmin(sNaN, sNaN）= qNaN, fmin(sNaN, NaN) = qNaN
>So signaling NaN should be tested and skipped for fmin/m
On Thu, May 5, 2022 at 9:50 AM Richard Biener via Gcc-patches
wrote:
>
> On Thu, May 5, 2022 at 9:37 AM liuhongt via Gcc-patches
> wrote:
> >
> > Enable optimization for TImode only under 32-bit target, for 64-bit
> > target there could be extra ineteger <-> sse move regarding psABI,
> > not effi
Hi,
This patch skips constant folding for fmin/max when either argument
is sNaN. According to C standard,
fmin(sNaN, sNaN）= qNaN, fmin(sNaN, NaN) = qNaN
So signaling NaN should be tested and skipped for fmin/max in match.pd.
Bootstrapped and tested on ppc64 Linux BE and LE with no regr
1 - 100 of 105 matches
Mail list logo
