PowerPC: Map long double built-in functions if IEEE 128-bit long double.
This patch is revised from the first version of the patch posted. It uses the
names that are not in the user's namespace (i.e. __sinieee128 instead of
sinf128) that Joseph Myers suggested.
This patch goes through the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95788
--- Comment #4 from Patrick Palka ---
(In reply to Johel Ernesto Guerrero Peña from comment #3)
> Thank you. Sorry for my laziness, but did you confirm this from the OP?
> > Other stuff in `bits/ranges_uninitialized.h` may be similarly affected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189
--- Comment #26 from Rich Felker ---
Is that complete, or is it unclear whether there are code paths other than
builtin memcmp by which this is hit? Am I correct in assuming that with builtin
memcmp expansion returning NULL_RTX, GCC always
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97344
--- Comment #2 from Stan Cox ---
tls variables on aarch64 lack location info:
[6e]variable abbrev: 5
name (strp) "rage"
decl_file(data1) tlsdwarf.c (1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97344
--- Comment #1 from Stan Cox ---
Created attachment 49335
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49335=edit
tls test program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97344
Bug ID: 97344
Summary: aarch64 tls debuginfo missing location info
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85576
--- Comment #1 from Luke Dalessandro ---
Just ran into this today while testing 11. https://godbolt.org/z/37G7P5
Any possibility we'll see a fix soon?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189
--- Comment #25 from Luke Dashjr ---
Created attachment 49334
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49334=edit
Hacky patch to workaround the bug by disabling builtin memcmp always
I wrote and am rebuilding my own systems with a
automatically:
$ gcc -dumpmachine
powerpc64le-unknown-linux-gnu
I built it from trunk last night on a power9 machine. I've attached my
config.log.
$ gcc --version
gcc (GCC) 11.0.0 20201008 (experimental)
(...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329
--- Comment #6 from Kip Warner ---
Created attachment 49333
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49333=edit
Autoconf configuration log on POWER9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95788
--- Comment #3 from Johel Ernesto Guerrero Peña ---
Thank you. Sorry for my laziness, but did you confirm this from the OP?
> Other stuff in `bits/ranges_uninitialized.h` may be similarly affected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97273
Patrick Palka changed:
What|Removed |Added
Summary|[8/9/10/11 Regression] |[8/9 Regression] Strange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88115
--- Comment #2 from CVS Commits ---
The releases/gcc-10 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:aeb69dda51e93379fce10fb03ec57650fbf73f31
commit r10-8872-gaeb69dda51e93379fce10fb03ec57650fbf73f31
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97273
--- Comment #5 from CVS Commits ---
The releases/gcc-10 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:aeb69dda51e93379fce10fb03ec57650fbf73f31
commit r10-8872-gaeb69dda51e93379fce10fb03ec57650fbf73f31
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95788
--- Comment #2 from Patrick Palka ---
Fixed for GCC 11 so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95788
--- Comment #1 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:9158a4d2a6cd58d6bb591d5ce64e766b399e4aef
commit r11-3739-g9158a4d2a6cd58d6bb591d5ce64e766b399e4aef
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97317
--- Comment #6 from Andrew Macleod ---
Thanks, yeah this is the same issue and the patch should fix it..?
the precision difference of one this time is 1 bit (bool) and a 2 bit object...
_5;
bool _6;
<..>
_6 = (bool) _5;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97343
Bug ID: 97343
Summary: AVX2 vectorizer generates extremely strange and slow
code for AoSoA complex dot product
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189
--- Comment #24 from Rich Felker ---
The fixes do not seem trivial to backport; lots of conflicts. It would be
really helpful to have versions of the patch that are minified and applicable
to all affected versions that might be shipping in
Snapshot gcc-8-20201008 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/8-20201008/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97317
--- Comment #5 from David Binderman ---
Reduced C++ source code is
class a {
public:
struct b {
int *c;
};
enum { j = 1 } e : 2;
struct {
b c;
} d;
bool f() const { return e & j; }
int *g() const;
};
int *a::g() const {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97328
--- Comment #5 from Patrick Palka ---
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555850.html
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
> characters? I think from the implementation that the answer is strings
> (so, in
On Linux/x86_64,
214d514fafcd78cd54e4a4aa9ae08c89abf9cc57 is the first bad commit
commit 214d514fafcd78cd54e4a4aa9ae08c89abf9cc57
Author: Aldy Hernandez
Date: Thu Oct 8 11:15:23 2020 +0200
Fix PR97315 (part 1 of 2)
caused
FAIL: gcc.dg/pr97315-1.c (test for excess errors)
with GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97342
Bug ID: 97342
Summary: bogus -Wstringop-overflow with nonzero signed and
unsigned offsets
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96805
--- Comment #11 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:1c56c143b2011080d8a4516f37f78f647b0ee258
commit r11-3738-g1c56c143b2011080d8a4516f37f78f647b0ee258
Author: Jason Merrill
Date:
Here we're trying to push into a::c in order to instantiate t, but
were building a TYPENAME_TYPE for it because a isn't open yet. Don't
do that when we know we're trying to enter the scope.
Tested x86_64-pc-linux-gnu, applying to trunk and 10.
gcc/cp/ChangeLog:
PR c++/96805
PR
On 07/10/20 12:10 -0400, Patrick Palka via Libstdc++ wrote:
On Wed, 30 Sep 2020, Patrick Palka wrote:
This rewrites ranges::construct_at in terms of std::construct_at so
that we can piggy back on the compiler's existing support for
recognizing placement new within std::construct_at during
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96199
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:1c56c143b2011080d8a4516f37f78f647b0ee258
commit r11-3738-g1c56c143b2011080d8a4516f37f78f647b0ee258
Author: Jason Merrill
Date:
In the testcase below, we're ICEing during constexpr evaluation of the
CONSTRUCTOR {.data={{}, [1 ... 7]={}}} of type 'vector'. The apparently
unique thing about this CONSTRUCTOR is that it has a RANGE_EXPR index
whose corresponding sub-aggregate initializer doesn't satisfy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272
--- Comment #8 from CVS Commits ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:83967508034454425dfce7fe0ea33a153c34e7cb
commit r9-8985-g83967508034454425dfce7fe0ea33a153c34e7cb
Author: Harald Anlauf
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 combine addition. So please
fix the target bug first.
I haven't had time to look at your patch yet, sorry.
Segher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329
--- Comment #5 from Segher Boessenkool ---
So both the cache line size and the cache size are wrong for GCC 10
and before, but okay on trunk, on all compiler I tested (I tested on
Linux only so far).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329
--- Comment #4 from Kip Warner ---
I'm going to do some more testing tonight and report back after.
On Oct 8, 2020, Richard Biener wrote:
> OK with a minor nit, see below
>> I'm a little unhappy with the duplication of the CASE_MATHFN* sequence,
>> that ought to be kept in sync, , and considered turning that whole
>> sequence into a #define used in both places, but that would bloat the
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2020-10-08
Ever confirmed|0
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 one access_ref member function is defined
Hi Richard!
On 2020-10-08T13:34:02+0200, Richard Biener wrote:
> It might be interesting to work on adding sth like
> dg-warning to look for -fopt-info-{optimized,missing} so
> we could directly annotate (not) vectorized loops instead of
> relying on fragile counts.
I'm maybe (likely?)
I eventually consider your last remark about using weak symbols to
inject libbacktrace calls when _GLIBCXX_DEBUG_BACKTRACE is defined.
libstdc++: [_GLIBCXX_DEBUG] Integrate libbacktrace
Add _GLIBCXX_DEBUG_BACKTRACE macro to ask for a backtrace on
_GLIBCXX_DEBUG
assertions using
On Linux/x86_64,
181702ef8ab76afbf5d2cd4d7bc0cef613397d6e is the first bad commit
commit 181702ef8ab76afbf5d2cd4d7bc0cef613397d6e
Author: Richard Biener
Date: Tue Oct 6 15:47:15 2020 +0200
SLP vectorize multiple BBs at once
caused
FAIL: gcc.c-torture/execute/loop-13.c -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97328
--- Comment #4 from Patrick Palka ---
(In reply to Marek Polacek from comment #3)
> (In reply to Patrick Palka from comment #2)
> > When 'storage' is a struct instead of a union, i.e. for the testcase
> >
> > template
> > struct vector {
> >
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 one access_ref member function is defined out-of-line:
offset_bounded(). I've
Using the tokenizer to sniff for an initial line marker for
preprocessed input is a little brittle, particularly with
-fdirectives-only. If there is no marker we'll happily munch initial
comments. This patch directly sniffs the buffer. This is safe
because the initial line marker was machine
On Thu, 2020-10-08 at 09:36 +1030, Alan Modra via Gcc-patches wrote:
> Implement more two insn constants. rotate_and_mask_constant covers
> 64-bit constants that can be formed by rotating a 16-bit signed
> constant, rotating a 16-bit signed constant masked on left or right
> (rldicl and rldicr),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97341
Bug ID: 97341
Summary: Implicit casting from char** to const char* const* in
template argument failing
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97341
--- Comment #1 from Pratyush Das ---
I should add, that this works in Clang.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97313
--- Comment #1 from Vladimir Makarov ---
Thank you for reporting this. I am trying to find the best place to fix this:
either in memory subreg elimination or in match_reload itself. I hope the fix
will be ready tomorrow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97328
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97328
--- Comment #2 from Patrick Palka ---
When 'storage' is a struct instead of a union, i.e. for the testcase
template
struct vector {
struct storage {
T t;
constexpr storage() {}
} data[N];
};
constexpr auto foo() {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95979
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
Dear all,
the present PR turned out to be fixable rather easily, once Paul had the
idea to add another attempt of simplification of elemental intrinsics
for array-valued arguments. There was some fallout which required only
small adjustments, see commit message below.
Regtested cleanly on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97212
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189
Martin Sebor changed:
What|Removed |Added
Known to fail|10.1.0 |
--- Comment #23 from Martin Sebor ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95886
--- Comment #8 from CVS Commits ---
The releases/gcc-10 branch has been updated by Martin Sebor
:
https://gcc.gnu.org/g:e4c9aac98611f63847ef6c57916808d9a2d7abcb
commit r10-8871-ge4c9aac98611f63847ef6c57916808d9a2d7abcb
Author: Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189
--- Comment #22 from CVS Commits ---
The releases/gcc-10 branch has been updated by Martin Sebor
:
https://gcc.gnu.org/g:e4c9aac98611f63847ef6c57916808d9a2d7abcb
commit r10-8871-ge4c9aac98611f63847ef6c57916808d9a2d7abcb
Author: Martin Sebor
On Thu, 2020-10-08 at 09:27 +1030, Alan Modra via Gcc-patches wrote:
> The aim of this patch is to make rtx_costs for SETs closer to
> insn_cost for SETs. One visible effect on powerpc code is increased
> if-conversion.
>
> * config/rs6000/rs6000.c (rs6000_rtx_costs): Reduce cost of SET
>
On Linux/x86_64,
532e882f8872b1b4437e3a0fa8c61d2af2d999d4 is the first bad commit
commit 532e882f8872b1b4437e3a0fa8c61d2af2d999d4
Author: Richard Biener
Date: Thu Oct 8 11:53:51 2020 +0200
adjust BB vectorization dump scanning
caused
FAIL: gcc.dg/vect/bb-slp-pr78205.c -flto
On Linux/x86_64,
dae673abd37d400408959497e50fe1f3fbef5533 is the first bad commit
commit dae673abd37d400408959497e50fe1f3fbef5533
Author: Richard Biener
Date: Wed Oct 7 10:42:12 2020 +0200
tree-optimization/97307 - improve sinking of loads
caused
FAIL: gcc.dg/vect/pr65947-3.c -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96805
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97212
--- Comment #2 from Jakub Jelinek ---
I believe the testcase is invalid.
As the explicit task doesn't have if(false) clause, the task isn't undeferred,
so it is up to the implementation whether it waits for its completion or just
continues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #15 from Jan Hubicka ---
So it seems that problem is that store in operator++ is TriaObjectAcessor while
read is DoFCellAccessor. I am however not sure where the type puning happens :(
On Thu, 8 Oct 2020, JeanHeyd Meneide via Gcc-patches wrote:
> * gcc/doc/cpp.texi: Document new predefined macro.
This documentation doesn't seem sufficient to use the macros. Do they
expand to (narrow) string literals? To an unquoted sequence of
characters? I think from the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #14 from Jan Hubicka ---
So this really seems that the alias set 6 is not conflicting with alias sets
11 or 13. active_cell is
struct active_cell_iterator active_cell;
and the code around seems SRA injected
MEM[(struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #13 from Jan Hubicka ---
OK, I can reproduce it even though the propagation happens in different
function in dom rather than pre.
The callee is again the operator++ so I start to suspect aliasing violation
there.
I get:
ipa-modref:
Hi all,
I'd like to backport this patch to the GCC 9 branch to implement these
Armv8.5-a intrinsics that should have been there.
The backport is fairly simple.
Bootstrapped and tested on aarch64-none-linux-gnu.
Pushing to GCC 9 branch.
This patch implements the ACLE intrinsics to access the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97336
Martin Sebor changed:
What|Removed |Added
Resolution|--- |INVALID
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96313
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97150
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97150
--- Comment #7 from CVS Commits ---
The releases/gcc-8 branch has been updated by Kyrylo Tkachov
:
https://gcc.gnu.org/g:311183d74e4f3fd5a37749cfbb0960e655e715fb
commit r8-10576-g311183d74e4f3fd5a37749cfbb0960e655e715fb
Author: Kyrylo Tkachov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96313
--- Comment #9 from CVS Commits ---
The releases/gcc-8 branch has been updated by Kyrylo Tkachov
:
https://gcc.gnu.org/g:7f8115b305f1a1a2ddec4f59bc08a3415359dda6
commit r8-10575-g7f8115b305f1a1a2ddec4f59bc08a3415359dda6
Author: Kyrylo Tkachov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97340
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324
--- Comment #9 from Kip Warner ---
Yup. Agreed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324
--- Comment #8 from Jakub Jelinek ---
Except for native supported on a subset of the architectures, no values are the
same, so this is highly target specific anyway. And yes, were it designed all
now, we'd use the same options, but some of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324
--- Comment #7 from Kip Warner ---
I understand what you mean from a maintainer's standpoint. But from a user's
standpoint, that's an inconsistency.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324
--- Comment #6 from Jakub Jelinek ---
There is no consistency.
Targets that have all of -march=, -mcpu= and -mtune=:
aarch64, arm, cris, i386 (-mcpu= deprecated and treated as -mtune=), m68k
Targets that have just -march= and -mtune=:
gcn, mips,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272
--- Comment #7 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:d4ec0a15afb7538247206aa9936071544fd860f8
commit r10-8870-gd4ec0a15afb7538247206aa9936071544fd860f8
Author: Harald Anlauf
On Okt 08 2020, korel ka via Gcc-patches wrote:
> diff --git a/libstdc++-v3/include/bits/stl_iterator.h
> b/libstdc++-v3/include/bits/stl_iterator.h
> index 2259f7c..13d5dbb 100644
> --- a/libstdc++-v3/include/bits/stl_iterator.h
> +++ b/libstdc++-v3/include/bits/stl_iterator.h
> @@ -625,8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324
--- Comment #5 from Kip Warner ---
The reason I asked is because of that inconsistency in the -mcpu usage on
targets. Thanks for clarifying.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97340
Bug ID: 97340
Summary: Spurious rejection of member variable template of
reference type
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324
--- Comment #3 from Kip Warner ---
Martin, is -mcpu deprecated for all architectures or just x86?
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)
+ : __istream_type(), _M_stringbuf(__mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97339
Bug ID: 97339
Summary: std::async sometimes prevents std::current_exception
from working properly in the terminate handler
Product: gcc
Version: 10.2.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97317
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97338
Bug ID: 97338
Summary: [nvptx] Convergence checking
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97150
--- Comment #6 from CVS Commits ---
The releases/gcc-9 branch has been updated by Kyrylo Tkachov
:
https://gcc.gnu.org/g:d5c6ea22fe6db1ee19a178941a8c7f8ff5d0538c
commit r9-8983-gd5c6ea22fe6db1ee19a178941a8c7f8ff5d0538c
Author: Kyrylo Tkachov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96313
--- Comment #8 from CVS Commits ---
The releases/gcc-9 branch has been updated by Kyrylo Tkachov
:
https://gcc.gnu.org/g:18d980d94f8d7187ce30bf23ddd365fa54189c36
commit r9-8982-g18d980d94f8d7187ce30bf23ddd365fa54189c36
Author: Kyrylo Tkachov
std::iterator considered as deprecated since C++17 and shouldn't be in use.
This patch marks std::iterator as deprecated using deprecated
attribute, and replace its usages with the required member types
inside each class.
libstdc++-v3/include/bits/ChangeLog:
stl_iterator_base_types.h: Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97337
Bug ID: 97337
Summary: new test case gcc.dg/pr97315-1.c fails with excess
errors
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
在 2020/10/8 22:56, Jason Merrill 写道:
> On 10/7/20 10:52 PM, Liu Hao via Gcc-patches wrote:
>> [Please CC me as I am not subscribed to this list.]
>
> Hmm, why isn't the mingw implementation used for all programs? That would
> avoid the bug.
>
I am afraid the libstdc++ implementation has to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #12 from Tamar Christina ---
(In reply to Martin Liška from comment #11)
> (In reply to Tamar Christina from comment #0)
> > With just -Ofast the benchmark doesn't seem to ever terminate until it is
> > eventually killed.
> >
>
>
On Mon, 2020-10-05 at 11:52 -0700, Carl Love wrote:
> Will, Segher:
>
> This patch adds support for converting to/from 128-bit integers and
> 128-bit decimal floating point formats using the new P10 instructions
> dcffixqq and dctfixqq. The new instructions are only used on P10 HW,
> otherwise
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97203
--- Comment #5 from Tom de Vries ---
FWIW, another aspect here is convergence (as usual).
Looking at the SASS code for main$_omp_fn$0$impl, I don't find evidence for the
usual divergence/convergence ops (SSY/SYNC), which might mean that the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97317
--- Comment #3 from Andrew Macleod ---
Created attachment 49331
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49331=edit
patch to calculate negative side properly
This is actually due to not handling a cast very well when the precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97335
--- Comment #3 from Martin Liška ---
One needs -flto here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #11 from Martin Liška ---
(In reply to Tamar Christina from comment #0)
> With just -Ofast the benchmark doesn't seem to ever terminate until it is
> eventually killed.
>
Can't reproduce the stuck without -flto.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97335
--- Comment #2 from Martin Liška ---
With the current master (g:3e1123e52f8eca2650efa0bc81768792d328961f) one needs
only one IPA modref transform to trigger the wrong code:
-fdbg-cnt=ipa_mod_ref:778-778
where one needs to copy the input file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97203
--- Comment #4 from Tom de Vries ---
So, I think calling functions from simd code is atm not supported for nvptx.
Stack variables in simd code are mapped on a per-thread stack rather than on
the
usual per-warp stack.
The functions are compiled
On 10/8/20 5:08 PM, Jakub Jelinek wrote:
On Thu, Oct 08, 2020 at 04:55:07PM +0200, Aldy Hernandez via Gcc-patches wrote:
Yes, for max == 0 aka [0, 0] I wanted:
1) if mini == -1, i.e. the DEFINED_VALUE_AT_ZERO == 2 VALUE is -1, return [-1,
-1]
2) if maxi == prec, i.e. DEFINED_VALUE_AT_ZERO
1 - 100 of 226 matches
Mail list logo
