On Tue, Sep 13, 2022 at 02:03:18PM -0700, Julian Brown wrote:
> This patch is an extension and rewrite/rethink of the following two patches:
>
> "OpenMP/OpenACC: Add inspector class to unify mapped address analysis"
> https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591977.html
>
> "Ope
On Wed, Sep 14, 2022 at 03:30:39PM +0200, Richard Biener via Gcc-patches wrote:
> > +// GCC is distributed in the hope that it will be useful, but WITHOUT ANY
> > +// WARRANTY; without even the implied warranty of MERCHANTABILITY or
> > +// FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Pub
On Wed, Sep 14, 2022 at 03:41:48PM +0200, Richard Biener via Gcc-patches wrote:
> On Wed, Aug 24, 2022 at 2:08 PM wrote:
> >
> > From: Philip Herron
> >
> > This allows us to invoke the rust testsuite.
>
> OK.
>
> >
> > ChangeLog:
> > * Makefile.def: Add autogen target
> > * Mak
On Tue, Sep 13, 2022 at 02:04:30PM -0700, Julian Brown wrote:
> This patch implements OpenMP 5.0 "declare mapper" support for C++.
> This hasn't been fully revised yet following previous review comments,
> but I am including it in this series to demonstrate the new approach to
> gimplifying map cla
On Wed, Sep 14, 2022 at 11:31:34AM -0600, Sandra Loosemore wrote:
> GCC presently enables the loop vectorizer at lower optimization levels for
> OpenMP loops with the "simd" specifier than it does for loops without it.
> The "simd" specifier isn't defined to be purely an optimization hint to the
>
On Wed, Sep 14, 2022 at 11:32:11AM -0600, Sandra Loosemore wrote:
> This patch is part of the ongoing effort to find more SIMD optimization
> opportunities in OpenMP code. Here we are looking for functions that have
> the "omp declare target" attribute that are also suitable candidates for
> autom
On Fri, Sep 16, 2022 at 01:48:54PM +0200, Jason Merrill wrote:
> On 9/12/22 04:05, Jakub Jelinek wrote:
> > The following patch implements the compiler part of C++23
> > P1467R9 - Extended floating-point types and standard names compiler part
> > by introducing _Float{16,32,64,128} as keywords and
Hi!
As the following testcase reduced from glibc fmtmsg.c shows
(it doesn't ICE on x86_64/i686 unfortunately, but does on various other
arches), my last optimize_range_tests_cmp_bitwise change wasn't fully
correct. The intent was to let all pointer operands be cast to
pointer_sized_int_node first
On Sat, Sep 17, 2022 at 01:23:59AM +0200, Jason Merrill wrote:
> On 9/13/22 12:42, Jakub Jelinek wrote:
> > The following patch attempts to implement C++23 P1169R4 - static operator()
> > paper's compiler side (there is some small library side too not implemented
> > yet). This allows static membe
On Sun, Sep 18, 2022 at 08:10:00PM +0100, Julian Brown wrote:
> I don't think any ATTACH clauses can appear during
> the gimplify_adjust_omp_clause_1 walk. So, how about this?
LGTM, thanks.
Jakub
Hi!
On Sat, Sep 17, 2022 at 01:23:59AM +0200, Jason Merrill wrote:
> I wonder why we don't give an error when setting the
> conflicting_specifiers_p flag in cp_parser_set_storage_class? We should be
> able to give a better diagnostic at that point.
I didn't have time to update the whole patch la
Hi!
The following patch implements something that has Florian found as
low hanging fruit in our unwinder and has been discussed in the
https://gcc.gnu.org/wiki/cauldron2022#cauldron2022talks.inprocess_unwinding_bof
talk.
_Unwind_FrameState type seems to be (unlike the pre-GCC 3 frame_state
which h
On Mon, Sep 19, 2022 at 09:37:22AM +0200, Richard Biener wrote:
> On Sat, Sep 17, 2022 at 10:25 AM Aldy Hernandez via Gcc-patches
> wrote:
> >
> > Jakub has mentioned that for -funsafe-math-optimizations we may flush
> > denormals to zero, in which case we need to be careful to extend the
> > rang
On Mon, Sep 19, 2022 at 10:57:25AM +0200, Richard Biener wrote:
> For even more uglification and avoiding of the cache effect mentioned below
> we could squeeze the 4 bits into the union members, at least on 64bit
> platforms
> (probably not on 32bit ones) ...
Maybe, but it would limit the offset
On Mon, Sep 19, 2022 at 11:25:13AM +0200, Florian Weimer wrote:
> * Jakub Jelinek:
>
> > The disadvantage of the patch is that touching reg[x].loc and how[x]
> > now means 2 cachelines rather than one as before, and I admit beyond
> > bootstrap/regtest I haven't benchmarked it in any way. Florian
Hi!
On Sat, Sep 17, 2022 at 01:30:08PM +0200, Jason Merrill wrote:
Below is an updated patch on top of the
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601788.html
patch.
> Ah, OK. I don't think you need to check for C++23 or CALL_EXPR at all, just
> CONVERSION_RANK of the other cand
On Sat, Sep 17, 2022 at 10:58:54AM +0200, Jason Merrill wrote:
> > I thought it is fairly important because __float128 has been around in GCC
> > for 19 years already. To be precise, I think e.g. for x86_64 GCC 3.4
> > introduced it, but mangling was implemented only in GCC 4.1 (2006), before
> >
On Mon, Sep 19, 2022 at 02:25:59PM -0400, Marek Polacek via Gcc-patches wrote:
> A trivial fix for maybe_warn_for_null_address where we print an
> inform note without first checking the return value of a warning
> call.
>
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/12?
>
>
On Tue, Sep 20, 2022 at 07:22:03AM +0200, Aldy Hernandez wrote:
> > > Jakub actually suggested something completely different...just set +0
> > > always for !HONOR_SIGNED_ZEROS.
> >
> > Hmm, but the [-1, -0.] with known sign becomes [-1, +0.] with unknown sign?
>
> Huh. I guess that's true. Does
On Tue, Sep 20, 2022 at 11:35:07AM +0800, Hongtao Liu wrote:
> > The question is (mainly for aarch64, arm and x86 backend maintainers) if we
> > shouldn't support it, in the PR there is a partial patch to do so, but
> > the big question is if it should be supported as the __bf16 type those
> > 3 ta
On Tue, Sep 20, 2022 at 04:58:38PM +0200, Aldy Hernandez wrote:
> > > > deal with NaNs just fine and is required to correctly capture the sign
> > > > of
> > > > 'x'. If frange::set_nonnegative is supposed to be used in such contexts
> > > > (and I think it's a good idea if that were the case), t
On Wed, Sep 21, 2022 at 03:45:36PM +0800, Chung-Lin Tang via Gcc-patches wrote:
> Hi Tom,
> I had a patch submitted earlier, where I reported that the current way of
> implementing
> barriers in libgomp on nvptx created a quite significant performance drop on
> some SPEChpc2021
> benchmarks:
> ht
Hi!
The following patch implements C++23 P1774R8 - Portable assumptions
paper, by introducing support for [[assume (cond)]]; attribute for C++.
In addition to that the patch adds [[gnu::assume (cond)]]; and
__attribute__((assume (cond))); support to both C and C++.
As described in C++23, the attri
On Tue, Sep 06, 2022 at 09:20:47PM -0400, David Malcolm via Gcc-patches wrote:
> I added c_expr::m_decimal in r13-2386-gbedfca647a9e9c1a as part of the
> implementation of -Wxor-used-as-pow, but I missed various places where
> the field needed to be initialized.
>
> Fixed thusly (based on searchin
On Tue, Jun 21, 2022 at 11:12:15AM -0700, Noah Goldstein wrote:
> This patch allows for strchr(x, c) to the replace with memchr(x, c,
> strlen(x) + 1) if strlen(x) has already been computed earlier in the
> tree.
>
> Handles PR95821: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95821
>
> Since me
On Mon, Aug 15, 2022 at 03:23:11PM -0400, Siddhesh Poyarekar wrote:
> --- a/gcc/tree-object-size.cc
> +++ b/gcc/tree-object-size.cc
> @@ -495,6 +495,18 @@ decl_init_size (tree decl, bool min)
>return size;
> }
>
> +/* Get the outermost object that PTR may point into. */
> +
> +static tree
>
On Sun, Sep 18, 2022 at 08:19:29PM +0100, Julian Brown wrote:
> @@ -2609,6 +2672,9 @@ gfc_trans_omp_clauses (stmtblock_t *block,
> gfc_omp_clauses *clauses,
>if (clauses == NULL)
> return NULL_TREE;
>
> + hash_map sym_rooted_nl;
Isn't hash_map ctor pretty costly (allocates memory etc.
On Mon, Sep 19, 2022 at 08:40:34PM +0100, Julian Brown wrote:
> On Wed, 14 Sep 2022 15:24:12 +0200
> Jakub Jelinek wrote:
>
> > On Tue, Sep 13, 2022 at 02:03:18PM -0700, Julian Brown wrote:
> > > This patch is an extension and rewrite/rethink of the following two
> > > patches:
> > >
> > > "Op
On Thu, Sep 22, 2022 at 05:02:19PM +0200, Aldy Hernandez wrote:
> It has always irritated me that we don't have TYPE_MIN_VALUE and
> TYPE_MAX_VALUE for floats (and for pointers for that matter). This
> means, we have to recalculate it ad-nauseum in vrp_val_min and
> vrp_val_max.
>
> I know we hav
On Tue, Sep 20, 2022 at 10:51:18AM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Sep 20, 2022 at 11:35:07AM +0800, Hongtao Liu wrote:
> > > The question is (mainly for aarch64, arm and x86 backend maintainers) if
> > > we
> > > shouldn't support it, in
On Thu, Sep 22, 2022 at 06:49:10PM +0200, Aldy Hernandez wrote:
> It has been suggested that if we start bumping numbers by an ULP when
> calculating open ranges (for example the numbers less than 3.0) that
> dumping these will become increasingly harder to read, and instead we
> should opt for the
Hi!
When looking at the attribs code, I've noticed weird diagnostics
like
int a __attribute__((section ("foo", "bar")));
a.c:1:1: error: wrong number of arguments specified for ‘section’ attribute
1 | int a __attribute__((section ("foo", "bar")));
| ^~~
a.c:1:1: note: expected between 1
On Fri, Sep 23, 2022 at 02:42:54PM +0800, liuhongt via Gcc-patches wrote:
> 2022-09-23 Hongtao Liu
> Liwei Xu
>
> gcc/ChangeLog:
>
> PR target/53346
> * config/i386/i386-expand.cc (expand_vec_perm_shufps_shufps):
> New function.
> (ix86_expand_vec_perm_const
On Thu, Sep 22, 2022 at 01:10:08PM +0200, Richard Biener via Gcc-patches wrote:
> * g++.dg/tree-ssa/pr106922.C: Adjust.
> --- a/gcc/testsuite/g++.dg/tree-ssa/pr106922.C
> +++ b/gcc/testsuite/g++.dg/tree-ssa/pr106922.C
> @@ -87,5 +87,4 @@ void testfunctionfoo() {
>}
> }
>
> -// { dg-fi
On Fri, Sep 23, 2022 at 08:29:46AM +0100, Julian Brown wrote:
> On Thu, 22 Sep 2022 15:17:08 +0200
> Jakub Jelinek wrote:
>
> > > + bool built_sym_hash = false;
> >
> > So, I think usually we don't construct such hash_maps right away,
> > but have just pointer to the hash map initialized to N
On Thu, Sep 22, 2022 at 11:26:29AM -0400, Siddhesh Poyarekar wrote:
> On 2022-09-22 09:02, Jakub Jelinek wrote:
> > On Mon, Aug 15, 2022 at 03:23:11PM -0400, Siddhesh Poyarekar wrote:
> > > --- a/gcc/tree-object-size.cc
> > > +++ b/gcc/tree-object-size.cc
> > > @@ -495,6 +495,18 @@ decl_init_size (
Hi!
As the testcase shows, OFFSET_TYPE needs the same treatment as
POINTER_TYPE/REFERENCE_TYPE, otherwise we fail the same during the
newly added verification. OFFSET_TYPE is signed though, so unlike
POINTER_TYPE/REFERENCE_TYPE it can also trigger with the
x < 0 && y < 0 && z < 0 to (x | y | z) <
Hi!
The following patch implements OpenMP 5.1
#pragma omp assume
#pragma omp assumes
and
#pragma omp begin assumes
#pragma omp end assumes
directive support for C and C++. Currently it doesn't remember
anything from the assumption clauses for later, so is mainly
to support the directives and diag
On Mon, Sep 26, 2022 at 05:15:12PM -0400, Jason Merrill wrote:
> > Anyway, here is an updated patch that adds also _Float{32,64,128}x support
> > with DF{32,64,128}x mangling and demangling and the conv->bad_p + pedwarn
> > change. __float128 is still distinct from _Float128.
>
> Looks good with
On Mon, Sep 26, 2022 at 05:23:45PM -0600, Jeff Law via Gcc-patches wrote:
>
> On 9/26/22 13:52, H.J. Lu wrote:
> > On Sat, Sep 24, 2022 at 1:37 PM Jeff Law wrote:
> > >
> > > On 9/21/22 16:11, H.J. Lu wrote:
> > > > On Wed, Sep 7, 2022 at 10:03 AM Jeff Law via Gcc-patches
> > > > wrote:
> > > >
Hi!
The following patch is partial support for std::float{16,32,64,128}_t
in libstdc++.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1467r9.html
says that , , , and
need changes too, but before doing that, it would be nice to get an
agreement on what macros to use etc.
The support f
Hi!
As reported by Tobias, my C++ _Float{16,32,64,128,32x,64x,128x} support
patch broke Debian/Ubuntu bootstraps. The problem is that there
glibc bits/floatn.h and bits/floatn-common.h isn't in /usr/include/
directly, but in a subdirectory like /usr/include/x86_64-linux-gnu/
Seems other fixinclud
Hi!
On Wed, Sep 28, 2022 at 12:23:31AM +, Joseph Myers wrote:
> In general the changes match those made by fixincludes, though I think
> the ones in sysdeps/powerpc/bits/floatn.h, where the header tests
> __LDBL_MANT_DIG__ == 113 or uses #elif, wouldn't match the existing
> fixincludes pattern
Hi!
My recent change to enable _Float{16,32,64,128,32x,64x,128x} for C++
apparently broke bootstrap on some Debian/Ubuntu setups.
Those multiarch targets put some headers into
/usr/include/x86_64-linux-gnu/bits/ etc. subdirectory instead of
/usr/include/bits/.
This is handled by
/* /usr/includ
Hi!
The following testcase ICEs on x86 as well as ppc64le (the latter
with -mabi=ieeelongdouble), because _Float64x there isn't mangled as
DF64x but e or u9__ieee128 instead.
Those are the mangling that should be used for the non-standard
types with the same mode or for long double, but not for _F
Hi!
Here is more complete patch to add std::bfloat16_t support on
x86, AArch64 and (only partially) on ARM 32-bit. No BFmode optabs
are added by the patch, so for binops/unops it extends to SFmode
first and then truncates back to BFmode.
For {HF,SF,DF,XF,TF}mode -> BFmode conversions libgcc has i
On Wed, Sep 28, 2022 at 08:19:43PM +0200, Jakub Jelinek via Gcc-patches wrote:
> Another case are the following 3 snippets:
> # if !__GNUC_PREREQ (7, 0) || defined __cplusplus
> # error "_Float128X supported but no constant suffix"
> # else
> # define __f12
On Sun, Sep 18, 2022 at 10:24:43AM +0200, Marcel Vollweiler wrote:
> gcc/ChangeLog:
>
> * gimplify.cc (optimize_target_teams): Set initial num_teams_upper
> to "-2" instead of "1" for non-existing num_teams clause in order to
> disambiguate from the case of an existing num_teams
On Wed, Sep 21, 2022 at 09:17:18PM -0600, Sandra Loosemore wrote:
> On 9/14/22 12:12, Jakub Jelinek wrote:
>
> > If it is pure optimization thing and purely keyed on the definition,
> > all the simd clones should be local to the TU, never exported from it.
>
> OK, here is a revised patch that add
On Fri, Sep 30, 2022 at 12:41:19PM +0200, Tobias Burnus wrote:
> While has_device_addr has been implemented (in GCC 12), updating
> use_device_ptr for Fortran was missed.
>
> This patch fixes it: Removing the restrictions and mapping to
> has_device_addr where applicable.
>
> For use_device_ptr s
On Fri, Sep 30, 2022 at 09:49:08AM -0400, Jason Merrill wrote:
> The comment from Apple on the ABI mangling proposal suggests to me that we
> might want to delay enabling C++ std::bfloat16_t (i.e. defining
> __STDCPP_BFLOAT16_T__) until we have that excess precision support?
I saw that comment. W
On Fri, Sep 30, 2022 at 10:07:59AM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Sep 29, 2022 at 12:01:43PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > --- gcc/config/i386/i386.cc.jj 2022-09-29 09:13:25.713718513 +0200
> > +++ gcc/config/i386/i386.cc 2022-09-
Hi!
The following patch adds support for the begin declare target construct,
which is another spelling for declare target construct without clauses
(where it needs paired end declare target), but unlike that one accepts
clauses.
This is an OpenMP 5.1 feature, implemented with 5.2 clarification be
On Fri, Sep 30, 2022 at 09:54:49AM -0400, Jason Merrill wrote:
> > Note, there is one further problem on aarch64/arm, types with HFmode
> > (_Float16 and __fp16) are there mangled as Dh (which is standard
> > Itanium mangling:
> > ::= Dh # IEEE 754r half-precision floating point (
On Fri, Sep 30, 2022 at 06:38:39PM +0100, Richard Sandiford wrote:
> OK for the aarch64 part, thanks. But could you add some scan-assemblers
> to the test to check for the mangled names? I assume they should be:
Ok, about to commit the aarch64 part, will await review of the rest
afterwards.
>
>
On Fri, Sep 30, 2022 at 06:47:07PM +0100, Jonathan Wakely via Gcc-patches wrote:
> On Fri, 30 Sept 2022 at 17:26, Jonathan Wakely wrote:
> >
> > On Fri, 30 Sept 2022 at 17:04, Torbjörn SVENSSON
> > wrote:
> > >
> > > libstdc++-v3/testsuite:
> > >
> > > * 20_util/bind/ref_neg.cc: Prune Wind
On Fri, Sep 30, 2022 at 06:21:04PM +, Joseph Myers wrote:
> On Fri, 30 Sep 2022, Jakub Jelinek via Gcc-patches wrote:
>
> > What isn't in the patch but I think we'll need to also change are some
> > minimal set of __builtin_*bf16 builtins. Seems for _Float
On Sat, Oct 01, 2022 at 12:56:59AM -0700, Julian Brown wrote:
> This patch is a minimal fix for the recently-added
> struct-component-kind-1.c test (which is currently failing to emit one
> of the errors it expects in scan output). This fragment was erroneously
> omitted from the second version of
On Fri, Sep 30, 2022 at 04:39:25PM -0400, Jason Merrill wrote:
> > --- gcc/cp/decl.cc.jj 2022-09-22 00:14:55.478599363 +0200
> > +++ gcc/cp/decl.cc 2022-09-22 00:24:01.121178256 +0200
> > @@ -223,6 +223,7 @@ struct GTY((for_user)) named_label_entry
> > bool in_transaction_scope;
> >
Hi!
Obvious typo in diagnostics.
Committed as obvious to trunk.
2022-10-02 Jakub Jelinek
PR tree-optimization/107121
* tree-cfg.cc (verify_gimple_call): Fix a typo in diagnostics,
DEFFERED_INIT -> DEFERRED_INIT.
--- gcc/tree-cfg.cc.jj 2022-09-29 09:13:31.321641176 +
On Fri, Sep 30, 2022 at 04:39:25PM -0400, Jason Merrill wrote:
> > * fold-const.h (simple_operand_p_2): Declare.
>
> This needs a better name if it's going to be a public interface.
>
> The usage also needs rationale for why this is the right predicate for
> assume, rather than just no-side-e
On Fri, Sep 30, 2022 at 04:08:10PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Fri, Sep 30, 2022 at 09:49:08AM -0400, Jason Merrill wrote:
> > The comment from Apple on the ABI mangling proposal suggests to me that we
> > might want to delay enabling C++ std::bfloat16_t
Hi!
In these spots, the error/error_at has some inform afterwards which are
explanation part of the same diagnostics, so should be tied with
auto_diagnostic_group with it.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2022-10-04 Jakub Jelinek
* attribs.cc (hand
On Sun, Oct 02, 2022 at 07:47:18PM +0200, Tobias Burnus wrote:
> gcc/ChangeLog:
>
> * doc/invoke.texi (-fopenmp-simd): Document that also 'assume'
> is enabled.
>
> libgomp/ChangeLog:
>
> * libgomp.texi (OpenMP 5.1 Impl. Status): Mark 'assume' as 'Y'.
>
> gcc/fortran/ChangeLog
On Mon, Oct 03, 2022 at 09:22:42PM +0200, Jakub Jelinek via Gcc-patches wrote:
> Here is a lightly tested updated patch which I'll bootstrap/regtest tonight.
Bootstrap/regtest passed on both x86_64-linux and i686-linux.
Jakub
On Tue, Oct 04, 2022 at 02:26:13PM +0200, Tobias Burnus wrote:
> Hi Jakub,
>
> On 04.10.22 12:19, Jakub Jelinek wrote:
>
> On Sun, Oct 02, 2022 at 07:47:18PM +0200, Tobias Burnus wrote:
>
>
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -2749,9 +2749,9 @@ have support for @option{
On Tue, Oct 04, 2022 at 04:42:04PM -0400, Jason Merrill wrote:
> It could choose which function to call based on whether the constexpr_ctx
> parameter is null?
Done, though it needs to be in constexpr.cc then because struct
constexpr_ctx and cxx_eval_constant_expression is local to constexpr.cc.
Hi!
I'd like to ping this patch.
Thanks.
> 2022-09-19 Jakub Jelinek
>
> * unwind-dw2.h (REG_UNSAVED, REG_SAVED_OFFSET, REG_SAVED_REG,
> REG_SAVED_EXP, REG_SAVED_VAL_OFFSET, REG_SAVED_VAL_EXP,
> REG_UNDEFINED): New anonymous enum, moved from inside of
> struct frame_sta
On Wed, Oct 05, 2022 at 01:49:40PM +0200, Martin Liška wrote:
> PR c/107156
>
> gcc/ChangeLog:
>
> * attribs.h (lookup_attribute_by_prefix): Support attributes
> starting with underscore (like _noreturn, or __Noreturn).
There are no _noreturn or __Noreturn attributes, there is
Hi!
The following patch uses the new lookup_attribute overload and extra
tests to avoid emitting weird warnings on foreign namespace attributes
which we should just ignore (perhaps with a warning), but shouldn't
imply any meaning to them just because they have a name matching some
standard or gnu
On Tue, Oct 04, 2022 at 05:50:50PM -0400, Jason Merrill wrote:
> > Another question is the suffixes of the builtins. For now I have added
> > bf16 suffix and enabled the builtins with !both_p, so one always needs to
> > use __builtin_* form for them. None of the GCC builtins end with b,
> > so th
On Wed, Oct 05, 2022 at 02:29:56PM +0200, Tobias Burnus wrote:
> + gfc_error ("!OMP ASSUMES at %C must be in the specification part of a "
s/!OMP/!$OMP/
Otherwise LGTM.
Jakub
Hi!
Now that [[assume (cond)]] support is in, this simple patch makes
#pragma omp assume holds(cond)
use it.
Committed to trunk.
2022-10-06 Jakub Jelinek
* c-parser.cc (c_parser_omp_assumption_clauses): Emit IFN_ASSUME
call for holds clause on assume construct.
* p
On Thu, Oct 06, 2022 at 12:55:01PM +0200, Tobias Burnus wrote:
> Same as for C/C++, albeit a tiny bit longer patch.
>
> I don't know whether it makes sense to handle – in the long run – the
> case of se.pre/se.post being nonempty – and, if so, how.
I think it is essential not to throw those away,
On Thu, Oct 06, 2022 at 06:15:52PM +0200, Tobias Burnus wrote:
> On 06.10.22 14:17, Jakub Jelinek wrote:
> > On Thu, Oct 06, 2022 at 12:55:01PM +0200, Tobias Burnus wrote:
> > > I don't know whether it makes sense to handle – in the long run – the
> > > case of se.pre/se.post being nonempty – and,
On Thu, Oct 06, 2022 at 09:42:47AM -0400, Jason Merrill wrote:
> > - tree t = lookup_attribute ("fallthrough", attr);
> > + tree t = lookup_attribute (NULL, "fallthrough", attr);
> > + if (t == NULL_TREE)
> > +t = lookup_attribute ("gnu", "fallthrough", attr);
>
> Maybe lookup_attribute wit
On Thu, Oct 06, 2022 at 01:30:18PM -0400, Jason Merrill wrote:
> Yes, except I was thinking the new function would take the attribute
> TREE_LIST as its parameter so that all the callers don't have to also call
> get_attribute_namespace.
Ok, here it is in patch form.
2022-10-06 Jakub Jelinek
Hi!
On Thu, Oct 06, 2022 at 10:05:29PM +, Joseph Myers wrote:
> I'm seeing the following build failure for arc-linux-gnu after this
> commit. (Note that this is for building GCC *after* glibc, not for an
> initial inhibit_libc bootstrap build of GCC.)
>
> In file included from
> /scratch/
Hi!
When looking at tree-inline.cc I've noticed a comment typo and grepped
for similar typos elsewhere.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk
as obvious.
2022-10-07 Jakub Jelinek
* ipa-prop.h (ipa_constant_data): Fix comment typo.
* value-r
On Thu, Oct 06, 2022 at 06:15:52PM +0200, Tobias Burnus wrote:
> Like as attached? – It did survive regtesting.
Like in other spots in trans-openmp.cc that create a TARGET_EXPR, the
slot has to be created with create_tmp_var_raw, because gfc_create_var
adds the var to BLOCK_VARS and that ICEs duri
Hi!
My earlier patches gimplify the simplest non-side-effects assumptions
into if (cond) ; else __builtin_unreachable (); and throw the rest
on the floor.
The following patch attempts to do something with the rest too.
For -O0, it actually throws even the simplest assumptions on the floor,
we don'
Hi!
On Fri, Oct 07, 2022 at 02:26:56PM +0200, Richard Biener via Gcc-patches wrote:
> * gcc.dg/autopar/pr107153.c: New testcase.
The test uses -floop-parallelize-all which emits a sorry when graphite
isn't configured in.
Tested on x86_64-linux and i686-linux, committed to trunk as obvious.
On Sun, Oct 09, 2022 at 02:51:37PM -0700, Julian Brown wrote:
> This patch adds support for non-constant component offsets in "map"
> clauses for OpenMP (and the equivalants for OpenACC), which are not able
> to be sorted into order at compile time. Normally struct accesses in
> such clauses are g
On Mon, Oct 10, 2022 at 05:09:29PM -0400, Jason Merrill wrote:
> On 10/10/22 04:54, Jakub Jelinek via Gcc-patches wrote:
> > My earlier patches gimplify the simplest non-side-effects assumptions
> > into if (cond) ; else __builtin_unreachable (); and throw the rest
> >
On Fri, Oct 07, 2022 at 04:26:58PM +0200, Tobias Burnus wrote:
> libgomp/nvptx: Prepare for reverse-offload callback handling
>
> This patch adds a stub 'gomp_target_rev' in the host's target.c, which will
> later handle the reverse offload.
> For nvptx, it adds support for forwarding the offload
On Thu, Jan 13, 2022 at 02:53:16PM +, Hafiz Abid Qadeer wrote:
> Currently we only make use of this directive when it is associated
> with an allocate statement.
Sorry for the delay.
I'll start with a comment that allocate directive in 5.0/5.1
for Fortran is a complete mess that has been fixe
On Thu, Jan 13, 2022 at 02:53:17PM +, Hafiz Abid Qadeer wrote:
> gcc/fortran/ChangeLog:
>
> * trans-openmp.c (gfc_trans_omp_clauses): Handle OMP_LIST_ALLOCATOR.
> (gfc_trans_omp_allocate): New function.
> (gfc_trans_omp_directive): Handle EXEC_OMP_ALLOCATE.
>
> gcc/ChangeLog
Hi!
The following patch implements excess precision support for C++.
Like for C, it uses EXCESS_PRECISION_EXPR tree to say that its operand
is evaluated in excess precision and what the semantic type of the
expression is.
In most places I've followed what the C FE does in similar spots, so
e.g. fo
On Mon, Oct 10, 2022 at 11:19:24PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Oct 10, 2022 at 05:09:29PM -0400, Jason Merrill wrote:
> > On 10/10/22 04:54, Jakub Jelinek via Gcc-patches wrote:
> > > My earlier patches gimplify the simplest non-side-effects assumpt
On Tue, Oct 11, 2022 at 04:03:16PM +0800, liuhongt via Gcc-patches wrote:
> gcc/ChangeLog:
>
> * config/i386/i386.md (*notxor_1): New post_reload
> define_insn_and_split.
> (*notxorqi_1): Ditto.
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.md
> @@ -10826,6 +10826
On Tue, Oct 11, 2022 at 03:22:02PM +0200, Tobias Burnus wrote:
> Hi Jakub,
>
> On 11.10.22 14:24, Jakub Jelinek wrote:
>
> There is another issue besides what I wrote in my last review,
> and I'm afraid I don't know what to do about it, hoping Tobias
> has some ideas.
> The problem is that withou
On Tue, Oct 11, 2022 at 04:15:25PM +0200, Jakub Jelinek wrote:
> Well, it can use a weak symbol, if not linked against libgomp, the bit
> that it is OpenMP shouldn't be set and so realloc/free will be used
> and do
> if (arrdescr.gomp_alloced_bit)
> GOMP_free (arrdescr.data, 0);
> else
>
On Wed, Oct 05, 2022 at 04:02:25PM -0400, Jason Merrill wrote:
> > > > @@ -5716,7 +5716,13 @@ emit_store_flag_1 (rtx target, enum rtx_
> > > >{
> > > > machine_mode optab_mode = mclass == MODE_CC ? CCmode :
> > > > compare_mode;
> > > > icode = optab_handler (cstore_optab,
On Tue, Oct 11, 2022 at 02:05:52PM -0400, Andrew MacLeod wrote:
> > Aldy, could ranger handle this? If it sees .ASSUME call,
> > walk the body of such function from the edge(s) to exit with the
> > assumption that the function returns true, so above set _2 [true, true]
> > and from there derive th
On Mon, Feb 28, 2022 at 09:45:10PM +0100, Mikael Morin wrote:
> Le 28/02/2022 à 21:37, Mikael Morin a écrit :
> > Maybe corank should be checked together with rank?
>
> Lesson learned today: expressions don’t have a corank.
> Does pr104131-2.f90 really need to be rejected?
OpenMP 5.2 says that de
On Tue, Mar 01, 2022 at 08:58:54AM +0100, Tobias Burnus wrote:
> The wording actually also permits array sections. But contrary to coarrays,
> (which are odd but otherwise fine), I think it does not really make sense
> to have arrays and array sections here.
>
> (Do we need/want to get this clarif
Hi!
The r12-7287-g1b71bc7c8b18bd1b change improved the -Wdeprecated
warning for C++, but regressed it for C, in particular in
gcc.dg/deprecated.c testcase we now report a type that actually isn't
deprecated as deprecated instead of the one that is deprecated.
The following change tries to find th
Hi!
The following testcase emits bogus -Wdangling-pointer warnings.
The bug is that when it sees that ptr immediate use is a call that
returns one of its arguments, it will assume that the return value
is based on ptr, but that is the case only if ptr is passed to the
argument that is actually ret
Hi!
I've noticed various spelling bugs in comments in this file.
There is one spot I haven't fixed:
"Otherwise, VAR is the auto variable
(including an unnamed temporary such as a compound literal) whose
lifetime's rended it dangling."
I'm afraid I don't know what it wanted to say, "lifetime rende
Hi!
As mentioned in the PR, different standards have different definition
on what is an UB left shift. They all agree on out of bounds (including
negative) shift count.
The rules used by ubsan are:
C99-C2x ((unsigned) x >> (uprecm1 - y)) != 0 then UB
C++11-C++17 x < 0 || ((unsigned) x >> (uprecm1
801 - 900 of 4686 matches
Mail list logo
