[Bug c/64479] New: wrong optimization delayed-branch for SH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64479
Bug ID: 64479
Summary: wrong optimization delayed-branch for SH
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: oshima...@yagoto-urayama.jp
On NetBSD/landisk(sh3) 7.0_BETA, gcc4.8.4 generates some strange code.
Test case:
int foo(int);
void bar(int *);
void func(int args)
{
int key;
int flag = (args==0);
bar(&key);
if (!args) foo(1);
if (foo(args)) {
if (flag && key == 0) foo(2);
else
if (flag) foo(3);
}
}
it generated by compile with -Os -S:
func:
.LFB0:
.cfi_startproc
mov.l r8,@-r15
.cfi_def_cfa_offset 4
.cfi_offset 8, -4
mov.l r9,@-r15
.cfi_def_cfa_offset 8
.cfi_offset 9, -8
mov.l r10,@-r15
.cfi_def_cfa_offset 12
.cfi_offset 10, -12
mov.l r11,@-r15
.cfi_def_cfa_offset 16
.cfi_offset 11, -16
sts.l pr,@-r15
.cfi_def_cfa_offset 20
.cfi_offset 17, -20
add #-4,r15
.cfi_def_cfa_offset 24
mov.l .L16,r1
tst r4,r4
movtr8 # T bit -> R8
mov r4,r9
jsr @r1# subroutine call (bar)
mov r15,r4
mov.l .L18,r11
bf .L2 # what condition? (T bit == 0?)
jsr @r11
mov #1,r4
.L2
When compiled with -Os -fno-delayed-branch -S:
func:
.LFB0:
.cfi_startproc
mov.l r8,@-r15
.cfi_def_cfa_offset 4
.cfi_offset 8, -4
mov.l r9,@-r15
.cfi_def_cfa_offset 8
.cfi_offset 9, -8
mov.l r10,@-r15
.cfi_def_cfa_offset 12
.cfi_offset 10, -12
mov.l r11,@-r15
.cfi_def_cfa_offset 16
.cfi_offset 11, -16
sts.l pr,@-r15
.cfi_def_cfa_offset 20
.cfi_offset 17, -20
add #-4,r15
.cfi_def_cfa_offset 24
mov.l .L16,r1
tst r4,r4
movtr8# T bit -> R8
mov r4,r9
mov r15,r4
jsr @r1 # subroutine call (bar)
nop
tst r8,r8 # if (R8 == 0) then T bit = 1
mov.l .L18,r11
bt .L2 # if (T bit == 1) branch .L2
mov #1,r4
jsr @r11
nop
.L2:
With -Os (include -fdelayed-branch), tst r8,r8 instruction is omitted, and
branch condition is inverted.
The same problem in this case occurs in flow_loops_find() function of
gcc/cfgloop.c when building gcc 4.8.4 for NetBSD/sh3-binary. So gcc
native-binary for sh3 will be wrong.
[Bug target/64477] [4.9/5 Regression] x86 sse unnecessary GPR spill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64477 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-03 CC||jakub at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Target Milestone|--- |4.9.3 Summary|x86 sse unnecessary GPR |[4.9/5 Regression] x86 sse |spill |unnecessary GPR spill Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r210824.
[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478 Bernd Edlinger changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #7 from Bernd Edlinger --- (In reply to Andrew Pinski from comment #6) > Actually here is what glibc says about malloc: > Function: void * malloc (size_t size) > Preliminary: | MT-Safe | AS-Unsafe lock | AC-Unsafe lock fd mem | See POSIX > Safety Concepts. > > But this is a non-Async-Signal here we are talking about so this is safe and > a bug in tsan for not realizing that. Well, in this example the signal is synchonous, but I see the same problem also when the stack overflows. Ada installs a separate signal handler stack. So it is supposed to handle that signal and do something about it, for instance re-boot the system or something really security relevant. That will not happen if the stack overflows inside malloc. For instance this test case: ulimit -s 1000 ./c380004 ,.,. C380004 ACATS 2.5 15-01-03 09:13:13 C380004 Check evaluation of discriminant expressions when the constraint depends on a discriminant, and the discriminants have defaults - discriminant-dependententry families and protected components. - C380004 Discriminant-dependent entry families for task types. - C380004 Discriminant-dependent entry families for protected types. == WARNING: ThreadSanitizer: signal-unsafe call inside of a signal (pid=19947) #0 malloc ../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors.cc:491 (libtsan.so.0+0x00025c33) #1 __gnat_malloc /home/ed/gnu/gcc-build/gcc/ada/rts/s-memory.adb:92 (c380004+0x004330c0) #2 _ada_c380004 /home/ed/gnu/gcc-test/c380004.adb:341 (c380004+0x00406700) #3 main /home/ed/gnu/gcc-test/b~c380004.adb:301 (c380004+0x004040be) SUMMARY: ThreadSanitizer: signal-unsafe call inside of a signal /home/ed/gnu/gcc-build/gcc/ada/rts/s-memory.adb:92 __gnat_malloc == == WARNING: ThreadSanitizer: signal-unsafe call inside of a signal (pid=19947) #0 malloc ../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors.cc:491 (libtsan.so.0+0x00025c33) #1 __gnat_malloc /home/ed/gnu/gcc-build/gcc/ada/rts/s-memory.adb:92 (c380004+0x004330c0) #2 _ada_c380004 /home/ed/gnu/gcc-test/c380004.adb:341 (c380004+0x00406700) #3 main /home/ed/gnu/gcc-test/b~c380004.adb:301 (c380004+0x004040be) SUMMARY: ThreadSanitizer: signal-unsafe call inside of a signal /home/ed/gnu/gcc-build/gcc/ada/rts/s-memory.adb:92 __gnat_malloc == * C380004 Unexpected exception. C380004 FAILED . == WARNING: ThreadSanitizer: signal-unsafe call inside of a signal (pid=19947) #0 free ../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors.cc:538 (libtsan.so.0+0x00025f29) #1 __gnat_free /home/ed/gnu/gcc-build/gcc/ada/rts/s-memory.adb:113 (c380004+0x00433111) #2 _ada_c380004 /home/ed/gnu/gcc-test/c380004.adb:341 (c380004+0x00406700) #3 main /home/ed/gnu/gcc-test/b~c380004.adb:301 (c380004+0x004040be) SUMMARY: ThreadSanitizer: signal-unsafe call inside of a signal /home/ed/gnu/gcc-build/gcc/ada/rts/s-memory.adb:113 __gnat_free == ThreadSanitizer: reported 3 warnings see: the signal handler calls malloc and free, and apparently evenreturns and prints "* C380004 Unexpected exception."
[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #8 from Andrew Pinski --- (In reply to Bernd Edlinger from comment #7) > (In reply to Andrew Pinski from comment #6) > > Actually here is what glibc says about malloc: > > Function: void * malloc (size_t size) > > Preliminary: | MT-Safe | AS-Unsafe lock | AC-Unsafe lock fd mem | See POSIX > > Safety Concepts. > > > > But this is a non-Async-Signal here we are talking about so this is safe and > > a bug in tsan for not realizing that. > > Well, in this example the signal is synchonous, > but I see the same problem also when the stack overflows. Stack overflow is still synchonous. But really there is not much to be done with a stack overflow. it is hard for anything to do with both stack overflow not in malloc and one in malloc unless you know you are not in malloc. Still not a bug which is fixable easily. Still a BUG in tsan for reporting a non bug. Please report this to TSAN for reporting a non BUG. Thanks, Andrew Pinski
[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478 --- Comment #9 from Bernd Edlinger --- Sorry, Andrew, a deadlock in the Ada exception handler is an Ada BUG by definition. Even if YOU can't fix it easily. The memory could be pre-allocated as the call stack and we should make it to the point where the user code starts. If they call malloc then that's no more our problem. Please stop this now. I still dont see what's wrong with tsan here, the signal could easily be from a kill -SIGSEGV . Thanks Bernd.
[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478 --- Comment #10 from Andrew Pinski --- (In reply to Bernd Edlinger from comment #9) > I still dont see what's wrong with tsan here, the signal could > easily be from a kill -SIGSEGV . Because this is while executing in the synchonous signal form. Yes TSAN should realize that and not report it.
[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
--- Comment #11 from Bernd Edlinger ---
Sorry.
again the test case c380004
just with this little addition
begin
Test ("C380004",
"Check evaluation of discriminant expressions " &
"when the constraint depends on a discriminant, " &
"and the discriminants have defaults - discriminant-dependent" &
"entry families and protected components");
Comment ("Discriminant-dependent entry families for task types");
+ delay 60.0;
F1_Poe := 18;
ed@w-ed:~/gnu/gcc-test$ ./c380004 &
[1] 20972
ed@w-ed:~/gnu/gcc-test$
,.,. C380004 ACATS 2.5 15-01-03 10:17:46
C380004 Check evaluation of discriminant expressions when the
constraint depends on a discriminant, and the
discriminants have defaults -
discriminant-dependententry families and protected
components.
- C380004 Discriminant-dependent entry families for task types.
ed@w-ed:~/gnu/gcc-test$ ps
PID TTY TIME CMD
20842 pts/900:00:00 bash
20972 pts/900:00:00 c380004
20974 pts/900:00:00 ps
ed@w-ed:~/gnu/gcc-test$ kill -SIGSEGV 20972
ed@w-ed:~/gnu/gcc-test$ ==
WARNING: ThreadSanitizer: signal-unsafe call inside of a signal (pid=20972)
#0 malloc ../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors.cc:491
(libtsan.so.0+0x00025c33)
#1 __gnat_malloc /home/ed/gnu/gcc-build/gcc/ada/rts/s-memory.adb:92
(c380004+0x00436ab0)
#2 system__task_primitives__operations__timed_delay
/home/ed/gnu/gcc-build/gcc/ada/rts/s-taprop.adb:597 (c380004+0x0041de9f)
#3 main /home/ed/gnu/gcc-test/b~c380004.adb:304 (c380004+0x00404138)
SUMMARY: ThreadSanitizer: signal-unsafe call inside of a signal
/home/ed/gnu/gcc-build/gcc/ada/rts/s-memory.adb:92 __gnat_malloc
==
==
WARNING: ThreadSanitizer: signal-unsafe call inside of a signal (pid=20972)
#0 malloc ../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors.cc:491
(libtsan.so.0+0x00025c33)
#1 (ld-linux-x86-64.so.2+0xdeab)
#2 system__task_primitives__operations__timed_delay
/home/ed/gnu/gcc-build/gcc/ada/rts/s-taprop.adb:597 (c380004+0x0041de9f)
#3 main /home/ed/gnu/gcc-test/b~c380004.adb:304 (c380004+0x00404138)
SUMMARY: ThreadSanitizer: signal-unsafe call inside of a signal ??:0 ??
==
[1]+ Aborted (core dumped) ./c380004
ed@w-ed:~/gnu/gcc-test$
Is this asynchronous enough for you?
[Bug fortran/63494] ICE with deferred-character-length component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63494 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|WAITING |NEW CC||janus at gcc dot gnu.org Summary|internal compiler error:|ICE with |Bus error, and out of |deferred-character-length |memory allocating ... |component --- Comment #2 from janus at gcc dot gnu.org --- I get an ICE on the following reduced and slightly modified test case: implicit none type :: lrStringType character(:), allocatable :: right end type type :: lrString type(lrStringType), allocatable :: storage(:) end type contains pure subroutine getRight(this) type(lrString), intent(IN) :: this character(:), allocatable :: text text = this%storage(1)%right(2:) end subroutine end $ gfortran-5.0 c0.f90 f951: internal compiler error: Speicherzugriffsfehler 0xa2e19f crash_signal /home/jweil/gcc/gcc50/trunk/gcc/toplev.c:359 0x5f06a4 gfc_copy_ref(gfc_ref*) /home/jweil/gcc/gcc50/trunk/gcc/fortran/expr.c:651 0x5f0368 gfc_copy_expr(gfc_expr*) /home/jweil/gcc/gcc50/trunk/gcc/fortran/expr.c:395 0x646987 gfc_resolve_substring_charlen(gfc_expr*) /home/jweil/gcc/gcc50/trunk/gcc/fortran/resolve.c:4530 0x64420d gfc_resolve_expr(gfc_expr*) /home/jweil/gcc/gcc50/trunk/gcc/fortran/resolve.c:6203 0x64adb4 gfc_resolve_code(gfc_code*, gfc_namespace*) /home/jweil/gcc/gcc50/trunk/gcc/fortran/resolve.c:10003 0x64d6fa resolve_codes /home/jweil/gcc/gcc50/trunk/gcc/fortran/resolve.c:14908 0x64d607 resolve_codes /home/jweil/gcc/gcc50/trunk/gcc/fortran/resolve.c:14894 0x64d7e2 gfc_resolve /home/jweil/gcc/gcc50/trunk/gcc/fortran/resolve.c:14936 0x638e2a resolve_all_program_units /home/jweil/gcc/gcc50/trunk/gcc/fortran/parse.c:4886 0x638e2a gfc_parse_file() /home/jweil/gcc/gcc50/trunk/gcc/fortran/parse.c:5129 0x677f35 gfc_be_parse_file /home/jweil/gcc/gcc50/trunk/gcc/fortran/f95-lang.c:222 When removing the PURE attribute, I get: f951: out of memory allocating 30704883504 bytes after a total of 561152 bytes
[Bug fortran/38319] Memory leaks in allocatable component expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38319 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #7 from janus at gcc dot gnu.org --- I think it is indeed expected for valgrind to report leaks for the code in comment 5, since variables in the main program are not supposed to be auto-deallocated in F08. Valgrind does not show any leaks if I put x into a subroutine: type :: thytype integer(4), allocatable :: h(:) end type thytype type :: mytype type(thytype), allocatable :: q(:) end type mytype contains subroutine s type (mytype) :: x x = mytype ([thytype([555])]) end subroutine end One should check the test cases listed in comment 0, in order to see if they still show leaks and if those are actual bugs.
[Bug fortran/38724] Segfault caused by derived-type with allocatable component in OpenMP private clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38724 janus at gcc dot gnu.org changed: What|Removed |Added Summary|Segfault caused by |Segfault caused by |derived-type with |derived-type with |allocatable component in|allocatable component in |private clause |OpenMP private clause Severity|normal |enhancement
[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
Bernd Edlinger changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |---
--- Comment #12 from Bernd Edlinger ---
Andrew,
please stop setting this bug to INVALID all the time
that is not really funny any more.
And I don't see, why this cant be fixed at all,
there are only one or two memory allocations that have to be
be pre-allocated in some kind of signal safe memory pool.
Just to prove the concept I changed the test case c380004
to do some memory allocations while waiting for the
asynchronous signal.
--- ../gcc-trunk/gcc/testsuite/ada/acats/tests/c3/c380004.a2014-05-24
19:26:48.763568674 +0200
+++ c380004.adb2015-01-03 11:41:04.198306842 +0100
@@ -36,6 +36,7 @@
--!
with Report;
use Report;
+with Unchecked_Deallocation;
procedure C380004 is
type Rec (D1, D2 : Positive) is
@@ -180,7 +181,9 @@
end;
end Check;
-
+ type P is access Rec;
+ procedure Deallocate is new Unchecked_Deallocation(Rec, P);
+ pp : P;
begin
Test ("C380004",
"Check evaluation of discriminant expressions " &
@@ -190,6 +193,11 @@
Comment ("Discriminant-dependent entry families for task types");
+for I in 1..10 loop
+pp := new Rec(1,2);
+Deallocate(pp);
+end loop;
+-- delay 60.0;
F1_Poe := 18;
usually I get this:
ed@w-ed:~/gnu/gcc-test$ ./c380004 &
[1] 21589
ed@w-ed:~/gnu/gcc-test$
,.,. C380004 ACATS 2.5 15-01-03 11:45:42
C380004 Check evaluation of discriminant expressions when the
constraint depends on a discriminant, and the
discriminants have defaults -
discriminant-dependententry families and protected
components.
- C380004 Discriminant-dependent entry families for task types.
ed@w-ed:~/gnu/gcc-test$ killall -SIGSEGV c380004
* C380004 Unexpected exception.
C380004 FAILED .
ed@w-ed:~/gnu/gcc-test$
[1]+ Fertig ./c380004
ed@w-ed:~/gnu/gcc-test$
but after several re-tries the killed process freezes:
ed@w-ed:~/gnu/gcc-test$ ./c380004 &
[1] 21592
ed@w-ed:~/gnu/gcc-test$
,.,. C380004 ACATS 2.5 15-01-03 11:45:46
C380004 Check evaluation of discriminant expressions when the
constraint depends on a discriminant, and the
discriminants have defaults -
discriminant-dependententry families and protected
components.
- C380004 Discriminant-dependent entry families for task types.
ed@w-ed:~/gnu/gcc-test$
ed@w-ed:~/gnu/gcc-test$ killall -SIGSEGV c380004
ed@w-ed:~/gnu/gcc-test$
ed@w-ed:~/gnu/gcc-test$
ed@w-ed:~/gnu/gcc-test$ ps
PID TTY TIME CMD
2244 pts/000:00:00 bash
21592 pts/000:00:01 c380004
21596 pts/000:00:00 ps
ed@w-ed:~/gnu/gcc-test$ sudo bash
[sudo] password for ed:
root@w-ed:~/gnu/gcc-test# gdb
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
[Bug pch/61250] Random pch failures on x86_64-apple-darwin1(3|4).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250 Dominique d'Humieres changed: What|Removed |Added Target|x86_64-apple-darwin13 |x86_64-apple-darwin1(3|4) Host|x86_64-apple-darwin13 |x86_64-apple-darwin1(3|4) Summary|Random pch failures on |Random pch failures on |x86_64-apple-darwin13. |x86_64-apple-darwin1(3|4). Build|x86_64-apple-darwin13 |x86_64-apple-darwin1(3|4) --- Comment #3 from Dominique d'Humieres --- Also seen on x86_64-apple-darwin14.
[Bug target/50077] FAIL: gcc.target/i386/pr49866.c (test for excess errors) on x86_64-apple-darwin1*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50077 Dominique d'Humieres changed: What|Removed |Added Target|x86_64-apple-darwin10, |x86_64-apple-darwin1*, |i?86-apple-darwin9 |i?86-apple-darwin9 Summary|FAIL: |FAIL: |gcc.target/i386/pr49866.c |gcc.target/i386/pr49866.c |(test for excess errors) on |(test for excess errors) on |x86_64-apple-darwin10 |x86_64-apple-darwin1* --- Comment #4 from Dominique d'Humieres --- Also seen on x86_64-apple-darwin14.
[Bug fortran/60913] [OOP] Memory leak with allocatable polymorphic function result (in type-bound operator)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60913 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Summary|Memory leak with deferred |[OOP] Memory leak with |operators |allocatable polymorphic ||function result (in ||type-bound operator) --- Comment #3 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #2) > It may be a duplicate of pr55603. Pretty much. But the case here is a bit more complicated, since the result is polymorphic and the function is bound to a type-bound operator.
[Bug fortran/55603] [F03] Memory leak with scalar allocatable function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55603 --- Comment #8 from janus at gcc dot gnu.org --- PR 60913 is closely related and contains a more complicated test case.
[Bug fortran/38319] Memory leaks in allocatable component expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38319 --- Comment #8 from janus at gcc dot gnu.org --- (In reply to Paul Thomas from comment #0) > alloc_comp_assign_4.f90 nested constructors(line 56) With current trunk I see additional leaks in lines 28 and 29. Those are again due to not auto-deallocating variables in the main program, which is an F08 feature, not a gfortran bug. The leak in line 56 persists. Here is a reduced test case for that: type :: a character(4), allocatable :: ch(:) end type a call test_ab6 () contains subroutine test_ab6 () type b type(a) :: a end type b type c type(b), allocatable :: b(:) end type c type(c):: p p = c((/b(a((/"Mary","Lamb"/)))/)) end subroutine end While 4.4 shows only a single 8-byte leak, 4.6 to trunk shows two of them.
[Bug middle-end/64388] [5 Regression] r219037 caused FAIL: gcc.dg/pr44194-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64388 --- Comment #4 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01990.html
[Bug c/64480] New: List designated initializer triggers -Wmissing-field-initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64480
Bug ID: 64480
Summary: List designated initializer triggers
-Wmissing-field-initializers
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: petr.pisar at atlas dot cz
This code:
struct lower {
char *foo;
char *bar;
};
struct upper {
struct lower inner;
};
int main (void) {
struct upper u = {
/* This triggers -Wmissing-field-initializers warning */
.inner.foo = "Foo",
.inner.bar = "Bar",
/* While this passes:
.inner = {
.foo = "Foo",
.bar = "Bar",
},
*/
};
(void)u;
return 0;
}
Triggers warning about initialized lower.bar field:
$ gcc -Wall -Wextra -std=c99 -O0 -g test.c
test.c: In function ‘main’:
test.c:14:9: warning: missing initializer for field ‘bar’ of ‘struct lower’
[-Wmissing-field-initializers]
.inner.bar = "Bar",
^
test.c:3:11: note: ‘bar’ declared here
char *bar;
^
If I change to initialization from the list form (.inner.foo=) to nested
(.inner={.foo=}), then it passes. The change is commented out in the quoted
code.
I think the list syntax is valid per C99, 6.7.9 Initialization grammar.
[Bug fortran/60255] [OOP] Deferred character length variable at (1) cannot yet be associated with unlimited polymorphic entities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60255 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |vehre at gmx dot de Summary|[oop] Deferred character|[OOP] Deferred character |length variable at (1) |length variable at (1) |cannot yet be associated|cannot yet be associated |with unlimited polymorphic |with unlimited polymorphic |entities|entities
[Bug ipa/64481] New: [5 Regression] r219076 breaks bootstrap (x86_64-unknown-linux-gnu)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64481 Bug ID: 64481 Summary: [5 Regression] r219076 breaks bootstrap (x86_64-unknown-linux-gnu) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: david.abdurachmanov at gmail dot com While doing testing, I found that I couldn't bootstrap GCC anymore during holidays. Using git bisect, I found first breaking commit: d326c10c2de4a884476d099dbeca4794e145d8c1 / r219076. Last good commit: 09196675b74bd04b562fe3b264a9648eb0568a59 / r219075 Last tested bad: 27f6a8a0012f8df67c88b9d28ab47c3492319a07 / r219158 Tested on Fedora 21 OpenStack image (clean setup). Commands executed on a new virtual machine: yum makecache yum update yum -y groupinstall "Development Tools" yum -y groupinstall "C Development Tools and Libraries" yum -y install zlib-devel mkdir -p /build cd /build/ git clone git://gcc.gnu.org/git/gcc.git git checkout d326c10c2de4a884476d099dbeca4794e145d8c1 ./contrib/download_prerequisites mkdir obj cd obj ../configure --prefix=/tmp/gccbuild --enable-bootstrap --disable-checking --enable-languages=c,c++ --disable-multilib --with-system-zlib --enable-shared --disable-nls make -j4 bootstrap [snip] make[2]: Entering directory '/build/gcc/obj' make[3]: Entering directory '/build/gcc/obj' rm -f stage_current make[3]: Leaving directory '/build/gcc/obj' Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! gcc/valtrack.o differs gcc/rtlanal.o differs gcc/tree-ssa-ccp.o differs gcc/tree-nested.o differs gcc/tree-vect-stmts.o differs gcc/tree-ssa-loop-ivopts.o differs gcc/tree-sra.o differs gcc/dwarf2out.o differs gcc/lto/lto.o differs gcc/c/c-typeck.o differs gcc/c/c-array-notation.o differs gcc/c/c-decl.o differs gcc/c/c-parser.o differs gcc/tree-ssa-uninit.o differs gcc/i386.o differs gcc/tree-ssa.o differs gcc/expr.o differs gcc/except.o differs gcc/tree-ssa-reassoc.o differs gcc/rtl-error.o differs gcc/tree-ssa-tail-merge.o differs gcc/omp-low.o differs gcc/ipa-icf.o differs gcc/dominance.o differs gcc/toplev.o differs gcc/tree-ssa-structalias.o differs gcc/ipa-pure-const.o differs gcc/ipa-profile.o differs gcc/coverage.o differs gcc/ifcvt.o differs gcc/tree-ssa-threadedge.o differs gcc/tree-inline.o differs gcc/trans-mem.o differs gcc/lto-streamer-out.o differs gcc/loop-iv.o differs gcc/ipa-polymorphic-call.o differs gcc/ipa-reference.o differs gcc/tree-ssa-math-opts.o differs gcc/graphite-sese-to-poly.o differs gcc/cgraph.o differs gcc/sese.o differs gcc/ipa-split.o differs gcc/tree-ssa-sccvn.o differs gcc/tree-into-ssa.o differs gcc/alias.o differs gcc/attribs.o differs gcc/c-family/c-pretty-print.o differs gcc/c-family/array-notation-common.o differs gcc/c-family/c-common.o differs gcc/ipa-inline-analysis.o differs gcc/vtable-verify.o differs gcc/ipa-chkp.o differs gcc/cfgrtl.o differs gcc/ipa-inline-transform.o differs gcc/tree-ssa-loop-im.o differs gcc/dwarf2cfi.o differs gcc/tree-ssa-dom.o differs gcc/tree-eh.o differs gcc/gcov.o differs gcc/loop-invariant.o differs gcc/tree-vrp.o differs gcc/opts.o differs gcc/combine-stack-adj.o differs gcc/gimplify.o differs gcc/varasm.o differs gcc/tree-ssa-pre.o differs gcc/ipa-cp.o differs gcc/tree-cfg.o differs gcc/ipa-prop.o differs gcc/cfgloop.o differs gcc/tree-chkp.o differs gcc/ipa-comdats.o differs gcc/tree-vectorizer.o differs gcc/postreload.o differs gcc/lto-streamer-in.o differs gcc/build/genmatch.o differs gcc/ipa-icf-gimple.o differs gcc/cfg.o differs gcc/optabs.o differs gcc/tsan.o differs gcc/var-tracking.o differs gcc/loop-unroll.o differs gcc/cp/pt.o differs gcc/cp/parser.o differs gcc/cp/typeck2.o differs gcc/cp/decl.o differs gcc/cp/rtti.o differs gcc/cp/call.o differs gcc/cp/init.o differs gcc/cp/cp-array-notation.o differs gcc/cp/name-lookup.o differs gcc/cp/constexpr.o differs gcc/cp/semantics.o differs gcc/tree-ssa-loop-niter.o differs isl/isl_arg.o differs isl/isl_ilp.o differs isl/isl_tab_pip.o differs isl/isl_space.o differs isl/isl_transitive_closure.o differs isl/isl_stream.o differs isl/isl_output.o differs libiberty/d-demangle.o differs libiberty/pic/d-demangle.o differs mpfr/lngamma.o differs mpfr/gamma.o differs Makefile:22563: recipe for target 'compare' failed make[2]: *** [compare] Error 1 make[2]: Leaving directory '/build/gcc/obj' Makefile:22542: recipe for target 'stage3-bubble' failed make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory '/build/gcc/obj' Makefile:22605: recipe for target 'bootstrap' failed make: *** [bootstrap] Error 2
[Bug middle-end/64388] [5 Regression] r219037 caused FAIL: gcc.dg/pr44194-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64388 --- Comment #5 from dave.anglin at bell dot net --- On 2015-01-03, at 10:01 AM, hjl.tools at gmail dot com wrote: > --- Comment #4 from H.J. Lu --- > A patch is posted at > > https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01990.html Can't review but the implementation looks good to me. Dave -- John David Anglindave.ang...@bell.net
[Bug ada/48918] GNAT Bug Box with Assert_Failure with einfo.adb:2661
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48918 --- Comment #3 from Anh Vo --- Great. Thank you for your effort.
[Bug c++/56126] -fno-exceptions should activate -fcheck-new or issue diagnostic for all new operators without throw()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126 Olaf van der Spek changed: What|Removed |Added CC||olafvdspek at gmail dot com --- Comment #4 from Olaf van der Spek --- Isn't abort() called when new fails with -fno-exceptions?
[Bug c++/64482] New: No Exceptions Improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64482
Bug ID: 64482
Summary: No Exceptions Improvements
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: olafvdspek at gmail dot com
Currently -fno-exceptions is partially implemented in the std library. throw is
replaced by abort(), try and catch are basically no-ops. However, user code
doesn't benefit from this.
Could these things be implemented in the compiler instead?
Ideally a throw would still result in something like:
terminate called after throwing an instance of 'std::runtime_error'
what(): Bah
Aborted
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_exceptions.html
#include
int main()
{
throw std::runtime_error("Bah");
}
[Bug c++/64482] No Exceptions Improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64482 Olaf van der Spek changed: What|Removed |Added Severity|normal |enhancement
[Bug target/64460] ARM ICE on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64460 --- Comment #1 from Joel Sherrill --- I ran a git bisect and it didn't narrow it down much but I hope this helps. After the list of candidates, I am posting the full git bisect log. Bisecting: 27 revisions left to test after this (roughly 5 steps) [9d0ddb1d2f78d8f75d1663c450bfb79a434316a4] -fuse-caller-save - Enable for MIPS running /users/joel/test-gcc/test.sh There are only 'skip'ped commits left to test. The first bad commit could be any of: c72a450a93b2267ed467dccba674ffbf5cf422aa e5d9420b3864e1bee10962f9962086f6b4424bd9 b652abf9ece0468d3c4f7e28592f514f92555192 ec0d1d643fa3b5a0a4bb6cdc6e5bad494b84cb7e 0bf90b7bfb72acfedbbe7af3e57e8cca7711434f 754158d9189fd020e9cde6a16c55d0340035f503 9ac9a75871aa0616c341048f1d5fd9ff9567c5c6 f1714fa0234e7465d69869735ac90a5f6959948d 53037a4d5be734e4ccc99db221676fa7cec7a806 db2d29508c505d3fa5beda75afca51e1496d97df 9227ba81ede93aa32eeb27f3f44210e028356d2e aec1009feb0d0f8568501195a39d47cd86b1b479 30b4a99c52814ac12e95bfbc46855ce3b716ccb0 e9bf1d7eb0815c5e0afb4ceb374ff4222b5647eb 3a2864197399bc0847ad020c536efbdf5a4c9233 753a9c15373e367581810622175047bcd8609231 7ea5b9d97b7ea13ca759b1f7ca4f81a54d9d2698 dbe2840abe44f5b7f166547a633abc8fb4ca 09fb1a0adb85c0ced9b1cbf3e354ef3562a04aa9 7ce85a1fe8e0fa9b1ad9913ea82107c8c9a245f3 0d4c8cda4ac52f9d1b8aee46e85205e8fbaf312d b35f062ed12db8b2aaa9f8485be506baf41b871f 2f6bdc73b914b478dabb7bdd0ad996a9e3567bda fdfe65e2642826951d8050c4071a9bd00bb8bd14 82a1c922605243e401ea56d1b6288e771dacf248 8b433e5e84822c0bc35942950eb0ccc22dd5c7e6 540af08f9b8503433d9c2aa8d6c93f91bb2e6979 5692b79caf9e04153427ab7c0663509242a447be 1d9ca4f001f34692e768942c8a1295ab96783917 dcfff6f9996e8c7b2d323c806f17325c3bbc4f4e 32ce9a5c4208411361402f60e672c4830da0bc8f 75b115f41512fbbab79191059ba6a21bbd98a7c9 205c3b0ab6423dca05db534c7b7099f39eaee409 49523e2f0b01f0d5e58b16279115be1ab1393147 ac37483380d835da1ddb54a2cc8a7e75d12a c20614820dd7acd77899a9a1ca52071356f05a3e 7f9463ecb4e1285d80975224aff4d71e7a64bc2e fa64988a95dc95e538fe8d1b44b0fa91e8349966 487fea840105dbb0ff516b797e7d86bea82ef74a 61b1440327acebe3aebb7bca187df4abafbf3179 3a05a70c9631864b0c87824cf983ec0665eea501 de8b47de2e5ffc6bdbba5bf14024a843af5d9012 6b204f796d985a7983f9dd4b37098435814583b9 6f0c730b2b89c556b8846f8859226ffafca93350 587e70a69bd133c66c4d62fb7881753fd0133996 8753931abe4a279eb4b2c945fb8b5c14fc6774c9 0a8b68fa1ad04e3b56733adaa1926448fd96046d 1a344a3feb0312e6bf51cc666449168f28317780 949d4c6f91bc04cd8dafc7b80bb177d4f222a077 e00f93485cc99b84d47c0ef273eb2cf57fd4d73c 41a5159cce6cf6a14d783db438b5cd9e285f5e29 723c5269bcf4c0d7d459b69480602179c24ad73a 9d0ddb1d2f78d8f75d1663c450bfb79a434316a4 d2b854bc935a18434b59f77d8a6e329e4146a2ba 0abea32ce53397ae5f3f9db852687aede815f6d4 Full git bisect log === # bad: [71a1e0b3c4bc5434ba2acc6dc317d98395888eb1] 2015-01-02 Tobias Burnus # good: [92b64c52c7ab48215e9bbd6b578a1b2324d10497] 2014-01-31 Vladimir Makarov git bisect start 'HEAD' '92b64c52c7ab48215e9bbd6b578a1b2324d10497' # bad: [73dc3c0d503205db874ed94eb894b2c059031717] 2014-07-31 Arnaud Charlet git bisect bad 73dc3c0d503205db874ed94eb894b2c059031717 # good: [9fa165ac10cbcbd65142077a0ce0e60cec60d6ae] 2014-05-08 Richard Biener git bisect good 9fa165ac10cbcbd65142077a0ce0e60cec60d6ae # bad: [72dc204f1926c75112c52304925b93265e4bec82] rs6000: Make cr5 allocatable git bisect bad 72dc204f1926c75112c52304925b93265e4bec82 # skip: [30b4a99c52814ac12e95bfbc46855ce3b716ccb0] PR target/61044 * doc/extend.texi (Local Labels): Note that label differences are not supported for AVR. git bisect skip 30b4a99c52814ac12e95bfbc46855ce3b716ccb0 # good: [b3096d437157c3ff9b01315e48eeab7e736bbac0] 2014-05-11 Paolo Carlini git bisect good b3096d437157c3ff9b01315e48eeab7e736bbac0 # skip: [6b204f796d985a7983f9dd4b37098435814583b9] runtime: disable split stacks for runtime_printf function under Clang git bisect skip 6b204f796d985a7983f9dd4b37098435814583b9 # bad: [a1032d45752b8ff864201ca3ad0b7e289ec4e904] runtime: Initialize variable to avoid compiler warning. git bisect bad a1032d45752b8ff864201ca3ad0b7e289ec4e904 # good: [18f0a24b677b550b7271d18959ba994a681af6a4] rs6000: New type attribute value "halfmul" git bisect good 18f0a24b677b550b7271d18959ba994a681af6a4 # bad: [a99cebb7bcfba6f574f062bcff80f1f9f67fd179] * config/ia64/ia64.c (ia64_first_cycle_multipass_dfa_lookahead_guard): Check pending_data_specs first. git bisect bad a99cebb7bcfba6f574f062bcff80f1f9f67fd179 # skip: [aec1009feb0d0f8568501195a39d47cd86b1b479] 2014-05-25 Paolo Carlini git bisect skip aec1009feb0d0f8568501195a39d47cd86b1b479 # bad: [c98fd781d8c0752f75b4ae03f1fa652b17265c27] * sanitizer_common/sanitizer_stacktrace.cc: Cherry pick upstream r209879. * sanitizer_common/sanitizer_common.h: Likewise. * asan/asan_mapping.h: Likewise. * asan/asan_linux.cc: Likewise. * tsan/tsan_mman.cc: Cherry pick upstream r209744. * sanitizer_common/sanitizer_allocator.h: Likewise.
[Bug target/55192] bfin generates invalid assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55192 Joel Sherrill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Joel Sherrill --- I have an installed bfin-rtems 4.8.3 so I am going to assume this has been fixed and close it.
[Bug libstdc++/64483] New: FAIL: 18_support/exception_ptr/64241.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64483 Bug ID: 64483 Summary: FAIL: 18_support/exception_ptr/64241.cc (test for excess errors) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 spawn /test/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc -B/test/gnu/gcc/objdir/./gc c -nostdinc++ -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src -L/tes t/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs -L/test/gnu/gcc/objd ir/hppa64-hp-hpux11.11/libstdc++-v3/libsupc++/.libs -B/opt/gnu64/gcc/gcc-5.0/hpp a64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-5.0/hppa64-hp-hpux11.11/lib/ -isystem /opt/gnu64/gcc/gcc-5.0/hppa64-hp-hpux11.11/include -isystem /opt/gnu64/gcc/gcc- 5.0/hppa64-hp-hpux11.11/sys-include -B/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -DLOCALEDIR="." -nostdinc++ -I/test/gnu/gcc/objdir/hppa6 4-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc ++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util /test/gnu/gcc/gcc/libstdc++-v3/testsuite/18_support/exception_ptr/64241.cc -std=gnu++11 -fno-exceptions -O0 ./libtestc++.a -lm -o ./64241.exe/test/gnu/gcc/gcc/libstdc++-v3/testsuite/18_support/exception_ptr/64241.cc: In function 'void test01()':/test/gnu/gcc/gcc/libstdc++-v3/testsuite/18_support/exception_ptr/64241.cc:31:3: error: 'exception_ptr' is not a member of 'std' std::exception_ptr p = std::make_exception_ptr(1); ^ In file included from /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/cassert:43:0, from /test/gnu/gcc/gcc/libstdc++-v3/testsuite/util/testsuite_hooks.h:58, from /test/gnu/gcc/gcc/libstdc++-v3/testsuite/18_support/exception_ptr/64241.cc:21: /test/gnu/gcc/gcc/libstdc++-v3/testsuite/18_support/exception_ptr/64241.cc:32:11: error: 'p' was not declared in this scope VERIFY( p == nullptr ); ^ /test/gnu/gcc/gcc/libstdc++-v3/testsuite/18_support/exception_ptr/64241.cc:32:3: note: in expansion of macro 'VERIFY' VERIFY( p == nullptr ); ^ compiler exited with status 1 ... FAIL: 18_support/exception_ptr/64241.cc (test for excess errors) Excess errors: /test/gnu/gcc/gcc/libstdc++-v3/testsuite/18_support/exception_ptr/64241.cc:31:3: error: 'exception_ptr' is not a member of 'std' /test/gnu/gcc/gcc/libstdc++-v3/testsuite/18_support/exception_ptr/64241.cc:32:11: error: 'p' was not declared in this scope UNRESOLVED: 18_support/exception_ptr/64241.cc compilation failed to produce executable
[Bug c++/63779] g++ 4.9 generates invalid object provoking a GOT relative relocation must reference a local symbol linker error on SunOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63779 --- Comment #4 from Václav Zeman --- I think I am experiencing same or similar issue with GCC 4.8.2 on Oracle Solaris 11.2 Express (i386). This is a snippet from log4cplus build. Almost all of these are related to __gthread* symbols but I also get some typeinfo symbols there. ld: fatal: relocation error: R_386_GOTOFF: file src/.libs/liblog4cplus_la-global-init.o: symbol __gthread_active: a GOT relative relocation must reference a local symbol ld: fatal: relocation error: R_386_GOTOFF: file src/.libs/liblog4cplus_la-global-init.o: symbol __gthread_active_p()::__gthread_active_mutex: a GOT relative relocation must reference a local symbol
[Bug c++/63779] g++ 4.9 generates invalid object provoking a GOT relative relocation must reference a local symbol linker error on SunOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63779 --- Comment #5 from Václav Zeman --- Created attachment 34369 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34369&action=edit assembler source
[Bug c++/63779] g++ 4.9 generates invalid object provoking a GOT relative relocation must reference a local symbol linker error on SunOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63779 --- Comment #6 from Václav Zeman --- Created attachment 34370 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34370&action=edit preprocessed source for global-init.cxx
[Bug c++/63779] g++ 4.9 generates invalid object provoking a GOT relative relocation must reference a local symbol linker error on SunOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63779 --- Comment #7 from Václav Zeman --- Created attachment 34371 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34371&action=edit resulting .o file
[Bug fortran/63552] [OOP] Type-bound procedures rejected as actual argument to dummy procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63552 Ian Harvey changed: What|Removed |Added CC||ian_harvey at bigpond dot com --- Comment #6 from Ian Harvey --- Note that using a type bound procedure (versus a procedure component) as an actual argument is an extension to Fortran 2008.
[Bug ada/64484] New: TSAN reports lock-order-inversion in c940006, c940011 and c940012
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64484 Bug ID: 64484 Summary: TSAN reports lock-order-inversion in c940006, c940011 and c940012 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de Hi, with my TSAN Ada patch I see a lock-order-inversion in three test cases: ed@w-ed:~/gnu/gcc-test$ TSAN_OPTIONS=second_deadlock_stack=1 ./c940006 ,.,. C940006 ACATS 2.5 15-01-03 21:44:18 C940006 Check external calls of protected functions and procedures. == WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=21031) Cycle in lock order graph: M14 (0x7fff21661758) => M13 (0x7fff216616e0) => M14 Mutex M13 acquired here while holding mutex M14 in main thread: #0 pthread_mutex_lock ../../../../gcc-trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:2988 (libtsan.so.0+0x00035456) #1 system__task_primitives__operations__write_lock /home/ed/gnu/gcc-build/gcc/ada/rts/s-taprop.adb:363 (c940006+0x0040ba07) #2 c940006__B_1__ramp_32__set_local_overloadN.5152 (c940006+0x0040a5ff) #3 c940006__B_1__ramp_32__set_local_overloadP.5156 (c940006+0x0040a6e8) #4 _ada_c940006 /home/ed/gnu/gcc-test/c940006.adb:209 (c940006+0x004098b6) #5 main /home/ed/gnu/gcc-test/b~c940006.adb:248 (c940006+0x00403fac) Mutex M14 previously acquired by the same thread here: #0 pthread_mutex_lock ../../../../gcc-trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:2988 (libtsan.so.0+0x00035456) #1 system__task_primitives__operations__write_lock /home/ed/gnu/gcc-build/gcc/ada/rts/s-taprop.adb:363 (c940006+0x0040ba07) #2 _ada_c940006 /home/ed/gnu/gcc-test/c940006.adb:209 (c940006+0x004098b6) #3 main /home/ed/gnu/gcc-test/b~c940006.adb:248 (c940006+0x00403fac) Mutex M14 acquired here while holding mutex M13 in main thread: #0 pthread_mutex_lock ../../../../gcc-trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:2988 (libtsan.so.0+0x00035456) #1 system__task_primitives__operations__read_lock /home/ed/gnu/gcc-build/gcc/ada/rts/s-taprop.adb:407 (c940006+0x0040ba67) #2 c940006__B_1__ramp_31__downstream_rampsN.5133 (c940006+0x0040a20d) #3 c940006__B_1__ramp_31__downstream_rampsP.5136 (c940006+0x0040a2e9) #4 _ada_c940006 /home/ed/gnu/gcc-test/c940006.adb:211 (c940006+0x004098cf) #5 main /home/ed/gnu/gcc-test/b~c940006.adb:248 (c940006+0x00403fac) Mutex M13 previously acquired by the same thread here: #0 pthread_mutex_lock ../../../../gcc-trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:2988 (libtsan.so.0+0x00035456) #1 system__task_primitives__operations__write_lock /home/ed/gnu/gcc-build/gcc/ada/rts/s-taprop.adb:363 (c940006+0x0040ba07) #2 _ada_c940006 /home/ed/gnu/gcc-test/c940006.adb:211 (c940006+0x004098cf) #3 main /home/ed/gnu/gcc-test/b~c940006.adb:248 (c940006+0x00403fac) SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) /home/ed/gnu/gcc-build/gcc/ada/rts/s-taprop.adb:363 system__task_primitives__operations__write_lock == C940006 PASSED . ThreadSanitizer: reported 1 warnings ed@w-ed:~/gnu/gcc-test$ ed@w-ed:~/gnu/gcc-test$ TSAN_OPTIONS=second_deadlock_stack=1 ./c940011 ,.,. C940011 ACATS 2.5 15-01-03 21:45:26 C940011 Protected Objects created by allocators: external calls via access types. == WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=7832) Cycle in lock order graph: M15 (0x7d20bec0) => M14 (0x7d20bf40) => M15 Mutex M14 acquired here while holding mutex M15 in main thread: #0 pthread_mutex_lock ../../../../gcc-trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:2988 (libtsan.so.0+0x00035456) #1 system__task_primitives__operations__write_lock /home/ed/gnu/gcc-build/gcc/ada/rts/s-taprop.adb:363 (c940011+0x0040b4d7) #2 c940011__ramp__set_local_overloadN.5119 (c940011+0x00409c55) #3 c940011__ramp__set_local_overloadP.5123 (c940011+0x00409d3f) #4 _ada_c940011 /home/ed/gnu/gcc-test/c940011.adb:165 (c940011+0x0040998d) #5 main /home/ed/gnu/gcc-test/b~c940011.adb:248 (c940011+0x00403fac) Mutex M15 previously acquired by the same thread here: #0 pthread_mutex_lock ../../../../gcc-trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:2988 (libtsan.so.0+0x00035456) #1 system__task_primitives__operations__write_lock /home/ed/gnu/gcc-build/gcc/ada/rts/s-taprop.adb:363 (c940011+0x0040b4d7) #2 _ada_c940011 /home/ed/gnu/gcc-test/c940011.adb:165 (c940011+0x0040998d) #3 main /home/e
[Bug ipa/64485] New: ICE at -Os and above on x86_64-linux-gnu in compute_inlined_call_time, at ipa-inline.c:550
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64485
Bug ID: 64485
Summary: ICE at -Os and above on x86_64-linux-gnu in
compute_inlined_call_time, at ipa-inline.c:550
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-Os and above on x86_64-linux-gnu in both 32-bit and 64-bit modes.
It is a regression from 4.9.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 5.0.0 20150103 (experimental) [trunk revision 219158] (GCC)
$
$ gcc-trunk -O1 -c small.c
$ gcc-4.9 -Os -c small.c
$
$ gcc-trunk -Os -c small.c
small.c:26:1: internal compiler error: in compute_inlined_call_time, at
ipa-inline.c:550
}
^
0x110a06d compute_inlined_call_time(cgraph_edge*, int)
../../gcc-trunk/gcc/ipa-inline.c:550
0x11003b1 big_speedup_p
../../gcc-trunk/gcc/ipa-inline.c:561
0x1104cb6 want_inline_small_function_p
../../gcc-trunk/gcc/ipa-inline.c:613
0x1107623 inline_small_functions
../../gcc-trunk/gcc/ipa-inline.c:1640
0x1107623 ipa_inline
../../gcc-trunk/gcc/ipa-inline.c:2185
0x1107623 execute
../../gcc-trunk/gcc/ipa-inline.c:2558
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
int a, b, c, d;
void
fn1 (int p)
{
b = ~c;
for (;;)
;
}
static int
fn2 (int p)
{
if (p)
d = 0;
if (!p)
fn1 (0);
return a;
}
void
fn3 ()
{
a = 0;
fn2 (a);
}
[Bug ipa/64481] [5 Regression] r219076 breaks bootstrap (x86_64-unknown-linux-gnu)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64481 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |5.0
[Bug web/64469] Broken link on main page
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64469 Andrew Pinski changed: What|Removed |Added CC||tg at mirbsd dot org --- Comment #1 from Andrew Pinski --- *** Bug 64471 has been marked as a duplicate of this bug. ***
[Bug web/64471] 403 Forbidden on GCC 5 page
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64471 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 64469. *** This bug has been marked as a duplicate of bug 64469 ***
[Bug ipa/64485] ICE at -Os and above on x86_64-linux-gnu in compute_inlined_call_time, at ipa-inline.c:550
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64485
--- Comment #1 from Zhendong Su ---
The following (somewhat simpler) test case triggers the same ICE:
-
int a, b, c;
int
fn1 ()
{
return a || b;
}
static void
fn2 (int p)
{
if (p)
c = fn1 ();
for (;;)
;
}
void
fn3 ()
{
fn2 (1);
}
[Bug web/64469] Broken link on main page
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64469 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-03 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug middle-end/64457] NVCC like features CUDA/OpenCL support for GCC to use GPU's to speed up compile jobs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64457 Andrew Pinski changed: What|Removed |Added Component|c |middle-end --- Comment #2 from Andrew Pinski --- I think this is already implemented as part of OpenMP 4.0 offloading which includes support for nvptx (well nvptx is GCC 5).
[Bug target/64456] [AArch64] pr64252.c fail on aarch64_be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64456 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Target|aarch64 |aarch64_be-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-03 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug target/63596] Saving of GPR/FPRs for stdarg even though the variable argument is not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63596 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/60669] VRP misses asserts for some already defined statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60669 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug fortran/63552] [OOP] Type-bound procedures rejected as actual argument to dummy procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63552 --- Comment #7 from Tobias Burnus --- (In reply to Ian Harvey from comment #6) > Note that using a type bound procedure (versus a procedure component) as an > actual argument is an extension to Fortran 2008. Can you pinpoint this in the standard? At a glance, it seems to be supported: R1223 procedure-designator is procedure-name or proc-component-ref or data-ref % binding-name "12.2.2.3 Dummy procedures A dummy argument that is specified to be a procedure or appears as the procedure designator in a procedure reference is a dummy procedure. A dummy procedure with the POINTER attribute is a dummy procedure pointer." Quotes from the Fortran 2015 draft J3/14-007r2.
[Bug tree-optimization/40211] 12.2 SSA Operands needs to be updated for tuples
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40211 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-03 Summary|13.2 SSA Operands needs to |12.2 SSA Operands needs to |be updated for tuples |be updated for tuples Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed, it is 12.2 now: https://gcc.gnu.org/onlinedocs/gccint/SSA-Operands.html#SSA-Operands tree stmt is wrong, it should be gimple stmt instead.
[Bug ada/64486] New: Failure building cross compiler for arm-eabi (system.ads)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64486 Bug ID: 64486 Summary: Failure building cross compiler for arm-eabi (system.ads) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Both GCC 4.9.1 and GNAT GPL 2014 fail to build a cross-compiler to arm-eabi based on gcc-5-20141228. gcc -c -g -O2 -gnatpg -gnata -W -Wall -nostdinc -I- -I. -Iada/generated -Iada -I../../gcc-5-20141228/gcc/ada -I../../gcc-5-20141228/gcc/ada/gcc-interface ../../gcc-5-20141228/gcc/ada/system.ads -o ada/system.o system.ads:53:11: warning: unrecognized pragma "No_Elaboration_Code_All" make[2]: *** [ada/system.o] Error 1 The configuration command was $ ../gcc-5-20141228/configure --build=x86_64-apple-darwin13 --target=arm-eabi --prefix=/Users/simon/local-arm --with-stage1-libs=no --with-stage1-ldflags=no --with-cpu=cortex-m4 --with-fpu=fpv4-sp-d16 --with-float=hard --with-mode=thumb --enable-interwork --enable-multilib --enable-languages=c,c++,ada --with-system-zlib --with-newlib --with-libgloss --disable-shared --disable-nls --disable-libada --with-gnu-as --with-gnu-ld --with-bugurl=URL:mailto:si...@pushface.org I worked round by wrapping the offending line in pragma Warnings (Off), pragma Warnings (On).
[Bug ada/64486] Failure building cross compiler for arm-eabi (system.ads)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64486 --- Comment #1 from Andrew Pinski --- You need a GCC 5 gnat to begin with.
[Bug ada/64486] Failure building cross compiler for arm-eabi (system.ads)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64486 simon at pushface dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from simon at pushface dot org --- Of course I do. Sorry.
[Bug bootstrap/63539] libgo does not use the newly built objcopy when doing a combined build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63539 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #7 from Andrew Pinski --- Fixed.
[Bug bootstrap/63539] libgo does not use the newly built objcopy when doing a combined build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63539 --- Comment #6 from Andrew Pinski --- Author: pinskia Date: Sat Jan 3 22:50:48 2015 New Revision: 219165 URL: https://gcc.gnu.org/viewcvs?rev=219165&root=gcc&view=rev Log: 2015-01-03 Andrew Pinski Bug #63539 * Makefile.def (flags_to_pass): Pass OBJCOPY_FOR_TARGET also. * Makefile.tpl (HOST_EXPORTS): Add OBJCOPY_FOR_TARGET. (BASE_TARGET_EXPORTS): Add OBJCOPY. (OBJCOPY_FOR_TARGET): New variable. (EXTRA_TARGET_FLAGS): Add OBJCOPY. * Makefile.in: Regenerate. * configure.ac: Check for already installed target objcopy. Also GCC_TARGET_TOOL on objcopy. * configure: Regenerate. Modified: trunk/ChangeLog trunk/Makefile.def trunk/Makefile.in trunk/Makefile.tpl trunk/configure trunk/configure.ac
[Bug fortran/63552] [OOP] Type-bound procedures rejected as actual argument to dummy procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63552 --- Comment #8 from Ian Harvey --- For clarity - there is a difference between a procedure as an actual argument and a procedure reference (something with parentheses and maybe arguments following) that is part of an expression that is an actual argument. See also definition of "procedure reference" in 1.3.123.4 - noting reference "requires execution at that point". A procedure as an actual argument does not require execution of the procedure at the time of argument association (a procedure reference may occur later through the corresponding dummy procedure). The syntax rule for an /actual-arg/ in 14-007r2 is R1225. None of the child syntax rules of R1225 permit a type bound procedure, noting that a binding of a type is not a component of a type. R1223 in 14-007r2 is only used in the forms of procedure reference (/function-reference/ or /call-stmt/). It is not relevant to procedures as actual arguments.
[Bug c++/64487] New: internal compiler error: in fold_offsetof_1, at c-family/c-common.c:9857
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64487
Bug ID: 64487
Summary: internal compiler error: in fold_offsetof_1, at
c-family/c-common.c:9857
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matthias.hochsteger at tuwien dot ac.at
The C++ file:
#include
struct foo {
int member;
};
template < int N>
struct bar {};
template
struct qux {
static bar static_member;
};
template
bar qux::static_member;
int main() { }
>g++ -c foo.cpp
Error message:
foo.cpp:16:6: internal compiler error: in fold_offsetof_1, at
c-family/c-common.c:9857
The code compiles with GCC 4.4.7, but fails to compile with all other tested
versions (4.6, 4.7, 4.8, 4.9, 5.0).
Tested versions:
- GCC 4.4.7
=
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.4.7-8ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran --prefix=/usr --program-suffix=-4.4
--enable-shared --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--disable-libmudflap --disable-werror --with-arch-32=i686 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.7 (Ubuntu/Linaro 4.4.7-8ubuntu1)
- GCC 4.6.4
=
Using built-in specs.
COLLECT_GCC=g++-4.6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.4-6ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.4 (Ubuntu/Linaro 4.6.4-6ubuntu2)
- GCC 4.7.4
=
Using built-in specs.
COLLECT_GCC=g++-4.7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.4-2ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-gnu-unique-object --disable-libmudflap --enable-plugin
--with-system-zlib --enable-objc-gc --with-cloog --enable-cloog-backend=ppl
--disable-cloog-version-check --disable-ppl-version-check --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.4 (Ubuntu/Linaro 4.7.4-2ubuntu1)
- GCC 4.8.3
=
Using built-in specs.
COLLECT_GCC=g++-4.8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.3-12ubuntu3'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=
[Bug testsuite/62250] FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=lib -O2 -lcaf_single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62250 --- Comment #2 from John David Anglin --- Author: danglin Date: Sun Jan 4 01:22:54 2015 New Revision: 219171 URL: https://gcc.gnu.org/viewcvs?rev=219171&root=gcc&view=rev Log: PR testsuite/62250 * lib/gfortran.exp: Add libatomic library search path. * gfortran.dg/coarray/caf.exp: Add -latomic to test options. * gfortran.dg/coarray_lib_comm_1.f90: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/coarray/caf.exp trunk/gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90 trunk/gcc/testsuite/lib/gfortran.exp
[Bug testsuite/62250] FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=lib -O2 -lcaf_single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62250 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from John David Anglin --- Fixed.
[Bug c++/56126] -fno-exceptions should activate -fcheck-new or issue diagnostic for all new operators without throw()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126 --- Comment #5 from Michael Bruck --- @Olaf "5.3.4 New 13 [Note: unless an allocation function is declared with a non-throwing exception-specification (15.4), it indicates failure to allocate storage by throwing a std::bad_alloc exception (Clause 15, 18.6.2.1); it returns a non-null pointer otherwise. If the allocation function is declared with a non-throwing exception-specification, it returns null to indicate failure to allocate storage and a non-null pointer otherwise. —end note] If the allocation function returns null, initialization shall not be done, the deallocation function shall not be called, and the value of the new-expression shall be null."
[Bug fortran/63494] ICE with deferred-character-length component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63494 Bud Davis changed: What|Removed |Added CC||bdavis at gcc dot gnu.org --- Comment #3 from Bud Davis --- type :: lrStringType character(:), allocatable :: a end type type(lrStringType), allocatable :: storage(:) storage(1)%a(j+2:) ='a' end I think the above is a bit more concise representative of the problem.
[Bug fortran/63494] ICE with deferred-character-length component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63494 --- Comment #4 from Bud Davis --- my comment sounded snarky; not intended. I did not know that you were also reducing this test case !!! This page was 'stale' in my browser when i added the comment. --bud
