Hi!
This fixes some spelling mistakes in ipa-modref*.
Committed as obvious.
2022-03-02 Jakub Jelinek
* ipa-modref-tree.cc (modref_access_node::contains,
modref_access_node::closer_pair_p, modref_access_node::insert,
modref_access_node::insert_kill): Comment spelling f
Hi!
This fixes some comment spelling bugs in tree-ssa-strlen.cc.
Committed as obvious.
2022-03-02 Jakub Jelinek
* tree-ssa-strlen.cc (strlen_pass::handle_assign,
strlen_pass::before_dom_children): Comment spelling fixes.
--- gcc/tree-ssa-strlen.cc.jj 2022-02-04 14:36:56.34
Hi!
This is similar to PR104237 and similarly to that, no testcase included
for the testsuite, as we don't have a framework to compile/link with
-g -flto and -g0 -flto and compare -fdump-final-insns= results from
the lto1 compilations.
With -flto, whether two location_t compare equal or not and j
Hi!
When debugging the PR104589 issue, I've run into a problem that
goto_locus doesn't show up in the logs, so it wasn't clear if
the bug hasn't been introduced far earlier just by divergence
in goto_locus of some edge.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk,
or for G
Hi!
These testcases started failing with r12-630 and one of them
got fixed with r12-4531 (aka PR102764 fix and r12-4616 further
improved the fix) and the other went latent in r12-2591 (i.e. threader
changes) and I believe was fixed for real by the PR102764 fix too.
Regtested on x86_64-linux and i
Hi!
I'd like to ping the:
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590276.html
PR102586 - reject __builtin_clear_padding on non-trivially-copyable types with
one exception
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590641.html
PR104568 - fix up constexpr evaluation o
Hi!
I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590526.html
PR104558 - when bypassing emit_push_insn for 0 sized arg, emit at least
anti_adjust_stack for alignment pad if needed
patch.
Thanks
Jakub
Hi!
On Mon, Feb 28, 2022 at 04:49:08PM -0500, Vladimir Makarov via Gcc-patches
wrote:
> PR rtl-optimization/104637
> * gcc.target/i386/pr104637.c: New.
This testcase FAILs everywhere for 3 reasons:
1) the testcase can't work on ia32, where sizeof (long double) == 12
an
On Tue, Mar 01, 2022 at 12:07:49PM -0700, Martin Sebor wrote:
> Thanks for the fix. It makes sense to me. Besides the test for
> the false positives I would suggest to add one to verify that using
> the first argument to a strstr() call is diagnosed if it's dangling
> (both as is, as well as with
On Tue, Mar 01, 2022 at 05:46:20PM +0100, Thomas Schwinge wrote:
> OK to proceed in this way?
With a suitable ChangeLog entry and one nit fixed yes.
> --- gcc/omp-low.cc
> +++ gcc/omp-low.cc
> @@ -188,7 +188,7 @@ struct omp_context
> static splay_tree all_contexts;
> static int taskreg_nesting_
On Wed, Mar 02, 2022 at 05:22:21PM +, Kwok Cheung Yeung wrote:
> I have updated the patch to catch array elements and structure components as
> additional checks, in addition to checking that the variable is a scalar.
>
> The check has been moved to the end of resolve_omp_clauses as it is more
On Wed, Mar 02, 2022 at 04:15:09PM -0700, Martin Sebor via Gcc-patches wrote:
> The -Wdangling-pointer code tests the EDGE_DFS_BACK but the pass never
> calls the mark_dfs_back_edges() function that initializes the bit (I
> didn't know about it). As a result the bit is not set when expected,
> whi
Hi!
When offloading to nvptx is enabled, scan_omp_simd duplicates the simd
region including its clauses and body using inliner's
copy_gimple_seq_and_replace_locals. That works nicely for decls, remaps
only those that are seen in the nested bind expr vars (i.e. local variables)
and doesn't remap o
Hi!
The following testcase regressed when SRA started punting on stores to
TREE_READONLY vars. We document that:
"In a VAR_DECL, PARM_DECL or FIELD_DECL, or any kind of ..._REF node,
nonzero means it may not be the lhs of an assignment."
so the SRA change looks desirable. On the other side, at l
On Thu, Mar 03, 2022 at 05:08:30PM -0700, Martin Sebor wrote:
> > 1) shouldn't it give up for EDGE_ABNORMAL too? I mean, e.g.
> > following a non-local goto forced edge from a noreturn call
> > to a non-local label (if there is just one) doesn't seem
> > right to me
>
> Possibly yes.
On Fri, Mar 04, 2022 at 03:47:31PM +0100, Marcel Vollweiler wrote:
> libgomp/ChangeLog:
>
> * libgomp.map: Added omp_get_mapped_ptr.
> * libgomp.texi: Tagged omp_get_mapped_ptr as supported.
> * omp.h.in: Added omp_get_mapped_ptr.
> * omp_lib.f90.in: Added interface for omp
Hi!
The following testcase ICEs, because the cond_andv* expander
has vector_operand predicates in both of the commutative inputs
and calls gen_andv*_mask which calls ix86_binary_operator_ok
in its condition, but nothing calls ix86_fixup_binary_operands_no_copy
during the expansion, which means con
On Fri, Mar 04, 2022 at 02:58:37PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Thu, Mar 03, 2022 at 05:08:30PM -0700, Martin Sebor wrote:
> > > 1) shouldn't it give up for EDGE_ABNORMAL too? I mean, e.g.
> > > following a non-local goto forced edge from a noretu
Hi!
As mentioned in the PR, right now on powerpc* __SIZEOF_{FLOAT,IBM}128__
macros are predefined unconditionally, because {ieee,ibm}128_float_type_node
is always non-NULL, doesn't reflect whether __ieee128 or __ibm128 are
actually supported or not.
The following patch:
1) makes those {ieee,ibm}1
Hi!
The following testcase fails to assemble due to clgte %r6,0(%r1,%r10)
insn not being accepted by assembler.
My rough understanding is that in the RSY-b insn format the spot
in other formats used for index registers is used instead for M3 what
kind of comparison it is, so this patch follows wha
On Sat, Mar 05, 2022 at 09:33:58AM +0100, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> The following testcase fails to assemble due to clgte %r6,0(%r1,%r10)
> insn not being accepted by assembler.
> My rough understanding is that in the RSY-b insn format the spot
> in othe
On Mon, Mar 07, 2022 at 10:15:48AM +0800, Hongtao Liu wrote:
> > Note, the predicates on cond_fma* and other FMA variants look all wrong to
> > me, usually the fma instructions require nonimmediate_operand operands,
> > but the cond_* patterns use vector_operand. Besides what this patch
>
On Mon, Mar 07, 2022 at 11:09:26AM +0100, Martin Liška wrote:
> gcc/ChangeLog:
>
> * config/arm/arm-builtins.cc (arm_expand_builtin): Reuse error
> message.
Will defer review to ARM maintainers, just wanted to mention some of the
lines are way too long (before or after).
> --- a/gcc/
On Mon, Mar 07, 2022 at 11:51:50AM -, Roger Sayle wrote:
> I agree that for completeness similar peepholes handling inserts into
> SImode would be a good thing, but these wouldn't be restricted by
> TARGET_64BIT and would therefore require additional -m32 testing.
> The DImode peepholes I can
Hi!
Like in r10-7215-g700d4cb08c88aec37c13e21e63dd61fd698baabc 2 years ago,
I've run
grep -v 'long long\|optab optab\|template template\|double double' *.{[chS],cc}
*/*.{[chS],cc} *.def config/*/* 2>/dev/null | grep ' \([a-zA-Z]\+\) \1 '
and for the cases that looked clearly wrong changed them, m
On Mon, Mar 07, 2022 at 05:57:40AM -0800, H.J. Lu via Gcc-patches wrote:
> --- a/gcc/config/i386/i386.cc
> +++ b/gcc/config/i386/i386.cc
> @@ -9444,9 +9444,8 @@ ix86_expand_epilogue (int style)
> rtx sa = EH_RETURN_STACKADJ_RTX;
> rtx_insn *insn;
>
> - /* %ecx can't be used
Hi!
After more than 2 years I've run my
https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00844.html
script again. While it has lots of false positives, it discovered
two bugs.
Committed to trunk as obvious.
2022-03-07 Jakub Jelinek
gcc/c/
* c-parser.cc (c_parser_omp_clause_map): Add mi
Hi!
On the following testcase, we emit "did you mean '__dt '?" in the error
message. "__dt " shows there because it is dtor_identifier, but we
shouldn't suggest those to the user, they are purely internal and can't
be really typed by the user because of the final space in it.
Bootstrapped/regtes
On Tue, Mar 08, 2022 at 10:23:28AM +0100, Richard Biener wrote:
> On Tue, Mar 8, 2022 at 8:27 AM Jakub Jelinek via Gcc-patches
> > On the following testcase, we emit "did you mean '__dt '?" in the error
> > message. "__dt " shows there because it is
On Mon, Mar 07, 2022 at 07:06:28AM -0800, H.J. Lu wrote:
> Since eh_return doesn't work with stack realignment, disable SSE on
> unwind-c.c and unwind-dw2.c to avoid stack realignment with the 4-byte
> incoming stack to avoid SSE usage which is caused by
>
> commit 609e8c492d62d92465460eae3d43dfc4
On Tue, Mar 08, 2022 at 11:23:51AM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Mar 07, 2022 at 07:06:28AM -0800, H.J. Lu wrote:
> > Since eh_return doesn't work with stack realignment, disable SSE on
> > unwind-c.c and unwind-dw2.c to avoid stack realignment with the
On Tue, Mar 08, 2022 at 12:15:15PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > --- gcc/config/i386/i386.h.jj 2022-02-25 12:06:45.535493490 +0100
> > +++ gcc/config/i386/i386.h 2022-03-08 11:20:43.207043370 +0100
> > @@ -2848,6 +2848,10 @@ extern enum attr_cpu ix86_sche
On Tue, Mar 08, 2022 at 07:37:17AM -0800, H.J. Lu wrote:
> > Though, perhaps it should be
> > #ifndef __x86_64__
> > #define LIBGCC2_UNWIND_ATTRIBUTE __attribute__((target ("no-sse")))
> > #endif
> > or something similar, on x86-64 one at least normally doesn't use lower
> > stack realignment unles
Hi!
The following testcase is miscompiled on powerpc64le-linux at -O1 and higher
(except for -Og). The bug was introduced in r12-3252-gcad36f38576a6a7
which for SIGN_EXTEND from SUBREG_PROMOTED_SIGNED_P SUBREG used
SUBREG_PROMOTED_SET (temp, 1) (but that makes temp
SUBREG_PROMOTED_UNSIGNED_P beca
On Tue, Mar 08, 2022 at 09:49:15AM -0600, Segher Boessenkool wrote:
> > But like I said above, even if we didn't copy these XVECLEN 0 rtvecs,
> > the crash would not go away.
>
> An rtvec should never have length 0. Look at gen_rtvec for another
> example.
That is not true. In case of ASM_OPERA
On Tue, Mar 08, 2022 at 11:33:59AM -0500, Marek Polacek wrote:
> PR rtl-optimization/104777
>
> gcc/ChangeLog:
>
> * rtl.cc (classify_insn): For ASM_OPERANDS, return JUMP_INSN only if
> ASM_OPERANDS_LABEL_VEC has at least one element.
>
> gcc/testsuite/ChangeLog:
>
> * g
On Tue, Mar 08, 2022 at 08:09:25AM -0800, H.J. Lu wrote:
> > Ok. So, what do you think about replacing the libgcc/ part of your patch
> > with that
> > /* __builtin_eh_return can't handle stack realignment, so disable SSE in
> >32-bit libgcc functions that call it. */
> > #ifndef __x86_64__
>
On Tue, Mar 08, 2022 at 05:58:34PM +, Jonathan Wakely via Gcc-patches wrote:
> This now works with Solaris /usr/xpg4/bin/sed and should work with BSD
> sed too.
>
> OK for trunk?
>
> -- >8 --
>
> POSIX sed does not support \? or \+ in its Basic Regular Expression
> grammar. Replace the \(tag
On Wed, Mar 09, 2022 at 08:18:38AM +0100, Richard Biener wrote:
> I wonder if this is a good case for general-regs-only instead? At
> least no-sse cannot be functionally equivalent (since then we would
> not have needed general-regs-only ...).
I think general-regs-only is approx. equivalent to no
On Wed, Mar 09, 2022 at 11:07:21AM +0100, Richard Biener wrote:
> The following fixes an ICE observed with a MEM_REF allows_mem asm
> operand. There's code expecting INDIRECT_REFs that are now never
> going to appear. The following simply treats all tcc_reference
> operands the same.
The INDIREC
On Wed, Mar 09, 2022 at 12:30:08PM +0100, Richard Biener wrote:
> The following fixes an ICE observed with a MEM_REF allows_mem asm
> operand referencing a VLA. The following makes sure to not attempt
> to go the temporary creation way when we cannot.
>
> 2022-03-09 Richard Biener
>
> P
On Mon, Mar 07, 2022 at 03:37:18PM -0600, Segher Boessenkool wrote:
> > As mentioned in the PR, right now on powerpc* __SIZEOF_{FLOAT,IBM}128__
> > macros are predefined unconditionally, because {ieee,ibm}128_float_type_node
> > is always non-NULL, doesn't reflect whether __ieee128 or __ibm128 are
On Wed, Mar 09, 2022 at 03:21:53PM +0100, Richard Biener wrote:
> As noticed we are looking for INDIRECT_REF with allows_mem to avoid
> a copy since then we're sure the operand is in memory (assuming
> *& is folded). But INDIRECT_REFs are no longer a thing, the following
> replaces the check with
On Wed, Mar 09, 2022 at 10:43:56PM +0800, Chung-Lin Tang wrote:
> when troubleshooting building/running SPEC HPC 2021 with GCC with OpenMP
> offloading,
> specifically 534.hpgmgfv_t, an issue encountered in the benchmark was:
> when the benchmark was initializing and creating its data environment
On Wed, Mar 09, 2022 at 12:40:24PM -0500, Patrick Palka via Gcc-patches wrote:
> On Wed, Mar 9, 2022 at 8:54 AM Mikael Morin wrote:
> > Le 08/03/2022 à 18:58, Jonathan Wakely via Gcc-patches a écrit :
> > > Replace \([0-9]\+\) with \([0-9][0-9]*\) or with \([1-9][0-9]*\) in
> > > release branch n
On Wed, Mar 09, 2022 at 12:34:06PM -0600, Segher Boessenkool wrote:
> It is a common idiom anyway, much clearer than any macro :-) (But no
> parens please? sizeof is an operator, not a function).
Ok, changed in my copy.
> > > > +{ "if","ibm128_float_type_node "
> > > > +
On Wed, Mar 09, 2022 at 02:57:20PM -0600, Segher Boessenkool wrote:
> But __ibm128 should *always* be supported, so this is a hypothetical
> problem.
I bet that will require much more work. I think for the barely supported
(or really unsupported?) case of old sysv IEEE quad or for when long doubl
Hi!
wg21.link/p2128 removed "with exactly one parameter" from over.sub
section. grok_op_properties has for that the last 2 lines in:
case OVL_OP_FLAG_BINARY:
if (arity != 2)
{
if (operator_code == ARRAY_REF && cxx_dialect >= cxx23)
break;
but unfortunately
On Wed, Mar 09, 2022 at 04:57:01PM -0600, Segher Boessenkool wrote:
> > > If you are fed up with all this, please commit what you have now (after
> > > testing of course ;-) ), and I'll pick up things myself. Either way,
> > > thank you for all your work on this!
> >
> > Ok, here is what I'll tes
On Thu, Mar 10, 2022 at 05:01:35PM +0100, Marcel Vollweiler wrote:
> --- a/gcc/omp-low.cc
> +++ b/gcc/omp-low.cc
> @@ -3962,6 +3962,7 @@ omp_runtime_api_call (const_tree fndecl)
>"target_is_present",
>"target_memcpy",
>"target_memcpy_rect",
> + "get_mapped_ptr",
>
On Fri, Mar 11, 2022 at 02:51:23PM -0600, Segher Boessenkool wrote:
> On Fri, Mar 11, 2022 at 08:42:27PM +, Joseph Myers wrote:
> > The version of this patch applied to GCC 10 branch (commit
> > 641b407763ecfee5d4ac86d8ffe9eb1eeea5fd10) has broken the glibc build for
> > powerpc64le-linux-gnu
Hi!
We ICE on the following testcase, because we tentatively parse it multiple
times and the erroneous attribute syntax results in
cp_parser_skip_to_end_of_statement, which when seeing CPP_PRAGMA (can be
any deferred one, OpenMP/OpenACC/ivdep etc.) it calls
cp_parser_skip_to_pragma_eol, which call
Hi!
These intrinsics are supposed to do an unaligned may_alias load
of a 16-bit or 32-bit value and store it as the first element of
a 128-bit integer vector, with all other elements cleared.
The current _mm_storeu_* implementation implements that correctly, uses
__*_u types to do the store and e
Hi!
The following testcase ICEs on powerpc-linux, because lra_substitute_pseudo
substitutes (const_int 1) into a subreg operand. First a subreg of subreg
of a reg appears in a debug insn (which surely is invalid outside of
debug insns, but in debug insns we allow even what is normally invalid in
Hi!
find_if_case_{1,2} implicitly assumes conditional jumps and rewrites them,
so if they have extra side-effects or are say asm goto, things don't work
well, either the side-effects are lost or we could ICE.
In particular, the testcase below on s390x has there a doloop instruction
that decrements
On Sun, Mar 13, 2022 at 02:03:33PM +0100, Eric Botcazou wrote:
> > Bootstrapped/regtested on {x86_64,i686,powerpc64le,aarch64,s390x}-linux,
> > ok for trunk?
> >
> > 2022-03-13 Jakub Jelinek
> >
> > PR rtl-optimization/104814
> > * ifcvt.cc (find_if_case_1, find_if_case_2): Punt if tes
Hi!
This fixes typos and while changing that, also uses %< %> around attribute
names and fixes up formatting.
2022-03-14 Jakub Jelinek
PR other/104899
* config/bfin/bfin.cc (bfin_handle_longcall_attribute): Fix a typo
in diagnostic message - cannott -> cannot. Use %<
On Sun, Mar 13, 2022 at 02:43:18PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > Are the !BB_END tests really necessary? cond_exec_process_if_block has the
> > same test on onlyjump_p without it. Likewise for noce_find_if_block.
>
> Probably not, I've put it
On Sun, Mar 13, 2022 at 09:34:10PM +0800, Hongtao Liu wrote:
> LGTM, thanks for handling this.
Thanks, committed.
> > Note, while the Intrinsics guide for _mm_loadu_si32 says SSE2,
> > for _mm_loadu_si16 it says strangely SSE. But the intrinsics
> > returns __m128i, which is only defined in emmi
On Mon, Mar 14, 2022 at 06:49:01AM -0700, H.J. Lu via Gcc-patches wrote:
> gcc/
>
> PR target/104890
> * config/i386/i386.cc (ix86_can_inline_p): Ignore
> OPTION_MASK_ISA_64BIT for -m32.
>
> gcc/testsuite/
>
> PR target/104890
> * gcc.target/i386/pr104890.c: New tes
On Mon, Mar 14, 2022 at 09:26:57AM -0400, Marek Polacek via Gcc-patches wrote:
> Thanks for the patch.
>
> The new configure option needs documenting in doc/install.texi, and configure
> needs to be regenerated.
More importantly, I don't see explanation why the patch is needed, analysis
why did t
Hi!
Sorry for the delay, GCC is currently in stage 4, which means a lot of us
concentrate on fixing GCC 12 so that it can be released soon and projects
that are clearly GCC 13 material are much lower priority.
On Wed, Feb 16, 2022 at 11:04:13PM +0200, Mohamed Atef via Gcc-patches wrote:
> --- a/l
Hi!
Regardless of the outcome of the general-regs-only stuff in x86gprintrin.h,
apparently general-regs-only is much bigger hammer than no-sse, and e.g.
using 387 instructions in the unwinder isn't a big deal, it never needs
to realign the stack because of it.
So, the following patch uses no-sse
Hi!
While checking if all targets honor -Wno-psabi for ABI related warnings
or messages, I found that almost all do, except for riscv.
In the testsuite when we want to ignore ABI related messages we
typically use -Wno-psabi -w, but it would be nice to get rid of those
-w uses eventually.
The foll
On Fri, Mar 11, 2022 at 11:28:09PM -0500, Jason Merrill wrote:
> > @@ -7264,9 +7265,66 @@ cxx_eval_constant_expression (const cons
> > DECL_NAME (var)
> > = (DECL_NAME (var) == heap_uninit_identifier
> > ? heap_identifier : heap_vec_identifier);
> > + /* For zer
On Fri, Feb 11, 2022 at 12:27:49PM -0500, Jason Merrill wrote:
> Yes, that's what the above code would correctly do if TYPE were the
> pointer-to-method type. It's wrong for this case because TYPE is unrelated
> to TREE_TYPE (field).
>
> I think the problem is just this line:
>
> >
On Fri, Jan 28, 2022 at 11:50:26AM -0600, Bill Schmidt via Gcc-patches wrote:
> PR104004 caught some misses on my part in converting to the new built-in
> function infrastructure. In particular, I forgot to mark all of the "nosoft"
> built-ins, and one of those should also have been marked "no32bi
On Tue, Mar 15, 2022 at 11:57:22AM -0400, Jason Merrill wrote:
> > The intent of r11-6729 is that it prints something that helps user to figure
> > out what exactly is being accessed.
> > When we find a unique non-static data member that is being accessed, even
> > when we can't fold it nicely, IMN
On Tue, Mar 15, 2022 at 06:05:48PM +0100, Marcel Vollweiler wrote:
> Hi,
>
> This patch fixes a small bug for omp_set_num_teams in fortran.c.
>
> Marcel
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
> München; Gesellschaft mit beschränkter Ha
Hi!
We unshare all RTL created during expansion, but when
aarch64_load_symref_appropriately is called after expansion like in the
following testcases, we use imm in both HIGH and LO_SUM operands.
If imm is some RTL that shouldn't be shared like a non-sharable CONST,
we get at least with --enable-c
On Wed, Mar 16, 2022 at 01:56:50PM +0530, Siddhesh Poyarekar wrote:
> Retain the sizetype alloc_object_size to guarantee the assertion in
> size_for_offset and to avoid adding a conversion there. nop conversions
> are eliminated at the end anyway in dynamic object size computation.
>
> gcc/Change
On Wed, Mar 16, 2022 at 09:10:35AM +, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > We unshare all RTL created during expansion, but when
> > aarch64_load_symref_appropriately is called after expansion like in the
> > following testcases, we use imm in both HIGH and LO_SUM operands.
> >
On Tue, Mar 15, 2022 at 01:32:46PM +0100, Jakub Jelinek via Gcc-patches wrote:
> Another one is whether we shouldn't punt for FIELD_DECLs that don't have
> nicely printable name of its containing scope, something like:
> if (tree scope = get_cont
On Wed, Mar 16, 2022 at 01:42:26PM +0100, Richard Biener wrote:
> The following re-orders the newly added code sinking pass before
> the last phiopt pass which performs hoisting of adjacent loads
> with the intent to enable if-conversion on those.
>
> I've added the aarch64 specific testcase from
On Wed, Mar 16, 2022 at 02:06:16PM +0100, Marcel Vollweiler wrote:
> libgomp/ChangeLog:
>
> * fortran.c (omp_set_num_teams_8_): Fix bug.
> * testsuite/libgomp.fortran/icv-8.f90: New test.
Ok, with a minor nit. Please use
Call omp_set_num_teams instead of omp_set_max_active_levels.
in
On Wed, Mar 16, 2022 at 08:24:24PM +0530, Siddhesh Poyarekar wrote:
> Assign the result of fold_convert to offset.
>
> gcc/ChangeLog:
>
> PR tree-optimization/104941
> * tree-object-size.cc (size_for_offset): Assign result of
> fold_convert to OFFSET.
>
> gcc/testsuite/ChangeLo
On Tue, Mar 15, 2022 at 04:19:05PM -0400, Jason Merrill wrote:
> > But if you strongly prefer it that way, I can do that.
> > Note, probably not 3 new args but 4, depends on whether we could turn
> > all those cases where the tree arg0 = CALL_EXPR_ARG (oldop, 0);
> > is done but var_size_adjusted i
Hi!
As mentioned in the PR, we emit a bogus uninitialized warning but
easily could emit wrong-code for it or similar testcases too.
The bug is that we emit clobber for a TARGET_EXPR_SLOT too early:
D.2499.e = B::qux (&h); [return slot optimization]
D.2516 = 1;
try
Hi!
I'd like to ping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590960.html
Thanks.
On Mon, Feb 28, 2022 at 07:06:30AM +0100, Jakub Jelinek wrote:
> As mentioned in the PR, the latest Intel SDM has added:
> "Processors that enumerate support for Intel® AVX (by setting th
Hi!
On Thu, Nov 11, 2021 at 02:14:05PM +0100, Thomas Schwinge wrote:
> There appears to be yet another issue: there still are quite a number of
> 'FAIL: libgomp.c/places-10.c execution test' reports on
> . Also in my testing testing, on a system
> where '/sys/devices/system/node/online' contains
On Fri, Mar 18, 2022 at 01:44:00PM +0100, Tom de Vries wrote:
> The test-case included in this patch contains:
> ...
> #pragma omp taskloop simd shared(a) lastprivate(myId)
> ...
>
> This is translated to 3 taskloop statements in gimple, visible with
> -fdump-tree-gimple:
> ...
> #pragma omp t
On Fri, Mar 18, 2022 at 02:15:11PM +0100, Tobias Burnus wrote:
> This patch addresses a side issue found when looking at PR103039.
>
> Namely instead of printing:
>
>55 | !$omp parallel firstprivate(tt)
> | 1
> Error: ASSOCIATE name ‘__tmp_INTEGER_4’ in FI
On Fri, Mar 18, 2022 at 03:42:48PM +0100, Tom de Vries wrote:
> > And for NVPTX we somehow lower the taskloop into GIMPLE_ASM
> > or how we end up ICEing?
> >
>
> In the nvptx backend, gen_comment (triggering not very frequently atm) uses
> gen_rtx_ASM_INPUT_loc with as location argument DECL_SOU
On Fri, Mar 18, 2022 at 05:27:02PM +0100, Tobias Burnus wrote:
> SELECT TYPE, SELECT RANK and ASSOCIATE have
> associate-name => selector
> and create a pointer to the selector.
>
> GCC was fixed to handle CLASS properly in
> class(t) :: var
> !$omp ... firstprivate(var)
> As a side effect,
Hi!
Starting with GCC11 we keep emitting false positive -Warray-bounds or
-Wstringop-overflow etc. warnings on widely used *(type *)0x12345000
style accesses (or memory/string routines to such pointers).
This is a standard programming style supported by all C/C++ compilers
I've ever tried, used mo
On Fri, Mar 18, 2022 at 01:35:53PM -0400, Jason Merrill wrote:
> On 3/15/22 12:06, Jakub Jelinek wrote:
> > On Tue, Mar 15, 2022 at 11:57:22AM -0400, Jason Merrill wrote:
> > > > The intent of r11-6729 is that it prints something that helps user to
> > > > figure
> > > > out what exactly is being
On Fri, Mar 18, 2022 at 02:27:30PM -0400, Jason Merrill wrote:
> > That is also correct C++ expression, but user probably has no idea what is
> > present at offset 32 into the variable.
> > Of course if there is a type match and not any kind of type punning,
> > it will try to print much shorter an
Hi!
__builtin_ia32_readeflags_u* aren't marked const or pure I think
intentionally, so that they aren't CSEd from different regions of a function
etc. because we don't and can't easily track all dependencies between
it and surrounding code (if somebody looks at the condition flags, it is
dependent
Hi!
Apparently clang has a -fgnuc-version= option which allows it to pretend
it is any GCC version the user likes. It is already bad that it claims to
be GCC 4.2 compatible by default when it is not (various unimplemented
extensions at least), but this option is a horrible idea.
Anyway, this pat
Hi!
On Mon, Feb 28, 2022 at 07:52:56AM -, Roger Sayle wrote:
> This patch resolves PR c++/84964 which is an ICE in the middle-end after
> emitting a "sorry, unimplemented" message, and is a regression from
> earlier releases of GCC. This issue is that after encountering a
> function call requ
Hi!
C++14 to C++20 apparently should allow extern thread_local declarations in
constexpr functions, however useless they are there (because accessing
such vars is not valid in a constant expression, perhaps sizeof/decltype).
P2242 changed that for C++23 to passing through declaration but
https://c
Hi!
This test started ICEing with r12-3876 but stopped with r12-5264.
Committed to trunk as obvious.
Can we close the PR (are the unroll-and-jam bugs if any are latent) tracked
elsewhere?
2022-03-22 Jakub Jelinek
PR tree-optimization/102645
* gcc.c-torture/compile/pr102645.c
Hi!
As reported, libtool -export-symbols-regex doesn't work on Solaris
when using GNU ld instead of Sun ld, libtool just always assumes Sun ld.
As I'm unsure what is the maintainance status of libtool right now,
this patch solves it on the lto-plugin side instead, tests at configure time
similar w
On Tue, Mar 22, 2022 at 01:56:27PM +0100, Tobias Burnus wrote:
> --- a/gcc/cgraph.cc
> +++ b/gcc/cgraph.cc
> @@ -3980,6 +3980,9 @@ cgraph_node::get_untransformed_body ()
>
>/* We may have renamed the declaration, e.g., a static function. */
>name = lto_get_decl_name_mapping (file_data, n
Hi!
This got broken with r12-3529 and fixed with r12-5255.
Tested on x86_64-linux, committed to trunk as obvious.
2022-03-22 Jakub Jelinek
PR c++/102489
* g++.dg/coroutines/pr102489.C: New test.
--- gcc/testsuite/g++.dg/coroutines/pr102489.C.jj 2022-03-22
15:34:00.372
Hi!
This test is dg-do run and invokes UB when these rotate functions
are called with 0 as second argument. There are some other tests
that do this but they are dg-do compile only and not even call those
functions at all, so it IMHO doesn't matter that they are only well
defined for [1,127] and n
On Thu, Mar 24, 2022 at 08:39:44AM +0530, Siddhesh Poyarekar wrote:
> Limit object size computation only to the simple case where access
> attribute has been explicitly specified. The object passed to
> __builtin_dynamic_object_size could either be a pointer or a VLA whose
> size has been describe
On Thu, Mar 24, 2022 at 09:28:15AM +0100, Tom de Vries via Gcc-patches wrote:
> Hi,
>
> On nvptx (using a Quadro K2000 with driver 470.103.01) I ran into this:
> ...
> FAIL: gcc.dg/atomic/stdatomic-flag-2.c -O1 execution test
> ...
> which mimimized to:
> ...
> #include
> atomic_flag a = ATOM
Hi!
As mentioned in the PR, operand_equal_p already contains some hacks so that
it can be called already on pre-instantiation C++ trees from templates,
but the recent change to compare DECL_FIELD_OFFSET in the COMPONENT_REF
case broke this. Many such COMPONENT_REFs are already punted on earlier
b
On Tue, Mar 22, 2022 at 05:51:58PM +0100, Jakub Jelinek via Gcc wrote:
> I guess it would be nice to include the testcases we are talking about,
> like { float x; int : 0; float y; } and { float x; int : 0; } and
> { int : 0; float x; } into compat.exp testsuite so that we see ABI
> differences in
901 - 1000 of 4686 matches
Mail list logo
