[Bug tree-optimization/93131] ((a&8) == 8) && ((a&2) == 2) is not optimized to (a&(8|2)) == (8|2)
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. One executable. Writing testcases take longer than writing the original patch due to all of the combos that need to be tested (using macros to simplify things though).
[Bug c++/93033] [10 Regression] error: incorrect sharing of tree nodes
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=gcc=rev Log: PR c++/93033 - incorrect tree node sharing with array init. The split_nonconstant_init piece is the only one necessary to fix the testcase, but it occurred to me that we might as well not split when -fno-exceptions. * typeck2.c (split_nonconstant_init): Unshare non-decl. * cp-gimplify.c (cp_gimplify_init_expr): Only split if -fexceptions. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist-array9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/cp/typeck2.c
[Bug libstdc++/93147] std::tuple of empty structs with member equality operators has ambiguous equality operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93147 --- Comment #9 from Alexander Kondratskiy --- Ah, that explains everything. Thank you for clarifying.
[Bug libstdc++/93147] std::tuple of empty structs with member equality operators has ambiguous equality operator
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 subtle than > > "the compiler sees the equality operators". Could the empty-base > > optimization play a role? Common initial sequence? > > That's not surprising at all. We only use derivation for tuple elements that > are empty types, otherwise they're just data members. i.e. it *is* as simple as "the compiler sees the equality operators". If the elements are not empty, then the compiler doesn't see the operators, because name lookup doesn't find members of members, only members of bases.
[Bug libstdc++/93147] std::tuple of empty structs with member equality operators has ambiguous equality operator
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 operators". Could the empty-base > optimization play a role? Common initial sequence? That's not surprising at all. We only use derivation for tuple elements that are empty types, otherwise they're just data members.
[Bug libstdc++/93147] std::tuple of empty structs with member equality operators has ambiguous equality operator
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, then something in the frontend needs to be fixed regarding member function lookup. 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 operators". Could the empty-base optimization play a role? Common initial sequence?
[Bug c++/93149] -fno-concepts silently ignored in c++2a mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93149 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-03 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Since concepts have no runtime overhead I don't see any advantage to being able to disable them. Arguably, since the option is documented as enabling the Concepts TS, we could claim that -fno-concepts disables the TS, but leaves C++20 concepts enabled :-) A warning saying it has no effect would make sense though.
[Bug libstdc++/93147] std::tuple of empty structs with member equality operators has ambiguous equality operator
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, Tuple) { return true; }
bool example(Tuple a, Tuple b)
{
return a == b;
}
Clang does accept this, but EDG rejects it the same way as GCC:
"pr93147.cc", line 15: error: more than one operator "==" matches these
operands:
"Tuple::operator==" (ambiguous by inheritance)
operand types are: Tuple == Tuple
return a == b;
^
1 error detected in the compilation of "pr93147.cc".
[Bug libstdc++/93147] std::tuple of empty structs with member equality operators has ambiguous equality operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93147
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-01-03
Ever confirmed|0 |1
--- Comment #4 from Jonathan Wakely ---
Reduced:
struct A {
bool operator == (A) const { return true; }
};
struct B {
bool operator == (B) const { return true; }
};
struct Tuple_base : private A { };
struct Tuple_impl : Tuple_base, private B { };
struct Tuple : Tuple_impl { };
bool operator==(Tuple, Tuple) { return true; }
bool example(Tuple a, Tuple b)
{
return a == b;
}
[Bug target/93141] Missed optimization : Use of adc when checking overflow
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 addsx0, x6, x0 adcsx1, x3, x1 cincx7, x7, cs cmp x5, 16384 bne .L4 --- CUT addcs might be faster than cinc on some cores but the difference is 1 cycle vs 2 cycles plus the latency would be hidden so it might not matter in the end.
[Bug target/93141] Missed optimization : Use of adc when checking overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93141 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-03 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Jakub Jelinek --- Created attachment 47589 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47589=edit gcc10-pr93141.patch Untested patch that improves double-word __builtin_add_overflow and thus also the original testcase too. __builtin_sub_overflow is for next week.
[Bug c++/93149] New: -fno-concepts silently ignored in c++2a mode
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++
Assignee: unassigned at gcc dot gnu.org
Reporter: nathan at gcc dot gnu.org
Target Milestone: ---
In testing something out, I discovered that '-std=c++2a -fno-concepts' is
concept-enabled.
template
requires (sizeof (T) > 1)
void frob (T);
nathans@devvm2772:306>./cc1plus conc.cc -quiet -std=c++2a
nathans@devvm2772:307>./cc1plus conc.cc -quiet -std=c++2a -fno-concepts
nathans@devvm2772:308>./cc1plus conc.cc -quiet -std=c++17 -fno-concepts
conc.cc:2:10: error: expected constructor, destructor, or type conversion
before '(' token
2 | requires (sizeof (T) > 1)
| ^
I expected either:
1) a warning telling me -fno-concepts had no effect with -std=c++2a
2) concepts disabled, in a similar manner to -fno-rtti and -fno-exceptions
[Bug target/93119] [ICE] The traditional TLS support of aarch64-ilp32 target may be not perfect while enable fPIC
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 weekend to see what can be done ...
[Bug libstdc++/93147] std::tuple of empty structs with member equality operators has ambiguous equality operator
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 > comparison operators and considers them ambiguous. GCC tries to implicitly > convert `std::tuple` into `A` and `B` to call `operator ==`. Yes, there were plans to use [[unique_address]] instead, but either noone had time to implement it, or they found an issue with this plan. The difference of behavior with clang seems worth investigating though.
[Bug fortran/93148] New: Pointer-function-result as LVALUE variable – function called multiple times with copy-in/out
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 Keywords: wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: tkoenig at gcc dot gnu.org Target Milestone: --- Created attachment 47588 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47588=edit Test case – compile & run Found when looking at PR91640, cf. https://gcc.gnu.org/ml/gcc-patches/2020-01/threads.html#00070 If one uses: call foo(f()) where foo takes a nonpointer dummy argument and f returns a pointer, the pointer result is regarded as normal variable. (= gfc_is_variable == true). Unfortunately, "f()" is called twice: once for the copy in and once for the copy out. Expected: It is only called once. See attached test case.
[Bug libgcc/93145] strerror_r() and INT_MIN returns "Unknown error -18446744071562067968" (for x86_64)
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 right place to report glibc issues. Sorry for the noise. Thanks for the pointer -- have filed against glibc. Chris
[Bug libgcc/93145] strerror_r() and INT_MIN returns "Unknown error -18446744071562067968" (for x86_64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93145 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #1 from Andrew Pinski --- You want to file it against glibc; https://sourceware.org/bugzilla . glibc has the implementation of strerror_r/_itoa_word .
[Bug libstdc++/93147] std::tuple of empty structs with member equality operators has ambiguous equality operator
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
[Bug libstdc++/93147] std::tuple of empty structs with member equality operators has ambiguous equality operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93147 Andrew Pinski changed: What|Removed |Added Component|c++ |libstdc++ --- Comment #1 from Andrew Pinski --- > - This compiles fine with Clang Is that with GCC's libstdc++ or LLVM's stdc++? Both can be used and that is why I am asking.
[Bug target/93136] [10 regression] gcc.dg/vmx/ops.c and several other test break after r279772
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.
[Bug target/93005] Redundant NEON loads/stores from stack are not eliminated
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 *__P, __m128i __B)
{
*__P = __B;
}
arm_neon.h
__extension__ extern __inline void
__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
vst1q_s32 (int32_t * __a, int32x4_t __b)
{
__builtin_neon_vst1v4si ((__builtin_neon_si *) __a, __b);
}
So why is one implemented with a built-in, and the other with a pointer
dereference?
Is there a way of making the optimizer see through __builtin_neon_vst1v4si with
GIMPLE? Where would the code be implemented? Where is it implemented for other
architectures?
[Bug c++/93147] New: std::tuple of empty structs with member equality operators has ambiguous equality operator
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
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kholdstare0.0 at gmail dot com
Target Milestone: ---
The following code:
#include
struct A {
bool operator == (A) const { return true; }
};
struct B {
bool operator == (B) const { return true; }
};
using Tuple = std::tuple;
bool example(Tuple a, Tuple b)
{
return a == b;
}
Results in an error:
: In function 'bool example(Tuple, Tuple)':
:18:21: error: request for member 'operator==' is ambiguous
18 | return a == b;
| ^
:4:14: note: candidates are: 'bool A::operator==(A) const'
4 | bool operator == (A) const { return true; }
| ^~~~
:8:14: note: 'bool B::operator==(B) const'
8 | bool operator == (B) const { return true; }
| ^~~~
Compiler returned: 1
Here is the godbolt link, with the preprocessor output on the side:
https://godbolt.org/z/a4TuB3
Some things to note:
- This compiles fine with Clang
- If the structs are non-empty, this also compiles fine
- If the comparison operators are non-members this also compiles fine
- The failure is exactly the same going back all the way to gcc 4
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 comparison
operators and considers them ambiguous. GCC tries to implicitly convert
`std::tuple` into `A` and `B` to call `operator ==`.
[Bug fortran/91648] [9/10 Regression] ICE in generate_finalization_wrapper, at fortran/class.c:2009
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 from Tobias Burnus --- During resolution, one has the call tree: gfc_resolve (ns) -> resolve_types -> gfc_traverse_ns (ns, resolve_symbol) -> resolve_fl_derived -> gfc_resolve_finalizers And generate_finalization_wrapper assumes that: gcc_assert (fini->proc_tree); /* Should have been set in gfc_resolve_finalizers. */ However, for the test case, one has: #0 generate_finalization_wrapper (vtab_final=, vtab_final=, tname=0x7fffd450 "m_T", ns=, derived=) at ../../repos/gcc/gcc/fortran/class.c:2009 #1 gfc_find_derived_vtab (derived=) at ../../repos/gcc/gcc/fortran/class.c:2487 #2 0x00836611 in gfc_find_vtab (ts=0x24f98d8) at ../../repos/gcc/gcc/fortran/class.c:2865 #3 0x00885de3 in gfc_match_assignment () at ../../repos/gcc/gcc/fortran/match.c:1375 Namely, generate_finalization_wrapper is already called during parsing. Side note: "s" is called recursively – without being marked 'recursive'. Additionally, at the end of 's', s(y) is called, which calls s(y) etc. – something which will never finish ... Better variant – same ICE but avoids this problem: module m type t contains final :: s end type contains subroutine g(x) type(t) :: x class(*), allocatable :: y y = x end subroutine s(x) type(t) :: x end end
[Bug fortran/91640] [9/10 Regression] ICE: gimplification failed (contiguous expr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91640 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #4 from Thomas Koenig --- Should be rather simple to fix.
[Bug target/93136] [10 regression] gcc.dg/vmx/ops.c and several other test break after r279772
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've changed.
[Bug target/93146] C++ TLS init function not generated on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93146 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-03 CC||hubicka at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Edelsohn --- Confirmed.
[Bug target/93146] New: TLS init function not generated on AIX
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: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
Target: powerpc-ibm-aix*
SYMPTOM:
On AIX, TLS init elicits linker errors such as
TLS init fuction for thread_local_seg_handler
or
__tls_init
An example C++ program is
$ cat a.cc
#include
struct Test {std::atomic x; };
thread_local Test t;
$ cat main.cc
#include
struct Test {std::atomic x; };
extern thread_local Test t;
int main () {
return t.x.load();
}
$ g++ -std=c++14 -pthread a.cc main.cc
ld: 0711-317 ERROR: Undefined symbol: __tls_init
BACKGROUND:
AIX XCOFF symbol aliases do not function the same as ELF symbols aliases: XCOFF
generates "hard aliases" (like hard links) with only one definition and the
attributes are shared / overwritten, instead of a "symbolic" reference to the
other definition with its own attributes. Because of this
gcc/config/rs6000/xcoff.h defines:
/* This is how we tell the assembler to equate two values.
The semantic of AIX assembler's .set do not correspond to middle-end
expectat
ions.
We output aliases as alternative symbols in the front of the definition
via DECLARE_FUNCTION_NAME and DECLARE_OBJECT_NAME.
We still need to define this macro to let middle-end know that aliases are
supported.
*/
#define ASM_OUTPUT_DEF(FILE,LABEL1,LABEL2) do { } while (0)
Honza generously provided other AIX-specific code for function aliases that
generate alternative labels in front of the definition.
Because of this, GCC internals consider AIX as TARGET_SUPPORTS_ALIASES. Note
that the above macro will not output anything for an alias.
AIX also support TLS.
These two features / behaviors collide for TLS init functions. gcc/cp/decl2.c
get_tls_init_fn() and handle_tls_init() depend upon TARGET_SUPPORTS_ALIASES,
e.g.,
if (TARGET_SUPPORTS_ALIASES && TREE_PUBLIC (var))
{
tree single_init_fn = get_tls_init_fn (var);
if (single_init_fn == NULL_TREE)
continue;
cgraph_node *alias
= cgraph_node::get_create (fn)->create_same_body_alias
(single_init_fn, fn);
gcc_assert (alias != NULL);
}
Disabling TARGET_SUPPORTS_ALIASES within cp/decl2.c does not generate correct
code (it switches from a mangled TLS init function to __tls_init).
How can G++ be coerced to generate TLS init functions for AIX?
[Bug fortran/91648] [9/10 Regression] ICE in generate_finalization_wrapper, at fortran/class.c:2009
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91648 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #2 from Thomas Koenig --- Wrong bug
[Bug fortran/91648] [9/10 Regression] ICE in generate_finalization_wrapper, at fortran/class.c:2009
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91648 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED CC||tkoenig at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org
[Bug target/93141] Missed optimization : Use of adc when checking overflow
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/config/i386/i386.md 2020-01-03 17:05:51.435808734 +0100
@@ -1036,6 +1036,9 @@
(define_mode_iterator DWI [(DI "!TARGET_64BIT")
(TI "TARGET_64BIT")])
+;; SWI and DWI together.
+(define_mode_iterator SWIDWI [QI HI SI DI (TI "TARGET_64BIT")])
+
;; GET_MODE_SIZE for selected modes. As GET_MODE_SIZE is not
;; compile time constant, it is faster to use than
;; GET_MODE_SIZE (mode). For XFmode which depends on
@@ -6121,12 +6124,12 @@
(define_expand "uaddv4"
[(parallel [(set (reg:CCC FLAGS_REG)
(compare:CCC
-(plus:SWI
- (match_operand:SWI 1 "nonimmediate_operand")
- (match_operand:SWI 2 ""))
+(plus:SWIDWI
+ (match_operand:SWIDWI 1 "nonimmediate_operand")
+ (match_operand:SWIDWI 2 ""))
(match_dup 1)))
- (set (match_operand:SWI 0 "register_operand")
- (plus:SWI (match_dup 1) (match_dup 2)))])
+ (set (match_operand:SWIDWI 0 "register_operand")
+ (plus:SWIDWI (match_dup 1) (match_dup 2)))])
(set (pc) (if_then_else
(ltu (reg:CCC FLAGS_REG) (const_int 0))
(label_ref (match_operand 3))
@@ -6885,6 +6888,49 @@
[(set_attr "type" "alu")
(set_attr "mode" "SI")])
+(define_insn_and_split "*add3_doubleword_cc_overflow_1"
+ [(set (reg:CCC FLAGS_REG)
+ (compare:CCC
+ (plus:
+ (match_operand: 1 "nonimmediate_operand" "%0,0")
+ (match_operand: 2 "x86_64_hilo_general_operand" "r,o"))
+ (match_dup 1)))
+ (set (match_operand: 0 "nonimmediate_operand" "=ro,r")
+ (plus: (match_dup 1) (match_dup 2)))]
+ "ix86_binary_operator_ok (PLUS, mode, operands)"
+ "#"
+ "reload_completed"
+ [(parallel [(set (reg:CCC FLAGS_REG)
+ (compare:CCC
+(plus:DWIH (match_dup 1) (match_dup 2))
+(match_dup 1)))
+ (set (match_dup 0)
+ (plus:DWIH (match_dup 1) (match_dup 2)))])
+ (parallel [(set (reg:CCC FLAGS_REG)
+ (compare:CCC
+(zero_extend:
+ (plus:DWIH
+(plus:DWIH
+ (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0))
+ (match_dup 4))
+(match_dup 5)))
+(plus:
+ (zero_extend: (match_dup 5))
+ (ltu: (reg:CC FLAGS_REG) (const_int 0)
+ (set (match_dup 3)
+ (plus:DWIH
+(plus:DWIH (ltu:DWIH (reg:CC FLAGS_REG) (const_int 0))
+ (match_dup 4))
+(match_dup 5)))])]
+{
+ split_double_mode (mode, [0], 3, [0], [3]);
+ if (operands[2] == const0_rtx)
+{
+ emit_insn (gen_addcarry_0 (operands[3], operands[4],
operands[5]));
+ DONE;
+}
+})
+
;; x == 0 with zero flag test can be done also as x < 1U with carry flag
;; test, where the latter is preferrable if we have some carry consuming
;; instruction.
[Bug fortran/91640] [9/10 Regression] ICE: gimplification failed (contiguous expr)
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 from Tobias Burnus ---
(In reply to Richard Biener from comment #1)
> Note gimplification fails because we are evaluating in an lvalue context but
> got -_7 in the end. In the past we've hacked around Fortran oddities by
> doing tem = -_7
Doing "tem = -_7" automatically would paper about a FE bug which is surely the
wrong approach!
For this ICE, gfortran is doing a copy-in/copy-out if the argument is not known
to be contiguous (i.e. not simply contiguous). — The copy-in ("tmp = -z") is
fine.
But if it is not a variable, copying-back does not make sense ("-z = tmp").
* * *
Patch: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00070.html
[Bug c++/93033] [10 Regression] error: incorrect sharing of tree nodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93033 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/93106] [c++2a] Deleted move constructor is not selected when returning an automatic variable
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 first perform overload resolution for the copy constructor > as if it was an rvalue, which in this case fails because the move ctor is > deleted. And in that case, another overload resolution is performed, this > time considering the implicitly movable entity as lvalue, and that succeeds. > So, if copy-ellision wouldn't be performed, > not_movable::not_movable(not_movable const&) would be invoked, but in this > case copy-ellision is invoked and thus it is default constructed into the > return value object in the caller. The first overload resolution should succeed by selecting the deleted move constructors. Deleted functions are defined and are considered for overload resolution (unless otherwise specified - there are some edge cases, but not in this example).
[Bug libgcc/93145] New: strerror_r() and INT_MIN returns "Unknown error -18446744071562067968" (for x86_64)
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 Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: gcc at gmch dot uk Target Milestone: --- For unknown errors __strerror_r() does: p = _itoa_word (abs (errnum), [20], 10, 0); where abs(INT_MIN) is undefined. As it happens, on x86_64 abs(INT_MIN) returns INT_MIN, which is widened to unsigned long long int -- hence the silly result. I guess absll(errnum) would fix the error where long long int is bigger than int. Otherwise, I dunno what hoops the library should be jumping through to allow for not-2's-complement. FWIW: the man-page mentions EINVAL and ERANGE errors, but is silent on whether the GNU strerror_r() returns errors. The implementation clearly does not return any errors -- not even for buflen == 0 (with or without buf == NULL). [buf == NULL with buflen != 0 gives a SEGV -- duh.] Also FWIW: the man-page, in general, talks of known/unknown error numbers and valid/invalid error numbers, but does not say how or whether those are different. This is also true of POSIX.1 which is not a miracle of precision either. The glibc POSIX/XSI implementation clearly does not distinguish known and valid, and 0 is known -- the function returns EINVAL for unknown error numbers, as well as setting a string. (Incidentally, if EINVAL is returned that takes precedence over ERANGE, but that's also a secret.) It would be nice to have a function to map an error number to its macro-name, returning a constant string (for known) or NULL (for unknown) errors. But that's another story. Chris
[Bug c++/91369] Implement P0784R7: constexpr new
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() {
delete[] i;
}
int* i;
};
constexpr a make_a(int size) {
return {new int[size]()};
}
constexpr bool test1() {
make_a(1);
return true;
}
constexpr bool test2() {
make_a(1);
return true;
}
static_assert(test1());
static_assert(test2());
[Bug target/93141] Missed optimization : Use of adc when checking overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93141 Peter Cordes changed: What|Removed |Added CC||peter at cordes dot ca --- Comment #2 from Peter Cordes --- gcc doesn't actually *branch* unless you use an if(), it just uses cmp/sbb to do a 128-bit compare. CMP is like a SUB that only sets flags. The CF result of SBB is used as an input for ADC. https://godbolt.org/z/64C4R- of a testcase GCC also wastes a varying number of MOV instructions beyond the minimum one to make cmp/sbb work, depending on BMI2 MULX or not, and how the sum is written. u128 prod = a[i] * (unsigned __int128) b[i]; #if 1 sum += prod; //if(sum
[Bug target/93141] Missed optimization : Use of adc when checking overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93141 --- Comment #1 from Madhur Chauhan --- The source of this bug is the stackoverflow Q: https://stackoverflow.com/questions/59575408/fastest-way-to-sum-dot-product-of-vector-of-unsigned-64-bit-integers-using-192-2/59579310#59579310
[Bug ipa/92917] [10 Regression] ICE in print_all_lattices at gcc/ipa-cp.c:547 since r278016.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92917 Martin Jambor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Jambor --- Fixed with https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00060.html
[Bug ipa/92917] [10 Regression] ICE in print_all_lattices at gcc/ipa-cp.c:547 since r278016.
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=gcc=rev Log: Avoid segfault when dumping IPA-CP lattices for unoptimized functions (PR 92917) 2020-01-03 Martin Jambor PR ipa/92917 * ipa-cp.c (print_all_lattices): Skip functions without info. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-cp.c
[Bug c++/93137] [10 regression] ICE in refs_may_alias_p_2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93137 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jakub Jelinek --- I believe it is a dup. *** This bug has been marked as a duplicate of bug 93033 ***
[Bug c++/93033] [10 Regression] error: incorrect sharing of tree nodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93033 Jakub Jelinek changed: What|Removed |Added CC||s...@li-snyder.org --- Comment #10 from Jakub Jelinek --- *** Bug 93137 has been marked as a duplicate of this bug. ***
[Bug ipa/93015] [10 Regression] Segmentation fault (ipcp_store_vr_results(void))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93015 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Jambor --- Should be fixed now.
[Bug c++/93033] [10 Regression] error: incorrect sharing of tree nodes
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 from Jakub Jelinek ---
Reduced testcase from PR93137:
template
struct A {
A ();
~A ();
};
template
A operator+(const T *, A);
void
foo ()
{
A f;
struct { A g; bool h; } i[] {"" + f};
}
[Bug fortran/77371] [8/9/10 Regression][OpenACC] ICE in force_constant_size, at gimplify.c:671 (... and others)
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 "copy(.z)" – not only "copy(z)". --- a/gcc/gimplify.c +++ b/gcc/gimplify.c @@ -7311 +7311 @@ oacc_default_clause (struct gimplify_omp_ctx *ctx, tree decl, unsigned flags) - else if (AGGREGATE_TYPE_P (type)) + else if (AGGREGATE_TYPE_P (type) || omp_is_allocatable_or_ptr (decl))
[Bug c++/93137] [10 regression] ICE in refs_may_alias_p_2
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 from Jakub Jelinek ---
I'm actually getting here
pr93137.C: In function ‘void foo(const string&)’:
pr93137.C:3:6: error: incorrect sharing of tree nodes
3 | void foo (const std::string& s)
| ^~~
*D.30380
D.30380->LibSuffix = std::operator+,
std::allocator > ("/gcc/", s); [return slot optimization]
during GIMPLE pass: cfg
pr93137.C:3:6: internal compiler error: verify_gimple failed
0x158d570 verify_gimple_in_cfg(function*, bool)
../../gcc/tree-cfg.c:5445
so it looks like a dup of the other C++ tree node sharing PRs.
[Bug ipa/93144] [10 Regression] 459.GemsFDTD debug info size increase by 50% since r279563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93144 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-03 Known to work||9.2.0 Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0 --- Comment #1 from Martin Liška --- There's a longer history for -march=znver1 machine: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=4.195.4
[Bug ipa/93144] New: [10 Regression] 459.GemsFDTD debug info size increase by 50% since r279563
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: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Since the revision I see the following regression: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=289.195.4 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug c++/93046] [10 Regression] ICE in cp_gimplify_init_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93046 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 47587 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47587=edit gcc10-pr93046.patch Untested fix.
[Bug fortran/77371] [8/9/10 Regression][OpenACC] ICE in force_constant_size, at gimplify.c:671 (... and others)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77371 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #11 from Tobias Burnus --- (In reply to Gerhard Steinmetz from comment #0) > Some snippets with allocatable scalars (valid code) combined with > OpenACC. Similar issue for "pointer" instead of "allocatable". > > $ cat z1.f90 > program p >character(:), allocatable :: z >!$acc parallel >z = 'abc' >!$acc end parallel >print *, z > end ZERO-TH ISSUE (OpenACC and OpenMP): I think with 'pointer', there are additional issues: – A pointer can be undefined (garbage address) besides not associated (NULL) and associated. – Depending on implicit vs. explicit mapping, OpenMP vs. OpenACC and the spec version, the pointer target may or may not be mapped – Changing the pointer address on the device is not permitted [except intermittently] (OpenACC: "Data Structures with Pointers"; OpenMP 5.0, "map clause", p. 317, ll. 22-25) FIRST ISSUE (OpenACC only): 'firstprivate' of 'z' Pre-remark: * GCC -fopenacc: For "len=3" and "len=n" strings (dummy arg or stack alloc), OpenACC uses in the dump "map(tofrom:str [len: 3])" etc. * GCC -fopenmp uses map(tofrom: for all variants, including the test case above. GCC 10 dump shows: #pragma omp target oacc_parallel firstprivate(z) firstprivate(.z) The firstprivate is odd; I think it should also an implicit 'copy(z)' [alias "map(tofrom:" as shown in the dump]. I think (cf. second issue) firstprivate(.z) is fine as modifying the pointer target is not permitted in OpenACC (cf. "Data Structures with Pointers"). In any case, the OpenACC spec is also bad. (I have filled OpenACC Issue 254 for this.) It has: "an array or composite variable referenced in the parallel construct that does not appear in a data clause for the construct or any enclosing data construct will be treated as if it appeared in a copy clause for the parallel construct" […] "A scalar variable referenced in the parallel construct that does not appear in a data clause for the construct or any enclosing data construct will be treated as if it appeared in a firstprivate clause" Here, "z" is clearly not a scalar (see OpenACC Glossary) as it is of character type. It is an aggregated variable (which encompasses nonscalar types). – However, it is neither an array (Fortran sense as not in the glossary) nor a composite type (as defined in the glossary); in particular, it is not a 'composite variable' as the latter requires nonallocatable/nonpointer variables. Side note: pointers will have additional issues, thus a spec fix probably should distinguish between pointers and allocatables. In any case, current spec already has problems without allocatable/pointer. * * * SECOND ISSUE: 'firstprivate' of DECL_ARTIFICIAL string-length variable OpenACC *and* OpenMP: occurs with implicit mapping in OpenMP – and with an explicit "copy(z)" / "map(tofrom:" The dump shows: map(tofrom:*z [len: SAVE_EXPR <.z.5>]) map(alloc:z [pointer assign, bias: 0]) firstprivate(.z) Here ".z" is an artificial variable generated by the compiler and storing the string length of the variable. That mapping is fine unless one does (re)allocations within the target/parallel region – in particular, those which modify the string-length and, hence, the artificial variable. I am not sure whether (re)allocating within an omp target/acc parallel/acc kernels section is permitted. [If one has unified-shared memory, it will work, except for the firstprivate(.z).] *In OpenMP 5.0,* I find the restriction (2.12.5 target Construct): "An attached pointer that is associated with a given pointer target must not become associated with a different pointer target in a target region." Which implies that re-allocation is permitted for 'allocatable' (as in the test case, assuming 'omp target' instead of 'acc parallel'). In OpenACC 2.7 + 3.0, "Data Structures with Pointers", I only find: "When the device pointer target is deallocated, the pointer in device memory should be restored to the host value, so it can be safely copied back to host memory" This does not talk about re-allocation but could be read such that (re)allocation on the device is not permitted. HENCE, if I read the specs correctly, there are the following bugs: * OpenACC in GCC: should use "copy(z)" for the test case * OpenACC as spec: needs to be fixed/clarified * OpenMP in GCC: assuming (re)allocation of 'allocatables' is permitted, firstprivate(.z) should be a 'map(tofrom:'.
[Bug c++/93143] New: Multiple calls to static constexpr member function gives wrong code
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 Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: larsbj at gullik dot net Target Milestone: --- Created attachment 47586 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47586=edit Source showing problem. This is with g++ (GCC) 10.0.0 20200102 (experimental), on x86_64. Compile the attached source with: g++ -std=gnu++17 v8.cpp When running it aborts, but should not. (it is the second abort that triggers.) If the single line in v6_type() is commented out, the example program stops aborting. Seems to be some interaction compile time/run time wrt constexpr.
[Bug rtl-optimization/93142] New: Missed optimization : Use of adc when checking overflow
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 Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: madhur4127 at gmail dot com Target Milestone: --- Created attachment 47585 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47585=edit Complete code for computing dot product (same as the godbolt link) Consider emulating 192-bit integer using a 128-bit integer and a 64-bit integer. In the code sample this emulated integer is used to compute dot product of two uint64_t vectors of length N. // function to compute dot product of two vectors using u128 = unsigned __int128; const int N = 2048; uint64_t a[N], b[N]; u128 sum = 0; uint64_t overflow = 0; for(int i=0;ihttps://godbolt.org/z/ktdA4b
[Bug rtl-optimization/93141] New: Missed optimization : Use of adc when checking overflow
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 Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: madhur4127 at gmail dot com Target Milestone: --- Created attachment 47584 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47584=edit Complete code for computing dot product (same as the godbolt link) Consider emulating 192-bit integer using a 128-bit integer and a 64-bit integer. In the code sample this emulated integer is used to compute dot product of two uint64_t vectors of length N. // function to compute dot product of two vectors using u128 = unsigned __int128; const int N = 2048; uint64_t a[N], b[N]; u128 sum = 0; uint64_t overflow = 0; for(int i=0;ihttps://godbolt.org/z/ktdA4b
[Bug c++/93046] [10 Regression] ICE in cp_gimplify_init_expr
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 from Jakub Jelinek --- Indeed, started with r279576.
[Bug c++/93140] [8/9/10 Regression] Segfault in cc1plus on incorrect decltype among function args
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 ../../gcc/cp/pt.c:14930
#103 0x00b83d4b in tsubst_decl (t=,
args=, complain=0) at ../../gcc/cp/pt.c:14048
#104 0x00b7a102 in tsubst_pack_expansion (t=, args=, complain=0,
in_decl=) at ../../gcc/cp/pt.c:12749
#105 0x00ba05e8 in tsubst_copy_and_build (t=,
args=, complain=0,
in_decl=, function_p=false,
integral_constant_expression_p=false) at ../../gcc/cp/pt.c:19438
#106 0x00b8b312 in tsubst (t=,
args=, complain=0,
in_decl=) at ../../gcc/cp/pt.c:15688
#107 0x00b83f51 in tsubst_decl (t=,
args=, complain=0) at ../../gcc/cp/pt.c:14083
#108 0x00b87bc3 in tsubst (t=,
args=, complain=0,
in_decl=) at ../../gcc/cp/pt.c:14930
#109 0x00b83d4b in tsubst_decl (t=,
args=, complain=0) at ../../gcc/cp/pt.c:14048
#110 0x00b7a102 in tsubst_pack_expansion (t=, args=, complain=0,
in_decl=) at ../../gcc/cp/pt.c:12749
#111 0x00ba05e8 in tsubst_copy_and_build (t=,
args=, complain=0,
in_decl=, function_p=false,
integral_constant_expression_p=false) at ../../gcc/cp/pt.c:19438
#112 0x00b8b312 in tsubst (t=,
args=, complain=0,
in_decl=) at ../../gcc/cp/pt.c:15688
#113 0x00b83f51 in tsubst_decl (t=,
args=, complain=0) at ../../gcc/cp/pt.c:14083
#114 0x00b87bc3 in tsubst (t=,
args=, complain=0,
in_decl=) at ../../gcc/cp/pt.c:14930
#115 0x00b83d4b in tsubst_decl (t=,
args=, complain=0) at ../../gcc/cp/pt.c:14048
#116 0x00b7a102 in tsubst_pack_expansion (t=, args=, complain=0,
in_decl=) at ../../gcc/cp/pt.c:12749
#117 0x00ba05e8 in tsubst_copy_and_build (t=,
args=, complain=0,
in_decl=, function_p=false,
integral_constant_expression_p=false) at ../../gcc/cp/pt.c:19438
#118 0x00b8b312 in tsubst (t=,
args=, complain=0,
in_decl=) at ../../gcc/cp/pt.c:15688
#119 0x00b86bdb in tsubst_arg_types (arg_types=, args=, end=, complain=0,
in_decl=) at ../../gcc/cp/pt.c:14600
#120 0x00b86a43 in tsubst_arg_types (arg_types=, args=, end=, complain=0,
in_decl=) at ../../gcc/cp/pt.c:14569
#121 0x00b871fa in tsubst_function_type (t=, args=, complain=0,
in_decl=) at ../../gcc/cp/pt.c:14742
#122 0x00b8a4e2 in tsubst (t=,
args=, complain=0,
in_decl=) at ../../gcc/cp/pt.c:15495
#123 0x00b7eb2d in tsubst_function_decl (t=, args=, complain=0,
lambda_fntype=) at ../../gcc/cp/pt.c:13575
#124 0x00b83afd in tsubst_decl (t=,
args=, complain=0)
at ../../gcc/cp/pt.c:14013
#125 0x00b87bc3 in tsubst (t=,
args=, complain=0,
in_decl=) at ../../gcc/cp/pt.c:14930
#126 0x00ba61d7 in instantiate_template_1 (tmpl=, orig_args=, complain=0)
at ../../gcc/cp/pt.c:20468
#127 0x00ba68aa in instantiate_template (tmpl=, orig_args=, complain=0)
at ../../gcc/cp/pt.c:20525
#128 0x00ba7f71 in fn_type_unification (fn=, explicit_targs=,
targs=, args=0x7fffbc00, nargs=1,
return_type=, strict=DEDUCE_CALL, flags=1, convs=0x3595320,
explain_p=false, decltype_p=false) at ../../gcc/cp/pt.c:20969
#129 0x008e9a4d in add_template_candidate_real
(candidates=0x7fffbf30, tmpl=,
ctype=,
explicit_targs=, first_arg=, arglist=0x7fffea965078,
return_type=, access_path=,
conversion_path=, flags=1, obj=, strict=DEDUCE_CALL,
complain=3) at ../../gcc/cp/call.c:3394
#130 0x008e9fc0 in add_template_candidate (candidates=0x7fffbf30,
tmpl=, ctype=,
explicit_targs=, first_arg=, arglist=0x7fffea965078,
return_type=, access_path=,
conversion_path=, flags=1, strict=DEDUCE_CALL, complain=3) at
../../gcc/cp/call.c:3479
#131 0x008f27a1 in add_candidates (fns=,
first_arg=, args=0x7fffea965078, return_type=,
explicit_targs=, template_only=false, conversion_path=,
access_path=, flags=1, candidates=0x7fffbf30,
complain=3) at ../../gcc/cp/call.c:5805
#132 0x008ed261 in perform_overload_resolution (fn=, args=0x7fffea965078, candidates=0x7fffbf30,
any_viable_p=0x7fffbf2f, complain=3) at ../../gcc/cp/call.c:4481
#133 0x008ed4d8 in build_new_function_call (fn=, args=0x7fffc0d0 = {...}, complain=3)
at ../../gcc/cp/call.c:4555
#134 0x00bf02aa in finish_call_expr (fn=,
args=0x7fffc0d0 = {...}, disallow_virtual=false, koenig_p=true,
complain=3) at ../../gcc/cp/semantics.c:2669
...
[Bug c++/93140] [8/9/10 Regression] Segfault in cc1plus on incorrect decltype among function args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93140
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Milestone|--- |8.4
Summary|Segfault in cc1plus on |[8/9/10 Regression]
|incorrect decltype among|Segfault in cc1plus on
|function args |incorrect decltype among
||function args
--- Comment #4 from Jakub Jelinek ---
int
bar ()
{
return 42;
}
template
void foo (R... r, decltype (bar (r...)) x = 0) {}
int
main ()
{
foo (3);
}
ICEs starting with r140120.
Note, clang emits there a mangled name that c++filt can't demangle:
_Z3fooIJEEvDpT_DTcl3barspfL0p_EE
which llvm-cxxfilt demangles as void foo<>(decltype(bar(fp...)))
[Bug c++/92552] [10 Regression] internal compiler error: in lazily_declare_fn, at cp/method.c:3045 with -fconcepts
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-explorer/libs/rangesv3/0.10.0/include/range/v3/range/access.hpp:31,
from
/opt/compiler-explorer/libs/rangesv3/0.10.0/include/range/v3/range/concepts.hpp:30,
from
/opt/compiler-explorer/libs/rangesv3/0.10.0/include/range/v3/action/concepts.hpp:23,
from
/opt/compiler-explorer/libs/rangesv3/0.10.0/include/range/v3/range/conversion.hpp:21,
from :4:
/opt/compiler-explorer/libs/rangesv3/0.10.0/include/range/v3/iterator/basic_iterator.hpp:
In instantiation of 'struct
ranges::detail::iterator_associated_types_base_ > >, ranges::ref_view >::cursor, true>':
/opt/compiler-explorer/libs/rangesv3/0.10.0/include/range/v3/iterator/basic_iterator.hpp:492:31:
required from 'struct
ranges::basic_iterator > >, ranges::ref_view >::cursor>'
/opt/compiler-explorer/libs/rangesv3/0.10.0/include/range/v3/range/access.hpp:75:13:
required from 'constexpr auto ranges::_begin_::fn::operator()(R&&) const
requires (_safe_range) && ((has_member_begin) ||
(has_non_member_begin)) [with R =
ranges::join_with_view > >, ranges::ref_view >&]'
/opt/compiler-explorer/libs/rangesv3/0.10.0/include/range/v3/range/concepts.hpp:80:9:
required from 'ranges::detail::to_container::container_t
ranges::detail::to_container::fn::operator()(Rng&&) const requires
(input_range) && (convertible_to_cont_cont)
[with Rng = ranges::join_with_view > >, ranges::ref_view >; MetaFn = meta::id >;
ranges::detail::to_container::container_t =
std::__cxx11::basic_string]'
/opt/compiler-explorer/libs/rangesv3/0.10.0/include/range/v3/functional/invoke.hpp:134:34:
required by substitution of 'template constexpr
decltype ((F&&)(f)((Args&(ranges::invoke_fn::operator()::args))...))
ranges::invoke_fn::operator()(F&&, Args&& ...) const [with F =
ranges::detail::to_container::fn > >;
Args = {ranges::join_with_view,
std::allocator >, std::allocator, std::allocator > > > >, ranges::ref_view >}]'
/opt/compiler-explorer/libs/rangesv3/0.10.0/include/range/v3/functional/concepts.hpp:31:9:
required by substitution of 'template
concepts::return_t, typename
std::enable_if<(invocable, Rng> &&
concepts::detail::CPP_true(concepts::detail::Nil{})), void>::type>
ranges::detail::operator|(Rng&&, ranges::detail::to_container::closure > (*)(ranges::detail::to_container))
[with Rng = ranges::join_with_view > >, ranges::ref_view >; MetaFn = meta::id >]'
:11:19: required from here
/opt/compiler-explorer/libs/rangesv3/0.10.0/include/range/v3/iterator/basic_iterator.hpp:456:23:
internal compiler error: in lazily_declare_fn, at cp/method.c:3066
456 | Cur>::readable_iterator_associated_types_base;
| ^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug c++/92552] [10 Regression] internal compiler error: in lazily_declare_fn, at cp/method.c:3045 with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92552
Tony E Lewis changed:
What|Removed |Added
CC||TonyELewis at hotmail dot com
--- Comment #3 from Tony E Lewis ---
I've seen an ICE which looks likely to be a duplicate of this one. I'll put it
here so it can be retested when this one is fixed to confirm it's also fixed.
My ICE can be seen here: https://godbolt.org/z/R6MgH9
It involves compiling the following code with GCC trunk (20200102) with
`-std=c++2a` with range-v3 0.10.0.
#include
#include
#include
#include
auto f() {
const std::vector the_strings = { "a", "b" };
return the_strings
| ranges::views::join( "," )
| ranges::to;
}
I can reduce this testcase if its ICE persists after the original ICE is fixed.
[Bug c++/93140] Segfault in cc1plus on incorrect decltype among function args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93140 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Status|WAITING |NEW CC||jason at gcc dot gnu.org --- Comment #3 from Martin Liška --- Good, then it's likely ICE on valid code. Fails with at least GCC 4.8.0.
[Bug debug/93122] ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1668
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-asynchronous-unwind-tables, it doesn't > > ICE, but just emit wrong-code, the stack clash protection code expects r12 > > to be r1 + stack offset, but it is not initialized to anything at all. > > The bug seems to be that add3 expander uses reg_or_add_cint_operand > > predicate for the last operand and if that isn't satisfied, gen_add3_insn > > simply doesn't emit anything. > > Yeah, gen_add3_insn needs to be fixed; it shouldn't silently generate bad > code. I don't think there is anything wrong on gen_add3_insn, like many other expander functions e.g. for optabs that can FAIL (or in this particular case also fail because of unmatched predicates) it signals to the caller a failure through returning NULL and it is up to the caller to handle it. So, rs6000-logue.c could also just gen_add3_insn and if it returns NULL, fall back to what it emits in the else block. > > On top of that, I think we want to use > > add_operand as before too, because otherwise gen_add3_insn can emit multiple > > instructions and in that case we really need to describe the effect to > > dwarf2frame.c properly. > > Does that not happen automatically here? No. First of all, the caller here marks just a single instruction with RTX_FRAME_RELATED_P, so if gen_add3_insn emits e.g. two instructions, it will mark the last instruction that way. That wouldn't be necessarily wrong, but in that case dwarf2cfi.c needs to be able to understand what the instruction does or it needs e.g. REG_FRAME_RELATED_EXPR note (or some other CFI note) that will tell dwarf2cfi.c what the instruction does in a way that it can understand the effects of that for unwind info. So, either we do what the patch does, or e.g. without any predicates try to gen_add3_insn, if it succeeds and returns more than one insn, force REG_FRAME_RELATED_EXPR to the last insn, and if it returns NULL, do what we do ATM in the else block.
[Bug tree-optimization/93134] [graphite] ICE: Segmentation fault in ISL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93134 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-03 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed with current trunk and isl-0.22. Apparently, isl-0.20 is fine. @Richi: Can you please take a look? There's updated isl: https://build.opensuse.org/package/show/home:marxin:branches:devel:libraries:c_c++/isl
[Bug c++/93140] Segfault in cc1plus on incorrect decltype among function args
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 that:
int Bar(){return 42;}
At least this way it compiles on clang. gcc fails either way.
[Bug c++/93140] Segfault in cc1plus on incorrect decltype among function args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93140 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-01-03 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Is the code snippet invalid, right?
[Bug c++/93046] [10 Regression] ICE in cp_gimplify_init_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93046 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-03 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Known to work||9.2.0 Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0 --- Comment #1 from Martin Liška --- Confirmed.
[Bug c++/93137] [10 regression] ICE in refs_may_alias_p_2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93137 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||9.2.0 Keywords||ice-on-valid-code Last reconfirmed||2020-01-03 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |10.0 Known to fail||10.0 --- Comment #1 from Martin Liška --- Confirmed, started with r279576.
[Bug target/93119] [ICE] The traditional TLS support of aarch64-ilp32 target may be not perfect while enable fPIC
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..dd10ec5 100644
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ -6725,7 +6725,7 @@
> [(parallel [(set (match_operand 0 "register_operand")
>(call (mem:DI (match_dup 2)) (const_int 1)))
> (unspec:DI [(const_int 0)] UNSPEC_CALLEE_ABI)
> -(unspec:DI [(match_operand:PTR 1 "aarch64_valid_symref")]
> UNSPEC_GOTSMALLTLS)
> +(unspec:DI [(match_operand:P 1 "aarch64_valid_symref")]
> UNSPEC_GOTSMALLTLS)
> (clobber (reg:DI LR_REGNUM))])]
> ""
> {
> @@ -6736,7 +6736,7 @@
>[(set (match_operand 0 "register_operand" "")
> (call (mem:DI (match_operand:DI 2 "" "")) (const_int 1)))
> (unspec:DI [(const_int 0)] UNSPEC_CALLEE_ABI)
> - (unspec:DI [(match_operand:PTR 1 "aarch64_valid_symref" "S")]
> UNSPEC_GOTSMALLTLS)
> + (unspec:DI [(match_operand:P 1 "aarch64_valid_symref" "S")]
> UNSPEC_GOTSMALLTLS)
> (clobber (reg:DI LR_REGNUM))
>]
>""
I don't think that's right either. These are supposed to be machine addresses,
not C pointers.
[Bug c++/93140] New: Segfault in cc1plus on incorrect decltype among function args
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 Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc at lxlz dot space Target Milestone: --- Created attachment 47583 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47583=edit mcve Failure happens when variadic template function args used inside decltype. Minimal example is in attachment. Failure happens whether function Bar declared or not.
[Bug preprocessor/55820] cpp: unterminated argument list invoking macro "BAR" for #include in macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55820 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #4 from Jakub Jelinek --- See e.g. ISO C99, 6.10.3/11, last sentence: "If there are sequences of preprocessing tokens within the list of arguments that would otherwise act as preprocessing directives, the behavior is undefined." Similarly for C++, see e.g. http://eel.is/c++draft/cpp.replace#11 So, the compiler can do anything with it.
[Bug target/93089] Force mprefer-vector-width=512 in 'e' simd clones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93089 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug target/93110] [10 Regression] grub-2.04/grub-core/lib/division.c:28:1: internal compiler error: in extract_insn, at recog.c:2294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93110 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug target/93089] Force mprefer-vector-width=512 in 'e' simd clones
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=gcc=rev Log: PR target/93089 * config/i386/i386-options.c (ix86_simd_clone_adjust): If TARGET_PREFER_AVX128, use prefer-vector-width=256 for 'c' and 'd' simd clones. If TARGET_PREFER_AVX256, use prefer-vector-width=512 for 'e' simd clones. * gcc.target/i386/pr93089-2.c: New test. * gcc.target/i386/pr93089-3.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr93089-2.c trunk/gcc/testsuite/gcc.target/i386/pr93089-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-options.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/93084] [10 regression] Infinite loop in ipa-cp when building clang with LTO+PGO
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.
[Bug target/93089] Force mprefer-vector-width=512 in 'e' simd clones
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=gcc=rev Log: PR target/93089 * config/i386/i386.opt (x_prefer_vector_width_type): Remove TargetSave entry. (mprefer-vector-width=): Add Save. * config/i386/i386-options.c (ix86_target_string): Add PVW argument, print -mprefer-vector-width= if non-zero. Fix up -mfpmath= comment. (ix86_debug_options, ix86_function_specific_print): Adjust ix86_target_string callers. (ix86_valid_target_attribute_inner_p): Handle prefer-vector-width=. (ix86_valid_target_attribute_tree): Likewise. * config/i386/i386-options.h (ix86_target_string): Add PVW argument. * config/i386/i386-expand.c (ix86_expand_builtin): Adjust ix86_target_string caller. * gcc.target/i386/pr93089-1.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr93089-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-expand.c trunk/gcc/config/i386/i386-options.c trunk/gcc/config/i386/i386-options.h trunk/gcc/config/i386/i386.opt trunk/gcc/testsuite/ChangeLog
[Bug target/93110] [10 Regression] grub-2.04/grub-core/lib/division.c:28:1: internal compiler error: in extract_insn, at recog.c:2294
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=gcc=rev Log: PR target/93110 * config/i386/i386.md (abs2): Use expand_simple_binop instead of emitting ASHIFTRT, XOR and MINUS by hand. Use gen_int_mode with QImode instead of gen_int_shift_amount + convert_modes. * gcc.dg/torture/pr93110.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr93110.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug c++/93138] [10 regression] elaborated type specifier visibility check problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93138 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 47582 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47582=edit gcc10-pr93138.patch Untested fix.
[Bug fortran/72715] [OpenACC] ICE in gfc_trans_omp_do, at fortran/trans-openmp.c:3164
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72715
Tobias Burnus changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--- |FIXED
--- Comment #7 from Tobias Burnus ---
(In reply to anlauf from comment #6)
> Code is still rejected with current 10-trunk:
>
> 4 | do concurrent (i=1:3)
> | 1
> Error: !$ACC LOOP cannot be a DO CONCURRENT loop at (1)
In OpenMP up to 5.0 and TR8 (= draft 5.1), DO CONCURRENT is an unsupported
Fortran 2008 feature ("unspecified behaviour", cf. "1.7 Normative
References").
The reason is that DO CONCURRENT can become rather complex due to MASK etc.,
cf. PR 60127 comment 3 )
In OpenACC, 2.7 only supports Fortran 2003 (see "1.6. References"), which does
not have "do concurrent". And while OpenACC 3.0 does support Fortran 2008, it
also lists "DO CONCURRENT" as unspecified behaviour.
Since r239845 (gomp-4_0-branch) and r268875 (for GCC 9 trunk), the ICE is gone
and has been replaced by an error message.
I believe the current implementation in GCC is fine – and as the ICE has been
fixed, this PR can be closed as: FIXED.
[Bug fortran/89047] [OpenACC] ICE in mark_scope_block_unused, at tree-ssa-live.c:391
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89047 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Tobias Burnus --- (In reply to G. Steinmetz from comment #0) > With option -fopenacc, down to at least version 5 : > real function f() >!$acc update device (f) > end This now compiles and the dump (-fdump-tree-omplower) looks fine: .omp_data_arr.1.__result_p = &__result_f; #pragma omp target oacc_update map(force_to:__result_f [len: 4]) Namely, the result variable "f" (internally: "__result_f") is used. Close as FIXED – even without knowing which commit it did fix. [I have not added it as test case, though one could argue, one should.]
[Bug rtl-optimization/93088] [10 Regression] Compile time hog on gcc/testsuite/gcc.target/i386/pr56348.c w/ -O3 -funroll-loops -fno-tree-dominator-opts -fno-tree-vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93088 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #3 from Jakub Jelinek --- Fixed on the trunk, latent on branches.
[Bug rtl-optimization/93088] [10 Regression] Compile time hog on gcc/testsuite/gcc.target/i386/pr56348.c w/ -O3 -funroll-loops -fno-tree-dominator-opts -fno-tree-vrp
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=gcc=rev Log: PR rtl-optimization/93088 * loop-iv.c (find_single_def_src): Punt after looking through 128 reg copies for regs with single definitions. Move definitions to first uses. * gcc.target/i386/pr93088.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr93088.c Modified: trunk/gcc/ChangeLog trunk/gcc/loop-iv.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/92994] [10 Regression] ICE on invalid in gfc_get_class_from_expr, at fortran/trans-expr.c:486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92994 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Tobias Burnus --- Should now be FIXED on the GCC 10 trunk. Thanks for all the testcases!
[Bug testsuite/93139] new test case gfortran.dg/implied_shape_5.f90 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93139 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tobias Burnus --- (In reply to Tobias Burnus from comment #1) > UNRESOLVED: gfortran.dg/implied_shape_5.f90 -O0 compilation failed to > produce executable > fixed by the commit r279849 > cf. https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00044.html Assuming that was the issue and it has been fixed by the commit, close as FIXED – please re-open if there is still an issue.
[Bug fortran/92994] [10 Regression] ICE on invalid in gfc_get_class_from_expr, at fortran/trans-expr.c:486
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=gcc=rev Log: Fortran] PR 92994 – add more ASSOCIATE checks PR fortran/92994 * primary.c (gfc_match_rvalue): Add some flavor checks gfc_matching_procptr_assignment. * resolve.c (resolve_assoc_var): Add more checks for invalid targets. PR fortran/92994 * gfortran.dg/associate_50.f90: Update dg-error. * gfortran.dg/associate_51.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/associate_51.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/associate_50.f90
[Bug testsuite/93139] new test case gfortran.dg/implied_shape_5.f90 fails
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 been fixed by the commit r279849 – cf. https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00044.html
