On Thu, Feb 24, 2022 at 11:01:22AM +0100, Tom de Vries wrote:
> [ was: Re: [Patch] nvptx: Add -mptx=6.0 + -misa=sm_70 ]
>
> On 2/24/22 09:29, Tom de Vries wrote:
> > I'll try to submit a patch with one or more test-cases.
>
> Hi,
>
> These test-cases exercise the omp declare variant construct us
On Thu, Feb 24, 2022 at 11:32:53AM +0100, Tom de Vries wrote:
> libgomp/ChangeLog:
>
> 2022-02-24 Tom de Vries
>
> * testsuite/libgomp.c/declare-variant-3-sm30.c: New test.
> * testsuite/libgomp.c/declare-variant-3-sm35.c: New test.
> * testsuite/libgomp.c/declare-variant-3-s
On Thu, Feb 24, 2022 at 02:30:05PM +, Qing Zhao wrote:
> PR middle-end/104550
>
> gcc/ChangeLog:
>
> * gimple-fold.cc (clear_padding_flush): Suppress warnings for new
> created uses.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/auto-init-pr104550-1.c: New test.
>
On Thu, Feb 24, 2022 at 04:00:33PM +0100, Richard Biener wrote:
> > > --- a/gcc/gimple-fold.cc
> > > +++ b/gcc/gimple-fold.cc
> > > @@ -4379,7 +4379,12 @@ clear_padding_flush (clear_padding_struct *buf,
> > > bool full)
> > > else
> > > {
> > > src = make_ssa_name (ty
On Fri, Feb 25, 2022 at 02:35:07AM +0800, Xi Ruoyao via Gcc-patches wrote:
> Bootstrapped on x86_64-linux-gnu. OK for master?
>
> The third parameter of find_fde_tail is an _Unwind_Ptr (which is an
> integer type instead of a pointer), but we are passing NULL to it. This
> causes a -Wint-convers
On Fri, Feb 25, 2022 at 08:11:40AM +0100, Richard Biener via Gcc-patches wrote:
> On Thu, 24 Feb 2022, Qing Zhao wrote:
>
> > I briefly checked all the usages of suppress_warning within the current
> > gcc,
> > and see that most of them are not guarded by any condition.
> >
> > So, the current
On Fri, Feb 25, 2022 at 10:13:33AM +0100, Richard Biener via Gcc-patches wrote:
> I meant
>
> /* Set the no_warning flag of STMT to NO_WARNING. */
>
> static inline void
> gimple_set_no_warning (gimple *stmt, bool no_warning)
> {
> stmt->no_warning = (unsigned) no_warning;
> }
>
> on the arti
Hi!
We don't support BIT_{AND,IOR,XOR,NOT}_EXPR on complex types,
&/|/^ are just rejected for them, and ~ is parsed as CONJ_EXPR.
So, we should avoid simplifications which turn valid complex type
expressions into something that will ICE during expansion.
Bootstrapped/regtested on x86_64-linux and
Hi!
As mentioned in the PR, the following testcase is miscompiled for similar
reasons as the already fixed PR78791 - we use SLOT_TEMP slots in various
places during expansion and during expansion we can guarantee that the
lifetime of those temporary slot doesn't overlap. But the following
splitte
Hi!
The following testcase is miscompiled on ia32 at -O2, because
when expand_SPACESHIP is called, we have pending stack adjustment
from the foo call right before it.
Now, ix86_expand_fp_spaceship uses emit_jump_insn several times
but then emit_jump also several times. While emit_jump_insn doesn'
Hi!
This fixes a spelling mistake I found while looking at warning-control
implementation.
Committed as obvious.
2022-02-25 Jakub Jelinek
* warning-control.cc (get_nowarn_spec): Comment spelling fix.
--- gcc/warning-control.cc.jj 2022-01-17 18:05:04.861306618 +0100
+++ gcc/warning
On Fri, Feb 25, 2022 at 10:31:50AM +0100, Richard Biener wrote:
> I think it's used as fallback for UNKNOWN_LOCATION, but if we "invent"
> a creative location for the artificial stmt it will of course
> affect other stmts/expressions using that location.
>
> > I think it will work.
>
> Yes, I thi
On Fri, Feb 25, 2022 at 11:12:13AM +0100, Richard Biener wrote:
> On Fri, 25 Feb 2022, Jakub Jelinek wrote:
>
> > On Fri, Feb 25, 2022 at 10:31:50AM +0100, Richard Biener wrote:
> > > I think it's used as fallback for UNKNOWN_LOCATION, but if we "invent"
> > > a creative location for the artificia
On Wed, Feb 23, 2022 at 07:45:20PM -0300, Alexandre Oliva via Gcc-patches wrote:
> PR middle-end/104540
> * g++.dg/PR104540.C: New.
Both -mforce-drap and -mstackrealign options are x86 specific.
Tested on x86_64-linux, i686-linux and powerpc64le-linux, committed to
trunk.
2022-02-25
Hi!
Mark mentioned in the PR further 2 simplifications that also ICE
with complex types.
For these, eventually (but IMO GCC 13 materials) we could support it
for vector types if it would be uniform vector constants.
Currently integer_pow2p is true only for INTEGER_CSTs and COMPLEX_CSTs
and we can'
Hi!
The following testcase ICEs, because for some strange reason it decides to use
movmisaligntf during expansion where the destination is MEM and source is
CONST_DOUBLE. For normal mov expanders the rs6000 backend uses
rs6000_emit_move to ensure that if one operand is a MEM, the other is a REG
a
Hi!
As mentioned in the PR, the latest Intel SDM has added:
"Processors that enumerate support for Intel® AVX (by setting the feature flag
CPUID.01H:ECX.AVX[bit 28])
guarantee that the 16-byte memory operations performed by the following
instructions will always be
carried out atomically:
• MOVA
On Mon, Feb 28, 2022 at 04:27:19PM +0800, Xi Ruoyao wrote:
> On Mon, 2022-02-28 at 07:06 +0100, Jakub Jelinek via Gcc-patches wrote:
> > +++ libatomic/Makefile.am 2022-02-25 17:25:16.298314196 +0100
> > @@ -138,8 +138,9 @@ IFUNC_OPTIONS = -march=i586
> >
On Mon, Feb 28, 2022 at 02:01:03PM +, Kwok Cheung Yeung wrote:
> gcc/fortran/
>
> PR fortran/104131
> * openmp.cc (gfc_match_omp_detach): Check that the event handle is not
> an array type.
>
> gcc/testsuite/
>
> PR fortran/104131
> * gfortran.dg/gomp/pr104131.f
On Mon, Feb 28, 2022 at 04:54:24PM +0100, Mikael Morin wrote:
> Le 28/02/2022 à 15:27, Kwok Cheung Yeung a écrit :
> > On 28/02/2022 2:07 pm, Jakub Jelinek wrote:
> (...)
> > > Don't we usually test instead || (*expr)->rank != 0 when testing for
> > > scalars?
> > >
> (...)
> >
> > So (*expr)->ra
On Mon, Feb 28, 2022 at 06:33:15PM +0100, Mikael Morin wrote:
> > It is true that the spots I saw in fortran/openmp.cc that test rank look
> > like:
> > if (!gfc_resolve_expr (el->expr)
> > || el->expr->ts.type != BT_INTEGER || el->expr->rank != 0)
> > etc., so probably !gfc_r
On Mon, Nov 08, 2021 at 08:50:41AM +0100, Gerald Pfeifer wrote:
> This is the first part I committed on Friday, the second will
> follow today.
Here is an alternative to the patch changing a file imported from
compiler-rt upstream, so that we don't need to cary a local patch for that
particular p
On Mon, Nov 08, 2021 at 08:48:07PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Nov 08, 2021 at 12:46:04PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > So, if we want to make PCH work for PIEs, I'd say we can:
> > 1) add a new GTY option, say callback, which would
Hi!
C says that aligned_alloc size must be an integral multiple of alignment.
While glibc doesn't care about it, apparently Solaris does.
So, this patch decreases the priority of aligned_alloc among the other
variants because it needs more work and can waste more memory and rounds
up the size to m
Hi!
struct gomp_team has struct gomp_work_share array inside of it.
If that latter structure has 64-byte aligned member in the middle,
the whole struct gomp_team needs to be 64-byte aligned, but we weren't
allocating it using gomp_aligned_alloc.
This patch fixes that, except that on gcn team_mall
On Wed, Nov 10, 2021 at 09:30:29PM +, Joseph Myers wrote:
> On Wed, 10 Nov 2021, Tobias Burnus wrote:
>
> > Disclaimer: While this patch does a step into the right direction,
> > it probably does help with any of the other _Pragma issues. Neither
> > with 'gcc -E' when the pragma wasn't regist
On Wed, Nov 03, 2021 at 05:27:42PM +0100, Florian Weimer wrote:
> + /* S3. See __condvar_load_64_relaxed. */
Shouldn't that be See __atomic_wide_counter_load_relaxed ?
> + if (((l >> 31) > 0) && ((h >> 31) > 0))
Any reason not to write it as (int) l < 0 && (int) h < 0?
Yes, the compiler
On Wed, Nov 03, 2021 at 05:28:02PM +0100, Florian Weimer wrote:
> This function is similar to __gnu_Unwind_Find_exidx as used on arm.
> It can be used to speed up the libgcc unwinder.
I'm little bit worried that this trades the speed of exceptions for
speed of dlopen/dlclose and extra memory use i
On Wed, Nov 03, 2021 at 05:28:35PM +0100, Florian Weimer wrote:
> It is always a null pointer.
>
> libgcc/ChangeLog
>
> * unwind-dw2-fde-dip.c (struct unw_eh_callback_data): Remove
> tbase member.
> (base_from_cb_data): Adjust.
> (_Unwind_IteratePhdrCallback): Likewise.
>
On Wed, Nov 03, 2021 at 05:28:41PM +0100, Florian Weimer wrote:
> Only i386 and nios2 need this member at present.
Only i386, nios2, frv and bfin to be precise.
>
> libgcc/ChangeLog
>
> * unwind-dw2-fde-dip.c (NEED_DBASE_MEMBER): Define.
> (struct unw_eh_callback_data): Make dbase m
On Wed, Nov 03, 2021 at 05:28:48PM +0100, Florian Weimer wrote:
> @@ -383,12 +376,34 @@ _Unwind_IteratePhdrCallback (struct dl_phdr_info *info,
> size_t size, void *ptr)
> # endif
> #endif
>
> - _Unwind_Ptr dbase = unw_eh_callback_data_dbase (data);
> + return 1;
> +}
> +
> +/* Result type o
On Wed, Nov 03, 2021 at 05:28:02PM +0100, Florian Weimer wrote:
> --- /dev/null
> +++ b/bits/dlfcn_eh_frame.h
> @@ -0,0 +1,33 @@
> +/* System dependent definitions for find unwind information using ld.so.
> + Copyright (C) 2021 Free Software Foundation, Inc.
> + This file is part of the GNU C L
On Wed, Nov 03, 2021 at 05:28:55PM +0100, Florian Weimer wrote:
> --- a/libgcc/unwind-dw2-fde-dip.c
> +++ b/libgcc/unwind-dw2-fde-dip.c
> @@ -129,6 +129,30 @@ unw_eh_callback_data_dbase (const struct
> unw_eh_callback_data *data
> #endif
> }
>
> +#ifdef DL_FIND_EH_FRAME_DBASE
> +#if DL_FIND_EH
On Fri, Nov 19, 2021 at 08:57:01AM +0100, Richard Biener wrote:
> This adds missing handling of VECTOR_CST.
>
> Bootstrap and regtest pending on x86_64-unknown-linux-gnu, OK?
>
> Thanks,
> Richard.
>
> 2021-11-19 Richard Biener
>
> PR c++/103326
> * pt.c (tsubst_copy): Handle VEC
Hi!
For DW_AT_rank we were emitting
.uleb128 0x4# DW_AT_rank
.byte 0x97# DW_OP_push_object_address
.byte 0x23# DW_OP_plus_uconst
.uleb128 0x1c
.byte 0x6 # DW_OP_deref
on 64-bit and
.uleb128 0x4# DW_AT_rank
.byte 0x
On Fri, Nov 19, 2021 at 10:38:41AM +0100, Richard Biener via Gcc-patches wrote:
> > Yup. Though there is a 1:1 equivalence right now, conceptually other
> > kinds of debug marker stmts, and of debug bind stmts, could be
> > introduced, and then the macros would be adjusted to encompass the new
> >
Hi!
decl_attributes and its caller cplus_decl_attributes sometimes add
implicit attributes, e.g. optimize attribute if #pragma GCC optimize
is active, target attribute if #pragma GCC target is active, or
e.g. omp declare target attribute if in between #pragma omp declare target
and #pragma omp end
On Fri, Nov 12, 2021 at 07:30:35AM +, Tamar Christina via Gcc-patches wrote:
> @@ -2099,7 +2124,7 @@ spaceship_replacement (basic_block cond_bb, basic_block
> middle_bb,
>|| !tree_fits_shwi_p (rhs)
>|| !IN_RANGE (tree_to_shwi (rhs), -1, 1))
> return false;
> - if (orig_us
On Wed, Nov 10, 2021 at 12:31:26AM +0530, Siddhesh Poyarekar wrote:
> - Instead of bailing out on non-constant sizes with
> __builtin_object_size, it should be possible to use ranger to
> get an upper and lower bound on the size expression and use that to
> implement __builtin_object_size.
I
On Wed, Nov 10, 2021 at 12:31:27AM +0530, Siddhesh Poyarekar wrote:
> A simple cleanup to allow inserting dynamic size code more easily.
>
> gcc/ChangeLog:
>
> * tree-object-size.c: New enum.
> (object_sizes, computed, addr_object_size,
> compute_builtin_object_size, init_object
On Wed, Nov 10, 2021 at 12:31:28AM +0530, Siddhesh Poyarekar wrote:
> Put all accesses to object_sizes behind functions so that we can add
> dynamic capability more easily.
>
> gcc/ChangeLog:
>
> * tree-object-size.c (object_sizes_grow, object_sizes_release,
> object_sizes_unknown_p,
On Wed, Nov 10, 2021 at 12:31:29AM +0530, Siddhesh Poyarekar wrote:
> * tree-object-size.h (compute_builtin_object_size): Return tree
> instead of HOST_WIDE_INT.
> * builtins.c (fold_builtin_object_size): Adjust.
> * gimple-fold.c (gimple_fold_builtin_strncat): Likewise.
>
On Sat, Nov 20, 2021 at 12:31:19AM +0530, Siddhesh Poyarekar wrote:
> > Neither of these are equivalent to what it used to do before.
> > If some target has e.g. pointers wider than size_t, then previously we could
> > compute bytes that doesn't fit into size_t and would return NULL which
> > event
Hi!
As shown in the testcase below, if a function has multiple target attributes
(rather than a single one with one or more arguments) or if a function
gets one target attribute on one declaration and another one on another
declaration, on x86 their effect is not combined into
DECL_FUNCTION_SPECIF
On Sat, Nov 20, 2021 at 12:24:21AM -0800, Andrew Pinski via Gcc-patches wrote:
> On Sat, Nov 20, 2021 at 12:18 AM Jacob Kroon via Gcc-patches
> wrote:
> >
> > cc1/cc1plus both include a checksum of the object files, archives and
> > options used during linking. Unless the host binutils has been bu
Hi!
The following testcase ICEs because two function declarations are nested in
each other and the acc routine handling code isn't prepared to put the
pragma on both.
The fix is similar to what #pragma omp declare {simd,variant} does,
in particular set the fndecl_seen flag already in cp_parser_la
Hi!
When adding OMP_MASKED, I apparently forgot to handle it in
potential_constant_expression_1, which means we can ICE on it.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk.
2021-11-22 Jakub Jelinek
PR c++/103349
* constexpr.c (potent
On Thu, Nov 18, 2021 at 09:55:52PM +, Joseph Myers wrote:
> On Thu, 18 Nov 2021, Jakub Jelinek via Gcc-patches wrote:
>
> > Are we handling the pragma at a wrong phase of preprocessing?
>
> I think that converting it to a single preprocessing token (rather than
> four s
Hi!
The target attribute handling is very expensive and for the common case
from x86intrin.h where many functions get implicitly the same target
attribute, we can speed up compilation a lot by caching it.
The following patches both create a single entry cache, where they cache
for a particular ta
On Mon, Nov 22, 2021 at 03:41:57PM +0530, Siddhesh Poyarekar wrote:
> So I played around a bit with this. Basically:
>
> char buf[8];
>
> __SIZE_TYPE__ test (void)
> {
> char *p = &buf[0x9004];
> return __builtin_object_size (p + 2, 0);
> }
>
> when built with -m32 returns 0x7002 bu
On Mon, Nov 22, 2021 at 06:01:08PM +0530, Siddhesh Poyarekar wrote:
> On 11/22/21 17:30, Siddhesh Poyarekar wrote:
> > So I've got patch 10/10, which handles dynamic (and consequently
> > negative) offsets. It basically computes a "whole size", which then
> > gives the extent to which a negative o
On Mon, Nov 22, 2021 at 02:03:19PM +0100, Martin Liška wrote:
> I see only one patch attached, Jakub. Can you please send also the second one?
The first one has been inlined in the mail body (the one with attribs.[ch]
changes), the second one has been attached (the one without that).
Jaku
On Mon, Nov 22, 2021 at 02:10:08PM +0100, Martin Liška wrote:
> On 11/22/21 14:05, Jakub Jelinek wrote:
> > On Mon, Nov 22, 2021 at 02:03:19PM +0100, Martin Liška wrote:
> > > I see only one patch attached, Jakub. Can you please send also the second
> > > one?
> >
> > The first one has been inlin
On Mon, Nov 22, 2021 at 03:49:42PM +0100, Thomas Schwinge wrote:
> Then, regarding the user-visible behavior:
>
> > +#pragma acc routine /* { dg-error "not immediately followed by a single
> > function declaration or definition" "" { target c++ } } */
> > +int foo (int bar ());
>
> So in C++ we
Hi!
We were using unshare_expr and walk_tree_without_duplicate replacement
of the placeholder vars. The OMP_CLAUSE_REDUCTION_{INIT,MERGE} can contain
other trees that need to be duplicated though, e.g. BLOCKs referenced in
BIND_EXPR(s), or local VAR_DECLs. This patch uses the inliner code to cop
Hi!
This struct copy_body_data's hook is always NULL since merge
of the tuples branch, before that it has been shortly used by the C++
FE during ctor/dtor cloning to chain the remapped blocks, but only
very shortly, before transform_lang_insert_block was a bool and
the call to insert_block was don
On Mon, Nov 22, 2021 at 01:32:22PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Nov 22, 2021 at 06:01:08PM +0530, Siddhesh Poyarekar wrote:
> > On 11/22/21 17:30, Siddhesh Poyarekar wrote:
> > > So I've got patch 10/10, which handles dynamic (and consequently
>
On Wed, Nov 10, 2021 at 12:31:30AM +0530, Siddhesh Poyarekar wrote:
> Use SSA names as placeholders self-referencing variables to generate
> expressions for object sizes and then reduce those size expressions
> to constants instead of repeatedly walking through statements.
>
> This change also mak
On Wed, Nov 10, 2021 at 12:31:31AM +0530, Siddhesh Poyarekar wrote:
> Recognize the __builtin_dynamic_object_size builtin and add paths in the
> object size path to deal with it, but treat it like
> __builtin_object_size for now. Also add tests to provide the same
> testing coverage for the new bu
On Tue, Nov 23, 2021 at 07:23:01PM +0530, Siddhesh Poyarekar wrote:
> > What's the advantage of another argument and then merging it with
> > object_size_type over just passing object_size_type which will have
> > all the bits in?
>
> I kept the size bits as an internal detail, I can define them i
On Tue, Nov 23, 2021 at 07:14:04PM +0530, Siddhesh Poyarekar wrote:
> > This feels way too risky to me. I think making some code do something
> > different between (x & OST_DYNAMIC) == 0 and == 1 is just fine,
> > it doesn't have to share everything. After all, for __bdos we actually
> > emit cod
On Wed, Nov 10, 2021 at 12:31:32AM +0530, Siddhesh Poyarekar wrote:
> (object_sizes_execute): Don't insert min/max for dynamic sizes.
I'm worried about this.
I'd say what we might want to do is in the early pass for __bdos
compute actually __bos (i.e. the static one) and add MIN_EXPR/MAX_EXP
On Tue, Nov 23, 2021 at 09:06:49PM +0530, Siddhesh Poyarekar wrote:
> On 11/23/21 20:42, Jakub Jelinek wrote:
> > On Wed, Nov 10, 2021 at 12:31:32AM +0530, Siddhesh Poyarekar wrote:
> > > (object_sizes_execute): Don't insert min/max for dynamic sizes.
> >
> > I'm worried about this.
> > I'd say
On Tue, Nov 23, 2021 at 09:08:35PM +0530, Siddhesh Poyarekar wrote:
> On 11/23/21 21:06, Siddhesh Poyarekar wrote:
> > On 11/23/21 20:42, Jakub Jelinek wrote:
> > > On Wed, Nov 10, 2021 at 12:31:32AM +0530, Siddhesh Poyarekar wrote:
> > > > (object_sizes_execute): Don't insert min/max for dynam
On Tue, Nov 23, 2021 at 09:30:30PM +0530, Siddhesh Poyarekar wrote:
> On 11/23/21 21:22, Jakub Jelinek wrote:
> > Evaluating __bdos in both passes is undesirable, certainly for the same
> > SSA_NAME, but even for different SSA_NAMEs, if everything is done in a
> > single pass it can easily share te
On Tue, Nov 23, 2021 at 09:34:04PM +0100, Christophe Lyon via Gcc-patches wrote:
> > > This patch breaks the build when the host compiler is gcc-4.8.5,
> > > because __has_cpp_attribute is not defined.
> > Sigh. I'd like to move to a more recent prereq if we could.
> >
>
> I don't know why we hav
On Fri, Nov 19, 2021 at 10:40:50AM -0500, Jason Merrill wrote:
> > Shall we also change the function so that it doesn't call
> > cplus_decl_attributes if late_attrs is NULL [...]?
>
> Please.
Here it is.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2021-11-24 Jakub Jeli
On Mon, Nov 22, 2021 at 08:39:42AM -, Roger Sayle wrote:
> This patch implements PR tree-optimization/103345 to merge adjacent
> loads when combined with addition or bitwise xor. The current code
> in gimple-ssa-store-merging.c's find_bswap_or_nop alreay handles ior,
> so that all that's requi
Hi!
As the patch shows, we have quite a few asserts that we don't call
lookup_attribute etc. with attr_name that starts with an underscore,
to make sure nobody is trying to call it with non-canonicalized
attribute name like "__cold__" instead of "cold".
We canonicalize only attributes that start w
On Wed, Nov 24, 2021 at 10:00:56AM +0100, Richard Biener via Gcc-patches wrote:
> On Mon, Nov 15, 2021 at 12:16 PM Richard Biener via Gcc-patches
> wrote:
> >
> > This avoids doing aforementioned canoncalization when -ftrapping-math
> > is in effect and we honor NaNs.
> >
> > Bootstrapped and test
On Wed, Nov 24, 2021 at 12:53:02AM -0800, Andrew Pinski wrote:
> Only one comment on the new testcases, you might want to add a
> testcase for the option on the command line too.
You're right, I've committed the patch with the following
incremental diff in it:
--- gcc/testsuite/c-c++-common/Wno-a
Hi!
As the testcase shows, we weren't handling kind(host) and kind(nohost) properly
in the ACCEL_COMPILERs, the code written in there is valid for the host
compiler only, where if we are maybe offloaded, we defer resolution after IPA,
otherwise return 0 for kind(nohost) and accept it for kind(host
On Tue, Nov 23, 2021 at 10:28:48PM -0500, Jason Merrill wrote:
Thanks.
> > + while (true)
> > + {
> > + cp_expr expr (NULL_TREE);
> > + /* Parse the next assignment-expression. */
> > + if (cp_lexer_next_token_is (parser->lexer, CPP_OPEN_BRACE))
> > +
On Tue, Nov 23, 2021 at 03:45:20PM -0500, Jason Merrill wrote:
> > I've played a little bit with this (tried to do it at cp_fold time), but
> > there are problems with that.
> > cp_fold of course isn't a good spot for this because it can be called from
> > fold_for_warn and at that point we don't k
On Wed, Nov 24, 2021 at 05:02:03PM +0100, Jakub Jelinek via Gcc-patches wrote:
> Unfortunately, the location wrappers are optimized away before we get a
> chance to use them in cp_fold_r.
> So, on the following patch, we get the location right on PTRMEM_CSTs not
> used inside of initi
On Wed, Nov 24, 2021 at 05:15:51PM -0500, Jason Merrill wrote:
> > +case CALL_EXPR:
> > + if (tree fndecl = cp_get_callee_fndecl_nofold (stmt))
> > + if (DECL_IMMEDIATE_FUNCTION_P (fndecl)
> > + && source_location_current_p (fndecl))
> > + {
> > + tree fn = cp_get_callee
On Wed, Nov 24, 2021 at 09:45:16AM +0100, Richard Biener wrote:
> > Thinking more about it, perhaps we could do more for BIT_XOR_EXPR.
> > We could allow masked1 == masked2 case for it, but would need to
> > do something different than the
> > n->n = n1->n | n2->n;
> > we do on all the bytes toge
Hi!
The following testcase is miscompiled since the r12-5489-g0888d6bbe97e10
changes.
The simplification triggers on
(x & 4294967040U) >= 0U
and turns it into:
x <= 255U
which is incorrect, it should fold to 1 because unsigned >= 0U is always
true and normally the
/* Non-equality compare simplific
On Thu, Nov 25, 2021 at 08:23:50AM +, Tamar Christina wrote:
> > But, IMNSHO while it isn't incorrect to handle le and gt there, it is
> > unnecessary. Because (x & cst) <= 0U and (x & cst) > 0U should never
> > appear,
> > again in
> > /* Non-equality compare simplifications from fold_binary
On Thu, Nov 25, 2021 at 09:21:37AM +0100, Richard Biener wrote:
> OK if you can add a testcase that exercises this "feature".
Sure, that is easy.
Here is what I've committed. f2 tests the x | x = x handling in it,
f3 tests x | y = unknown instead of punting, f4 tests x ^ x = 0
and f5 tests x ^ y
On Thu, Nov 25, 2021 at 10:17:52AM +0100, Richard Biener wrote:
> > Ah I see, sorry I didn't see that rule before, you're right that if this is
> > ordered
> > after it then they can be dropped.
>
> So the patch is OK, possibly with re-ordering the matches.
I've committed the patch as is because
On Wed, Nov 24, 2021 at 09:07:48PM -0500, Jason Merrill wrote:
> > --- gcc/cp/tree.c.jj2021-11-24 15:05:23.371927735 +0100
> > +++ gcc/cp/tree.c 2021-11-24 17:09:05.348164621 +0100
> > @@ -5167,6 +5167,7 @@ make_ptrmem_cst (tree type, tree member)
> > tree ptrmem_cst = make_node (PTRM
On Tue, Nov 23, 2021 at 06:56:14PM +0100, Florian Weimer wrote:
> 8<--8<
> This allows switching to a different implementation for
> PT_GNU_EH_FRAME lookup in a subsequent commit.
>
> This moves some of the PT_GNU_EH_FRAME parsing out
Hi!
stringify_arg uses pfile->u_buff to create the string literal.
Unfortunately, paste_tokens -> _cpp_lex_direct -> lex_number ->
_cpp_unaligned_alloc
can in some cases use pfile->u_buff too, which results in losing everything
prepared for the string literal until the token pasting.
The followi
On Fri, Nov 26, 2021 at 12:29:25PM +, Jonathan Wakely via Gcc-patches wrote:
> + // Internal version of std::is_constant_evaluated() for C++11.
> + // This can be used without checking if the compiler supports the built-in.
> + constexpr inline bool
> + __is_constant_evaluated() noexcept
>
On Fri, Nov 26, 2021 at 12:43:44PM +, Jonathan Wakely wrote:
> > On Fri, Nov 26, 2021 at 12:29:25PM +, Jonathan Wakely via Gcc-patches
> > wrote:
> > > + // Internal version of std::is_constant_evaluated() for C++11.
> > > + // This can be used without checking if the compiler supports t
On Thu, Nov 25, 2021 at 09:35:14PM +0100, Florian Weimer wrote:
> +struct dl_find_object
> +{
> + unsigned long long int dlfo_flags; /* Currently 0. */
> + void *dlfo_map_start; /* Beginning of mapping containing
> address. */
> + void *dlfo_map_end;/* End of mappi
On Thu, Nov 25, 2021 at 09:42:53PM +0100, Florian Weimer wrote:
> I've included a simplified version below, based on the _dl_find_object
> patch for glibc.
>
> This is a bit difficult to test, but I ran a full toolchain bootstrap
> with GCC + glibc on all glibc-supported architectures (except Hurd
On Fri, Nov 26, 2021 at 10:58:44AM +0530, Siddhesh Poyarekar wrote:
> A simple cleanup to allow inserting dynamic size code more easily.
>
> gcc/ChangeLog:
>
> * tree-object-size.c: New enum.
> (object_sizes, computed, addr_object_size,
> compute_builtin_object_size, expr_object
On Fri, Nov 26, 2021 at 10:58:45AM +0530, Siddhesh Poyarekar wrote:
> Put all accesses to object_sizes behind functions so that we can add
> dynamic capability more easily.
>
> gcc/ChangeLog:
>
> * tree-object-size.c (object_sizes_grow, object_sizes_release,
> object_sizes_unknown_p,
On Fri, Nov 26, 2021 at 10:58:46AM +0530, Siddhesh Poyarekar wrote:
> Transform tree-object-size to operate on tree objects instead of host
> wide integers. This makes it easier to extend to dynamic expressions
> for object sizes.
>
> The compute_builtin_object_size interface also now returns a t
On Fri, Nov 26, 2021 at 11:23:31PM +0530, Siddhesh Poyarekar wrote:
> On 11/26/21 22:16, Jakub Jelinek wrote:
> > On Fri, Nov 26, 2021 at 10:58:44AM +0530, Siddhesh Poyarekar wrote:
> > > A simple cleanup to allow inserting dynamic size code more easily.
> > >
> > > gcc/ChangeLog:
> > >
> > > *
On Fri, Nov 26, 2021 at 11:29:41PM +0530, Siddhesh Poyarekar wrote:
> > > The trees in object_sizes are each a TREE_VEC with the first element
> > > being the bytes from the pointer to the end of the object and the
> > > second, the size of the whole object. This allows analysis of negative
> > >
Hi!
On gcc.c-torture/execute/pr103376.c in the following code we trigger UB
in the compiler. n->range is 8 because it is 64-bit load and rsize is 0
because it is a bswap sequence with load and known to be 0:
/* Find real size of result (highest non-zero byte). */
if (n->base_addr)
for (t
On Wed, Nov 24, 2021 at 11:42:28PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > I'm surprised the source_location::current handling would be needed; why do
> > calls to that function live long enough for us to walk into the ADDR_EXPR
> > here? Maybe we should fold i
Hi!
The following testcase is miscompiled because the x86_{,64_}sh{l,r}d
patterns don't properly describe what the instructions do. One thing
is left out, in particular that there is initial count &= 63 for
sh{l,r}dq and initial count &= 31 for sh{l,r}d{l,w}. And another thing
not described prop
Hi!
This patch attempts to implement P1272R4 (except for the std::bit_cast
changes in there which seem quite unrelated to this and will need to be
fixed on the compiler side).
While at least for GCC __builtin_bswap{16,32,64,128} should work fine
in constant expressions, I wonder about other compil
On Sat, Nov 27, 2021 at 12:59:56PM +0100, Jakub Jelinek via Gcc-patches wrote:
> This patch attempts to implement P1272R4 (except for the std::bit_cast
> changes in there which seem quite unrelated to this and will need to be
> fixed on the compiler side).
> While at least for GCC __b
Hi!
On Tue, Aug 31, 2021 at 10:05:58AM +0200, Jakub Jelinek via Gcc-patches wrote:
> This is an incremental patch to
> https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578447.html
> for x86_64 ABI.
> For zero-width bitfields current GCC classify_argument does:
>
Hi!
Jonathan mentioned on IRC that:
"Accept P1949R7 (C++ Identifier Syntax using Unicode Standard Annex 31) as
a Defect Report and apply the changes therein to the C++ working paper."
while I've actually implemented it only for -std={gnu,c}++{23,2b}.
As the C++98 rules were significantly different
1301 - 1400 of 4686 matches
Mail list logo
