https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93139
--- Comment #1 from Tobias Burnus ---
Sorry, I do not see any FAILs in your description – if you mean:
UNRESOLVED: gfortran.dg/implied_shape_5.f90 -O0 compilation failed to
produce executable
please state so. If this is the issue, it has bee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92994
--- Comment #3 from Tobias Burnus ---
Author: burnus
Date: Fri Jan 3 08:08:30 2020
New Revision: 279853
URL: https://gcc.gnu.org/viewcvs?rev=279853&root=gcc&view=rev
Log:
Fortran] PR 92994 – add more ASSOCIATE checks
PR fortran/92994
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93139
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92994
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93088
--- Comment #2 from Jakub Jelinek ---
Author: jakub
Date: Fri Jan 3 09:10:13 2020
New Revision: 279854
URL: https://gcc.gnu.org/viewcvs?rev=279854&root=gcc&view=rev
Log:
PR rtl-optimization/93088
* loop-iv.c (find_single_def_src
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93088
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89047
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72715
Tobias Burnus changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93138
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93110
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Fri Jan 3 10:11:17 2020
New Revision: 279855
URL: https://gcc.gnu.org/viewcvs?rev=279855&root=gcc&view=rev
Log:
PR target/93110
* config/i386/i386.md (abs2): Use expand_s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93089
--- Comment #1 from Jakub Jelinek ---
Author: jakub
Date: Fri Jan 3 10:12:31 2020
New Revision: 279856
URL: https://gcc.gnu.org/viewcvs?rev=279856&root=gcc&view=rev
Log:
PR target/93089
* config/i386/i386.opt (x_prefer_vector_wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93084
--- Comment #12 from fxue at gcc dot gnu.org ---
Identified the cause, it's my bug, will give a fix soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93089
--- Comment #2 from Jakub Jelinek ---
Author: jakub
Date: Fri Jan 3 10:14:03 2020
New Revision: 279857
URL: https://gcc.gnu.org/viewcvs?rev=279857&root=gcc&view=rev
Log:
PR target/93089
* config/i386/i386-options.c (ix86_simd_cl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93110
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93089
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55820
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93140
Bug ID: 93140
Summary: Segfault in cc1plus on incorrect decltype among
function args
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93119
--- Comment #3 from Richard Earnshaw ---
(In reply to Andrew Pinski from comment #2)
> Simplier patch, change PTR to P instead. Mine then.
>
> That is:
> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> index f114f85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93137
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93046
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93140
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93140
--- Comment #2 from Denis Sheremet ---
(In reply to Martin Liška from comment #1)
> Is the code snippet invalid, right?
It was invalid on real-life example I caught, but it could be valid if `Bar`
function is defined and takes no arguments, like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93134
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93122
--- Comment #4 from Jakub Jelinek ---
(In reply to Segher Boessenkool from comment #2)
> (In reply to Jakub Jelinek from comment #1)
> > Created attachment 47581 [details]
> > gcc10-pr93122.patch
> >
> > Untested fix. With additional -fno-async
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93140
Martin Liška changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|WAIT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92552
Tony E Lewis changed:
What|Removed |Added
CC||TonyELewis at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92552
--- Comment #4 from Tony E Lewis ---
Sorry - forgot to include the compiler output...
In file included from
/opt/compiler-explorer/libs/rangesv3/0.10.0/include/range/v3/iterator/reverse_iterator.hpp:20,
from
/opt/compiler-explo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93140
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Milest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93140
--- Comment #5 from Jakub Jelinek ---
Seems mutual infinite recursion:
...
#101 0x00b83f51 in tsubst_decl (t=,
args=, complain=0) at ../../gcc/cp/pt.c:14083
#102 0x00b87bc3 in tsubst (t=,
args=, complain=0,
in_decl=) at ../..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93046
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93141
Bug ID: 93141
Summary: Missed optimization : Use of adc when checking
overflow
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93142
Bug ID: 93142
Summary: Missed optimization : Use of adc when checking
overflow
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77371
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93143
Bug ID: 93143
Summary: Multiple calls to static constexpr member function
gives wrong code
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93046
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93144
Bug ID: 93144
Summary: [10 Regression] 459.GemsFDTD debug info size increase
by 50% since r279563
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93144
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93137
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77371
--- Comment #12 from Tobias Burnus ---
[OpenACC]
The following patch fixes the "firstprivate(z)" issue – but it also assumes
that a pointer variable is not undefined (only null/not associated or
associated is fine); interestingly, it also yields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93033
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93015
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93033
Jakub Jelinek changed:
What|Removed |Added
CC||s...@li-snyder.org
--- Comment #10 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93137
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92917
--- Comment #2 from Martin Jambor ---
Author: jamborm
Date: Fri Jan 3 13:52:38 2020
New Revision: 279859
URL: https://gcc.gnu.org/viewcvs?rev=279859&root=gcc&view=rev
Log:
Avoid segfault when dumping IPA-CP lattices for unoptimized functions (P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92917
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93141
--- Comment #1 from Madhur Chauhan ---
The source of this bug is the stackoverflow Q&A:
https://stackoverflow.com/questions/59575408/fastest-way-to-sum-dot-product-of-vector-of-unsigned-64-bit-integers-using-192-2/59579310#59579310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93141
Peter Cordes changed:
What|Removed |Added
CC||peter at cordes dot ca
--- Comment #2 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91369
--- Comment #25 from Toni Neubert ---
I get: "deallocation of already deallocated storage" for test2() but compiling
just test1() or test2() is just fine.
struct a {
constexpr a(int* i) : i{i} {
}
constexpr ~a() {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93145
Bug ID: 93145
Summary: strerror_r() and INT_MIN returns "Unknown error
-18446744071562067968" (for x86_64)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93106
--- Comment #2 from Yunrui Wang ---
(In reply to Jakub Jelinek from comment #1)
> What you cite doesn't say anything that would make the testcase invalid.
> The standard says that for an implicitly movable entity seen in return
> statement shall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93033
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91640
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93141
--- Comment #3 from Jakub Jelinek ---
Untested fix, though this is just about double-word uaddv4, would be good to
handle double-word usubv4, addv4 and subv4 similarly.
--- gcc/config/i386/i386.md.jj 2020-01-03 11:10:43.839511446 +0100
+++ gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91648
Thomas Koenig changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91648
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|tkoenig at gcc do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93146
Bug ID: 93146
Summary: TLS init function not generated on AIX
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93146
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93136
--- Comment #2 from Peter Bergner ---
So the vmx/ops.c test just needs -flax-vector-conversions to quiet the
warnings.
The vsx-vector-6-p*.c tests actually have some differences in the number of
xxand, etc. insn counts. I'll find out why they'v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91640
Thomas Koenig changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91648
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93147
Bug ID: 93147
Summary: std::tuple of empty structs with member equality
operators has ambiguous equality operator
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93005
--- Comment #3 from Joel Holdsworth ---
Interesting. Comparing the implementation of _mm_store_si128 to vst1q_s32:
emminitrin.h
extern __inline void __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_store_si128 (__m128i *__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93136
--- Comment #3 from Peter Bergner ---
So the vsx-vector-6.p*.c FAILs are due to sloppy insn counting in the test
cases. I have a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93147
Andrew Pinski changed:
What|Removed |Added
Component|c++ |libstdc++
--- Comment #1 from Andrew Pin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93147
--- Comment #2 from Alexander Kondratskiy ---
Hi, it compiles fine with both.
See godbolt link for Clang using GCC's libstdc++ : https://godbolt.org/z/iFHemn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93145
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93145
--- Comment #2 from Chris Hall ---
(In reply to Andrew Pinski from comment #1)
> You want to file it against glibc; https://sourceware.org/bugzilla .
> glibc has the implementation of strerror_r/_itoa_word .
Ooops. I thought this would be the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93148
Bug ID: 93148
Summary: Pointer-function-result as LVALUE variable – function
called multiple times with copy-in/out
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93147
--- Comment #3 from Marc Glisse ---
(In reply to Alexander Kondratskiy from comment #0)
> My suspicion is that tuple indirectly inherits the types `A` and `B`, and
> even though it may be private inheritance, the compiler still finds both
> compa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93119
--- Comment #4 from Andrew Pinski ---
(In reply to Richard Earnshaw from comment #3)
> I don't think that's right either. These are supposed to be machine
> addresses, not C pointers.
HMm, you might be right. I will take a look over the weeke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93149
Bug ID: 93149
Summary: -fno-concepts silently ignored in c++2a mode
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93141
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93141
--- Comment #5 from Andrew Pinski ---
Just for reference here is aarch64 assembly for the loop:
.L4:
ldr x4, [x9, x5]
ldr x3, [x8, x5]
add x5, x5, 8
mul x6, x4, x3
umulh x3, x4, x3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93147
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93147
--- Comment #5 from Jonathan Wakely ---
Further reduced:
struct A {
bool operator == (A) const { return true; }
};
struct B {
bool operator == (B) const { return true; }
};
struct Tuple : private A, private B { };
bool operator==(Tuple, T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93149
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93147
--- Comment #6 from Alexander Kondratskiy ---
Interesting. Some thoughts I had -
- If this is the correct behavior given the C++ standard, then that means the
tuple implementation in the library has to be fixed.
- If this is incorrect behavior,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93147
--- Comment #7 from Jonathan Wakely ---
(In reply to Alexander Kondratskiy from comment #6)
> What's strange here is that if one
> of the structs isn't empty, the problem goes away - it's more subtle than
> "the compiler sees the equality operato
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93147
--- Comment #8 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Alexander Kondratskiy from comment #6)
> > What's strange here is that if one
> > of the structs isn't empty, the problem goes away - it's more s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93147
--- Comment #9 from Alexander Kondratskiy ---
Ah, that explains everything. Thank you for clarifying.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93033
--- Comment #11 from Jason Merrill ---
Author: jason
Date: Fri Jan 3 22:10:56 2020
New Revision: 279871
URL: https://gcc.gnu.org/viewcvs?rev=279871&root=gcc&view=rev
Log:
PR c++/93033 - incorrect tree node sharing with array init.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93131
--- Comment #13 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #12)
> Otherwise it LGTM, so please post it this week, I'd really like to see it in
> GCC 10.
I writing the testcases right now. There will be at least 25 of them.
82 matches
Mail list logo
