[Bug rtl-optimization/67462] [6 Regression] FAIL: gcc.dg/ifcvt-3.c scan-rtl-dump ce1 "3 true changes made"

[ktkachov at gcc dot gnu.org]

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 fortran/46310] [F03] gfortran wrongly treats INTERFACE BLOCK and not INTERFACE BODY as scoping unit

[dominiq at lps dot ens.fr]

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

[paolo.carlini at oracle dot com]

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/25708] [F95] Module loading is not good at all

[dominiq at lps dot ens.fr]

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 c/67492] New: insn-attrtab and insn-automata for arm target neede huge amount of memory to generate/compile

[michael at weiser dot dinsnail.net]

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=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 c++/67491] New: [meta-bug] concepts issues

[paolo.carlini at oracle dot com]

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 c++/67384] [concepts] More fun with deduction constraints

[paolo.carlini at oracle dot com]

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 fortran/41107] [F03] Proc-pointer components: Fix calling DECL for f2c

[dominiq at lps dot ens.fr]

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++/67487] ICE: Illegal instruction, header

[mazen....@uni-ulm.de]

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 target/67462] [6 Regression] FAIL: gcc.dg/ifcvt-3.c scan-rtl-dump ce1 "3 true changes made"

[ktkachov at gcc dot gnu.org]

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 ipa/67280] [5 Regression] wrong C++11 code generated on arm-linux-gnueabihf

[ramana at gcc dot gnu.org]

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++/67491] [meta-bug] concepts issues

[paolo.carlini at oracle dot com]

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 c++/66844] [c++-concepts] Requires-expression parameter with void type

[paolo.carlini at oracle dot com]

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++/67427] [concepts] Subsumption dependence on template parameter ordering

[paolo.carlini at oracle dot com]

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

[dominiq at lps dot ens.fr]

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/40881] [F03] warn for obsolescent features

[dominiq at lps dot ens.fr]

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 fortran/65921] GFortran should use __builtin_mul_overflow when checking allocation sizes

[dominiq at lps dot ens.fr]

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

[michael at weiser dot dinsnail.net]

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/66575] Endless compilation on missing end interface

[dominiq at lps dot ens.fr]

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 target/67492] insn-attrtab and insn-automata for arm target neede huge amount of memory to generate/compile

[pinskia at gcc dot gnu.org]

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]

[dominiq at lps dot ens.fr]

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 target/67492] insn-attrtab and insn-automata for arm target neede huge amount of memory to generate/compile

[ktkachov at gcc dot gnu.org]

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/67454] GCC-5.2.0 `GCC_4.3.0' not found (required by file /usr/local/add-on/gcc/lib/libgfortran.so.3)

[dominiq at lps dot ens.fr]

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/66155] Macro not replaced after multi-line string constant

[dominiq at lps dot ens.fr]

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 fortran/67493] New: -fcheck=recursive not thread aware

[franke.daniel at gmail dot com]

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(, );
}

int main(int argc, char **argv) {
  pthread_t t1, t2;

  pthread_create(, NULL, controller, NULL);
  pthread_create(, 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

[michael at weiser dot dinsnail.net]

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 c++/67369] [5/6 Regression] ICE (in tsubst_decl, at cp/pt.c:11302) with -std=c++14

[paolo.carlini at oracle dot com]

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 c++/67487] ICE: Illegal instruction, header

[trippels at gcc dot gnu.org]

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

[mazen....@uni-ulm.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67487

--- Comment #4 from mazen@uni-ulm.de ---
Ok, thanks Markus.

[Bug fortran/66107] ICE on missing parameter value for initialisation (segfault)

[dominiq at lps dot ens.fr]

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 fortran/65086] Segfault: Invalid copy-out of temporary as argument is in read-only memory

[dominiq at lps dot ens.fr]

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 target/67492] insn-attrtab and insn-automata for arm target neede huge amount of memory to generate/compile

[pinskia at gcc dot gnu.org]

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 fortran/66056] ICEs and endless compilation for lonely labels/numbers in type

[dominiq at lps dot ens.fr]

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/52176] Valgrind complains about some realloc on assignment to unallocated LHS

[dominiq at lps dot ens.fr]

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 c++/67487] ICE: Illegal instruction, header

[trippels at gcc dot gnu.org]

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/66244] ICE on assigning a value to a pointer variable

[dominiq at lps dot ens.fr]

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 fortran/66094] Handle transpose(A) in inline matmul

[dominiq at lps dot ens.fr]

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 fortran/66762] ICE when compiling gfortran.dg/submodule_[16].f90 with -flto

[marxin at gcc dot gnu.org]

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/67454] GCC-5.2.0 `GCC_4.3.0' not found (required by file /usr/local/add-on/gcc/lib/libgfortran.so.3)

[j.ballantine at gmail dot com]

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 c++/67350] auto deduction error in variable template lambda

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67350

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Jason Merrill  ---
Duplicate.

*** This bug has been marked as a duplicate of bug 67041 ***

[Bug c++/67041] [C++14] Variable template initialized by call to lambda does not compile

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67041

Jason Merrill  changed:

   What|Removed |Added

 CC||norbert.pfeiler+gcc.gnu.org
   ||/bugzilla at gmail dot com

--- Comment #2 from Jason Merrill  ---
*** Bug 67350 has been marked as a duplicate of this bug. ***

[Bug fortran/65819] overzealous checking in gfc_check_dependency for identical=true

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65819

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #2 from Thomas Koenig  ---
The LHS and the arrays on the RHS cannot possibly overlap,
because of the difference in the first index.

ig25@linux-fd1f:~/Krempel/Dep-f> cat foo.f90
program main
  implicit none
  real, dimension(3,3,3) :: f
  integer :: three
  call random_number(f)
  three = 3
  f(1, 1:three, :) = matmul(f(2,1:3,2:3), f(3,2:3,:))
  print *,f
end program main
ig25@linux-fd1f:~/Krempel/Dep-f> gfortran -O -Warray-temporaries foo.f90
foo.f90:7:21:

   f(1, 1:three, :) = matmul(f(2,1:3,2:3), f(3,2:3,:))
 1
Warning: Creating array temporary at (1) [-Warray-temporaries]

[Bug c++/67318] [6 regression] Parsing error when using abbreviated integral type names in template parameter pack declaration

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67318

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Paolo Carlini  ---
Regressed in r225621.

[Bug c++/67041] [C++14] Variable template initialized by call to lambda does not compile

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67041

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Tue Sep  8 19:33:47 2015
New Revision: 227553

URL: https://gcc.gnu.org/viewcvs?rev=227553=gcc=rev
Log:
PR c++/67041
* pt.c (tsubst_copy_and_build): Handle variables like functions.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-var-templ1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug target/63870] [Aarch64] [ARM] Errors in use of NEON intrinsics are reported incorrectly

[alalaw01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870

--- Comment #10 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Tue Sep  8 19:43:39 2015
New Revision: 227557

URL: https://gcc.gnu.org/viewcvs?rev=227557=gcc=rev
Log:
ARM/AArch64 Testsuite] Add float16 lane_f16_indices tests

PR target/63870
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_f16_indices_1.c: New.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_f16_indices_1.c:
New.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_f16_indices_1.c: New.
* gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_f16_indices_1.c:
New.
* gcc.target/aarch64/advsimd-intrinsics/vld4_lane_f16_indices_1.c: New.
* gcc.target/aarch64/advsimd-intrinsics/vld4q_lane_f16_indices_1.c:
New.
* gcc.target/aarch64/advsimd-intrinsics/vst2_lane_f16_indices_1.c: New.
* gcc.target/aarch64/advsimd-intrinsics/vst2q_lane_f16_indices_1.c:
New.
* gcc.target/aarch64/advsimd-intrinsics/vst3_lane_f16_indices_1.c: New.
* gcc.target/aarch64/advsimd-intrinsics/vst3q_lane_f16_indices_1.c:
New.
* gcc.target/aarch64/advsimd-intrinsics/vst4_lane_f16_indices_1.c: New.
* gcc.target/aarch64/advsimd-intrinsics/vst4q_lane_f16_indices_1.c:
New.

Added:
   
trunk/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld2_lane_f16_indices_1.c
   
trunk/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_f16_indices_1.c
   
trunk/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld3_lane_f16_indices_1.c
   
trunk/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_f16_indices_1.c
   
trunk/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld4_lane_f16_indices_1.c
   
trunk/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vld4q_lane_f16_indices_1.c
   
trunk/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vst2_lane_f16_indices_1.c
   
trunk/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vst2q_lane_f16_indices_1.c
   
trunk/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vst3_lane_f16_indices_1.c
   
trunk/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vst3q_lane_f16_indices_1.c
   
trunk/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vst4_lane_f16_indices_1.c
   
trunk/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vst4q_lane_f16_indices_1.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c/64249] Missing warning for if (A) else if (A)

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64249

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |6.0

--- Comment #2 from Marek Polacek  ---
I seem to have something that seemingly works for the C FE.

[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[fredrik.hederstie...@securitas-direct.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578

--- Comment #25 from Fredrik Hederstierna 
 ---
I've but this last example in a separate issue:
Bug 67507 - Code size increase with -Os from GCC 4.8.x to GCC 4.9.x for ARM
thumb1.
I've also previously put this one that causes size increase
Bug 67213 - When compiling for size with -Os loops can get bigger after
peeling.
Best Regards, Fredrik

[Bug tree-optimization/37705] [graphite] Remove limit_scops() workaround

[spop at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37705

Sebastian Pop  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||spop at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #6 from Sebastian Pop  ---
Fixed in r227567.

[Bug target/67507] New: Code size increase with -Os from GCC 4.8.x to GCC 4.9.x for ARM thumb1

[fredrik.hederstie...@securitas-direct.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67507

Bug ID: 67507
   Summary: Code size increase with -Os from GCC 4.8.x to GCC
4.9.x for ARM thumb1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fredrik.hederstie...@securitas-direct.com
  Target Milestone: ---

Created attachment 36308
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36308=edit
Example code

Starting with GCC 4.9.x the code size increase with arm-eabi thumb for attached
example code. It seems related to alignment and is still present in GCC 5.2.0.

Example C Code (see attachment for more and list):
The code does cause possible alignment data abort, but still it should compile
consistent and fine assuming user give aligned data. Example 5 gives
type-punned warning for all compilations, neither of the other examples gives
warnings.

extern void func(int data);
char global_data_unaligned[4];
void test_unaligned_1(void) {
  int *idata = (int*)global_data_unaligned;
  func(*idata);
}

Compiles to GCC 4.8.5 arm-none-eabi cortex-m0  -Os

 :
   0:   b508push{r3, lr}
   2:   4b07ldr r3, [pc, #28]   ; (20 )
   4:   7858ldrbr0, [r3, #1]
   6:   781aldrbr2, [r3, #0]
   8:   0200lslsr0, r0, #8
   a:   4310orrsr0, r2
   c:   789aldrbr2, [r3, #2]
   e:   78dbldrbr3, [r3, #3]
  10:   0412lslsr2, r2, #16
  12:   4310orrsr0, r2
  14:   061blslsr3, r3, #24
  16:   4318orrsr0, r3
  18:   f7ff fffe   bl  0 
  1c:   bd08pop {r3, pc}
  1e:   46c0nop ; (mov r8, r8)
  20:   .word   0x

Compiles GCC 5.2.0 arm-none-eabi cortex-m0 -Os,  +4 bytes

 :
   0:   b510push{r4, lr}
   2:   4c08ldr r4, [pc, #32]   ; (24 )
   4:   7863ldrbr3, [r4, #1]
   6:   7821ldrbr1, [r4, #0]
   8:   78a0ldrbr0, [r4, #2]
   a:   021blslsr3, r3, #8
   c:   430borrsr3, r1
   e:   0400lslsr0, r0, #16
  10:   001amovsr2, r3  // ???
  12:   0003movsr3, r0  // ???
  14:   78e0ldrbr0, [r4, #3]
  16:   4313orrsr3, r2
  18:   0600lslsr0, r0, #24
  1a:   4318orrsr0, r3
  1c:   f7ff fffe   bl  0 
  20:   bd10pop {r4, pc}
  22:   46c0nop ; (mov r8, r8)
  24:   .word   0x

With GCC 4.8.5 arm-none-eabi cortex-m0  -O2, code gets shorter,
no alignment check when compile for speed?

 :
   0:   b508push{r3, lr}
   2:   4b02ldr r3, [pc, #8]; (c )
   4:   6818ldr r0, [r3, #0]
   6:   f7ff fffe   bl  0 
   a:   bd08pop {r3, pc}
   c:   .word   0x

--

Example3 compiled with GCC 4.8.5 arm-none-eabi cortex-m0 -Os

0048 :
  48:   b508push{r3, lr}
  4a:   4b03ldr r3, [pc, #12]   ; (58 )
  4c:   2201movsr2, #1
  4e:   4393bicsr3, r2
  50:   6818ldr r0, [r3, #0]
  52:   f7ff fffe   bl  0 
  56:   bd08pop {r3, pc}
  58:   .word   0x

Same code compiled with GCC 5.2.0 arm-none-eabi cortex-m0 -Os

0028 :
  28:   2201movsr2, #1
  2a:   4b05ldr r3, [pc, #20]   ; (40 )
  2c:   b510push{r4, lr}
  2e:   4393bicsr3, r2
  30:   8858ldrhr0, [r3, #2]// ?? why ldrh
  32:   881aldrhr2, [r3, #0]// ?? why ldrh
  34:   0400lslsr0, r0, #16
  36:   4310orrsr0, r2
  38:   f7ff fffe   bl  0 
  3c:   bd10pop {r4, pc}
  3e:   46c0nop ; (mov r8, r8)
  40:   .word   0x

Seems to be some issue with assumtions on alignment, causing larger code size.
I checked IRA dump for IRA-coloring/build and some examples seems to assign
more hardregs with new threads code added in GCC 4.9. Though I haven't digged
further into this yet.

Toolchain was build with GNU Build Buddy for arm-none-eabi, softfloat, see
scripts at https://github.com/fredrikhederstierna/buildbuddy

/Fredrik

[Bug target/67506] New: [SH][5]: error: unrecognizable insn when compiling texlive-binaries

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67506

Bug ID: 67506
   Summary: [SH][5]: error: unrecognizable insn when compiling
texlive-binaries
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: kkojima at gcc dot gnu.org, olegendo at gcc dot gnu.org
  Target Milestone: ---
Target: sh*-*-*

Created attachment 36307
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36307=edit
Preprocessed source for tftopl.c

Hello!

I just noticed that we run into a new regression which seems to have been
introduced with gcc-5.

The compiler output is as follows:

gcc -DHAVE_CONFIG_H -I. -I../../../texk/web2c -I./w2c 
-I/«PKGBUILDDIR»/Work/texk -I/«PKGBUILDDIR»/texk  -Wimplicit -Wreturn-type -g
-O2 -c -o tftopl.o tftopl.c
tftopl.c: In function 'mainbody':
tftopl.c:1808:1: error: unrecognizable insn:
 } 
 ^
(insn 9938 541 9939 36 (set (reg:SI 147 t)
(eq:SI (and:SI (reg:HI 1069 [ *_271 ])
(const_int 128 [0x80]))
(const_int 0 [0]))) tftopl.c:1542 -1
 (nil))
tftopl.c:1808:1: internal compiler error: in extract_insn, at recog.c:2343
0x83edf3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src/gcc/rtl-error.c:110
0x83ee2d _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../src/gcc/rtl-error.c:118
0x8139dd extract_insn(rtx_insn*)
../../src/gcc/recog.c:2343
0xba62f3 decompose_multiword_subregs
../../src/gcc/lower-subreg.c:1502
0xba731f execute
../../src/gcc/lower-subreg.c:1772
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /tmp/ccRGajx7.out file, please attach this to
your bugreport.

A full build log can be found in [1]. The build log of a previous, successful
build with gcc-4.9 can be found in [2]. I am attaching the preprocessed source
which is mentioned in the build log.

Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=texlive-bin=sh4=2015.20150524.37493-6=1440539292
> [2] 
> https://buildd.debian.org/status/fetch.php?pkg=texlive-bin=sh4=2015.20150524.37493-5=1437123205

[Bug c++/67041] [C++14] Variable template initialized by call to lambda does not compile

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67041

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #4 from Jason Merrill  ---
Fixed for GCC 6.

[Bug go/67508] New: [aarch64] gccgo runtime crashes with CONFIG_ARM64_PGTABLE_LEVELS=4

[michael.hudson at canonical dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67508

Bug ID: 67508
   Summary: [aarch64] gccgo runtime crashes with
CONFIG_ARM64_PGTABLE_LEVELS=4
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: michael.hudson at canonical dot com
CC: cmang at google dot com
  Target Milestone: ---

As reported at
https://bugs.launchpad.net/ubuntu/+source/gccgo-4.9/+bug/1472650, any
gccgo-compiled program crashes on startup on an arm64 using 4 level page tables
with an error "fatal error: runtime_lfstackpush: invalid pointer". There is a
fix available at https://go-review.googlesource.com/#/c/13037/

[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)

[dominiq at lps dot ens.fr]

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 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

[mpolacek at gcc dot gnu.org]

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 fortran/66708] Possible (minor) improvement on formatted io with format too short

[dominiq at lps dot ens.fr]

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

[dominiq at lps dot ens.fr]

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)

[pinskia at gcc dot gnu.org]

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 fortran/65819] overzealous checking in gfc_check_dependency for identical=true

[dominiq at lps dot ens.fr]

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)

[pinskia at gcc dot gnu.org]

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 ada/67494] New: xsinfo sanitizer detects overlapping strings in assignment statement

[zeccav at gmail dot com]

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 other/67457] segfault in libbacktrace

[ian at airs dot com]

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 c/67495] #pragma omp atomic ICEs

[jakub at gcc dot gnu.org]

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)

[j.ballantine at gmail dot com]

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)

[dominiq at lps dot ens.fr]

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 rtl-optimization/15473] Sibcall optimization for libcalls.

[hjl.tools at gmail dot com]

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 fortran/67454] GCC-5.2.0 `GCC_4.3.0' not found (required by file /usr/local/add-on/gcc/lib/libgfortran.so.3)

[pinskia at gcc dot gnu.org]

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)

[j.ballantine at gmail dot com]

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 c/67495] New: #pragma omp atomic ICEs

[jakub at gcc dot gnu.org]

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 fortran/67454] GCC-5.2.0 `GCC_4.3.0' not found (required by file /usr/local/add-on/gcc/lib/libgfortran.so.3)

[j.ballantine at gmail dot com]

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 other/67457] segfault in libbacktrace

[ian at gcc dot gnu.org]

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=gcc=rev
Log:
PR other/67457
* mmap.c (backtrace_alloc): Correct test for mmap failure.

Modified:
trunk/libbacktrace/ChangeLog
trunk/libbacktrace/mmap.c

[Bug fortran/67509] New: [6 regression] FAIL: gfortran.dg/ieee/ieee_7.f90 -O0 execution test

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67509

Bug ID: 67509
   Summary: [6 regression] FAIL: gfortran.dg/ieee/ieee_7.f90   -O0
 execution test
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: fxcoudert at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc*-*-*

$ gcc/gfortran -Bgcc/ -Bpowerpc64-suse-linux/32/libgfortran/
../gcc/testsuite/gfortran.dg/ieee/ieee_7.f90 -O0 -pedantic-errors
-fintrinsic-modules-path $PWD/powerpc64-suse-linux/./libgfortran/
-fno-unsafe-math-optimizations -frounding-math -fsignaling-nans
-Bpowerpc64-suse-linux/./libgfortran/.libs
-Lpowerpc64-suse-linux/./libgfortran/.libs
-Lpowerpc64-suse-linux/./libgfortran/.libs
-Lpowerpc64-suse-linux/./libatomic/.libs -lm -m64 -o ./ieee_7.exe -g
$
LD_LIBRARY_PATH=.:powerpc64-suse-linux/./libgfortran/.libs:powerpc64-suse-linux/./libgfortran/.libs:gcc
./ieee_7.exe 

Program aborted. Backtrace:
#0  0x3FFFB2FF3D93
Aborted

Breakpoint 1, MAIN__ () at ../gcc/testsuite/gfortran.dg/ieee/ieee_7.f90:37
37if (ieee_selected_real_kind(0,range(0._maxreal)+1) /= -2) call abort
(gdb) s
ieee_arithmetic::ieee_selected_real_kind (p=0, r=292, 
radix=)
at ../../../libgfortran/ieee/ieee_arithmetic.F90:790
790 res = SELECTED_REAL_KIND (P, R, RADIX)
(gdb) fin
Run till exit from #0  ieee_arithmetic::ieee_selected_real_kind (p=0, r=292, 
radix=)
at ../../../libgfortran/ieee/ieee_arithmetic.F90:790
0x1c7c in MAIN__ ()
at ../gcc/testsuite/gfortran.dg/ieee/ieee_7.f90:37
37if (ieee_selected_real_kind(0,range(0._maxreal)+1) /= -2) call abort
Value returned is $1 = 8

[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)

[j.ballantine at gmail dot com]

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)

[pinskia at gcc dot gnu.org]

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 c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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/67500] OpenMP ICE with invalid safelen/simdlen/alignment expressions

[jakub at gcc dot gnu.org]

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

[trippels at gcc dot gnu.org]

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/67502] New: ICE with collapsed for simd loop inside of parallel

[jakub at gcc dot gnu.org]

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/67495] #pragma omp atomic ICEs

[jakub at gcc dot gnu.org]

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=edit
gcc6-pr67495.patch

Untested fix.

[Bug fortran/67497] New: data.c sanitizer runtime error: null pointer passed as argument 2, which is declared to never be null

[zeccav at gmail dot com]

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 ([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 ([start], rvalue->value.character.string, len *
! sizeof (gfc_char_t));"
!Target: x86_64-unknown-linux-gnu
  CHARACTER, POINTER :: PTR
  DATA  PTR / NULL() /
  end

[Bug other/67457] segfault in libbacktrace

[Joost.VandeVondele at mat dot ethz.ch]

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 c++/67369] [5/6 Regression] ICE (in tsubst_decl, at cp/pt.c:11302) with -std=c++14

[paolo at gcc dot gnu.org]

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=gcc=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

[paolo at gcc dot gnu.org]

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=gcc=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 c++/67499] c++ template/overload diagnostic compression

[trippels at gcc dot gnu.org]

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 c/67502] ICE with collapsed for simd loop inside of parallel

[jakub at gcc dot gnu.org]

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 target/67506] [5/6 Regression][SH]: error: unrecognizable insn when compiling texlive-binaries

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67506

--- Comment #2 from Kazumoto Kojima  ---
Created attachment 36309
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36309=edit
reduced test case

It looks that some problem happens in tstsi_t splitter.
The insns before splitting are:

(insn 124 123 125 13 (set (reg:HI 262 [ *_48 ])
(zero_extend:HI (reg:QI 263 [ *_48 ]))) tfoo.c:41 223
{zero_extendqihi2}
 (expr_list:REG_DEAD (reg:QI 263 [ *_48 ])
(nil)))
(note 125 124 126 13 NOTE_INSN_DELETED)
(insn 126 125 127 13 (set (reg:SI 197 [ *_48 ])
(zero_extend:SI (reg:HI 262 [ *_48 ]))) tfoo.c:42 220
{*zero_extendhisi2_compact}
 (nil))
(insn 127 126 128 13 (set (reg:SI 147 t)
(zero_extract:SI (subreg:SI (reg:HI 262 [ *_48 ]) 0)
(const_int 1 [0x1])
(const_int 7 [0x7]))) tfoo.c:42 516 {*zero_extract_0}
 (nil))

and the last insn is splitted into

(insn 478 126 479 16 (set (reg:SI 147 t)
(eq:SI (and:SI (subreg:SI (reg:HI 262 [ *_48 ]) 0)
(const_int 128 [0x80]))
(const_int 0 [0]))) tfoo.c:42 -1
 (nil))

with *zero_extract_0 splitter.  Then it seems that tstsi_t splitter
replaces (subreg:SI (reg:HI 262 [ *_48 ]) 0) with (reg:HI 262 [ *_48 ])
as the result of eop0.use_as_extended_reg and we got

(insn 480 126 481 16 (set (reg:SI 147 t)
(eq:SI (and:SI (reg:HI 262 [ *_48 ])
(const_int 128 [0x80]))
(const_int 0 [0]))) tfoo.c:42 -1
 (nil))

Oleg, could you please look at this?

[Bug middle-end/55035] reload1.c:3766:41: error: ‘orig_dup[0]’ may be used uninitialized in this function (for fr30, microblaze, moxie, rl78)

[hp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55035

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #12 from Hans-Peter Nilsson  ---
*** Bug 67475 has been marked as a duplicate of this bug. ***

[Bug bootstrap/67475] [6 regression] reload1.c:3772:41: error: 'orig_dup[1]' may be used uninitialized in this function breaks SPARC bootstrap

[hp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67475

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||hp at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Hans-Peter Nilsson  ---
Mentioned as SPARC-breaking in PR55035#11.

*** This bug has been marked as a duplicate of bug 55035 ***

[Bug target/67506] [5/6 Regression][SH]: error: unrecognizable insn when compiling texlive-binaries

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67506

Kazumoto Kojima  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to work||4.9.4
Summary|[SH][5]: error: |[5/6 Regression][SH]:
   |unrecognizable insn when|error: unrecognizable insn
   |compiling texlive-binaries  |when compiling
   ||texlive-binaries
  Known to fail||5.2.1, 6.0

--- Comment #1 from Kazumoto Kojima  ---
Cross trunk compiler fails with the same ICE.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[myriachan at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892

Melissa  changed:

   What|Removed |Added

 CC||myriachan at gmail dot com

--- Comment #12 from Melissa  ---
This is broken in C++ as well, and in C++, the rules are much more clear that
GCC isn't following them.

Quoting the C++ Standard, revision 4296 (post-C++14?):

16. The "common initial sequence" of two standard-layout struct (Clause 9)
types is the longest sequence of non-static data members and bit-fields in
declaration order, starting with the first such entity in each of the structs,
such that the corresponding entries have layout-compatible types and either
neither entity is a bit-field or both are bit-fields with the same width.

19. In a standard-layout union with an active member (9.5) of struct type T1,
it is permitted to read a non-static data member m of another union member of
struct type T2 provided m is part of the common initial sequence of T1 and T2.


A C++ conversion of the original example is below.  I asked about the word
"read" on the C++ Standard Discussion (std-discussion) mailing list, because it
probably should also allow writing if it allows reads.  As a result, I modified
the below to only *read* in an aliasing way, to fully comply with the written
word of the Standard.


#include 

struct t1 { int m; };
struct t2 { int m; };

union U {
t1 s1;
t2 s2;
};

int f (t1 *p1, t2 *p2)
{
// union U visible here, p1->m and p2->m may alias
// p1 is the active member; read from p2 per [class.mem]/19.

if (p2->m < 0)
p1->m = -p1->m;

return p2->m;
}

int main (void)
{
union U u = { { -1 } };

int n = f (, );

assert (1 == n);

return 0;
}

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[myriachan at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892

--- Comment #13 from Melissa  ---
As for a reason why this should be allowed, all I need is to do is mention
struct sockaddr.

[Bug c++/67499] c++ template/overload diagnostic compression

[manu at gcc dot gnu.org]

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

[Bug libstdc++/67503] String cannot be loaded from binary representation

[pinskia at gcc dot gnu.org]

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 c++/67504] ICE with type dependent collapse argument

[jakub at gcc dot gnu.org]

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

[redi at gcc dot gnu.org]

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 c++/67504] New: ICE with type dependent collapse argument

[jakub at gcc dot gnu.org]

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

[radventure at yandex dot ru]

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 () std::string(s1);
  s2 = *(reinterpret_cast());
  std::cout << s2 << std::endl;
  std::swap(buff1, buff2);
  s2 = *(reinterpret_cast());
  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 other/67457] segfault in libbacktrace

[ian at airs dot com]

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 fortran/67454] GCC-5.2.0 `GCC_4.3.0' not found (required by file /usr/local/add-on/gcc/lib/libgfortran.so.3)

[j.ballantine at gmail dot com]

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 fortran/67496] New: trans-array.c sanitizer runtime error: load of value 124, which is not a valid value for type 'bool'

[zeccav at gmail dot com]

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 c++/67369] [5/6 Regression] ICE (in tsubst_decl, at cp/pt.c:11302) with -std=c++14

[paolo.carlini at oracle dot com]

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.