[Bug ipa/67280] [5 Regression] wrong C++11 code generated on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67280 Ramana Radhakrishnan changed: What|Removed |Added Component|target |ipa --- Comment #4 from Ramana Radhakrishnan --- It's really an IPA issue.
[Bug c++/67487] ICE: Illegal instruction, header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67487 --- Comment #2 from mazen@uni-ulm.de --- The node I was trying to compile the program at uses an AMD Opteron with the x86-64 instruction set. I listed the detailed CPU information below, in case it is useful. Here is the backtrace and disassembly. (gdb) bt #0 0x010d7fa8 in __gmpn_popcount () #1 0x010bfa94 in parsed_string_to_mpfr () #2 0x010c0311 in mpfr_strtofr () #3 0x00a1bb8e in real_from_string(real_value*, char const*) () #4 0x00a1c5dd in real_from_string3(real_value*, char const*, machine_mode) () #5 0x0073c024 in interpret_float(cpp_token const*, unsigned int, char const*, overflow_type*) () #6 0x0073cccd in c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int) () #7 0x0065ff40 in cp_lexer_get_preprocessor_token(cp_lexer*, cp_token*) () #8 0x0068ee89 in c_parse_file() () #9 0x007418a3 in c_common_parse_file() () #10 0x00aa0f32 in compile_file() () #11 0x00aa2c1f in toplev::main(int, char**) () #12 0x0103418a in main () (gdb) disassemble Dump of assembler code for function __gmpn_popcount: 0x010d7f40 <+0>: lea(%rdi,%rsi,8),%rdi 0x010d7f44 <+4>: imul $0x,%esi,%ecx 0x010d7f47 <+7>: and$0x7,%ecx 0x010d7f4a <+10>:neg%rsi 0x010d7f4d <+13>:mov%ecx,%eax 0x010d7f4f <+15>:neg%rax 0x010d7f52 <+18>:lea(%rdi,%rax,8),%rdi 0x010d7f56 <+22>:xor%eax,%eax 0x010d7f58 <+24>:lea(%rcx,%rcx,4),%rcx 0x010d7f5c <+28>:lea0x1d(%rip),%rdx# 0x10d7f80 <__gmpn_popcount+64> 0x010d7f63 <+35>:lea(%rdx,%rcx,2),%rdx 0x010d7f67 <+39>:jmpq *%rdx 0x010d7f69 <+41>:nopl 0x0(%rax,%rax,1) 0x010d7f71 <+49>:data16 data16 data16 data16 data16 nopw %cs:0x0(%rax,%rax,1) 0x010d7f80 <+64>:popcnt 0x0(%rdi,%rsi,8),%r8 0x010d7f87 <+71>:add%r8,%rax 0x010d7f8a <+74>:popcnt 0x8(%rdi,%rsi,8),%r9 0x010d7f91 <+81>:add%r9,%rax 0x010d7f94 <+84>:popcnt 0x10(%rdi,%rsi,8),%r8 0x010d7f9b <+91>:add%r8,%rax 0x010d7f9e <+94>:popcnt 0x18(%rdi,%rsi,8),%r9 0x010d7fa5 <+101>: add%r9,%rax => 0x010d7fa8 <+104>: popcnt 0x20(%rdi,%rsi,8),%r8 0x010d7faf <+111>: add%r8,%rax 0x010d7fb2 <+114>: popcnt 0x28(%rdi,%rsi,8),%r9 0x010d7fb9 <+121>: add%r9,%rax 0x010d7fbc <+124>: popcnt 0x30(%rdi,%rsi,8),%r8 0x010d7fc3 <+131>: add%r8,%rax 0x010d7fc6 <+134>: popcnt 0x38(%rdi,%rsi,8),%r9 0x010d7fcd <+141>: add%r9,%rax 0x010d7fd0 <+144>: add$0x8,%rsi 0x010d7fd4 <+148>: js 0x10d7f80 <__gmpn_popcount+64> 0x010d7fd6 <+150>: retq End of assembler dump. Here is the CPU info. processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 37 model name : AMD Opteron(tm) Processor 252 stepping: 1 cpu MHz : 2611.975 cache size : 1024 KB physical id : 0 siblings: 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow rep_good extd_apicid pni lahf_lm bogomips: 5223.95 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 37 model name : AMD Opteron(tm) Processor 252 stepping: 1 cpu MHz : 2611.975 cache size : 1024 KB physical id : 1 siblings: 1 core id : 0 cpu cores : 1 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow rep_good extd_apicid pni lahf_lm bogomips: 5222.97 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp
[Bug c++/67491] New: [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug ID: 67491 Summary: [meta-bug] concepts issues Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: paolo.carlini at oracle dot com Target Milestone: ---
[Bug rtl-optimization/67462] [6 Regression] FAIL: gcc.dg/ifcvt-3.c scan-rtl-dump ce1 "3 true changes made"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67462 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-08 Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- This is just a failure to if-convert with -m32 due to costs. The costing logic deems it to not be profitable, which may well be a valid decision to make. In this case, if-converting would actually always be profitable as the code: s64 d = a - b; if (d == 0) return a + c; else return b + d + c; can be simplified to just "a + c" but that's not something we can see in ifcvt (shouldn't the tree-level optimizers catch this earlier?). I propose to skip the testcase for -m32, what is the standard way of specifying that in the testsuite?
[Bug c++/66844] [c++-concepts] Requires-expression parameter with void type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66844 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-08 CC|Casey at Carter dot net| Blocks||67491 Ever confirmed|0 |1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 [Bug 67491] [meta-bug] concepts issues
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-08 Ever confirmed|0 |1
[Bug target/67462] [6 Regression] FAIL: gcc.dg/ifcvt-3.c scan-rtl-dump ce1 "3 true changes made"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67462 ktkachov at gcc dot gnu.org changed: What|Removed |Added Component|rtl-optimization|target --- Comment #2 from ktkachov at gcc dot gnu.org --- IMO this is a target issue. If you think if-conversion should happen for -m32 then the backend costs should be fixed. If not, then this test should be skipped.
[Bug fortran/46310] [F03] gfortran wrongly treats INTERFACE BLOCK and not INTERFACE BODY as scoping unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46310 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-08 Blocks||20585 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- > That makes sense; thus, either remove INTENT(IN) from or add POINTER > to the example. Sorry for the wrong/incomplete example. Confirmed with module foo_module implicit none interface real function func_interface() end function subroutine bar_interface(f) import func_interface implicit none procedure(func_interface) :: f end subroutine end interface end module Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585 [Bug 20585] [meta-bug] Fortran 2003 support
[Bug c++/67319] Short-hand concepts for variadic member functions broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67319 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-08 Ever confirmed|0 |1
[Bug fortran/41107] [F03] Proc-pointer components: Fix calling DECL for f2c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41107 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-09-08 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- > A bit more explanation would be good here :-) Agreed!-(no answer for more than four years).
[Bug c++/67384] [concepts] More fun with deduction constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67384 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-08 Ever confirmed|0 |1
[Bug c++/67427] [concepts] Subsumption dependence on template parameter ordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67427 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-08 Ever confirmed|0 |1
[Bug fortran/49636] [F03] ASSOCIATE construct confused with slightly complicated case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49636 Dominique d'Humieres changed: What|Removed |Added Blocks||20585 --- Comment #7 from Dominique d'Humieres --- Ping! Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585 [Bug 20585] [meta-bug] Fortran 2003 support
[Bug fortran/25708] [F95] Module loading is not good at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING --- Comment #24 from Dominique d'Humieres --- I wonder if this PR has not been fixed by recent changes.
[Bug fortran/40881] [F03] warn for obsolescent features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40881 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING Blocks||20585 --- Comment #13 from Dominique d'Humieres --- > I'm not really sure if it makes sense to add a warning for fixed source, > but I'm leaving this PR open, in case someone will consider it in the future. IMO it does not make sense to warn for fixed form. Any objection to close this PR as FIXED? Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585 [Bug 20585] [meta-bug] Fortran 2003 support
[Bug c/67492] New: insn-attrtab and insn-automata for arm target neede huge amount of memory to generate/compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67492 Bug ID: 67492 Summary: insn-attrtab and insn-automata for arm target neede huge amount of memory to generate/compile Product: gcc Version: 4.9.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: michael at weiser dot dinsnail.net Target Milestone: --- Created attachment 36305 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36305&action=edit disable some CPU support in the arm target to reduce memory usage during compiler compilation I run Gentoo Linux on an embedded arm box with 128MB of RAM. This routinely includes compiling gcc for it. Up to 4.9.3 that would require 400MB of swap and take about two days. With 4.9.3 the situation has escalated in so far that even 500MB of swap aren't enough any more. Upon closer inspection I found that generation and compilation of insn-attrtab.c and insn-automata.c are huge memory hogs. Instead of even trying to unserstand the internals of those, I've patched support for all Cortex CPUs and some others out of the arm target to see what'd happen to memory usage. This reduced the size of insn-attrtab.c from 1,1MB to 700KB and more noticeably insn-automata.c from 7,5MB to 160KB. Generation of the source as well as compilation don't push the machine nearly as much into the swap as before and compilation succeeds. I suspect, 99% of people compiling their own compiler on a memory-constrained box will only ever want to compile for that box. So is how hard would it be or is there even some effort/patch to make gcc only compile in support for a selected number of CPUs of a given target, indirectly reducing size of insn-attrtab/insn-automata? Incidentally: Is my patch likely to produce a seriously broken compiler? (It seems fine so far.)
[Bug fortran/65921] GFortran should use __builtin_mul_overflow when checking allocation sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65921 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-08 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Marked as NEW.
[Bug target/67492] insn-attrtab and insn-automata for arm target neede huge amount of memory to generate/compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67492 Andrew Pinski changed: What|Removed |Added Component|c |target --- Comment #1 from Andrew Pinski --- 400MB of swap is nothing really. >memory-constrained box Those don't exist any more. Memory is cheap.
[Bug c++/67487] ICE: Illegal instruction, header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67487 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Markus Trippelsdorf --- Your CPU doesn't support popcnt (was implemented for Barcelona). Please reconfigure and rebuild the GMP library for your machine.
[Bug c++/67487] ICE: Illegal instruction, header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67487 --- Comment #4 from mazen@uni-ulm.de --- Ok, thanks Markus.
[Bug fortran/66244] ICE on assigning a value to a pointer variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66244 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-08 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (6.0). Note that the error for trunk configured with the default value of --enable-checking is f951: internal compiler error: in get, at cgraph.h:371
[Bug c++/67487] ICE: Illegal instruction, header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67487 --- Comment #5 from Markus Trippelsdorf --- And please do the same also for MPFR.
[Bug fortran/66155] Macro not replaced after multi-line string constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66155 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-08 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed. Could you please check that it is not a duplicate.
[Bug target/67492] insn-attrtab and insn-automata for arm target neede huge amount of memory to generate/compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67492 --- Comment #2 from Michael Weiser --- (In reply to Andrew Pinski from comment #1) > >memory-constrained box > Those don't exist any more. Memory is cheap. Yeah they do. Please read: > embedded arm box And the RAM chips are soldered on.
[Bug fortran/66094] Handle transpose(A) in inline matmul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66094 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-08 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Marked as NEW (Note that 'at' should be replaced with 'a'!-).
[Bug target/67492] insn-attrtab and insn-automata for arm target neede huge amount of memory to generate/compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67492 --- Comment #3 from Andrew Pinski --- And you should not be compiling a compiler on the embedded arm machine really. That is not what they are designed for really.
[Bug fortran/65889] ICE on invalid(?) with sizeof polymorphic variable [OOP]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65889 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-09-08 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed for trunk (6.0). The code compiles with 4.8 up to 5.2 and AFAICT gives a sensible result. Thus this PR is a regression if the use of sizeof is valid. If it is invalid then the behavior of 4.9 and 5.2 is wrong.
[Bug fortran/67493] New: -fcheck=recursive not thread aware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67493
Bug ID: 67493
Summary: -fcheck=recursive not thread aware
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: franke.daniel at gmail dot com
Target Milestone: ---
Hi all.
It seems that the checks done by -fcheck=recursive are not thread aware. In the
example below, the PURE procedure 'worker' is not called recursively, but in
parallel, still the recursion check triggers. I believe that there should be no
error in such a situation.
To note: declaring 'worker' RECURSIVE or not using -fcheck-recursive does not
trigger any runtime errors.
$ cat worker.f90
PURE SUBROUTINE worker(n, sumn) BIND(C)
USE ISO_C_BINDING
INTEGER(C_INT), INTENT(in) :: n
INTEGER(C_INT), INTENT(out) :: sumn
INTEGER :: k
sumn = 0
DO k = 1, n
sumn = sumn + k
END DO
END SUBROUTINE
$ cat main.c
#include
void worker(int*, int*);
void* controller(void *p) {
int n = 10, sumn;
worker(&n, &sumn);
}
int main(int argc, char **argv) {
pthread_t t1, t2;
pthread_create(&t1, NULL, controller, NULL);
pthread_create(&t2, NULL, controller, NULL);
pthread_join(t1, NULL);
pthread_join(t2, NULL);
return 0;
}
$ gfortran --version
[...]
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)
$ gfortran main.c worker.f90 -fcheck=recursion -lpthread && ./a.out
At line 3 of file worker.f90
Fortran runtime error: Recursive call to nonrecursive procedure 'worker'
$ gfortran --version
GNU Fortran (GCC) 5.2.0
$ gfortran main.c worker.f90 -fcheck=recursion -lpthread && ./a.out
At line 1 of file worker.f90
Fortran runtime error: Recursive call to nonrecursive procedure 'worker'
[Bug target/67492] insn-attrtab and insn-automata for arm target neede huge amount of memory to generate/compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67492 --- Comment #4 from Michael Weiser --- Okay, I can see this is headed for a WONTFIX. Can you please answer my questions before we chuck it? 1. How hard would it be or is there even some effort/patch to make gcc only compile in support for a selected number of CPUs of a given target, indirectly reducing size of insn-attrtab/insn-automata? 2. Incidentally: Is my patch likely to produce a seriously broken compiler? Thanks!
[Bug target/67492] insn-attrtab and insn-automata for arm target neede huge amount of memory to generate/compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67492 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktkachov at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #5 from ktkachov at gcc dot gnu.org --- (In reply to Michael Weiser from comment #4) > Okay, I can see this is headed for a WONTFIX. Can you please answer my > questions before we chuck it? > > 1. How hard would it be or is there even some effort/patch to make gcc only > compile in support for a selected number of CPUs of a given target, > indirectly reducing size of insn-attrtab/insn-automata? There's no effort to do that that I know of. There are ways to reduce the automaton size, but that involves modifying the pipeline descriptions (.md files) and as such would require a lot of benchmarking/validation to make sure it doesn't regress code quality. > > 2. Incidentally: Is my patch likely to produce a seriously broken compiler? Well, it's definitely not appropriate for submission upstream. Just removing cores is not the way to go. If that's a patch you want to use privately for your arm board and you only ever expect to compile for a single -mcpu then I suppose it may work, but don't expect any support for it ;) > > Thanks!
[Bug fortran/65086] Segfault: Invalid copy-out of temporary as argument is in read-only memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65086 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-08 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (6.0).
[Bug fortran/66107] ICE on missing parameter value for initialisation (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66107 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-08 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- I confirm the ICE with 5.2 and trunk (6.0). The first code in comment 0 is accepted by 4.8 and 4.9 which looks wrong.
[Bug c++/67369] [5/6 Regression] ICE (in tsubst_decl, at cp/pt.c:11302) with -std=c++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67369 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from Paolo Carlini --- Mine.
[Bug fortran/66762] ICE when compiling gfortran.dg/submodule_[16].f90 with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66762
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #7 from Martin Liška ---
I tried to investigate:
gfortran ./gcc/testsuite/gfortran.dg/submodule_6.f08 -flto
If I compare corresponding argument passed to output_addr_const w/o LTO, I see:
(const_int 54796891 [0x344225b])
,instead of:
(mem/u/f/c:DI (symbol_ref/f:DI ("*.LC0") [flags 0x2] ) [0 S8 A64])
Thus it looks for me that in case of LTO, it is unable to resolve offset of the
variable *.LC0:
unit size
align 8 symtab 0 alias set 0 canonical type 0x76e1ef18 context
pointer_to_this chain >
unsigned DI
size
unit size
align 64 symtab 0 alias set 0 canonical type 0x76c44738>
readonly addressable static unsigned ignored in-constant-pool DI file
(null) line 0 col 0 size unit size
align 64 initial >
Martin
[Bug fortran/66056] ICEs and endless compilation for lonely labels/numbers in type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66056 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-08 Ever confirmed|0 |1 --- Comment #5 from Dominique d'Humieres --- I confirm the ICE for 4.8 up to trunk (6.0), but all the tests compiles in a fraction of second.
[Bug fortran/66575] Endless compilation on missing end interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66575 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |NEW --- Comment #4 from Dominique d'Humieres --- I confirm the endless compilation for the tests in comment 3 with 4.8 up to trunk (6.0).
[Bug fortran/67454] GCC-5.2.0 `GCC_4.3.0' not found (required by file /usr/local/add-on/gcc/lib/libgfortran.so.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67454 --- Comment #2 from James Ballantine --- I downloaded the source tar file from the gnu gcc repository. As I stated 4.3.0 is not on the system, the latest version of gcc is 3.4.6. I don't have any fortran code, the failure was during the build of the R-3.2.2 package
[Bug fortran/52176] Valgrind complains about some realloc on assignment to unallocated LHS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52176 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dominique d'Humieres --- I no longer see the valgrind problem from 4.9.3 up to trunk (6.0). the test also runs without error if compiled with -fsanitize=address. Closing as FIXED.
[Bug fortran/67454] GCC-5.2.0 `GCC_4.3.0' not found (required by file /usr/local/add-on/gcc/lib/libgfortran.so.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67454 --- Comment #3 from Dominique d'Humieres --- > I downloaded the source tar file from the gnu gcc repository. > As I stated 4.3.0 is not on the system, the latest version of gcc is 3.4.6. Am I correct to understand that you built gcc5.2 yourself using gcc3.4.6 as the bootstrap compiler? > I don't have any fortran code, the failure was during the build of > the R-3.2.2 package Could you post the outputs of which gfortran and gfortran -v Do you still have the directory in which R is built? If yes, you should find fortran codes inside it.
[Bug fortran/67454] GCC-5.2.0 `GCC_4.3.0' not found (required by file /usr/local/add-on/gcc/lib/libgfortran.so.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67454 --- Comment #4 from James Ballantine --- Yes, I built it on a solaris10 system. ODIN $ which gfortran /usr/local/add-on/gcc/bin/gfortran ODIN $ /usr/local/add-on/gcc/bin/gfortran -v Using built-in specs. COLLECT_GCC=/usr/local/add-on/gcc/bin/gfortran COLLECT_LTO_WRAPPER=/usr/local/add-on/gcc-5.2.0/libexec/gcc/sparc-sun-solaris2.10/5.2.0/lto-wrapper Target: sparc-sun-solaris2.10 Configured with: ../configure --prefix=/usr/local/add-on/gcc-5.2.0 --with-as=/usr/local/add-on/binutils/bin/as --with-ld=/usr/local/add-on/binutils/bin/ld Thread model: posix gcc version 5.2.0 (GCC)
[Bug fortran/67454] GCC-5.2.0 `GCC_4.3.0' not found (required by file /usr/local/add-on/gcc/lib/libgfortran.so.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67454 --- Comment #5 from Dominique d'Humieres --- > As I stated 4.3.0 is not on the system, ... Has it been? Am I correct to understand that gap, mpfr, ... are built from your source tree?
[Bug rtl-optimization/15473] Sibcall optimization for libcalls.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15473
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
Version|4.0.0 |6.0
--- Comment #5 from H.J. Lu ---
Some libcalls are expanded in
static rtx
expand_builtin_unop (machine_mode target_mode, tree exp, rtx target,
rtx subtarget, optab op_optab)
{
rtx op0;
if (!validate_arglist (exp, INTEGER_TYPE, VOID_TYPE))
return NULL_RTX;
/* Compute the argument. */
op0 = expand_expr (CALL_EXPR_ARG (exp, 0),
(subtarget
&& (TYPE_MODE (TREE_TYPE (CALL_EXPR_ARG (exp, 0)))
== GET_MODE (subtarget))) ? subtarget : NULL_RTX,
VOIDmode, EXPAND_NORMAL);
/* Compute op, into TARGET if possible.
Set TARGET to wherever the result comes back. */
target = expand_unop (TYPE_MODE (TREE_TYPE (CALL_EXPR_ARG (exp, 0))),
op_optab, op0, target, op_optab != clrsb_optab);
gcc_assert (target);
return convert_to_mode (target_mode, target, 0);
}
which doesn't go through expand_call.
[Bug tree-optimization/67470] [5/6 Regression] ICE at -O3 on x86_64-linux-gnu in compute_live_loop_exits, at tree-ssa-loop-manip.c:235
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67470 --- Comment #3 from Martin Jambor --- (In reply to Marek Polacek from comment #1) > Confirmed. Started with r212034 (interesting). Even the revision before that ICEs with --param allow-store-data-races=0
[Bug tree-optimization/67470] [5/6 Regression] ICE at -O3 on x86_64-linux-gnu in compute_live_loop_exits, at tree-ssa-loop-manip.c:235
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67470 --- Comment #4 from Marek Polacek --- With --param allow-store-data-races=0 the ICE started with r211625.
[Bug target/67492] insn-attrtab and insn-automata for arm target neede huge amount of memory to generate/compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67492 --- Comment #6 from Michael Weiser --- Right. Thanks for the quick responses!
[Bug fortran/65819] overzealous checking in gfc_check_dependency for identical=true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65819 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-09-08 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Test case?
[Bug fortran/67454] GCC-5.2.0 `GCC_4.3.0' not found (required by file /usr/local/add-on/gcc/lib/libgfortran.so.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67454 --- Comment #6 from James Ballantine --- Gcc-4.3.0 has never been on the system as other then the source code for 4.3.2, in a directory not in any $PATH. Yes gmp, mpfr, ... are all in the top level directory tree.
[Bug fortran/66708] Possible (minor) improvement on formatted io with format too short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66708 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-08 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Marked as NEW with low priority. Related to pr28397.
[Bug fortran/28397] Check format mismatches at compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28397 --- Comment #5 from Dominique d'Humieres --- See also pr66708.
[Bug fortran/67454] GCC-5.2.0 `GCC_4.3.0' not found (required by file /usr/local/add-on/gcc/lib/libgfortran.so.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67454 --- Comment #7 from Dominique d'Humieres --- > Gcc-4.3.0 has never been on the system as other then the source code > for 4.3.2, in a directory not in any $PATH. Well, if you build everything yourself and you see some pointer to 4.3.0, it means that you have used 4.3.0 at some point and you have left over. Note that gcc has /usr/lib /usr/local/lib in the library search paths. From experience I know that /usr/local is some kind of evil.
[Bug fortran/67454] GCC-5.2.0 `GCC_4.3.0' not found (required by file /usr/local/add-on/gcc/lib/libgfortran.so.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67454 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #8 from Andrew Pinski --- Note the 4.3.0 is not referencing to 4.3.0 being installed. But rather you need to use libgcc_s.so from GCC 5.2 for libgfortran from GCC 5.2 to work. That is setup correctly LD_LIBRARY_PATH, etc.
[Bug fortran/67454] GCC-5.2.0 `GCC_4.3.0' not found (required by file /usr/local/add-on/gcc/lib/libgfortran.so.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67454 --- Comment #9 from Andrew Pinski --- Also make sure the paths that R generate are correctly referencing the correct one. Use ldd to see. It sounds like somewhere the LD_LIBRARY_PATH is not unset or being ignored.
[Bug other/67457] segfault in libbacktrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67457 --- Comment #1 from ian at gcc dot gnu.org --- Author: ian Date: Tue Sep 8 13:49:19 2015 New Revision: 227529 URL: https://gcc.gnu.org/viewcvs?rev=227529&root=gcc&view=rev Log: PR other/67457 * mmap.c (backtrace_alloc): Correct test for mmap failure. Modified: trunk/libbacktrace/ChangeLog trunk/libbacktrace/mmap.c
[Bug ada/67494] New: xsinfo sanitizer detects overlapping strings in assignment statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67494 Bug ID: 67494 Summary: xsinfo sanitizer detects overlapping strings in assignment statement Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com Target Milestone: --- The sanitizer detects overlapping strings in the assignemnt statement DR.Data (1 .. Source'Length) := Source; in a-strunb.adb:1456. The following is the sanitizer snapshot during gcc build (cd ada/bldtools/sinfo; gnatmake -q xsinfo ; ./xsinfo sinfo.h ) Check for field name consistency OK Check for function consistency OK Check for missing functions OK Check for set procedure consistency OK Check for missing set procedures OK Check pragma Inlines are all for existing subprograms = ==7358==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges [0x6041329c,0x604132aa) and [0x604132a0, 0x604132ae) overlap #0 0x2adcc5f71762 in __asan_memcpy ../../../../gcc-5.2.0/libsanitizer/asan/asan_interceptors.cc:365 #1 0x42bed0 in ada__strings__unbounded__set_unbounded_string /home/vitti/gcc-5.2.0-obj/gcc/ada/rts/a-strunb.adb:1456 #2 0x442c2a in gnat__spitbol__patterns__xmatch /home/vitti/gcc-5.2.0-obj/gcc/ada/rts/g-spipat.adb:4066 #3 0x4435ba in gnat__spitbol__patterns__match /home/vitti/gcc-5.2.0-obj/gcc/ada/rts/g-spipat.adb:2806 #4 0x40ae6e in _ada_csinfo (/home/vitti/1tb/vitti/gcc-5.2.0-undefined/gcc/ada/bldtools/sinfo/xsinfo+0x40ae6e) #5 0x41ba7f in _ada_xsinfo (/home/vitti/1tb/vitti/gcc-5.2.0-undefined/gcc/ada/bldtools/sinfo/xsinfo+0x41ba7f) #6 0x402b05 in main (/home/vitti/1tb/vitti/gcc-5.2.0-undefined/gcc/ada/bldtools/sinfo/xsinfo+0x402b05) #7 0x390da1ffdf in __libc_start_main (/lib64/libc.so.6+0x390da1ffdf) #8 0x4025f3 (/home/vitti/1tb/vitti/gcc-5.2.0-undefined/gcc/ada/bldtools/sinfo/xsinfo+0x4025f3) 0x6041329c is located 12 bytes inside of 48-byte region [0x60413290,0x604132c0) allocated by thread T0 here: #0 0x2adcc5f7d509 in __interceptor_malloc ../../../../gcc-5.2.0/libsanitizer/asan/asan_malloc_linux.cc:38 #1 0x458a10 in __gnat_malloc /home/vitti/gcc-5.2.0-obj/gcc/ada/rts/s-memory.adb:92 #2 0x6066157f () 0x604132a0 is located 16 bytes inside of 48-byte region [0x60413290,0x604132c0) allocated by thread T0 here: #0 0x2adcc5f7d509 in __interceptor_malloc ../../../../gcc-5.2.0/libsanitizer/asan/asan_malloc_linux.cc:38 #1 0x458a10 in __gnat_malloc /home/vitti/gcc-5.2.0-obj/gcc/ada/rts/s-memory.adb:92 #2 0x6066157f () SUMMARY: AddressSanitizer: memcpy-param-overlap ../../../../gcc-5.2.0/libsanitizer/asan/asan_interceptors.cc:365 __asan_memcpy ==7358==ABORTING /home/vitti/gcc-5.2.0/gcc/ada/Make-generated.in:42: recipe for target 'ada/sinfo.h' failed
[Bug fortran/67454] GCC-5.2.0 `GCC_4.3.0' not found (required by file /usr/local/add-on/gcc/lib/libgfortran.so.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67454 --- Comment #10 from James Ballantine --- Dominique, The way this system is managed, is that all packages that are not "official" ones are put in a separate add-on directory which are then added to the front of paths, or before the /usr "standard" directories. So I can see what source was download, built and installed, and while gcc-4.3.2 was built, it was not installed, and the prefix in the Makefile is /usr/local/add-on/gcc-4.3.2, which doesn't exist: ODIN $ ls /usr/local/add-on/gcc-4.3.2 /usr/local/add-on/gcc-4.3.2: No such file or directory As for /usr/local/lib and /usr/lib(/libgcc_s.so.1) here is what is on the system: ODIN $ ls /usr/local/lib X11@aliases diff3* libv9.a oprsub* pine.conf ODIN $ ls /usr/lib/libgcc* /usr/lib/libgcc*: No such file or directory Andrew, As I stated in my intial report, the LD_LIBRARY_PATH does include the GCC_5.2.0 lib directory.
[Bug other/67457] segfault in libbacktrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67457 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Ian Lance Taylor --- I committed a patch so that libbacktrace should no longer segfault when no memory is available. If other compilers can print a backtrace when mmap fails, then I think they must be recording all necessary information in loadable sections. When no memory is available we could print a trace of PC addresses, but it would be very painful to print file/line information. We could stage the I/O through a static buffer, but finding the information to print without being able to build any data structures would be very inefficient.
[Bug fortran/67454] GCC-5.2.0 `GCC_4.3.0' not found (required by file /usr/local/add-on/gcc/lib/libgfortran.so.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67454 --- Comment #11 from Andrew Pinski --- Can you run ldd on the R and show the output, I bet something is going wrong and it is picking up against the wrong libgcc_s.so.
[Bug c/67495] New: #pragma omp atomic ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67495
Bug ID: 67495
Summary: #pragma omp atomic ICEs
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, openmp
Severity: normal
Priority: P3
Component: c
Assignee: jakub at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
int a, b, c;
void
foo (void)
{
#pragma omp atomic capture
a = (float)a + b;/* { dg-do error "invalid operator" } */
#pragma omp atomic read
(float) a = b;/* { dg-do error "lvalue required" } */
#pragma omp atomic write
(float) a = b;/* { dg-do error "lvalue required" } */
#pragma omp atomic read
a = (float) b;/* { dg-do error "lvalue required" } */
#pragma omp atomic capture
(float) a = b += c;/* { dg-do error "lvalue required" } */
#pragma omp atomic capture
{ a += b; (float) c = a; }/* { dg-do error "lvalue required" } */
#pragma omp atomic capture
{ a += b; c = (float) a; }/* { dg-do error "uses two different expressions
for memory" } */
#pragma omp atomic capture
a = (int)a + b;/* { dg-do error "invalid operator" } */
#pragma omp atomic read
(int) a = b;/* { dg-do error "lvalue required" } */
#pragma omp atomic write
(int) a = b;/* { dg-do error "lvalue required" } */
#pragma omp atomic read
a = (int) b;/* { dg-do error "lvalue required" } */
#pragma omp atomic capture
(int) a = b += c;/* { dg-do error "lvalue required" } */
#pragma omp atomic capture
{ a += b; (int) c = a; }/* { dg-do error "lvalue required" } */
#pragma omp atomic capture
{ a += b; c = (int) a; }/* { dg-do error "lvalue required" } */
}
shows various ICEs, the common problem is that the C FE (unlike the C++ one)
relies on c_parser_unary_expression to be called only from
c_parser_cast_expression or from places which guarantee that there isn't a cast
expression in the source code (that is the case of sizeof or __alignof__).
c_parser_omp_atomic uses c_parser_unary_expression in lots of places, and does
not guarantee that.
[Bug c/67495] #pragma omp atomic ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67495 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |5.3
[Bug fortran/67454] GCC-5.2.0 `GCC_4.3.0' not found (required by file /usr/local/add-on/gcc/lib/libgfortran.so.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67454 --- Comment #12 from James Ballantine --- Andrew, This will take some time, R is just a script that executes another executable. I will post the results when I find the executable.
[Bug c/67495] #pragma omp atomic ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67495 --- Comment #1 from Jakub Jelinek --- Created attachment 36306 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36306&action=edit gcc6-pr67495.patch Untested fix.
[Bug fortran/67454] GCC-5.2.0 `GCC_4.3.0' not found (required by file /usr/local/add-on/gcc/lib/libgfortran.so.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67454 --- Comment #13 from James Ballantine --- Here is the ldd on the executable: ODIN $ ldd bin/exec/R libICE.so.6 => /usr/lib/libICE.so.6 libSM.so.6 =>/usr/lib/libSM.so.6 libRblas.so => (file not found) libgfortran.so.3 => /usr/local/add-on/gcc/lib/libgfortran.so.3 libm.so.2 => /usr/lib/libm.so.2 libreadline.so.6 => /usr/lib/libreadline.so.6 libcurses.so.1 =>/usr/lib/libcurses.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 librt.so.1 =>/usr/lib/librt.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libiconv.so.2 => /usr/lib/libiconv.so.2 libicuuc.so.3 => /usr/lib/libicuuc.so.3 libicui18n.so.3 => /usr/lib/libicui18n.so.3 libgomp.so.1 => /usr/local/add-on/gcc/lib/libgomp.so.1 libpthread.so.1 => /usr/lib/libpthread.so.1 libc.so.1 => /usr/lib/libc.so.1 libgcc_s.so.1 => /usr/local/add-on/gcc/lib/libgcc_s.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 libmd.so.1 =>/usr/lib/libmd.so.1 libscf.so.1 => /usr/lib/libscf.so.1 libaio.so.1 => /usr/lib/libaio.so.1 libicudata.so.3 => /usr/lib/libicudata.so.3 libCrun.so.1 => /usr/lib/libCrun.so.1 libdoor.so.1 => /usr/lib/libdoor.so.1 libuutil.so.1 => /usr/lib/libuutil.so.1 libgen.so.1 => /usr/lib/libgen.so.1 /platform/SUNW,SPARC-Enterprise/lib/libc_psr.so.1 And ODIN $ ls -l /usr/local/add-on/gcc lrwxrwxrwx 1 jwb staff 27 Sep 2 13:42 /usr/local/add-on/gcc -> /usr/local/add-on/gcc-5.2.0/
[Bug fortran/67454] GCC-5.2.0 `GCC_4.3.0' not found (required by file /usr/local/add-on/gcc/lib/libgfortran.so.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67454 --- Comment #14 from Andrew Pinski --- Can you double check what the shell script is doing as libRblas.so => (file not found) is worrying. Most likely there is also some ld.so debug env which you can set to see what is actually being loaded and why.
[Bug fortran/67496] New: trans-array.c sanitizer runtime error: load of value 124, which is not a valid value for type 'bool'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67496 Bug ID: 67496 Summary: trans-array.c sanitizer runtime error: load of value 124, which is not a valid value for type 'bool' Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com Target Milestone: --- !gcc-5.2.0/gcc/fortran/trans-array.c:2223:27: runtime error: load of value 124, which is not a valid value for type 'bool' ! source line "typespec_chararray_ctor = (expr->ts.u.cl && expr->ts.u.cl->length_from_typespec);" !Target: x86_64-unknown-linux-gnu type :: a end type a type :: b type (a) :: j(1) end type b type(a) :: x type(b) :: y y = b((/x/)) end
[Bug other/67457] segfault in libbacktrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67457 --- Comment #3 from Joost VandeVondele --- (In reply to Ian Lance Taylor from comment #2) > If other compilers can print a backtrace when mmap fails, then I think they > must be recording all necessary information in loadable sections. When no > memory is available we could print a trace of PC addresses, but it would be > very painful to print file/line information. We could stage the I/O through > a static buffer, but finding the information to print without being able to > build any data structures would be very inefficient. actually, just a trace of PC addresses would be sufficient and useful, it would allow to get the needed info afterwards nevertheless. This is actually what I get with the other compiler.
[Bug fortran/67497] New: data.c sanitizer runtime error: null pointer passed as argument 2, which is declared to never be null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67497 Bug ID: 67497 Summary: data.c sanitizer runtime error: null pointer passed as argument 2, which is declared to never be null Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com Target Milestone: --- !gcc-5.2.0/gcc/fortran/data.c:181:32: runtime error: null pointer passed as argument 2, which is declared to never be null ! source line "memcpy (&dest[start], rvalue->value.character.string, len * sizeof (gfc_char_t));" ! double check with "gcc_assert(rvalue->value.character.string)" immediately before ! esay fix "if(len) memcpy (&dest[start], rvalue->value.character.string, len * ! sizeof (gfc_char_t));" !Target: x86_64-unknown-linux-gnu CHARACTER, POINTER :: PTR DATA PTR / NULL() / end
[Bug fortran/67498] New: interface.c sanitizer runtime error: load of value 1818451807, which is not a valid value for type 'expr_t'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67498 Bug ID: 67498 Summary: interface.c sanitizer runtime error: load of value 1818451807, which is not a valid value for type 'expr_t' Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com Target Milestone: --- !gcc-5.2.0/gcc/fortran/interface.c:2705:33: runtime error: load of value 1818451807, which is not a valid value for type 'expr_t' ! source line "&& f->sym->ts.u.cl->length->expr_type == EXPR_CONSTANT" ! Target: x86_64-unknown-linux-gnu contains subroutine FWRite(S) class(*) :: S end subroutine subroutine IO_OutputMargeStats() character tag call FWrite(tag) end subroutine end
[Bug c++/67369] [5/6 Regression] ICE (in tsubst_decl, at cp/pt.c:11302) with -std=c++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67369 --- Comment #4 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Sep 8 15:02:01 2015 New Revision: 227530 URL: https://gcc.gnu.org/viewcvs?rev=227530&root=gcc&view=rev Log: /cp 2015-09-08 Paolo Carlini PR c++/67369 * pt.c (tsubst_copy, [case FUNCTION_DECL]): Do not call tsubst if the first argument isn't a template. /testsuite 2015-09-08 Paolo Carlini PR c++/67369 * g++.dg/cpp1y/lambda-generic-ice4.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-ice4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/67369] [5/6 Regression] ICE (in tsubst_decl, at cp/pt.c:11302) with -std=c++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67369 --- Comment #5 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Sep 8 15:02:27 2015 New Revision: 227531 URL: https://gcc.gnu.org/viewcvs?rev=227531&root=gcc&view=rev Log: /cp 2015-09-08 Paolo Carlini PR c++/67369 * pt.c (tsubst_copy, [case FUNCTION_DECL]): Do not call tsubst if the first argument isn't a template. /testsuite 2015-09-08 Paolo Carlini PR c++/67369 * g++.dg/cpp1y/lambda-generic-ice4.C: New. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/lambda-generic-ice4.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/pt.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/67454] GCC-5.2.0 `GCC_4.3.0' not found (required by file /usr/local/add-on/gcc/lib/libgfortran.so.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67454 --- Comment #15 from James Ballantine --- That is in the lib dir that is a peer of the bin dir., i.e. both directly under /usr/local/src/add-on/R-3.2.2, but then the bin/exec/R is normally run from a shell script that is bin/R, so that could be a issue because I ran ldd on the executable rather than from within the script
[Bug c++/67499] New: c++ template/overload diagnostic compression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67499
Bug ID: 67499
Summary: c++ template/overload diagnostic compression
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fche at redhat dot com
CC: dmalcolm at redhat dot com
Target Milestone: ---
It is very easy for c++ typos or errors involving templates or overloaded
functions to generate a "wall of text" of diagnostics, which overwhelm. Please
consider compressing / eliding / abbreviating ...
% cat foo.cxx
#include
class foo { int b; };
int main() {
foo bar;
std::cout << bar;
}
% g++ foo.cxx 2>&1 | wc -l
193
.. so that 193 number is closer to 1
[Bug c++/67369] [5/6 Regression] ICE (in tsubst_decl, at cp/pt.c:11302) with -std=c++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67369 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Paolo Carlini --- Fixed for 5.3.
[Bug c/52952] Wformat location info is bad (wrong column number)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952 Manuel López-Ibáñez changed: What|Removed |Added Last reconfirmed|2012-04-12 00:00:00 |2015-9-8 --- Comment #40 from Manuel López-Ibáñez --- Unreviewed patch that increases precision in some cases: https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01373.html
[Bug c++/67499] c++ template/overload diagnostic compression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67499 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf --- -Wfatal-errors is always an option.
[Bug ipa/67368] Inlining failed due to no_sanitize_address and always_inline conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368 Andrey Ryabinin changed: What|Removed |Added CC||ryabinin.a.a at gmail dot com --- Comment #3 from Andrey Ryabinin --- (In reply to Yury Gribov from comment #2) > (In reply to Richard Biener from comment #1) > > so it fails on purpose (not sure why though). And it ignores always-inline. > > I wonder if we should, for always-inline functions, inline anyway and output > > a warning instead. > > We prohibited this combination during ASan integration to kernel. Both > always_inline and no_sanitize_address are strong requirements for compiler > i.e. dropping any of these in favor of another would have unexpected effects > and hurt usability. Nope, it was prohibited because no_sanitize_address didn't work for inlined function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59600.
[Bug fortran/67454] GCC-5.2.0 `GCC_4.3.0' not found (required by file /usr/local/add-on/gcc/lib/libgfortran.so.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67454 --- Comment #16 from James Ballantine --- I've added the ldd to the R script, and now I get: ODIN $ ./My_R --version ldd: exec: cannot read file: Is a directory /usr/local/src/add-on/R-3.2.2/bin/exec/R: libICE.so.6 => /usr/openwin/lib/libICE.so.6 libSM.so.6 =>/usr/openwin/lib/libSM.so.6 libRblas.so => /usr/local/src/add-on/R-3.2.2/lib/libRblas.so libgfortran.so.3 => /usr/local/add-on/gcc/lib/libgfortran.so.3 libm.so.2 => /usr/lib/libm.so.2 libreadline.so.6 => /usr/lib/libreadline.so.6 libcurses.so.1 =>/usr/lib/libcurses.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 librt.so.1 =>/usr/lib/librt.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libiconv.so.2 => /usr/lib/libiconv.so.2 libicuuc.so.3 => /usr/lib/libicuuc.so.3 libicui18n.so.3 => /usr/lib/libicui18n.so.3 libgomp.so.1 => /usr/local/add-on/gcc/lib/libgomp.so.1 libpthread.so.1 => /usr/lib/libpthread.so.1 libc.so.1 => /usr/lib/libc.so.1 libgcc_s.so.1 => /usr/sfw/lib/libgcc_s.so.1 libgcc_s.so.1 (GCC_4.3.0) => (version not found) libgcc_s.so.1 (GCC_4.2.0) => (version not found) libmp.so.2 =>/usr/lib/libmp.so.2 libmd.so.1 =>/usr/lib/libmd.so.1 libscf.so.1 => /usr/lib/libscf.so.1 libaio.so.1 => /usr/lib/libaio.so.1 libicudata.so.3 => /usr/lib/libicudata.so.3 libCrun.so.1 => /usr/lib/libCrun.so.1 libdoor.so.1 => /usr/lib/libdoor.so.1 libuutil.so.1 => /usr/lib/libuutil.so.1 libgen.so.1 => /usr/lib/libgen.so.1 /platform/SUNW,SPARC-Enterprise/lib/libc_psr.so.1 ldd: --version: cannot open file: No such file or directory So now to find and fix the R build so it doesn't use /usr/sfw/lib.
[Bug c/67500] New: OpenMP ICE with invalid safelen/simdlen/alignment expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67500
Bug ID: 67500
Summary: OpenMP ICE with invalid safelen/simdlen/alignment
expressions
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
/* */
/* { dg-do compile } */
/* { dg-options "-fopenmp" } */
#pragma omp declare simd simdlen(d) /* { dg-error "clause expression must
be positive constant integer expression" } */
void f1 (int); /* { dg-error "undeclared here" "" {
target *-*-* } 5 } */
#pragma omp declare simd simdlen(0.5) /* { dg-error "clause expression must
be positive constant integer expression" } */
void f2 (int);
#pragma omp declare simd simdlen(-2)/* { dg-error "clause expression must
be positive constant integer expression" } */
void f3 (int);
#pragma omp declare simd simdlen(0) /* { dg-error "clause expression must
be positive constant integer expression" } */
void f4 (int);
void
foo (int *p)
{
int i;
#pragma omp simd safelen(d) /* { dg-error "must be positive
constant integer expression" } */
for (i = 0; i < 16; ++i) /* { dg-error "undeclared" "" { target
*-*-* } 18 } */
;
#pragma omp simd safelen(0.5) /* { dg-error "must be positive
constant integer expression" } */
for (i = 0; i < 16; ++i)
;
#pragma omp simd safelen(-2) /* { dg-error "must be positive
constant integer expression" } */
for (i = 0; i < 16; ++i)
;
#pragma omp simd safelen(0) /* { dg-error "must be positive
constant integer expression" } */
for (i = 0; i < 16; ++i)
;
#pragma omp simd aligned(p:d) /* { dg-error "must be positive
constant integer expression" } */
for (i = 0; i < 16; ++i)
;
#pragma omp simd aligned(p:0.5) /* { dg-error "must be positive
constant integer expression" } */
for (i = 0; i < 16; ++i)
;
#pragma omp simd aligned(p:-2)/* { dg-error "must be positive
constant integer expression" } */
for (i = 0; i < 16; ++i)
;
#pragma omp simd aligned(p:0) /* { dg-error "must be positive
constant integer expression" } */
for (i = 0; i < 16; ++i)
;
}
has various ICEs due to bad checking of error conditions on these 3 clauses in
the C FE (C++ FE is ok).
[Bug c/67500] OpenMP ICE with invalid safelen/simdlen/alignment expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67500 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-09-08 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |5.3 Ever confirmed|0 |1
[Bug c++/67499] c++ template/overload diagnostic compression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67499 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-08 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #2 from Jonathan Wakely --- For the specific case of ostreams and operator<< see also PR 58713
[Bug c++/67499] c++ template/overload diagnostic compression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67499
--- Comment #3 from David Malcolm ---
(we were chatting on IRC, I suggested Frank file this)
It might be worth looking at Clang for inspiration; see e.g.:
http://clang.llvm.org/diagnostics.html ("Template Type Diffing")
though that's not quite the same thing.
[Bug c++/67499] c++ template/overload diagnostic compression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67499 --- Comment #4 from Markus Trippelsdorf --- Well, clang isn't much better by default: markus@x4 tmp % clang++ -stdlib=libc++ -c foo.cxx 2>&1 | wc -l 97 markus@x4 tmp % clang++ -c foo.cxx 2>&1 | wc -l 88
[Bug c/67501] New: Bad error recovery for invalid OpenMP clauses in C FE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67501
Bug ID: 67501
Summary: Bad error recovery for invalid OpenMP clauses in C FE
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
/* */
/* { dg-do compile } */
/* { dg-options "-fopenmp" } */
void
foo (void)
{
int i;
#pragma omp for simd simdlen(4
for (i = 0; i < 16; ++i)
;
}
ICEs during clause splitting, the C++ FE handles this right.
[Bug c/67501] Bad error recovery for invalid OpenMP clauses in C FE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67501 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-09-08 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |5.3 Ever confirmed|0 |1
[Bug c/67502] New: ICE with collapsed for simd loop inside of parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67502
Bug ID: 67502
Summary: ICE with collapsed for simd loop inside of parallel
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
With C (-std=gnu99) we ICE on:
void bar (void);
void
foo (void)
{
#pragma omp parallel
#pragma omp for simd collapse(2)
for (int i1 = 0; i1 < 16; ++i1)
for (int i2 = 0; i2 < 16; ++i2)
bar ();
}
It is fine without the parallel, or with just simd instead of for simd, or with
C++.
[Bug c/67502] ICE with collapsed for simd loop inside of parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67502 Jakub Jelinek changed: What|Removed |Added Keywords||ice-on-valid-code, openmp Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-09-08 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |5.3 Ever confirmed|0 |1
[Bug c++/67499] c++ template/overload diagnostic compression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67499 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #5 from Manuel López-Ibáñez --- There are several ways this output could be "easily" improved: 1) One problem with GCC's output is that it becomes difficult to track where each candidate is listed in the wall of text. We could print something like (also currently the candidates are not actually quoted, which is unusual when printing source code): note: candidate 1: %qD ... note: candidate 2: %qD 2) Also, we print two times the same include stack for two different candidates because we print a candidate from a different file in the middle. In file included from /usr/include/c++/4.8/ostream:612:0, from /usr/include/c++/4.8/iostream:39, from test.cc:1: /usr/include/c++/4.8/bits/ostream.tcc:91:5: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(short int) [with _CharT = char; _Traits = std::char_traits] basic_ostream<_CharT, _Traits>:: ^ /usr/include/c++/4.8/bits/ostream.tcc:91:5: note: no known conversion for argument 1 from ‘foo’ to ‘short int’ In file included from /usr/include/c++/4.8/iostream:39:0, from test.cc:1: /usr/include/c++/4.8/ostream:181:7: note: std::basic_ostream<_CharT, _Traits>::__ostream_type& std::basic_ostream<_CharT, _Traits>::operator<<(short unsigned int) [with _CharT = char; _Traits = std::char_traits; std::basic_ostream<_CharT, _Traits>::__ostr eam_type = std::basic_ostream] operator<<(unsigned short __n) ^ /usr/include/c++/4.8/ostream:181:7: note: no known conversion for argument 1 from ‘foo’ to ‘short unsigned int’ In file included from /usr/include/c++/4.8/ostream:612:0, from /usr/include/c++/4.8/iostream:39, from test.cc:1: /usr/include/c++/4.8/bits/ostream.tcc:105:5: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(int) [with _CharT = char; _Traits = std::char_traits] basic_ostream<_CharT, _Traits>:: ^ This is a lot of repetitive noise. The candidates could be sorted to reduce this noise. 3) We print the reason in a different line than the candidate, with the caret line in the middle. Thus, the caret line does not serve as a visual separation between candidates. /usr/include/c++/4.8/ostream:232:7: note: std::basic_ostream<_CharT, _Traits>::__ostream_type& std::basic_ostream<_CharT, _Traits>::operator<<(long double) [with _CharT = char; _Traits = std::char_traits; std::basic_ostream<_CharT, _Traits>::__ostream_type = std::basic_ostream] operator<<(long double __f) ^ /usr/include/c++/4.8/ostream:232:7: note: no known conversion for argument 1 from ‘foo’ to ‘long double’ /usr/include/c++/4.8/ostream:245:7: note: std::basic_ostream<_CharT, _Traits>::__ostream_type& std::basic_ostream<_CharT, _Traits>::operator<<(const void*) [with _CharT = char; _Traits = std::char_traits; std::basic_ostream<_CharT, _Traits>::__ostream_type = std::basic_ostream] operator<<(const void* __p) ^ /usr/include/c++/4.8/ostream:245:7: note: no known conversion for argument 1 from ‘foo’ to ‘const void*’ Instead, we could print the reason after the candidate, perhaps even within the same line. Maybe: /usr/include/c++/4.8/ostream:232:7: note: candidate 5: no known conversion for argument 1 from ‘foo’ to ‘long double’ for 'std::basic_ostream<_CharT, _Traits>::__ostream_type& std::basic_ostream<_CharT, _Traits>::operator<<(long double) [with _CharT = char; _Traits = std::char_traits; std::basic_ostream<_CharT, _Traits>::__ostream_type = std::basic_ostream]' operator<<(long double __f) ^ /usr/include/c++/4.8/ostream:245:7: note: candidate 6: no known conversion for argument 1 from ‘foo’ to ‘const void*’ for 'std::basic_ostream<_CharT, _Traits>::__ostream_type& std::basic_ostream<_CharT, _Traits>::operator<<(const void*) [with _CharT = char; _Traits = std::char_traits; std::basic_ostream<_CharT, _Traits>::__ostream_type = std::basic_ostream]' operator<<(const void* __p) ^ 4) The candidate output is too verbose in some cases: /usr/include/c++/4.8/ostream:548:5: note: template std::basic_ostream& std::operator<<(std::basic_ostream&, const unsigned char*) operator<<(basic_ostream& __out, const unsigned char* __s) ^ /usr/include/c++/4.8/ostream:548:5: note: template argument deduction/substitution failed: test.cc:5:18: note: cannot convert ‘bar’ (type ‘foo’) to type ‘const unsigned char*’ std::cout << bar; ^ The above could simply say: /usr/include/c++/4.8/ostream:548:5: note: template std::basic_ostream& std::operator<<(std::basic_ostream&, const unsigned char*) operator<<(basic_ostream& __out, const un
[Bug c++/67504] New: ICE with type dependent collapse argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67504
Bug ID: 67504
Summary: ICE with type dependent collapse argument
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
int bar (int);
double bar (double);
template
void
foo (T x)
{
#pragma omp for collapse (bar (x)) // { dg-error "collapse argument needs
positive constant integer expression" }
for (int i = 0; i < 10; i++)
;
}
ICEs during the testing, we should check for tree_fits_shwi_p first before
testing INTEGRAL_TYPE_P.
[Bug libstdc++/67503] New: String cannot be loaded from binary representation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67503
Bug ID: 67503
Summary: String cannot be loaded from binary representation
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: radventure at yandex dot ru
Target Milestone: ---
#include
#include
int main() {
unsigned char buff1[sizeof(std::string)], buff2[sizeof(std::string)];
std::string s1("SMAL STRING BUG"), s2;
new (&buff1) std::string(s1);
s2 = *(reinterpret_cast(&buff1));
std::cout << s2 << std::endl;
std::swap(buff1, buff2);
s2 = *(reinterpret_cast(&buff2));
std::cout << s2 << std::endl;
}
After swapping buffers _N_dataplus._M_p pointer points into we buff1 but actual
data stored in small local buffer was coped correctly. If initial string length
will be greater when data will be stored into the heap and everything will be
Ok.
[Bug c++/67504] ICE with type dependent collapse argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67504 Jakub Jelinek changed: What|Removed |Added Keywords||ice-on-invalid-code, openmp Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-09-08 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |5.3 Ever confirmed|0 |1
[Bug libstdc++/67503] String cannot be loaded from binary representation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67503 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- That's not valid, you can't do that with non-trivial types.
[Bug libstdc++/67503] String cannot be loaded from binary representation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67503 --- Comment #2 from Andrew Pinski --- Also there is an alignment issue with your example too.
[Bug other/67457] segfault in libbacktrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67457 --- Comment #4 from Ian Lance Taylor --- I committed a patch that should produce a more graceful fallback when out of memory. Please see if it helps your situation.
[Bug other/67457] segfault in libbacktrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67457 --- Comment #4 from Ian Lance Taylor --- I committed a patch that should produce a more graceful fallback when out of memory. Please see if it helps your situation. --- Comment #5 from ian at gcc dot gnu.org --- Author: ian Date: Tue Sep 8 16:46:16 2015 New Revision: 227533 URL: https://gcc.gnu.org/viewcvs?rev=227533&root=gcc&view=rev Log: PR other/67457 * backtrace.c: #include "internal.h". (struct backtrace_data): Add can_alloc field. (unwind): If can_alloc is false, don't try to get file/line information. (backtrace_full): Set can_alloc field in bdata. * alloc.c (backtrace_alloc): Don't call error_callback if it is NULL. * mmap.c (backtrace_alloc): Likewise. * internal.h: Update comments for backtrace_alloc and backtrace_free. Modified: trunk/libbacktrace/ChangeLog trunk/libbacktrace/alloc.c trunk/libbacktrace/backtrace.c trunk/libbacktrace/internal.h trunk/libbacktrace/mmap.c
[Bug fortran/67454] GCC-5.2.0 `GCC_4.3.0' not found (required by file /usr/local/add-on/gcc/lib/libgfortran.so.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67454 --- Comment #17 from Dominique d'Humieres --- > So now to find and fix the R build so it doesn't use /usr/sfw/lib. What is sfw? and what happens if you move it away?
[Bug libstdc++/67503] String cannot be loaded from binary representation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67503 --- Comment #3 from radventure at yandex dot ru --- I can solve the alignment but prbolem will not be fixed. I agree with remark about "non-trivial types" but this code works in previous gcc versions and works in visual c++ 2015.
[Bug fortran/67454] GCC-5.2.0 `GCC_4.3.0' not found (required by file /usr/local/add-on/gcc/lib/libgfortran.so.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67454 --- Comment #18 from James Ballantine --- It's a solaris directory that I think is for freeware.
[Bug libstdc++/67503] String cannot be loaded from binary representation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67503 radventure at yandex dot ru changed: What|Removed |Added Resolution|INVALID |WONTFIX
[Bug fortran/67505] New: Runtime error: recursive call to final subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67505 Bug ID: 67505 Summary: Runtime error: recursive call to final subroutine Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kergonath at me dot com Target Milestone: --- When compiled with -fcheck=all, the included code crashes with the following error message: At line 16 of file foo.f90 Fortran runtime error: Recursive call to nonrecursive procedure '__final_mod_foo_Foo' The fortran version is 6.0: Using built-in specs. COLLECT_GCC=gfortran-mp-6 COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin14/6.0.0/lto-wrapper Target: x86_64-apple-darwin14 Configured with: /opt/local/var/macports/build/_opt_mports_dports_lang_gcc6/gcc6/work/gcc-6-20150830/configure --prefix=/opt/local --build=x86_64-apple-darwin14 --enable-languages=c,c++,objc,obj-c++,lto,fortran,java --libdir=/opt/local/lib/gcc6 --includedir=/opt/local/include/gcc6 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-6 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-6 --with-gxx-include-dir=/opt/local/include/gcc6/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts gcc6 6-20150830_0' Thread model: posix gcc version 6.0.0 20150830 (experimental) (MacPorts gcc6 6-20150830_0) The code is: module mod_foo implicit none type, public :: foo type(foo), pointer :: child => null() contains final :: foo_finalise end type contains recursive subroutine foo_finalise(this) type(foo), intent(inout) :: this if (associated(this%child)) deallocate(this%child) end subroutine end module program test use mod_foo block type(foo) :: var allocate(var%child) end block end program
[Bug libstdc++/67503] String cannot be loaded from binary representation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67503 Jonathan Wakely changed: What|Removed |Added Resolution|WONTFIX |INVALID --- Comment #4 from Jonathan Wakely --- (In reply to radventure from comment #3) > I can solve the alignment but prbolem will not be fixed. > I agree with remark about "non-trivial types" but this code works in > previous gcc versions and works in visual c++ 2015. It was never valid before and it's not valid now. Just because it appeared to work previously doesn't make it valid.
[Bug libstdc++/67503] String cannot be loaded from binary representation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67503 --- Comment #5 from radventure at yandex dot ru --- When you use local buffer for storing string value it not necessary to have pointer to it. And we can reduce the size of string by the syzeof(pointer).
