On Tue, 30 Nov 2021, Jason Merrill wrote:
> 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
On Wed, Dec 01, 2021 at 09:47:21AM +0530, Siddhesh Poyarekar wrote:
> Avoid overwriting osi->changed if object_sizes_set does not update the
> size, so that a previous success in the same pass is not overwritten.
> This fixes the bootstrap-ubsan build config, which was failing due to
> incorrect ob
Avoid overwriting osi->changed if object_sizes_set does not update the
size, so that a previous success in the same pass is not overwritten.
This fixes the bootstrap-ubsan build config, which was failing due to
incorrect object size.
Also completed a bootstrap on x86_64 which didn't show any new f
Hi Segher,
Thanks for your review. Please see my comments.
On 1/12/2021 上午 2:11, Segher Boessenkool wrote:
> 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 hel
For PR61825, honza changed tree_single_nonzero_warnv_p to prevent a later
declaration from marking a function as weak after we've determined that it
wasn't weak before. But we shouldn't do that for speculative folding; we
should only do it when we actually need a constant value. In C++, such a
co
I see. That makes sense. Thanks for the explanation. I was looking at the 64992
and it seems all the implementation right now are only using INTEGER_CST at the
moment.
But now it makes sense.
Best wishes,
Navid.
From: Andrew Pinski
Sent: Tuesday, Novem
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/avx2-i32gatherpd256-2.c (inter
On Tue, Nov 30, 2021 at 3:18 PM Andrew Pinski wrote:
>
> On Tue, Nov 30, 2021 at 3:08 PM Navid Rahimi
> wrote:
> >
> > Hi Andrew,
> >
> > Thanks for your detailed comment. There are two problem I wanted to discuss
> > with you about:
> >
> > a) The optimization I have sent patch, does optimize
On Tue, Nov 30, 2021 at 3:08 PM Navid Rahimi wrote:
>
> Hi Andrew,
>
> Thanks for your detailed comment. There are two problem I wanted to discuss
> with you about:
>
> a) The optimization I have sent patch, does optimize variable length "<<"
> too(for example B0 << x, where x is variable). This
Tested powerpc64le-linux (old ABI) and x86_64-linux (new ABI), pushed to
trunk.
Fix some tests that assume that a moved-from string is empty, or that
default constructing a string doesn't allocate.
libstdc++-v3/ChangeLog:
* testsuite/21_strings/basic_string/cons/char/moveable.cc: Allow
Tested powerpc64le-linux (old ABI) and x86_64-linux (new ABI), pushed to
trunk.
My last change to the fully-dynamic-string actually broke it. This fixes
the move constructor so it builds, and simplifies it slightly so that
more code is common between the fully-dynamic enabled/disabled cases.
lib
Tested powerpc64le-linux (old ABI) and x86_64-linux (new ABI), pushed to
trunk.
The definitions of the new C++20 members of std::stringstream etc are
missing when --with-default-libstdcxx-abi=gcc4-compatible is used,
because all the explicit instantiations in src/c++20/sstream-inst.cc are
skipped
Hi Andrew,
Thanks for your detailed comment. There are two problem I wanted to discuss
with you about:
a) The optimization I have sent patch, does optimize variable length "<<"
too(for example B0 << x, where x is variable). This [1] link shows the actual
optimization and a link for the proof i
On 11/30/21 12:51 AM, Richard Biener wrote:
On Mon, 29 Nov 2021, Martin Sebor wrote:
On 11/29/21 11:53 AM, Martin Sebor wrote:
On 11/29/21 6:09 AM, Richard Biener via Gcc-patches wrote:
This removes more cases that appear when bootstrap with
-Wunreachable-code-return progresses.
...
diff -
Hi!
On Tue, Nov 30, 2021 at 01:05:48PM +0800, Kewen.Lin wrote:
> on 2021/11/30 上午6:06, Segher Boessenkool wrote:
> > On Tue, Sep 28, 2021 at 04:16:04PM +0800, Kewen.Lin wrote:
> >> unsigned adjusted_cost = (nunits == 2) ? 2 : 1;
> >> unsigned extra_cost = nunits * adjusted_cost;
> >
> >>
Successfully regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r12-5642-g955ea7b58e4f1e3cc5083e88575161168c147254.
gcc/testsuite/ChangeLog:
PR analyzer/94579
* gcc.dg/analyzer/pr94579.c: New test.
Signed-off-by: David Malcolm
---
gcc/testsuite/gcc.dg/analyzer/pr94579.c | 11
Successfully regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r12-5640-g03ea0ca1189a39e095188b0425c66446cc84a0a5.
gcc/testsuite/ChangeLog:
PR analyzer/100524
* gcc.dg/analyzer/pragma-2.c: New test.
Signed-off-by: David Malcolm
---
gcc/testsuite/gcc.dg/analyzer/pragma-2.c |
Attached is a revision of this patch with adjustments for
the changes to the prerequisite patch 1 in the series and
a couple of minor simplifications and slightly improved
test coverage, rested on x86_64-linux.
On 11/1/21 4:18 PM, Martin Sebor wrote:
Patch 2 in this series adds support for detec
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
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
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/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
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.
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
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
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
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:
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
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
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
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
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
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
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
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 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
> 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
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.
* 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
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
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
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 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
> 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 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 _
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 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
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
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
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)
>
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:
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 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:
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
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.
>
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
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
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 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
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
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
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
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,
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
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
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, 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
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
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
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
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
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
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
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 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 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
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, 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
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, 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
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, 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
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/
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 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
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
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 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.
>
>
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:
> --- 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 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 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
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
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_
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 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
Tejas Belagod via Gcc-patches writes:
> Ping for this series.
>
> Thanks,
> Tejas.
Hi all,
pinging this series.
BR
Andrea
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.
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, 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]
1 - 100 of 118 matches
Mail list logo
