Hi,
Thanks, i will dig it deeply :)
Jojo
在 2020年10月10日 +0800 AM11:14，Andrew Pinski ，写道：
> On Fri, Oct 9, 2020 at 8:01 PM Jojo R wrote:
> >
> > Hi,
> >
> > Is there any API or common codes to check any two blocks is reachable ?
>
> Yes the API in dominance.h.
> Depending on where you use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97361
Bug ID: 97361
Summary: power10 unrecognizable insn
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
On Fri, Oct 9, 2020 at 8:01 PM Jojo R wrote:
>
> Hi,
>
> Is there any API or common codes to check any two blocks is reachable
> ?
Yes the API in dominance.h.
Depending on where you use it, you might need to have it created.
Using calculate_dominance_info function.
The function to do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
Bug ID: 97360
Summary: ICE in range_on_exit
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Hi,
Is there any API or common codes to check any two blocks is reachable ?
Thanks.
Jojo
Jonathan Wakely writes:
> On 07/10/20 18:15 -0700, Thomas Rodgers wrote:
>>@@ -500,6 +576,40 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
>> }
>> #endif
>>
>>+#if __cplusplus > 201703L && _GLIBCXX_USE_CXX11_ABI
>>+ basic_istringstream(ios_base::openmode __mode, const allocator_type&
>>__a)
>>+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97168
--- Comment #6 from Martin Sebor ---
No failures in diagnostic-test-expressions-1.c in my latest build (just about
an hour old). The latest x86_64 result posted to gcc-testresults also looks
clear of plugin test failures except pr97117:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97168
David Malcolm changed:
What|Removed |Added
Status|NEW |UNCONFIRMED
Ever confirmed|1
On Fri, Oct 09, 2020 at 09:38:09AM +0100, Alex Coplan wrote:
> Hi Segher,
>
> On 08/10/2020 15:20, Segher Boessenkool wrote:
> > On Thu, Oct 08, 2020 at 11:21:26AM +0100, Alex Coplan wrote:
> > > Ping. The kernel is still broken on AArch64.
> >
> > You *cannot* fix a correctness bug with a
Snapshot gcc-9-20201009 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20201009/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97168
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97359
Jakub Jelinek changed:
What|Removed |Added
Summary|ice in logical_combine, at |[11 Regression] ice in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97359
--- Comment #2 from David Binderman ---
The reduced C code is
typedef unsigned int uint32_t;
int a;
void b(uint32_t c) {
uint32_t *d =
for (; a;)
for (;; (*d %= a) / (*d > 1 > (c > 0)) ?: d)
;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97359
--- Comment #1 from David Binderman ---
The code seems to break gcc trunk sometime between 20201006 and 20201007.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97359
Bug ID: 97359
Summary: ice in logical_combine, at gimple-range-gori.cc:754
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82721
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97358
--- Comment #1 from Jakub Jelinek ---
Slightly modified testcase where bar is surely instantiated and clang++ still
accepts it. It actually ICEs in all of -std=c++{11,14,17,20}.
struct A;
struct B { A foo (); };
enum C { E };
struct A {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97358
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |8.5
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97358
Bug ID: 97358
Summary: [8/9/10/11 Regression] ICE while building firefox
since r8-2720
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Hi Iain,
If the last node in the list is void_list_node (a TREE_LIST node whose
TREE_VALUE is the void_type_ node), then functions of this type do not
take variable arguments. Otherwise, they do take a variable number of
arguments.
> HTH
That does help, a lot.
It means that this decl is
On Linux/x86_64,
ffe8baa996486fa0313aa804a064a58b0b161f07 is the first bad commit
commit ffe8baa996486fa0313aa804a064a58b0b161f07
Author: Jan Hubicka
Date: Fri Oct 9 11:29:58 2020 +0200
IPA modref: fix miscompilation in clone when IPA modref is used
caused
FAIL:
On Linux/x86_64,
16760e5bf7028dfa36b39af305d05cdf2c15b3a9 is the first bad commit
commit 16760e5bf7028dfa36b39af305d05cdf2c15b3a9
Author: Richard Biener
Date: Fri Oct 9 12:24:46 2020 +0200
tree-optimization/97334 - improve BB SLP discovery
caused
FAIL: gcc.dg/vect/bb-slp-pr65935.c -flto
Thomas Koenig via Fortran wrote:
and the library function has
mmaxloc2_4_s1 (gfc_array_s1 * const restrict array,
gfc_array_l1 * const restrict mask,
GFC_LOGICAL_4 back,
gfc_charlen_type len)
As far as I can tell, the decl
Hi,
I am currently trying to get the argument lists for calling
intrinsic functions right, and I have run across something in a
tree I do not understand.
The declaration is:
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set -1
canonical-type 0x7feefcfec5e8
On 10/7/20 5:12 PM, H.J. Lu wrote:
> On Wed, Oct 7, 2020 at 3:09 PM Jeff Law via Gcc-patches
> wrote:
>> Adding the testcase...
>>
>> On 10/7/20 4:08 PM, Jeff Law wrote:
>>> On 9/17/20 1:03 PM, Jakub Jelinek wrote:
>>> [ ... Big snip, starting over ... ]
>>>
>>> I may have not explained things
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95904
Ville Voutilainen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95904
--- Comment #1 from CVS Commits ---
The master branch has been updated by Ville Voutilainen :
https://gcc.gnu.org/g:3427e31331677ca826c5588c87924214f7e5c54b
commit r11-3760-g3427e31331677ca826c5588c87924214f7e5c54b
Author: Ville Voutilainen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97168
--- Comment #3 from David Malcolm ---
(In reply to Thomas Schwinge from comment #2)
[...]
> (In reply to Martin Sebor from comment #0)
> > FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
> >
This removes the __detail::_Shift class template, replacing it with a
constexpr function template __pow2m1. Instead of using the _Mod class
template to calculate a modulus just perform a bitwise AND with the
result of __pow2m1. This works because the places that change all
perform a modulus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97318
--- Comment #1 from Tom de Vries ---
Tentative patch:
...
diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index afac1bda45d..7b6a42893f9 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -365,6 +365,30 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
--- Comment #7 from qinzhao at gcc dot gnu.org ---
as we noticed, when using gcc10.2.1 compile our application, 528 C++ modules
failed with this bug.
looks like a high priority bug to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P2
/10.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../latest_gcc/configure --prefix=/home/qinzhao/Install/latest
-enable-languages=c,c++,fortran,lto
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.1 20201009 (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97357
Bug ID: 97357
Summary: Unable to coalesce ssa_names which are marked as MUST
COALESCE.
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97349
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97356
Bug ID: 97356
Summary: [11 regression] several test case failures after
r11-3748
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97355
Bug ID: 97355
Summary: Bootstrap comparison failure!
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94823
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |11.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97311
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97311
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:3ee44d4c518d61c6bbf75fcf280edc6ce5326ce0
commit r11-3759-g3ee44d4c518d61c6bbf75fcf280edc6ce5326ce0
Author: Jonathan Wakely
Date:
This ensures that intermediate results are done in uint32_t values,
meeting the requirement for operations to be done modulo 2^32.
If the target doesn't define __UINT32_TYPE__ then substitute uint32_t
with a class type that uses uint_least32_t and masks the value to
UINT32_MAX.
I've also split
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94823
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:3ee44d4c518d61c6bbf75fcf280edc6ce5326ce0
commit r11-3759-g3ee44d4c518d61c6bbf75fcf280edc6ce5326ce0
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
--- Comment #8 from Jonathan Wakely ---
And please ping patches like
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552844.html if you don't
get a review.
Bootstrapped and regtested on s390x-redhat-linux. OK for master?
v1: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555782.html
v1 -> v2: Use related_int_vector_mode.
The vector copysign pattern incorrectly assumes that vector
if_then_else operates on bits, not on elements. This can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97336
--- Comment #3 from Martin Sebor ---
For better or worse, in the internal representation there's no way to
differentiate a call that was synthesized during loop unrolling (or any other
similar transformation) from the original call in the source
/gimple-iterator.h:43
0xf7b1b4 _bb_vec_info::~_bb_vec_info()
../../trunk.git/gcc/tree-vect-slp.c:2777
0xf7dcf0 vect_slp_region(vec,
vec, vec*, unsigned
int)
../../trunk.git/gcc/tree-vect-slp.c:3741
The bug first seems to occur sometime between 20201008 and 20201009.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97348
--- Comment #6 from Tom de Vries ---
(In reply to CVS Commits from comment #4)
> Both build again cuda 9.1.
FWIW, tested post-commit against cuda 11.1, no issues found.
On 10/9/20 4:48 AM, Jakub Jelinek wrote:
On Tue, Oct 06, 2020 at 03:40:52PM -0400, Jason Merrill via Gcc-patches wrote:
On 10/4/20 11:28 PM, Patrick Palka wrote:
cp_tree_equal currently considers alignof the same as __alignof__, but
these operators are semantically different ever since
On 10/9/20 10:51 AM, Martin Sebor wrote:
On 10/8/20 1:40 PM, Jason Merrill wrote:
On 10/8/20 3:18 PM, Martin Sebor wrote:
On 10/7/20 3:01 PM, Jason Merrill wrote:
On 10/7/20 4:11 PM, Martin Sebor wrote:
...
For the various member functions, please include the
comments with the definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94823
--- Comment #7 from Jonathan Wakely ---
Despite the code being correct, I think it would be better to hoist this branch
out of the loop:
if (__k == 0)
__r2 += __s;
else if (__k <= __s)
__r2 += __kn +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95464
--- Comment #13 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #12)
> Certainly.
I've just committed it into the branch
https://gcc.gnu.org/g:70a66ff0228277b4dd89263a663c0a87eb5d782f
On 10/8/20 1:40 PM, Jason Merrill wrote:
On 10/8/20 3:18 PM, Martin Sebor wrote:
On 10/7/20 3:01 PM, Jason Merrill wrote:
On 10/7/20 4:11 PM, Martin Sebor wrote:
...
For the various member functions, please include the comments
with the definition as well as the in-class declaration.
Only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97313
--- Comment #3 from CVS Commits ---
The releases/gcc-10 branch has been updated by Vladimir Makarov
:
https://gcc.gnu.org/g:70a66ff0228277b4dd89263a663c0a87eb5d782f
commit r10-8874-g70a66ff0228277b4dd89263a663c0a87eb5d782f
Author: Vladimir N.
On Fri, 9 Oct 2020 at 15:13, Joel Sherrill wrote:
>
>
>
> On Fri, Oct 9, 2020 at 8:49 AM Jonathan Wakely wrote:
>>
>> On Fri, 9 Oct 2020 at 14:31, Joel Sherrill wrote:
>> >
>> > Hi
>> >
>> > being deprecated for nearly 20 years of C++ standards has
>> > always been a bit baffling to me. I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97079
--- Comment #4 from Alex Coplan ---
Related testcase that gives a similar ICE:
int c, d;
int e[1];
void a(int *);
void f(void) {
while (d);
int g[5];
for (; d < 2; d++)
e[d] = c;
for (; d; d++)
g[d] = (long)e;
a(g);
}
$
The following patch has been committed into the main line. The patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97313
The patch was successfully bootstrapped and tested on x86-64.
gcc/ChangeLog:
2020-10-09 Vladimir Makarov
PR rtl-optimization/97313
* lra-constraints.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95464
--- Comment #12 from Jakub Jelinek ---
Certainly.
From: Claudiu Zissulescu
ARC MYP7+ instructions add MAC instructions for vector and scalar data
types. This patch adds a madd pattern for 16it datum that is using the
32bit MAC instruction, and dot_prod patterns for v4hi vector
types. The 64bit moves are also upgraded by using vadd2 instuction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97353
Bug ID: 97353
Summary: -Wuninitialized should warn about reading condition in
do-loop
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95464
--- Comment #11 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #7)
> Vlad, do you plan to backport this to 10.3?
Unfortunately, a few days ago people reported a serious problem with the patch
(see PR97313). I've just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97313
--- Comment #2 from CVS Commits ---
The master branch has been updated by Vladimir Makarov :
https://gcc.gnu.org/g:bb37ad8cc0fc937c7afcdab471e5d65d176041c3
commit r11-3758-gbb37ad8cc0fc937c7afcdab471e5d65d176041c3
Author: Vladimir N. Makarov
On Fri, Oct 9, 2020 at 8:49 AM Jonathan Wakely
wrote:
> On Fri, 9 Oct 2020 at 14:31, Joel Sherrill wrote:
> >
> > Hi
> >
> > being deprecated for nearly 20 years of C++ standards has
> > always been a bit baffling to me. I'm used to thingis being deprecated
> and
> > then removed a bit faster
On Fri, 9 Oct 2020 at 14:31, Joel Sherrill wrote:
>
> Hi
>
> being deprecated for nearly 20 years of C++ standards has
> always been a bit baffling to me. I'm used to thingis being deprecated and
> then removed a bit faster than that.
>
> It is still deprecated in C++17 but does not appear in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97333
--- Comment #2 from Tom de Vries ---
(In reply to Richard Biener from comment #1)
> (because well, on GIMPLE we can duplicate all blocks).
I'm not sure I understand why, given that tracer.c has a can_duplicate_bb_p
that sometimes returns false.
Hi,
The function gimple_can_duplicate_bb_p currently always returns true.
The presence of can_duplicate_bb_p in tracer.c however suggests that
there are cases when bb's indeed cannot be duplicated.
Move the implementation of can_duplicate_bb_p to gimple_can_duplicate_bb_p.
Bootstrapped and
Hi
being deprecated for nearly 20 years of C++ standards has
always been a bit baffling to me. I'm used to thingis being deprecated and
then removed a bit faster than that.
It is still deprecated in C++17 but does not appear in C++2x as of
draft N4860. GCC 10 still behaves the same and you get
x86-64-v2 includes CMPXCHG16B. Since -mcx16 enables CMPXCHG16B and
defines __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16, check it in x86-64-v[234]
tests.
PR target/97250
* gcc.target/i386/x86-64-v2.c: Verify that
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 is defined.
*
On 06/10/20 15:55 -0400, Daniel Lemire via Libstdc++ wrote:
The updated patch looks good to me. It is indeed cleaner to have a separate
(static) function.
It might be nice to add a comment to explain the _S_nd function maybe with
a comment like "returns a random value in [0,__range)
without any
On 09/10/20 14:02 +0100, Jonathan Wakely wrote:
It looks like our check-performance target runs completely unoptimized,
which is a bit silly. This exports the CXXFLAGS from the parent make
process to the check_performance script.
libstdc++-v3/ChangeLog:
* scripts/check_performance: Use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189
--- Comment #27 from Luke Dashjr ---
AFAIK it's complete, but I am not a GCC developer.
This tests std::uniform_int_distribution with various parameters and
engines.
libstdc++-v3/ChangeLog:
* testsuite/performance/26_numerics/random_dist.cc: New test.
Tested powerpc64le-linux. Committed to trunk.
commit f9919ba717dfaf6018b7e625bebc84a461477b52
Author: Jonathan Wakely
It looks like our check-performance target runs completely unoptimized,
which is a bit silly. This exports the CXXFLAGS from the parent make
process to the check_performance script.
libstdc++-v3/ChangeLog:
* scripts/check_performance: Use gnu++11 instead of gnu++0x.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250
--- Comment #8 from H.J. Lu ---
(In reply to Florian Weimer from comment #7)
> (In reply to H.J. Lu from comment #6)
> > (In reply to Florian Weimer from comment #5)
> > > (In reply to H.J. Lu from comment #4)
> > > > x86-64-v2 includes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250
--- Comment #7 from Florian Weimer ---
(In reply to H.J. Lu from comment #6)
> (In reply to Florian Weimer from comment #5)
> > (In reply to H.J. Lu from comment #4)
> > > x86-64-v2 includes CMPXCHG16B, aka CX16. But -mcx16 doesn't define
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329
--- Comment #8 from Segher Boessenkool ---
The default -mcpu= for a compiler targeting powerpc64le-linux is
normally power8 (you can change this with the --with-cpu= configure
option though). -mcpu=powerpc64le is also (currently) equal to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250
--- Comment #6 from H.J. Lu ---
(In reply to Florian Weimer from comment #5)
> (In reply to H.J. Lu from comment #4)
> > x86-64-v2 includes CMPXCHG16B, aka CX16. But -mcx16 doesn't define __CX16__.
>
> It's called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250
--- Comment #5 from Florian Weimer ---
(In reply to H.J. Lu from comment #4)
> x86-64-v2 includes CMPXCHG16B, aka CX16. But -mcx16 doesn't define __CX16__.
It's called __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16, I think. Is this good enough?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250
H.J. Lu changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
Hello,
> Typo: comple-time
>
> >2020-10-08 JeanHeyd "ThePhD" Meneide
> >
> >* gcc/c-family/c-cppbuiltin.c: Add predefined macro
> >definitions for charsets
>
> I think you should put the macro names in braces after the filename and drop
> the trailing "for charsets".
Can do!
>
On 10/9/20 2:19 PM, Tobias Burnus wrote:
> Hi,
>
> On 10/9/20 1:56 PM, Tom de Vries wrote:
>> The default in the nvptx port for -misa=sm_xx is sm_30, but the ptxas
>> of the
>> latest cuda release (11.1) no longer supports sm_30.
>
> Interestingly, at
>
Hi Jakub.
As the last known expert in this area, would you review this, please? :)
This sets things up so we can share range handling of builtins between
vr_values and ranger. It is meant to refactor the code so that we can
verify that both implementations yield the same results.
First, we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97148
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Hi,
On 10/9/20 1:56 PM, Tom de Vries wrote:
The default in the nvptx port for -misa=sm_xx is sm_30, but the ptxas of the
latest cuda release (11.1) no longer supports sm_30.
Interestingly, at
https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#release-notes__ptx-release-history
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97336
--- Comment #2 from Christian Franke ---
Sorry, but I disagree that this report is INVALID.
Unlike for example -Wstringop-overflow, warnings like -Wstring-compare should
IMO only occur if the warning condition holds for *all* function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97343
--- Comment #2 from Michael_S ---
(In reply to Richard Biener from comment #1)
> All below for Part 2.
>
> Without -ffast-math you are seeing GCC using in-order reductions now while
> with -ffast-math the vectorizer gets a bit confused about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97348
Tom de Vries changed:
What|Removed |Added
Target Milestone|--- |11.0
Resolution|---
Hi,
The nvptx-as assembler verifies the ptx code using ptxas, if there's any
in the PATH.
The default in the nvptx port for -misa=sm_xx is sm_30, but the ptxas of the
latest cuda release (11.1) no longer supports sm_30.
Consequently we cannot build gcc against that release (although we should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97348
--- Comment #4 from CVS Commits ---
The master branch has been updated by Tom de Vries :
https://gcc.gnu.org/g:383400a6078d75bbfa1216c9af2c37f7e88740c9
commit r11-3752-g383400a6078d75bbfa1216c9af2c37f7e88740c9
Author: Tom de Vries
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97350
Martin Liška changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97168
Thomas Schwinge changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97350
Eric Botcazou changed:
What|Removed |Added
Last reconfirmed||2020-10-09
Component|ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97350
--- Comment #1 from Eric Botcazou ---
This looks like a miscompilation of the compiler with this particular setup so
reclassifying (regular bootstrap works just fine).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97350
Richard Biener changed:
What|Removed |Added
Version|10.0|11.0
Target Milestone|---
The following adds a effective target to properly allow
the gcc.dg/vect/pr65947-3.c expected vectorization to be adjusted
when run with, say, -march=cascadelake.
Tested on x86_64-unknown-linux-gnu, pushed.
2020-10-09 Richard Biener
gcc/
* doc/sourcebuild.texi (vect_masked_load):
On 8 October 2020 23:39:15 CEST, JeanHeyd Meneide via Gcc-patches
wrote:
>Dear Joseph,
>
>On Thu, Oct 8, 2020 at 1:36 PM Joseph Myers
>wrote:
>>
>> This documentation doesn't seem sufficient to use the macros. Do
>they
>> expand to (narrow) string literals? To an unquoted sequence of
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 97334, which changed state.
Bug 97334 Summary: inefficient vectorization of gcc.dg/vect/bb-slp-pr65935.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97334
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97334
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
We're running into a multiplication with one unvectorizable
operand we expect to build from scalars but SLP discovery
fatally fails the build of both since one stmt is commutated:
_60 = _58 * _59;
_63 = _59 * _62;
_66 = _59 * _65;
...
where _59 is the "bad" operand. The following patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97334
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:16760e5bf7028dfa36b39af305d05cdf2c15b3a9
commit r11-3750-g16760e5bf7028dfa36b39af305d05cdf2c15b3a9
Author: Richard Biener
Date:
On 10/9/20 10:06 AM, Jiufu Guo wrote:
Hi,
I'm thinking about to tune the cunroll and cunrolli. And I also had some
tests about parameters like: param_max_completely_peel_times,
param_max_peel_times, param_max_completely_peeled_insns...
During tunning those parameters, I find there are some
1 - 100 of 182 matches
Mail list logo
