[Bug libstdc++/80654] is_trivially_copy_constructible fails with compiler error with vector of uncopyable objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80654
--- Comment #9 from Frank Heckenbach ---
Found another possible workaround: "Lie" to the compiler (though is it lying
when you're actually telling it the truth? ;) by specializing
std::is_trivially_copy_constructible like this (of course, one needs to repeat
it for all affected types, e.g. other containers and other non-copyable value
types):
namespace std
{
template struct
is_trivially_copy_constructible>>: false_type {
};
}
I guess it's totally illegal to put such a specialization into std, but
realistically, can anything bad happen, seeing that it just injects a correct
answer where the default is buggy?
[Bug libstdc++/80654] is_trivially_copy_constructible fails with compiler error with vector of uncopyable objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80654 --- Comment #8 from Frank Heckenbach --- (In reply to Ville Voutilainen from comment #7) > That's not a bug. You need to make the copy constructor of s conditionally > deleted depending on whether T is copyconstructible. The copy constructor of std::vector doesn't seem to do that either (bits/stl_vector.h:326 in 7.3.0) unless I'm missing something. Is that what Daniel Krügler meant by "not SFINAE-friendly"? But he also wrote: "This is a QoI issue but not a violation of the requirements of the standard.", so I'm confused now.
[Bug libstdc++/80654] is_trivially_copy_constructible fails with compiler error with vector of uncopyable objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80654 --- Comment #7 from Ville Voutilainen --- That's not a bug. You need to make the copy constructor of s conditionally deleted depending on whether T is copyconstructible. Otherwise the trait will result in true but the code will not compile due to an ill-formed definition of the copy constructor of s, and you'll get the same answer on every C++ compiler.
[Bug libstdc++/80654] is_trivially_copy_constructible fails with compiler error with vector of uncopyable objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80654
--- Comment #6 from Frank Heckenbach ---
Tried to use a self-written (simple) container as a stop-gap, but it also fell
prey to this bug. Daniel Krügler wrote: "std::vector's copy constructor is not
SFINAE-friendly and causes std::is_copy_constructible to evaluate to true
regradless of it's element type." The same seems to be true for my container.
Here's a very reduced example that shows the bug:
#include
struct MoveOnly
{
MoveOnly (MoveOnly &&) = default;
};
template struct s
{
T v;
s (const s &a): v (a.v) { }
};
using T = s ;
int main ()
{
static_assert (!std::is_copy_constructible ::value, "bug");
T *a, b (*a); // correct error here shows T is not copy-constructible
}
So I guess "not SFINAE-friendly" means that the copy constructor is declared
unconditionally, even if it can't be instantiated due to T not being copyable,
right? Does this mean I need to endow my copy constructor with enable_if (with
all the ugliness that brings), or are there better workarounds (until the
bugfix makes it into a release)?
[Bug libstdc++/80654] is_trivially_copy_constructible fails with compiler error with vector of uncopyable objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80654 Frank Heckenbach changed: What|Removed |Added CC||f.heckenb...@fh-soft.de --- Comment #5 from Frank Heckenbach --- Hit the same bug. It also seems to affect std::deque, std::list, std::forward_list, std::set, std::unordered_set, std::map, std::unordered_map, std::multiset, std::unordered_multiset, std::multimap, std::unordered_multimap, so apparently all standard library containers. Mentioning in case the fix affects the implementation of std::vector.
[Bug tree-optimization/85143] Loop limit prevents (auto)vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85143 --- Comment #5 from Marc Glisse --- The test becomes _1 = n_15(D) <= i_46; _2 = i_46 > 1336; _3 = _1 | _2; However, in match.pd, we only handle the AND case. The corresponding IOR transformation should be handled similarly.
[Bug libgcc/84292] __sync_add_and_fetch returns the old value instead of the new value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84292 Andreas Tobler changed: What|Removed |Added Last reconfirmed|2018-02-08 00:00:00 |2018-4-1 --- Comment #3 from Andreas Tobler --- I could reproduce the issue and I can confirm that the attached patch fixes the issue. Once the long awaited gcc-8.x gets released I'll commit the fix to all active branches and I'll take care that we update the FreeBSD ports tree with a fix for all gcc versions we (FreeBSD) actively support. Thanks a lot and sorry for the delay. It took a while to get my arm board back to live and it took also a while to build a native gcc on it.
[Bug target/85075] powerpc: ICE in iszero testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85075 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #2 from Segher Boessenkool --- __float128 is "g" (long double is "e").
[Bug c++/84768] [7/8 Regression] ICE with failed class template argument deduction because of invalid template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84768
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle
dot com
--- Comment #3 from Paolo Carlini ---
Something as straightforward as the below avoids the ICE and error recovery is
good. I'll see if I can figure out something better:
Index: pt.c
===
--- pt.c(revision 258972)
+++ pt.c(working copy)
@@ -26003,6 +26003,12 @@ build_deduction_guide (tree ctor, tree outer_args,
unsigned level = 1;
tree oldelt = TREE_VEC_ELT (ftparms, i);
tree olddecl = TREE_VALUE (oldelt);
+ if (olddecl == error_mark_node)
+ {
+ current_template_parms = save_parms;
+ --processing_template_decl;
+ return error_mark_node;
+ }
tree newdecl = rewrite_template_parm (olddecl, index, level,
tsubst_args, complain);
tree newdef = tsubst_template_arg (TREE_PURPOSE (oldelt),
@@ -26153,6 +26159,8 @@ do_class_deduction (tree ptype, tree tmpl, tree in
for (ovl_iterator iter (CLASSTYPE_CONSTRUCTORS (type)); iter; ++iter)
{
tree guide = build_deduction_guide (*iter, outer_args, complain);
+ if (guide == error_mark_node)
+ return error_mark_node;
if ((flags & LOOKUP_ONLYCONVERTING)
&& DECL_NONCONVERTING_P (STRIP_TEMPLATE (guide)))
elided = true;
[Bug fortran/85138] [8 regression] ICE with generic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85138 --- Comment #6 from Dominique d'Humieres --- The following variant gives the same ICE module fox_m_fsys_format interface mylen module procedure str_real_sp_len, str_real_sp_fmt_len end interface contains pure function str_real_sp_fmt_len(x, fmt) result(n) real, intent(in) :: x character(len=*), intent(in) :: fmt if (.not.checkFmt()) then endif end function str_real_sp_fmt_len pure function str_real_sp_len(x) result(n) real, intent(in) :: x n = mylen(x, "") end function str_real_sp_len function str_real_dp_matrix(xa) result(s) real, intent(in) :: xa character(len=mylen(xa)) :: s end function str_real_dp_matrix end module fox_m_fsys_format
[Bug fortran/85150] internal compiler error for module with illegal non-constant pointer initialization designator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85150 --- Comment #4 from kargl at gcc dot gnu.org --- (In reply to Nathan T. Weeks from comment #0) > The following module code results in an internal compiler error with > gfortran 7.3.0: > > == > $ cat mod_test.f90 > module mod_test >implicit none >integer, target :: buf(2) >integer :: buf_i = 1 >integer, pointer :: buf_ptr => buf(buf_i) ! invalid > end module mod_test > > C461 (R443) The designator shall designate a nonallocatable variable > that has the TARGET and SAVE attributes and does not have a vector > subscript. Every subscript, section subscript, substring starting > point, and substring ending point in designator shall be a constant > expression. Oddly, someone added code to check for only a portion of the constraint in expr.c(gfc_check_assign_symbol). At line 4046, we find /* F08:C461. Additional checks for pointer initialization. */ In fact it only checks for TARGET and SAVE. A little sleuthing shows the code came into the tree with r163356.
[Bug c++/71504] bogus error: accessing value through a glvalue in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71504
--- Comment #6 from Will ---
A simpler example exhibiting this bogus error; an innocent, idiomatic,
pedantic, platonic pair of nested range-for loops iterating a 2D array:
g++ prog.cc -Wall -Wextra -std=c++14 -pedantic-errors
#include
template
constexpr auto sum(A const& a)
{
int tot = 0;
for (auto& row : a)
for (auto elem : row)
tot += elem;
return tot;
}
constexpr int const a22[2][2] = {{1,2},{3,4}};
static_assert( sum(a22) == 10, "badsum");
prog.cc:17:18: in 'constexpr' expansion of 'sum(a22)'
prog.cc:17:24: error: accessing value of 'a22' through a 'const int' glvalue in
a constant expression
[Bug middle-end/85090] [8 Regression] wrong code with -O2 -fno-tree-dominator-opts -mavx512f -fira-algorithm=priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85090 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Sun Apr 1 06:05:01 2018 New Revision: 258994 URL: https://gcc.gnu.org/viewcvs?rev=258994&root=gcc&view=rev Log: PR middle-end/85090 * config/i386/sse.md (V): Add V64QI and V32HI for TARGET_AVX512F. (V_128_256): New mode iterator. (*avx512dq_vextract64x2_1 splitter): New define_split. (*avx512f_vextract32x4_1 splitter): Likewise. (xop_pcmov_): Use V_128_256 mode iterator instead of V. * config/i386/i386.c (ix86_expand_vector_set): Improve V32HImode and V64QImode expansion for !TARGET_AVX512BW && TARGET_AVX512F. * gcc.target/i386/avx512f-pr85090-1.c: New test. * gcc.target/i386/avx512f-pr85090-2.c: New test. * gcc.target/i386/avx512f-pr85090-3.c: New test. * gcc.target/i386/avx512bw-pr85090-2.c: New test. * gcc.target/i386/avx512bw-pr85090-3.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/avx512bw-pr85090-2.c trunk/gcc/testsuite/gcc.target/i386/avx512bw-pr85090-3.c trunk/gcc/testsuite/gcc.target/i386/avx512f-pr85090-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-pr85090-2.c trunk/gcc/testsuite/gcc.target/i386/avx512f-pr85090-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/85154] New: [8 regression] gcc.dg/vect/vect-95.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85154 Bug ID: 85154 Summary: [8 regression] gcc.dg/vect/vect-95.c fail Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: andrey.y.guskov at intel dot com Target Milestone: --- r258872 triggers this: spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/ /source/gcc/testsuite/gcc.dg/vect/vect-95.c -B/work/x86_64-pc-linux-gnu/./libmpx/ -B/work/x86_64-pc-linux-gnu/./libmpx/mpxrt -L/work/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs -B/work/x86_64-pc-linux-gnu/./libmpx/ -B/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap -L/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs -fno-diagnostics-show-caret -fdiagnostics-color=never -msse2 -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -lm -o ./vect-95.exe PASS: gcc.dg/vect/vect-95.c (test for excess errors) spawn [open ...] PASS: gcc.dg/vect/vect-95.c execution test PASS: gcc.dg/vect/vect-95.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/vect-95.c scan-tree-dump-times vect "Alignment of access forced using peeling" 0 Option set: -with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared --enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl --enable-languages=c,c++,fortran,jit,lto -with-arch=silvermont --with-cpu=silvermont
[Bug fortran/85138] [8 regression] ICE with generic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85138 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to Paul Thomas from comment #3) > (In reply to Dominique d'Humieres from comment #2) > > Up to revision r258235 (2018-03-04) compiling the test gave the error > > > > if (.not.checkFmt(fmt)) then > > 1 > > Error: Reference to impure function 'checkfmt' at (1) within a PURE > > procedure > > > > After revision r258362 (2018-03-08) I get the ICE. This has been back ported > > to 7.3.1. > > > > In this range I see only r258281, r258305, and r258347, but r258305 has not > > been back ported. > > Bizarrely it is r258347 that is the trigger. It has been backported without > any ill effects. > It's probably not bizarre when a user does something like overloading the name of an intrinsic subprogram and then tries to use it in a specification statement. Something that the contributor of r258347 and of very little brain would never do. The simple fix is to not be too clever. interface length module procedure alen, blen ! renamed to shorter symbols for debugging end interface function str_real_dp_matrix(xa) result(s) real, intent(in) :: xa character(len=length(xa)) :: s end function str_real_dp_matrix % gfc -c a.f90 a.f90:12:18: if (.not.checkFmt(fmt)) then 1 Error: Reference to impure function 'checkfmt' at (1) within a PURE procedure If I had to guess the gfc_reduce_init_expr() in r258347 is disabling the reporting of errors at some point when len=len(xa) is being reduced.
[Bug fortran/85150] internal compiler error for module with illegal non-constant pointer initialization designator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85150 --- Comment #3 from Dominique d'Humieres --- The code compiles if I replace integer :: buf_i = 1 with integer, parameter :: buf_i = 1
[Bug driver/85153] _Pragma to disable -Wswitch-unreachable diagnostic not properly working when used within preprocessor macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85153
--- Comment #2 from Fabio Alemagna ---
And removing the exclamation mark from the if condition actually makes it work
again, but only if the B and E macro are wrapped within the Y() macro,
otherwise it still complains, now indicating the parenthesis as the problem:
#define X6() B if (x) E
int test9(int val) {
switch (val) {
X6() {
case 1: return 10;
}
}
return 0;
}
pragmatest.cpp: In function ‘int test9(int)’:
pragmatest.cpp:96:25: warning: statement will never be executed
[-Wswitch-unreachable]
#define X6() B if (x) E
^
pragmatest.cpp:99:21: note: in expansion of macro ‘X6’
X6() {
^~
[Bug driver/85153] _Pragma to disable -Wswitch-unreachable diagnostic not properly working when used within preprocessor macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85153 Fabio Alemagna changed: What|Removed |Added Attachment #43809|0 |1 is obsolete|| --- Comment #1 from Fabio Alemagna --- Created attachment 43810 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43810&action=edit The preprocessed source, which works as expected The real one. The previous one was from another test.
[Bug driver/85153] New: _Pragma to disable -Wswitch-unreachable diagnostic not properly working when used within preprocessor macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85153
Bug ID: 85153
Summary: _Pragma to disable -Wswitch-unreachable diagnostic not
properly working when used within preprocessor macro
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: falemagn at gmail dot com
Target Milestone: ---
Created attachment 43809
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43809&action=edit
The preprocessed source, which works as expected
The preprocessed output (attached) behaves as expected, so I assume this
problem has to do with the driver and/or a strange interaction between driver,
preprocessor and compiler. For lack of better knowledge, I've filed this bug
under the "driver" component.
The whole code is on godbolt: https://godbolt.org/g/rTc3AU
Given the following code, g++ properly emits a warning.
int x;
int test1(int val) {
switch (val) {
if (!x) {
case 1: return 10;
}
}
return 0;
}
pragmatest.cpp: In function ‘int test1(int)’:
pragmatest.cpp:5:25: warning: statement will never be executed
[-Wswitch-unreachable]
if (!x) {
^~
If I then try to silence this warning with the proper _Pragma directive, in
clear, like in the following code, it works as expected as in the compiler
doesn't complain any longer:
int test2(int val) {
switch (val) {
_Pragma("GCC diagnostic push")
_Pragma("GCC diagnostic ignored \"-Wswitch-unreachable\"")
if (!x) {
_Pragma("GCC diagnostic pop")
case 1: return 10;
}
}
return 0;
}
If I then try to to hide the pragmas within 2 macros, like in the following
code, it still works:
#define B _Pragma("GCC diagnostic push") _Pragma("GCC diagnostic ignored
\"-Wswitch-unreachable\"")
#define E _Pragma("GCC diagnostic pop")
int test3(int val) {
switch (val) {
B if (!x) E {
case 1: return 10;
}
}
return 0;
}
However, if now I want to turn the whole "B if (!x) E" statement into a define
of its own, like in the following code, it doesn't work any longer.
#define X() B if (!x) E
int test4(int val) {
switch (val) {
X() {
case 1: return 10;
}
}
return 0;
}
pragmatest.cpp: In function ‘int test4(int)’:
pragmatest.cpp:39:23: warning: statement will never be executed
[-Wswitch-unreachable]
#define X() B if (!x) E
^~
pragmatest.cpp:43:21: note: in expansion of macro ‘X’
X() {
^
This looked quite odd, and at first thought I couldn't figure out what was
going on, but then I thought of using a layer of indirection around the pragma
macros, thinking it might have something to do with secondary expansion, so I
tried the following code, but still no luck.
#define Y(x) x
#define X2() Y(B) if (!x) Y(E)
int test5(int val) {
switch (val) {
X2() {
case 1: return 10;
}
}
return 0;
}
pragmatest.cpp: In function ‘int test5(int)’:
pragmatest.cpp:52:27: warning: statement will never be executed
[-Wswitch-unreachable]
#define X2() Y(B) if (!x) Y(E)
^~
pragmatest.cpp:55:21: note: in expansion of macro ‘X2’
X2() {
^~
So I tried something which in my mind wouldn't make sense at all - notice that
I wrapped the x **variable** in the Y() macro - but what did I have to lose
anyway? But the following code still (unsurprinsigly?) didn't work:
#define X3() Y(B) if (!Y(x)) Y(E)
int test6(int val) {
switch (val) {
X3() {
case 1: return 10;
}
}
return 0;
}
pragmatest.cpp: In function ‘int test6(int)’:
pragmatest.cpp:63:27: warning: statement will never be executed
[-Wswitch-unreachable]
#define X3() Y(B) if (!Y(x)) Y(E)
^
pragmatest.cpp:66:21: note: in expansion of macro ‘X3’
X3() {
^~
However this time around the warning message gave me a hint! Why would the
compiler complain only about the exclamation mark not being reachable? So I
tried the following... and it worked!
#define X4() Y(B) if (Y(!)x) Y(E)
int test7(int val) {
switch (val) {
X4() {
case 1: return 10;
}
}
return 0;
}
That code above makes the compiler stay silent, against all od
[Bug target/85152] VAX ICE with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85152 --- Comment #1 from coypu --- *** Bug 85151 has been marked as a duplicate of this bug. ***
[Bug target/85151] VAX ICE with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85151 coypu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from coypu --- Made a double bug report by mistake. *** This bug has been marked as a duplicate of bug 85152 ***
[Bug fortran/85150] internal compiler error for module with illegal non-constant pointer initialization designator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85150 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) > I get the ICE with 4.8 up to trunk (8.0). Compiling the test with 4.3.6 > gives the error > >integer, pointer :: buf_ptr => buf(buf_i) ! invalid > 1 > Error: Pointer initialization requires a NULL() at (1) 4.3.6 did not support pointer initialization to anything other than a null-init as 4.3.6 did not support Fortran 2008. With Fortran 2008, it is legal to do integer, target :: m integer, pointer :: n => m I haven't looked too closely at Nathan's code, but it may be invalid as buf_i is not a constant expression. That is, module mod_test implicit none integer, target :: buf(2) integer :: buf_i = 1 The above is not a named constant, integer, pointer :: buf_ptr => buf(buf_i) ! invalid so it may not be valid Fortran to reference it here in a specification statement. end module mod_test
[Bug fortran/85102] ICE in gfc_conv_intrinsic_dot_product, at fortran/trans-intrinsic.c:4464
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85102 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #3 from Thomas Koenig --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg4.html
[Bug fortran/85150] internal compiler error for module with illegal non-constant pointer initialization designator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85150 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-01 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- I get the ICE with 4.8 up to trunk (8.0). Compiling the test with 4.3.6 gives the error integer, pointer :: buf_ptr => buf(buf_i) ! invalid 1 Error: Pointer initialization requires a NULL() at (1)
[Bug fortran/72709] Incorrect assignment of allocatable character array used as component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72709 Thomas Koenig changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #6 from Thomas Koenig --- Hi Paul, I've only recently stumbled across this bug. Just in case you haven't seen this one yet...
[Bug fortran/72709] Incorrect assignment of allocatable character array used as component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72709 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #5 from Thomas Koenig --- *** Bug 85144 has been marked as a duplicate of this bug. ***
[Bug fortran/68241] [meta-bug] [F03] Deferred-length character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 Bug 68241 depends on bug 85144, which changed state. Bug 85144 Summary: Wrong assignment with allocatable charlen https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85144 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug fortran/85144] Wrong assignment with allocatable charlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85144 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Thomas Koenig --- Correct, this is a dup. A pretty bad bug, though... *** This bug has been marked as a duplicate of bug 72709 ***
