On Mon, 29 Nov 2021, Martin Sebor wrote:
> On 11/26/21 5:18 AM, Richard Biener via Gcc-patches wrote:
> > This implements a subset of -Wunreachable-code, unreachable code
> > after a return stmt. Contrary to the previous attemt at CFG
> > construction time this implements the bits during GIMPLE l
This makes sure to use a VIEW_CONVERT_EXPR for converting
vector signedness in the -((int)x >> (prec - 1)) to (unsigned)x >> (prec - 1)
simplification.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-11-30 Richard Biener
PR middle-end/103485
* match.pd (-((in
On Mon, Nov 29, 2021 at 11:56 PM Qing Zhao wrote:
>
> Peter,
>
> Thanks a lot for the patch.
>
> Richard, how do you think of the patch?
>
> (The major concern for me is:
>
> With the current patch proposed by Peter, we will generate the call
> to .DEFERRED_INIT for a variable with OPAQUE
On 15/11/2021 18:28, Marek Polacek via Gcc-patches wrote:
On Mon, Nov 08, 2021 at 04:33:43PM -0500, Marek Polacek wrote:
Ping, can we conclude on the name? IMHO, -Wbidirectional is just fine,
but changing the name is a trivial operation.
Here's a patch with a better name (suggested by Jonath
Hi,
This patch modifies the combine pattern with a helper -
change_pseudo_and_mask when recog fails. The helper converts a single pseudo to
the pseudo and with a mask if the outer operator is IOR/XOR/PLUS and the inner
operator is ASHIFT/LSHIFTRT/AND. The conversion helps match shift + ior
Hi Segher,
Thanks for the review!
on 2021/11/30 上午6:28, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Jun 11, 2021 at 09:16:21PM +0800, Kewen.Lin wrote:
+/* Should pick up the lowest luid if the references
+ are in the same block. */
+if (label_tick == rsp
On Tue, Nov 30, 2021 at 8:37 AM Richard Biener
wrote:
>
> On Mon, Nov 29, 2021 at 4:24 PM Aldy Hernandez wrote:
> >
> > On Mon, Nov 29, 2021 at 3:48 PM Richard Biener
> > wrote:
> > >
> > > On Mon, Nov 29, 2021 at 3:39 PM Jeff Law wrote:
> > > >
> > > >
> > > >
> > > > On 11/29/2021 7:00 AM, Al
Hi!
This patch adds [[nodiscard]] to std::byteswap, because the function
template doesn't do anything useful if the result isn't used.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2021-11-30 Jakub Jelinek
* include/std/bit (byteswap): Add [[nodiscard]].
--- l
On Tue, Nov 30, 2021 at 9:51 AM Aldy Hernandez wrote:
>
> On Tue, Nov 30, 2021 at 8:37 AM Richard Biener
> wrote:
> >
> > On Mon, Nov 29, 2021 at 4:24 PM Aldy Hernandez wrote:
> > >
> > > On Mon, Nov 29, 2021 at 3:48 PM Richard Biener
> > > wrote:
> > > >
> > > > On Mon, Nov 29, 2021 at 3:39 PM
Will adjust, re-test and commit.
Thanks.
Aldy
On Tue, Nov 30, 2021 at 10:00 AM Richard Biener
wrote:
>
> On Tue, Nov 30, 2021 at 9:51 AM Aldy Hernandez wrote:
> >
> > On Tue, Nov 30, 2021 at 8:37 AM Richard Biener
> > wrote:
> > >
> > > On Mon, Nov 29, 2021 at 4:24 PM Aldy Hernandez wrote:
>
This fixes a thinko in my fix for the -freorder-blocks-and-partition glitch
with SEH on 64-bit Windows:
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565208.html
Even if no exceptions are active, e.g. in C, we always need to consider calls.
Tested on x86-64/Windows, applied on mainli
Hi!
Seems simplify_associate_operation is quadratic, which isn't a big deal
for use during combine and other similar RTL passes, because those never
try to combine expressions from more than a few instructions and because
those instructions need to be recognized the machine description also bounds
On Mon, Nov 29, 2021 at 4:16 PM Martin Liška wrote:
>
> There are cases where a default option value is -1 and
> auto-detection happens in e.g. target.
>
> Do not print these options. Leads to the following diff:
>
> - -fdelete-null-pointer-checks [enabled]
> + -fdelete-null-poin
On Tue, 30 Nov 2021, Jakub Jelinek wrote:
> Hi!
>
> Seems simplify_associate_operation is quadratic, which isn't a big deal
> for use during combine and other similar RTL passes, because those never
> try to combine expressions from more than a few instructions and because
> those instructions ne
ix86_attr_length_immediate_default assume TYPE ishift only have 1
constant operand,
but *x86_64_shld_1/*x86_shld_1/*x86_64_shrd_1/*x86_shrd_1 has 2, with
condition: INTVAL (operands[3]) == 32 - INTVAL (operands[2]) or
INTVAL (operands[3]) == 64 - INTVAL (operands[2]), and hit
gcc_assert.
Explicitly
On Tue, Nov 30, 2021 at 5:44 PM liuhongt via Gcc-patches
wrote:
>
> ix86_attr_length_immediate_default assume TYPE ishift only have 1
> constant operand,
> but *x86_64_shld_1/*x86_shld_1/*x86_64_shrd_1/*x86_shrd_1 has 2, with
> condition: INTVAL (operands[3]) == 32 - INTVAL (operands[2]) or
> INTV
On Mon, Nov 29, 2021 at 10:07 AM Roger Sayle wrote:
>
>
> This middle-end patch is inspired by Richard Biener's until-wrap
> loop example in PR tree-optimization/101145.
>
> unsigned foo(unsigned val, unsigned start)
> {
> unsigned cnt = 0;
> for (unsigned i = start; i > val; ++i)
> cnt++;
Hi Rasmus,
We had something close but slight different for
the support of shared libraries (for which I'm preparing
the patches). I think your version should work as well
but we have quite a few configurations and the devil is
in the details so I'm testing the effects in a few cases
before approvi
On Tue, Nov 30, 2021 at 10:43 AM liuhongt wrote:
>
> ix86_attr_length_immediate_default assume TYPE ishift only have 1
> constant operand,
> but *x86_64_shld_1/*x86_shld_1/*x86_64_shrd_1/*x86_shrd_1 has 2, with
> condition: INTVAL (operands[3]) == 32 - INTVAL (operands[2]) or
> INTVAL (operands[3]
I missed a spot when adding the "#if __BYTE_ORDER__ == ..." guards to
the new test case for PR tree-optimization/103345. Committed as obvious.
2021-11-30 Roger Sayle
gcc/testsuite/ChangeLog
PR testsuite/103477
* gcc.dg/tree-ssa/pr103345.c: Correct xor test for big-endian.
R
On Tue, 30 Nov 2021 at 08:58, Jakub Jelinek via Libstdc++
wrote:
>
> Hi!
>
> This patch adds [[nodiscard]] to std::byteswap, because the function
> template doesn't do anything useful if the result isn't used.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Yes, thanks.
Tejas Belagod via Gcc-patches writes:
> Ping for this series.
>
> Thanks,
> Tejas.
Hi all,
pinging this series.
BR
Andrea
On Mon, Nov 29, 2021 at 1:45 PM Martin Liška wrote:
>
> On 11/26/21 09:12, Richard Biener wrote:
> > On Wed, Nov 24, 2021 at 3:32 PM Martin Liška wrote:
> >>
> >> On 11/24/21 15:14, Martin Liška wrote:
> >>> It likely miscompiles gcc.dg/loop-unswitch-5.c, working on that..
> >>
> >> Fixed that in
Hello,
Le 29/11/2021 à 22:31, Harald Anlauf via Fortran a écrit :
Dear all,
a trivial one: we need to check the type of the SUB argument
to the coarray IMAGE_INDEX intrinsic. It has to be an array
of type integer.
Patch by Steve Kargl.
I hope at some point he’ll finally come to a working gi
On 25/11/2021 12:46, Richard Biener wrote:
Oops, my fault, yes, it does. I would suggest to refactor things so
that the mode_i = first_loop_i case is there only once. I also wonder
if all the argument about starting at 0 doesn't apply to the
not unrolled LOOP_VINFO_EPIL_USING_PARTIAL_VECTORS_
Le 29/11/2021 à 23:01, Harald Anlauf via Fortran a écrit :
Dear all,
another trivial and obvious one, discovered by Gerhard.
We can have a NULL pointer dereference simplifying MINLOC/MAXLOC
on an array that was not properly declared.
OK for mainline / affected 11-branch after regtesting comple
Hi!
On 2020-07-28T10:44:29+0200, I wrote:
> On 2020-07-26T14:05:32+0100, Kwok Cheung Yeung wrote:
>> On 24/07/2020 8:27 am, Thomas Schwinge wrote:
>>> [proposed patch] however completely defeats what we're intending to test
>>> here, which
>>> is to "Test invalid intra-routine parallelism". The
Hi!
On 2017-05-01T18:27:59-0700, Cesar Philippidis wrote:
> This patch promotes all OpenACC gang reductions on orphan loops as
> errors. Accord to the spec, orphan loops are those which are not
> lexically nested inside an OpenACC parallel or kernels regions. I.e.,
> acc loops inside acc routines
Hi!
On 2017-05-01T18:27:59-0700, Cesar Philippidis wrote:
> --- a/gcc/fortran/openmp.c
> +++ b/gcc/fortran/openmp.c
> @@ -6090,6 +6090,18 @@ resolve_oacc_loop_blocks (gfc_code *code)
> + if (code->op == EXEC_OACC_LOOP
> + && code->ext.omp_clauses->lists[OMP_LIST_REDUCTION]
> + && code
Hi!
On 2020-07-20T12:26:48+0200, Frederik Harwath wrote:
> Thomas Schwinge writes:
>>> Can I include the patch in OG10?
> This has been delayed a bit by my vacation, but I have now committed
> the patch.
>> (Ideally, we'd also test 'serial' construct in addition to 'kernels',
>> 'parallel'
>
Hi!
On 2017-05-01T18:27:59-0700, Cesar Philippidis wrote:
> gcc/c/
> * c-typeck.c (c_finish_omp_clauses): Emit an error on orphan OpenACC
> gang reductions.
>
> gcc/cp/
> * semantics.c (finish_omp_clauses): Emit an error on orphan OpenACC
> gang reductions.
>
>
On Mon, Nov 29, 2021 at 10:25:58PM -0500, Jason Merrill wrote:
> It's a DR. Really, it was intended to be part of C++20; at the Cologne
> meeting in 2019 CWG thought byteswap was going to make C++20, so this bugfix
> could go in as part of that paper.
Ok, changed to be done unconditionally now.
Hi!
On 2020-03-19T17:12:02+, Kwok Cheung Yeung wrote:
> On 18/03/2020 11:34 pm, Kwok Cheung Yeung wrote:
>> I was looking at the regression in c-c++-common/goacc/nested-reductions.c,
>> which
>> has the following excess warnings in acc_routine:
>>
>> /scratch/kyeung/openacc/og10/nvidia/src/g
I've committed this change to use gneder agnostic pronouns on the
non-historical web documents.
and if you're upset that Those Are Plural!, assemble this URL and watch
youtube /watch?v=46ehrFk-gLk&t=87s at about the 2 minute mark
nathan
--
Nathan SidwellFrom b5a0f250f0f05364a51c331d040d78bf1
Le 29/11/2021 à 16:03, Richard Biener via Gcc-patches a écrit :
diff --git a/gcc/fortran/frontend-passes.c b/gcc/fortran/frontend-passes.c
index f5ba7cecd54..16ee2afc9c0 100644
--- a/gcc/fortran/frontend-passes.c
+++ b/gcc/fortran/frontend-passes.c
@@ -5229,7 +5229,6 @@ gfc_expr_walker (gfc_expr
I've pushed this change for the libstdc++ docs (should be "their"), but
didn't notice the typo in the changelog, so I'll fix that tomorrow after
the file is regenerated.
libstdc++-v3/ChangeLog:
* doc/xml/manual/debug_mode.xml: Replace "his or her" with "they".
* doc/html/manual/
On Tue, 30 Nov 2021, Mikael Morin wrote:
> Le 29/11/2021 à 16:03, Richard Biener via Gcc-patches a écrit :
> > diff --git a/gcc/fortran/frontend-passes.c b/gcc/fortran/frontend-passes.c
> > index f5ba7cecd54..16ee2afc9c0 100644
> > --- a/gcc/fortran/frontend-passes.c
> > +++ b/gcc/fortran/frontend
On Tue, Nov 30, 2021 at 09:38:57AM +0100, Stephan Bergmann wrote:
> On 15/11/2021 18:28, Marek Polacek via Gcc-patches wrote:
> > On Mon, Nov 08, 2021 at 04:33:43PM -0500, Marek Polacek wrote:
> > > Ping, can we conclude on the name? IMHO, -Wbidirectional is just fine,
> > > but changing the name
On Tue, Nov 30, 2021 at 3:46 AM HAO CHEN GUI wrote:
>
> Hi,
>
> This patch modifies the combine pattern with a helper -
> change_pseudo_and_mask when recog fails. The helper converts a single pseudo
> to the pseudo and with a mask if the outer operator is IOR/XOR/PLUS and the
> inner operat
Small update of the test-case, approved by Richi.
Martin
PR tree-optimization/103278
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/if-to-switch-5.c: Make the test acceptable by
targets with no jump-tables.
---
gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-5.c | 4 ++--
1 fil
On Tue, 30 Nov 2021, Andre Vieira (lists) wrote:
>
> On 25/11/2021 12:46, Richard Biener wrote:
> > Oops, my fault, yes, it does. I would suggest to refactor things so
> > that the mode_i = first_loop_i case is there only once. I also wonder
> > if all the argument about starting at 0 doesn't a
bool pattern recog currently does not handle cycles correctly
and when it fails we can ICE later vectorizing PHIs with
mismatched bool and non-bool vector types. The following avoids
blindly trusting bool pattern recog here and verifies things
more thoroughly in vectorizable_phi. A bool pattern r
On Tue, Nov 30, 2021 at 10:43:28AM +0100, Richard Biener wrote:
> I wonder given we now have 'simplify_context' whether we can
> track a re-association budget we can eat from. At least your
> code to determine whether the expression is too large is
> quadratic as well (but bound to 64, so just a v
On Tue, 30 Nov 2021, Jakub Jelinek wrote:
> On Tue, Nov 30, 2021 at 10:43:28AM +0100, Richard Biener wrote:
> > I wonder given we now have 'simplify_context' whether we can
> > track a re-association budget we can eat from. At least your
> > code to determine whether the expression is too large i
On Mon, Nov 29, 2021 at 07:28:10PM -0500, Jason Merrill wrote:
> Please add some of this explanation to the "paste any tokens" comment in the
> code.
Ok.
> > + while (rhs->flags & PASTE_LEFT);
> > + if ((flags & PREV_WHITE)
> > + &&
On 30/11/2021 14:25, Richard Biener wrote:
On Tue, 30 Nov 2021, Mikael Morin wrote:
Le 29/11/2021 à 16:03, Richard Biener via Gcc-patches a écrit :
diff --git a/gcc/fortran/frontend-passes.c b/gcc/fortran/frontend-passes.c
index f5ba7cecd54..16ee2afc9c0 100644
--- a/gcc/fortran/frontend-passes
Use SSE, instead of AVX, to save and restore XMM registers to support
processors without AVX. The affected codes are unused in upstream since
https://github.com/llvm/llvm-project/commit/66d4ce7e26a5
and will be removed in
https://reviews.llvm.org/D112604
This fixed
FAIL: g++.dg/tsan/pthread_c
Hi,
in PR 103267 Honza found out that IPA-SRA does not look at
ECF_LOOPING_CONST_OR_PURE when evaluating if a call can have side
effects. Fixed with this patch. The testcase infinitely loops in a
const function, so it would not make a good addition to the testsuite.
Bootstrapped and tested on x
On Tue, 30 Nov 2021, Mikael Morin wrote:
> On 30/11/2021 14:25, Richard Biener wrote:
> > On Tue, 30 Nov 2021, Mikael Morin wrote:
> >
> >> Le 29/11/2021 ? 16:03, Richard Biener via Gcc-patches a ?crit :
> >>> diff --git a/gcc/fortran/frontend-passes.c b/gcc/fortran/frontend-passes.c
> >>> index
On Tue, Nov 30, 2021 at 3:24 PM Martin Jambor wrote:
>
> Hi,
>
> in PR 103267 Honza found out that IPA-SRA does not look at
> ECF_LOOPING_CONST_OR_PURE when evaluating if a call can have side
> effects. Fixed with this patch. The testcase infinitely loops in a
> const function, so it would not m
When I flatten the call stack for range_of_stmt in PR 103231 (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103231 ), I mention that I
was only flattening it for chains of statements with range handlers. If
it turned out that PHI chaining was also a problem, we could also do PHIs.
The cost to
Updates the make files, and the gdc-specific modules of druntime.
Bootstrapped, regression tested, and committed to mainline.
Regards,
Iain.
---
libphobos/ChangeLog:
* libdruntime/Makefile.am (D_EXTRA_FLAGS): Build libdruntime with
-fpreview=dip1000, -fpreview=fieldwise, and -fp
On 30/11/2021 14:26, Marek Polacek wrote:
On Tue, Nov 30, 2021 at 09:38:57AM +0100, Stephan Bergmann wrote:
On 15/11/2021 18:28, Marek Polacek via Gcc-patches wrote:
On Mon, Nov 08, 2021 at 04:33:43PM -0500, Marek Polacek wrote:
Ping, can we conclude on the name? IMHO, -Wbidirectional is jus
Updates the make files that build phobos.
Bootstrapped, regression tested, and committed to mainline.
Regards,
Iain.
---
libphobos/ChangeLog:
* src/Makefile.am (D_EXTRA_DFLAGS): Add -fpreview=dip1000 and
-fpreview=dtorfields flags.
(PHOBOS_DSOURCES): Update list of std m
This is the updated D runtime library testsuite.
Bootstrapped, regression tested, and committed to mainline.
Regards,
Iain.
---
libphobos/ChangeLog:
* testsuite/libphobos.aa/test_aa.d: Update test.
* testsuite/libphobos.exceptions/unknown_gc.d: Likewise.
* testsuite/libp
This updates the GDC testsuite parts to be compatible with the current
language features/deprecations. The dejagnu gdc-utils helper has also
been updated to handle the new options and directives added to the D2
testsuite tests.
Bootstrapped, regression tested, and committed to mainline.
Regards,
On 11/30/21 2:37 AM, Richard Biener wrote:
> On Mon, Nov 29, 2021 at 11:56 PM Qing Zhao wrote:
> I think that's inconsistent indeed. Peter, what are "opaque"
> registers? rs6000-modes.def suggests
> that there's __vector_pair and __vector_quad, what's the GIMPLE types
> for those? It seems they
Hi!
I know I'm late this week ;-\ -- but here is another ping.
Grüße
Thomas
On 2021-11-22T11:27:49+0100, Thomas Schwinge wrote:
> Hi!
>
> Ping.
>
>
> Grüße
> Thomas
>
>
> On 2021-11-15T15:50:58+0100, I wrote:
>> Hi!
>>
>> ..., and here is another ping.
>>
>>
>> Grüße
>> Thomas
>>
>>
>> On
This adds new, or updates the dejagu testing scripts for the suite of
libphobos tests.
Bootstrapped, regression tested, and committed to mainline.
Regards,
Iain.
---
libphobos/ChangeLog:
* testsuite/lib/libphobos.exp (libphobos-dg-test): Handle assembly
compile types.
(d
On Tue, Nov 30, 2021 at 04:00:01PM +0100, Stephan Bergmann wrote:
> On 30/11/2021 14:26, Marek Polacek wrote:
> > On Tue, Nov 30, 2021 at 09:38:57AM +0100, Stephan Bergmann wrote:
> > > On 15/11/2021 18:28, Marek Polacek via Gcc-patches wrote:
> > > > On Mon, Nov 08, 2021 at 04:33:43PM -0500, Marek
We are currently restricting loop crossing paths in the generic copier
used by the back threader, but we should be able to handle them after
loop_done has completed.
This fixes the PR at -O2, though the problem remains at -O1 because we
have no threaders smart enough to elide the undefined read.
On 11/30/21 09:13, Jakub Jelinek wrote:
On Mon, Nov 29, 2021 at 07:28:10PM -0500, Jason Merrill wrote:
Please add some of this explanation to the "paste any tokens" comment in the
code.
Ok.
+ while (rhs->flags & PASTE_LEFT);
+ if ((flags & PREV
Tamar Christina writes:
> Hi All,
>
> This optimizes right shift rounding narrow instructions to
> rounding add narrow high where one vector is 0 when the shift amount is half
> that of the original input type.
>
> i.e.
>
> uint32x4_t foo (uint64x2_t a, uint64x2_t b)
> {
> return vrshrn_high_n_u
Tamar Christina writes:
> Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-linux-gnu and no
> issues.
>
> gcc/ChangeLog:
>
> * tree-vect-stmts.c (prepare_load_store_mask): Rename to...
> (prepare_vec_mask): ...This and record operations that have already been
> masked.
>
On Tue, Nov 16, 2021 at 11:49:18AM +, Andrew Stubbs wrote:
> This patch is needed for AMD GCN offloading when we use the assembler from
> LLVM 13+.
>
> The GCN runtime (libgomp+ROCm) requires that the location of all variables
> in the offloaded variables table are discoverable at runtime (usi
Hi GCC community,
This patch will add the missed pattern described in bug 98956 [1] to the
match.pd. The codegen and correctness proof for this pattern is here [2,3] in
case anyone is curious. Tested on x86_64 Linux.
Tree-optimization/98956:
Adding new optimization to match.pd:
BTW, in response to your earlier concern about stage 3: you posted the
series well in time for end of stage 1, so I think it can still go in
during stage 3.
Robin Dapp writes:
> Hi Richard,
>
>> It's hard to judge this in isolation because it's not clear when
>> and how the new arguments are goin
Hi,
This fixes PR103500 i.e. ensuring that stack slots for
passed-by-reference overaligned types are appropriately aligned. For the
testcase:
typedef struct __attribute__((aligned(32))) {
long x,y;
} S;
S x;
void f(S);
void g(void) { f(x); }
on AArch64, we currently generate (at -O2):
g:
On Tue, Nov 30, 2021 at 05:24:49PM +0100, Jakub Jelinek via Gcc-patches wrote:
> Consider in one TU
>
> static int a = 5;
> static int baz (void) { static int b;
> #pragma omp declare target to (b)
> return ++b; }
> int foo (void) { return ++a + baz (); }
> #pragma omp declare target to (a, foo)
>
Ping.
Excerpts from Iain Buclaw's message of November 18, 2021 2:06 am:
> Hi,
>
> As asked for, this adds the documentation note in install.texi about the
> upcoming bootstrap requirements.
>
> Obviously this will be applied alongside the patch posted previously:
>
> https://gcc.gnu.org/piperma
Ping.
Are the common gcc parts OK (also for backporting)?
Iain.
Excerpts from Iain Buclaw's message of November 26, 2021 1:51 pm:
> Excerpts from Iain Sandoe's message of November 19, 2021 10:21 am:
>> Hi Iain
>>
>>> On 19 Nov 2021, at 08:32, Iain Buclaw wrote:
>>
>>> This patch fixes a stage
On 29.11.21 22:11, Harald Anlauf wrote:
"A whole array is a named array or a structure component whose final
part-ref is an array component name; no subscript list is appended."
I think in "h(3)" there is not really a named array – thus I read it as
if the "Otherwise ... result value is 1" appl
I was too eager about removing ncopies calculations in g:10833849b55.
When emulating gather/scatter, the offset ncopies can be different from
the data ncopies. This patch restores the original calculation.
Tested on aarch64-linux-gnu and x86_64-linux-gnu. Pushed as obvious,
since it's essentiall
> On Nov 30, 2021, at 9:14 AM, Peter Bergner wrote:
>
> On 11/30/21 2:37 AM, Richard Biener wrote:
>> On Mon, Nov 29, 2021 at 11:56 PM Qing Zhao wrote:
>> I think that's inconsistent indeed. Peter, what are "opaque"
>> registers? rs6000-modes.def suggests
>> that there's __vector_pair and _
> On Nov 30, 2021, at 2:37 AM, Richard Biener
> wrote:
>
> On Mon, Nov 29, 2021 at 11:56 PM Qing Zhao wrote:
>>
>> Peter,
>>
>> Thanks a lot for the patch.
>>
>> Richard, how do you think of the patch?
>>
>> (The major concern for me is:
>>
>>With the current patch proposed by Pe
On 11/30/21 11:51 AM, Qing Zhao wrote:
> So, looks like that the variable with OPAQUE_TYPE cannot be all explicitly
> initialized even at source code level.
>
> The only way to initialize such variable (only __vector_quad, not for
> __vector_pairs) at source code level is through call to
> __b
Hi!
On Tue, Nov 30, 2021 at 04:46:34PM +0800, HAO CHEN GUI wrote:
> This patch modifies the combine pattern with a helper -
> change_pseudo_and_mask when recog fails. The helper converts a single pseudo
> to the pseudo and with a mask if the outer operator is IOR/XOR/PLUS and the
> inner op
On Mon, Nov 29, 2021 at 05:53:58PM -0500, Jason Merrill wrote:
> I'm inclined to go ahead and change C++98 as well; I doubt anyone is relying
> on the particular C++98 extended character set rules, and we already accept
> the union of the different sets when not pedantic.
Ok, here is an incrementa
On 11/30/21 13:19, Jakub Jelinek wrote:
On Mon, Nov 29, 2021 at 05:53:58PM -0500, Jason Merrill wrote:
I'm inclined to go ahead and change C++98 as well; I doubt anyone is relying
on the particular C++98 extended character set rules, and we already accept
the union of the different sets when not
* Alex Coplan via Gcc-patches:
> Bootstrapped and regtested on aarch64-linux-gnu, x86_64-linux-gnu, and
> arm-linux-gnueabihf: no regressions.
>
> I'd appreciate any feedback. Is it OK for trunk?
Does this need an ABI warning?
Thanks,
Florian
Hi Mikael,
Am 30.11.21 um 12:25 schrieb Mikael Morin:
Hello,
Le 29/11/2021 à 22:31, Harald Anlauf via Fortran a écrit :
Dear all,
a trivial one: we need to check the type of the SUB argument
to the coarray IMAGE_INDEX intrinsic. It has to be an array
of type integer.
Patch by Steve Kargl.
> On Nov 30, 2021, at 12:08 PM, Peter Bergner wrote:
>
> On 11/30/21 11:51 AM, Qing Zhao wrote:
>> So, looks like that the variable with OPAQUE_TYPE cannot be all explicitly
>> initialized even at source code level.
>>
>> The only way to initialize such variable (only __vector_quad, not for
On Linux/x86_64,
10833849b55401a52f2334eb032a70beb688e9fc is the first bad commit
commit 10833849b55401a52f2334eb032a70beb688e9fc
Author: Richard Sandiford
Date: Tue Nov 30 09:52:29 2021 +
vect: Support gather loads with SLP
caused
FAIL: gcc.target/i386/pr88531-1a.c (internal compile
Hi Tobias,
Am 30.11.21 um 18:24 schrieb Tobias Burnus:
On 29.11.21 22:11, Harald Anlauf wrote:
"A whole array is a named array or a structure component whose final
part-ref is an array component name; no subscript list is appended."
I think in "h(3)" there is not really a named array – thus I
On 11/30/21 8:54 PM, Harald Anlauf via Fortran wrote:
Hi Tobias,
You seem to be quite convinced with your interpretation,
while I am simply confused.
If both compiler developers are confused, and actual compiler
implementations differ in their outcomes of the test case, IMNSHO it is
time
On 11/30/21 1:50 PM, Qing Zhao via Gcc-patches wrote:
>> void
>> bar (__vector_pair *dst, __vector_pair *src)
>> {
>> __vector_pair pair;
>> pair = *src;
>> ...
>> }
>
> However, even with the above, the memory pointed by “src” still need to
> be initialized somewhere. How to provide the initia
Tested x86_64-linux, pushed to trunk.
Clang doesn't define __SANITIZE_ADDRESS__ so use its __has_feature check
to detect Asan instead.
libstdc++-v3/ChangeLog:
PR libstdc++/103453
* config/allocator/malloc_allocator_base.h
(_GLIBCXX_SANITIZE_STD_ALLOCATOR): Define for Cla
Tested x86_64-linux, pushed to trunk.
In C++17 mode all callers of _S_relocate have already done:
if constexpr (_S_use_relocate())
so we don't need to repeat that check and use tag dispatching to avoid
ill-formed instantiations.
libstdc++-v3/ChangeLog:
* include/bits/stl_vector.h (v
On 11/30/21 07:17, Jakub Jelinek wrote:
On Mon, Nov 29, 2021 at 10:25:58PM -0500, Jason Merrill wrote:
It's a DR. Really, it was intended to be part of C++20; at the Cologne
meeting in 2019 CWG thought byteswap was going to make C++20, so this bugfix
could go in as part of that paper.
Ok, cha
Sorry for the confusing…
My major question is:
for a variable of type __vector_pair, could it be in a register?
If it could be in a register, can we initialize this register with some
constant value?
Qing
> On Nov 30, 2021, at 2:07 PM, Peter Bergner wrote:
>
> On 11/30/21 1:50 PM, Qing Zh
Hello,
On 27/11/2021 21:56, Harald Anlauf via Fortran wrote:
diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c
index 6552eaf3b0c..fbc66097c80 100644
--- a/gcc/fortran/array.c
+++ b/gcc/fortran/array.c
@@ -1804,6 +1804,12 @@ expand_constructor (gfc_constructor_base base)
if (empty_con
richi's recent unreachable code warning experiments had trouble with the C++
front end folding away an 'if' with a constant condition. Let's do less
folding at the statement level. Thanks to Marek for finding the offending
code.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
Pushed.
---
htdocs/gcc-12/changes.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index 10ac025f..45a8d99a 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -322,7 +322,7 @@ a work-in-progre
Just a trivial, if permanent redirect, to follow.
Pushed, Gerald
---
htdocs/gcc-4.7/changes.html | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/htdocs/gcc-4.7/changes.html b/htdocs/gcc-4.7/changes.html
index 21294cc3..846946d6 100644
--- a/htdocs/gcc-4.7/changes.html
+++ b
While we are at it, remove the unnecessary trailing slash.
Pushed, Gerald
---
htdocs/readings.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/readings.html b/htdocs/readings.html
index e75bfc49..12755d7e 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
On Tue, Nov 30, 2021 at 8:35 AM Navid Rahimi via Gcc-patches
wrote:
>
> Hi GCC community,
>
> This patch will add the missed pattern described in bug 98956 [1] to the
> match.pd. The codegen and correctness proof for this pattern is here [2,3] in
> case anyone is curious. Tested on x86_64 Linux.
On 11/29/21 10:03, Richard Biener via Gcc-patches wrote:
This cleans up unreachable code diagnosed by -Wunreachable-code-ctrl.
It largely follows the previous series but discovers a few extra
cases, namely dead code after break or continue or loops without
exits.
Bootstrapped on x86_64-unknown-l
Attached is a revised patch with the following changes based
on your comments:
1) Set and use statement uids to determine which statement
precedes which in the same basic block.
2) Avoid testing flag_isolate_erroneous_paths_dereference.
3) Use post-dominance to decide whether to use the "maybe
On 11/30/21 2:44 PM, Qing Zhao via Gcc-patches wrote:
> Sorry for the confusing…
> My major question is:
>
> for a variable of type __vector_pair, could it be in a register?
Yes. To be pedantic, it will live in a vector register pair.
> If it could be in a register, can we initialize this r
Successfully regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r12-5641-g9603bccba62e250d0ff64863a1730a167d571a25.
gcc/testsuite/ChangeLog:
PR analyzer/99269
* gcc.dg/analyzer/pr99269.c: New test.
Signed-off-by: David Malcolm
---
gcc/testsuite/gcc.dg/analyzer/pr99269.c | 16
1 - 100 of 118 matches
Mail list logo
