[Bug c++/67164] ICE: tree check: expected class ‘expression’, have ‘exceptional’ (argument_pack_select) in tree_operand_check, at tree.h:3356

[jason at gcc dot gnu.org]

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

--- Comment #11 from Jason Merrill  ---
Author: jason
Date: Wed Jul 20 05:06:52 2016
New Revision: 238507

URL: https://gcc.gnu.org/viewcvs?rev=238507=gcc=rev
Log:
PR c++/67164 - clean up dead code

* pt.c (iterative_hash_template_arg, template_args_equal): Don't
handle ARGUMENT_PACK_SELECT.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c/71939] New: sole flexible array member in an anonymous structure rejected

[msebor at gcc dot gnu.org]

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

Bug ID: 71939
   Summary: sole flexible array member in an anonymous structure
rejected
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While testing a fix for bug 71912 and comparing the C++ front end results to
those of the C front end I came across the following test case that's accepted
in C++ but rejected in C.  By my reading of C11 the test case is valid because
"members of an anonymous structure or union are considered to be members of the
containing structure or union" and so struct S should be treated as if it had
been defined as:

  struct S {
int i;
int a[];
  };

I note that both Clang and EDG eccp 4.11 also reject the code in C, Clang
accepts in C++ mode with -Wflexible-array-extensions.

$ cat xyz.c && /build/gcc-71912/gcc/xgcc -B /build/gcc-71912/gcc -Wall -Wextra
-Wpedantic xyz.c
struct S {
  int i;
  struct { int a[]; };
};
xyz.c:3:16: error: flexible array member in otherwise empty struct
   struct { int a[]; };
^

[Bug bootstrap/66319] [6 Regression] gcov-tool.c:84:65: error: invalid conversion from 'int (*)(const c har*, const stat*, int, FTW*)' to 'int (*)(const char*, const stat*, int, FTW)'

[dave.anglin at bell dot net]

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

--- Comment #21 from dave.anglin at bell dot net ---
On 2016-07-19, at 1:23 PM, bugzilla-gcc at thewrittenword dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66319
> 
> --- Comment #20 from The Written Word  com> ---
> (In reply to dave.anglin from comment #17)
>> On 2016-07-12, at 12:36 PM, bugzilla-gcc at thewrittenword dot com wrote:
>> 
 don't have any ia64 hardware and I also don't have an 11.31 box.  So,
 there's a support issue for ia64 and 11.31.  Albert, if you or one of
 your staff could help in this regard, I would support the addition of
 a new hpux maintainer.
>>> 
>>> We can provide access to HP-UX 11.23/ia and 11.31/ia. Sadly, apart from
>>> building GCC, we don't have any intricate ia64 knowledge to help with
>>> maintainership.
>> 
>> What I was hoping for was someone to handle the hpux aspect on ia64.  Do
>> occasional builds and tests, etc.
> 
> We might be able to do this. Will look into getting something automated over
> the next few weeks.


That would be excellent.

--
John David Anglin   dave.ang...@bell.net

[Bug libstdc++/71856] [6/7 Regression] _GLIBCXX_DEBUG-mode breaks GNU parallel extension

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Author: redi
Date: Tue Jul 19 22:16:23 2016
New Revision: 238498

URL: https://gcc.gnu.org/viewcvs?rev=238498=gcc=rev
Log:
Do not define _GLIBCXX_ASSERTIONS in Parallel Mode

PR libstdc++/71856
* include/bits/c++config (_GLIBCXX_ASSERTIONS): Define to 1 not empty.
* include/parallel/balanced_quicksort.h: Include  for sleep.
* include/parallel/compiletime_settings.h (_GLIBCXX_ASSERTIONS):
Do not define here.

Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/include/bits/c++config
branches/gcc-6-branch/libstdc++-v3/include/parallel/balanced_quicksort.h
branches/gcc-6-branch/libstdc++-v3/include/parallel/compiletime_settings.h

[Bug target/70568] [4.9/5/6/7 regression] PowerPC64: union of floating and fixed doesn't use POWER8 GPR/VSR moves

[pthaugen at gcc dot gnu.org]

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

--- Comment #4 from Pat Haugen  ---
(In reply to acsawdey from comment #3)
> Tracked this back to 210824, and in particular this change:
> 
> @@ -860,10 +897,15 @@
> }
> }
> 
> - /* If the alternative actually allows memory, make
> -things a bit cheaper since we won't need an extra
> -insn to load it.  */
> - if (op_class != NO_REGS)
> + if (op_class == NO_REGS)
> +   /* Although we don't need insn to reload from
> +  memory, still accessing memory is usually more
> +  expensive than a register.  */
> +   pp->mem_cost = frequency;
> + else
> +   /* If the alternative actually allows memory, make
> +  things a bit cheaper since we won't need an
> +  extra insn to load it.  */
> pp->mem_cost
>   = ((out_p ? ira_memory_move_cost[mode][op_class][0] :
> 0)
>  + (in_p ? ira_memory_move_cost[mode][op_class][1] :
> 0)

So looking into things, there are the following 2 insns using pseudo 157:

(insn 2 4 3 2 (set (reg/v:SF 157 [ d ])
(reg:SF 33 1 [ d ])) test.c:9 466 {movsf_hardfloat}
 (expr_list:REG_DEAD (reg:SF 33 1 [ d ])
(expr_list:REG_EQUIV (mem/c:SF (plus:DI (reg/f:DI 67 ap)
(const_int 48 [0x30])) [1 d+0 S4 A64])
(nil
(insn 11 6 12 2 (set (reg/i:DI 3 3)
(sign_extend:DI (subreg:SI (reg/v:SF 157 [ d ]) 0))) test.c:16 40
{extendsidi2}
 (expr_list:REG_DEAD (reg/v:SF 157 [ d ])
(nil)))

For the alternatives of the 2 insns that accept memory, the new code is now
setting a mem_cost of 1000 (frequency), whereas before it wouldn't have been
modified for those alternatives. This seems to ignore the fact that the given
insn alternatives will be a store and load.

Vlad,
  Should the new code somehow be taking into account memory_move_cost (i.e.
memory_move_cost * frequency)?

[Bug fortran/71935] [4.9/5/6/7 Regression] ICE is_c_interoperable(): gfc_simplify_expr failed

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
Likely r197053.

[Bug c++/71937] [4.9.3] failure in cc1plus on very large fuction

[jmgjdubois at gmail dot com]

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

--- Comment #4 from Jean-Michel Dubois  ---
Created attachment 38937
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38937=edit
preprocessed files

Here are the processed files. I will try with gcc 5.4 to morrow morning.

[Bug fortran/71935] [4.9/5/6/7 Regression] ICE is_c_interoperable(): gfc_simplify_expr failed

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Index: check.c
===
--- check.c (revision 238385)
+++ check.c (working copy)
@@ -4278,7 +4278,7 @@ is_c_interoperable (gfc_expr *expr, cons
   }

 if (expr->ts.u.cl && expr->ts.u.cl->length
-   && !gfc_simplify_expr (expr, 0))
+   && !gfc_simplify_expr (expr->ts.u.cl->length, 0))
   gfc_internal_error ("is_c_interoperable(): gfc_simplify_expr failed");

 if (!c_loc && expr->ts.u.cl


Weird that an array reference out-of-bounds is only an error.

[Bug c++/71937] [4.9.3] failure in cc1plus on very large fuction

[jmgjdubois at gmail dot com]

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

--- Comment #3 from Jean-Michel Dubois  ---
The virtual machine has 4 Gb.

[jmd@localhost src]$ free
  totalusedfree  shared  buff/cache   available
Mem:3866920  618400 28506083260  397912 3001580
Swap:   2097148  929252 1167896

[Bug c++/71937] [4.9.3] failure in cc1plus on very large fuction

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
*** Bug 71938 has been marked as a duplicate of this bug. ***

[Bug c++/71938] [4.9.3] failure in cc1plus on very large fuction

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
.

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

[Bug c++/71937] [4.9.3] failure in cc1plus on very large fuction

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||memory-hog
   Severity|major   |normal

--- Comment #1 from Andrew Pinski  ---
How much memory do you have?  (you can find out via free command)

Also please attach the preprocessed source which you can get via -save-temps.

Also it might be a good idea to try GCC 5.4.0 also.

[Bug fortran/71902] [5/6 Regression] Unneeded temporary on reallocatable character assignment

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] Unneeded |[5/6 Regression] Unneeded
   |temporary on reallocatable  |temporary on reallocatable
   |character assignment|character assignment

--- Comment #3 from Thomas Koenig  ---
Fixed.

So far, little interest of a backport has appeared.

I'll leave this open for a little while so people can still ponder
if we want to backport.

[Bug c++/71938] New: [4.9.3] failure in cc1plus on very large fuction

[jmgjdubois at gmail dot com]

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

Bug ID: 71938
   Summary: [4.9.3] failure in cc1plus on very large fuction
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jmgjdubois at gmail dot com
  Target Milestone: ---

C++ source comes from a Basic to C++ translator. Original Basic source code
includes a very large function translating to a huge C++ function.

Backtrace :
g++: internal compiler error: Killed (program cc1plus)
0x40c61c execute
../../gcc/gcc.c:2854
0x40c9e4 do_spec_1
../../gcc/gcc.c:4658
0x40f2a6 process_brace_body
../../gcc/gcc.c:5941
0x40f2a6 handle_braces
../../gcc/gcc.c:5855
0x40d859 do_spec_1
../../gcc/gcc.c:5312
0x40f2a6 process_brace_body
../../gcc/gcc.c:5941
0x40f2a6 handle_braces
../../gcc/gcc.c:5855
0x40d859 do_spec_1
../../gcc/gcc.c:5312
0x40d5c3 do_spec_1
../../gcc/gcc.c:5427
0x40f2a6 process_brace_body
../../gcc/gcc.c:5941
0x40f2a6 handle_braces
../../gcc/gcc.c:5855
0x40d859 do_spec_1
../../gcc/gcc.c:5312
0x40f2a6 process_brace_body
../../gcc/gcc.c:5941
0x40f2a6 handle_braces
../../gcc/gcc.c:5855
0x40d859 do_spec_1
../../gcc/gcc.c:5312
0x40f2a6 process_brace_body
../../gcc/gcc.c:5941
0x40f2a6 handle_braces
../../gcc/gcc.c:5855
0x40d859 do_spec_1
../../gcc/gcc.c:5312
0x40f2a6 process_brace_body
../../gcc/gcc.c:5941
0x40f2a6 handle_braces
../../gcc/gcc.c:5855

[Bug c++/71937] New: [4.9.3] failure in cc1plus on very large fuction

[jmgjdubois at gmail dot com]

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

Bug ID: 71937
   Summary: [4.9.3] failure in cc1plus on very large fuction
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jmgjdubois at gmail dot com
  Target Milestone: ---

C++ source comes from a Basic to C++ translator. Original Basic source code
includes a very large function translating to a huge C++ function.

Backtrace :
g++: internal compiler error: Killed (program cc1plus)
0x40c61c execute
../../gcc/gcc.c:2854
0x40c9e4 do_spec_1
../../gcc/gcc.c:4658
0x40f2a6 process_brace_body
../../gcc/gcc.c:5941
0x40f2a6 handle_braces
../../gcc/gcc.c:5855
0x40d859 do_spec_1
../../gcc/gcc.c:5312
0x40f2a6 process_brace_body
../../gcc/gcc.c:5941
0x40f2a6 handle_braces
../../gcc/gcc.c:5855
0x40d859 do_spec_1
../../gcc/gcc.c:5312
0x40d5c3 do_spec_1
../../gcc/gcc.c:5427
0x40f2a6 process_brace_body
../../gcc/gcc.c:5941
0x40f2a6 handle_braces
../../gcc/gcc.c:5855
0x40d859 do_spec_1
../../gcc/gcc.c:5312
0x40f2a6 process_brace_body
../../gcc/gcc.c:5941
0x40f2a6 handle_braces
../../gcc/gcc.c:5855
0x40d859 do_spec_1
../../gcc/gcc.c:5312
0x40f2a6 process_brace_body
../../gcc/gcc.c:5941
0x40f2a6 handle_braces
../../gcc/gcc.c:5855
0x40d859 do_spec_1
../../gcc/gcc.c:5312
0x40f2a6 process_brace_body
../../gcc/gcc.c:5941
0x40f2a6 handle_braces
../../gcc/gcc.c:5855

[Bug fortran/71902] [5/6/7 Regression] Unneeded temporary on reallocatable character assignment

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
Author: tkoenig
Date: Tue Jul 19 21:25:33 2016
New Revision: 238497

URL: https://gcc.gnu.org/viewcvs?rev=238497=gcc=rev
Log:
2016-07-19  Thomas Koenig  

PR fortran/71902
* dependency.c (gfc_check_dependency): Use dep_ref.  Handle case
if identical is true and two array element references differ.
(gfc_dep_resovler):  Move most of the code to dep_ref.
(dep_ref):  New function.
* frontend-passes.c (realloc_string_callback):  Name temporary
variable "realloc_string".

2016-07-19  Thomas Koenig  

PR fortran/71902
* gfortran.dg/dependency_47.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/dependency_47.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dependency.c
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/71936] [6/7 Regression] ICE in wide_int_to_tree, at tree.c:1487

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||vehre at gmx dot de

--- Comment #4 from Martin Liška  ---
Started with r224477.

[Bug fortran/71936] [6/7 Regression] ICE in wide_int_to_tree, at tree.c:1487

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-19
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |6.2
Summary|ICE in wide_int_to_tree, at |[6/7 Regression] ICE in
   |tree.c:1487 |wide_int_to_tree, at
   ||tree.c:1487
 Ever confirmed|0   |1

--- Comment #3 from Martin Liška  ---
Confirmed.

[Bug fortran/71935] [4.9/5/6/7 Regression] ICE is_c_interoperable(): gfc_simplify_expr failed

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-19
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |4.9.4
Summary|ICE is_c_interoperable():   |[4.9/5/6/7 Regression] ICE
   |gfc_simplify_expr failed|is_c_interoperable():
   ||gfc_simplify_expr failed
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with GCC 4.9.0.

[Bug rtl-optimization/71916] [6/7 Regression] ICE at -O3 on valid code on x86_64-linux-gnu in "maybe_record_trace_start"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #18 from Jakub Jelinek  ---
Fixed.

[Bug pch/71934] pch cannot be disabled so gcc cannot be position independent

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
(In reply to Andrew Pinski from comment #2)
> Now having PCH around might not be useful anyways.  Someone would have to
> check to see if anyone uses PCH still.

I suggested that 2 years ago:
https://gcc.gnu.org/ml/gcc/2015-05/msg00259.html

Looks that we've been waiting for C++ module support to eventually remove PCH
support.

[Bug rtl-optimization/71916] [6/7 Regression] ICE at -O3 on valid code on x86_64-linux-gnu in "maybe_record_trace_start"

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jul 19 19:55:54 2016
New Revision: 238491

URL: https://gcc.gnu.org/viewcvs?rev=238491=gcc=rev
Log:
PR rtl-optimization/71916
* cfgrtl.c (contains_no_active_insn_p): Return false also for
bb which have a single succ fake edge.

* gcc.c-torture/compile/pr71916.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.c-torture/compile/pr71916.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/cfgrtl.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/71916] [6/7 Regression] ICE at -O3 on valid code on x86_64-linux-gnu in "maybe_record_trace_start"

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jul 19 19:54:49 2016
New Revision: 238490

URL: https://gcc.gnu.org/viewcvs?rev=238490=gcc=rev
Log:
PR rtl-optimization/71916
* cfgrtl.c (contains_no_active_insn_p): Return false also for
bb which have a single succ fake edge.

* gcc.c-torture/compile/pr71916.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr71916.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgrtl.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/71912] [6/7 regression] flexible array in struct in union rejected

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks||69698
   Severity|normal  |minor

--- Comment #5 from Martin Sebor  ---
(In reply to Martin Sebor from comment #4)
> Even though GCC with -Wpedantic silently accepts the equivalent definition
> of struct xyyzy, it issues a diagnostic for baz supporting the
> interpretation above:
> 
>   warning: invalid use of structure with flexible array member
> 
> Since the struct definitions are equivalent, it seems that either they both
> should be diagnosed or neither should be.

Let me correct the above.  GCC does give a pedantic warning in both cases
confirming that the test case is, strictly speaking, invalid.  (I must have
missed it somehow.)  Clang too diagnoses it with -Wflexible-array-extensions:

  warning: 'u' may not be nested in a struct due to flexible array

I'm lowering the Severity to Minor but I will fix the C++ error for
compatibility with GCC.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69698
[Bug 69698] [meta-bug] flexible array members

[Bug debug/71855] duplicate unspecified_parameters DIE in DWARF for functions with variable arguments

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Aldy Hernandez  ---
Fixed.  Committed to mainline, will commit to gcc-6-branch as well.

[Bug debug/71855] duplicate unspecified_parameters DIE in DWARF for functions with variable arguments

[aldyh at gcc dot gnu.org]

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

--- Comment #10 from Aldy Hernandez  ---
Author: aldyh
Date: Tue Jul 19 19:31:24 2016
New Revision: 238489

URL: https://gcc.gnu.org/viewcvs?rev=238489=gcc=rev
Log:
PR debug/71855
* dwarf2out.c (gen_subprogram_die): Only call
gen_unspecified_parameters_die while dumping early dwarf.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/debug/dwarf2/pr71855.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/dwarf2out.c

[Bug debug/71855] duplicate unspecified_parameters DIE in DWARF for functions with variable arguments

[aldyh at gcc dot gnu.org]

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

--- Comment #9 from Aldy Hernandez  ---
Author: aldyh
Date: Tue Jul 19 19:29:42 2016
New Revision: 238488

URL: https://gcc.gnu.org/viewcvs?rev=238488=gcc=rev
Log:
PR debug/71855
* dwarf2out.c (gen_subprogram_die): Only call
gen_unspecified_parameters_die while dumping early dwarf.

Added:
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr71855.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c

[Bug fortran/71936] ICE in wide_int_to_tree, at tree.c:1487

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #2 from Gerhard Steinmetz  
---

To get the whole picture it's necessary to take a look at four
analogous cases with "type" instead of "class". They compile without
an error (v6/v7), but occationally run for a long time (y3/y4).


$ cat y1.f90
program p
   type t
   end type
   type(t), allocatable :: x(:)
   allocate (x, mold=f())
   deallocate (x)
   allocate (x, source=f())
contains
   function f()
  type(t), allocatable :: f(:)
   end
end


$ cat y2.f90
program p
   type t
   end type
   type(t), allocatable :: x(:)
   allocate (x, mold=f())
   deallocate (x)
   allocate (x, source=f())
contains
   function f()
  type(t), pointer :: f(:)
   end
end


$ cat y3.f90
program p
   type t
   end type
   type(t), pointer :: x(:)
   allocate (x, mold=f())
   deallocate (x)
   allocate (x, source=f())
contains
   function f()
  type(t), allocatable :: f(:)
   end
end


$ cat y4.f90
program p
   type t
   end type
   type(t), pointer :: x(:)
   allocate (x, mold=f())
   deallocate (x)
   allocate (x, source=f())
contains
   function f()
  type(t), pointer :: f(:)
   end
end



$ gfortran-5 y4.f90
y4.f90:5:13:

allocate (x, mold=f())
 1
Error: Array specification required in ALLOCATE statement at (1)
y4.f90:7:13:

allocate (x, source=f())
 1
Error: Array specification required in ALLOCATE statement at (1)
$


$ gfortran-7-20160717 y4.f90
$
$ time timeout 100.0 a.out

real1m40.002s
user1m40.046s
sys 0m0.003s

[Bug fortran/71936] ICE in wide_int_to_tree, at tree.c:1487

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---
These other two cases produce an related ICE :


$ cat z3.f90
program p
   type t
   end type
   class(t), pointer :: x(:)
   allocate (x, mold=f())
   deallocate (x)
   allocate (x, source=f())
contains
   function f()
  class(t), allocatable :: f(:)
   end
end


$ cat z4.f90
program p
   type t
   end type
   class(t), pointer :: x(:)
   allocate (x, mold=f())
   deallocate (x)
   allocate (x, source=f())
contains
   function f()
  class(t), pointer :: f(:)
   end
end



$ gfortran-7-20160717 z4.f90
z4.f90:5:0:

allocate (x, mold=f())

internal compiler error: in fold_convert_loc, at fold-const.c:2370
0x943a0c fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.c:2370
0x71f6a4 gfc_allocate_using_malloc(stmtblock_t*, tree_node*, tree_node*,
tree_node*)
../../gcc/fortran/trans.c:663
0x7a0b70 gfc_trans_allocate(gfc_code*)
../../gcc/fortran/trans-stmt.c:5878
0x71c407 trans_code
../../gcc/fortran/trans.c:1838
0x74b218 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6207
0x6d6cc0 translate_all_program_units
../../gcc/fortran/parse.c:5916
0x6d6cc0 gfc_parse_file()
../../gcc/fortran/parse.c:6122
0x719192 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug libstdc++/71899] An internal BooleanTestable trait should be provided

[daniel.kruegler at googlemail dot com]

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

--- Comment #4 from Daniel Krügler  ---
(In reply to Ville Voutilainen from comment #2)
[..]
> I'm also not a fan of the name boolean_testable

Note that no-one yet has made an improved name suggestion for this thingee that
is discussed in LWG 2743. Unless this happens, I think that the corresponding
trait should match this name and should match the intention of what is tested
here.

> - perhaps boolean_like would
> be better? The rationale being that there are "boolean testable" types
> that work in cases where a contextual conversion to bool is performed,
> but those types are otherwise not "boolean-like". 

If you believe so, please make a corresponding comment to LWG 2743 and convince
people for accepting this revised name.

[Bug fortran/71936] New: ICE in wide_int_to_tree, at tree.c:1487

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 71936
   Summary: ICE in wide_int_to_tree, at tree.c:1487
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Looking at "class" and 4 combinations allocatable|pointer, the following
cases give an ICE with gfortran 7 and 6 (not with 5, 4.9, 4.8).


$ cat z1.f90
program p
   type t
   end type
   class(t), allocatable :: x(:)
   allocate (x, mold=f())
   deallocate (x)
   allocate (x, source=f())
contains
   function f()
  class(t), allocatable :: f(:)
  ! delivers no data
   end
end


$ cat z2.f90
program p
   type t
   end type
   class(t), allocatable :: x(:)
   allocate (x, mold=f())
   deallocate (x)
   allocate (x, source=f())
contains
   function f()
  class(t), pointer :: f(:)
   end
end



$ gfortran-5 z1.f90
z1.f90:5:13:

allocate (x, mold=f())
 1
Error: Array specification required in ALLOCATE statement at (1)
z1.f90:7:13:

allocate (x, source=f())
 1
Error: Array specification required in ALLOCATE statement at (1)
$


$ gfortran-7-20160717 z1.f90
z1.f90:5:0:

allocate (x, mold=f())

internal compiler error: in wide_int_to_tree, at tree.c:1487
0xeb3f53 wide_int_to_tree(tree_node*,
generic_wide_int const&)
../../gcc/tree.c:1487
0xeb41d6 build_int_cst(tree_node*, long)
../../gcc/tree.c:1295
0x71f88b gfc_allocate_allocatable(stmtblock_t*, tree_node*, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node*, tree_node*, gfc_expr*)
../../gcc/fortran/trans.c:794
0x7a013e gfc_trans_allocate(gfc_code*)
../../gcc/fortran/trans-stmt.c:5876
0x71c407 trans_code
../../gcc/fortran/trans.c:1838
0x74b218 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6207
0x6d6cc0 translate_all_program_units
../../gcc/fortran/parse.c:5916
0x6d6cc0 gfc_parse_file()
../../gcc/fortran/parse.c:6122
0x719192 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/71935] New: ICE is_c_interoperable(): gfc_simplify_expr failed

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 71935
   Summary: ICE is_c_interoperable(): gfc_simplify_expr failed
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With an out of bounds error :   (no ICE with 4.8.3)


$ cat z1.f90
program p
   use iso_c_binding
   character(len=1, kind=c_char), parameter :: z(2) = 'z'
   print *, sizeof(z(3))
   print *, c_sizeof(z(3))
end


$ cat z2.f90
program p
   use iso_c_binding
   character(len=1), parameter :: z(2) = 'z'
   print *, sizeof(z(3))
   print *, c_sizeof(z(3))
end



$ gfortran-7-20160717 z1.f90
z1.f90:4:21:

print *, sizeof(z(3))
 1
Warning: Array reference at (1) is out of bounds (3 > 2) in dimension 1
z1.f90:5:23:

print *, c_sizeof(z(3))
   1
Warning: Array reference at (1) is out of bounds (3 > 2) in dimension 1
z1.f90:5:23:

print *, c_sizeof(z(3))
   1
Error: Index in dimension 1 is out of bounds at (1)
f951: internal compiler error: is_c_interoperable(): gfc_simplify_expr failed
0x684721 gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1312
0x65e848 is_c_interoperable
../../gcc/fortran/check.c:4282
0x663846 gfc_check_c_sizeof(gfc_expr*)
../../gcc/fortran/check.c:4329
0x695624 check_specific
../../gcc/fortran/intrinsic.c:4274
0x69ea04 gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.c:4489
0x6e42c6 resolve_unknown_f
../../gcc/fortran/resolve.c:2718
0x6e42c6 resolve_function
../../gcc/fortran/resolve.c:3020
0x6e42c6 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6353
0x6e8ef1 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:10469
0x6e8c4b gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:9520
0x6e8ffe gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:10459
0x6eb6d2 resolve_codes
../../gcc/fortran/resolve.c:15667
0x6eb7c1 gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:15701
0x6d6aea resolve_all_program_units
../../gcc/fortran/parse.c:5855
0x6d6aea gfc_parse_file()
../../gcc/fortran/parse.c:6107
0x719192 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug pch/71934] pch cannot be disabled so gcc cannot be position independent

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Now having PCH around might not be useful anyways.  Someone would have to check
to see if anyone uses PCH still.

[Bug pch/71934] pch cannot be disabled so gcc cannot be position independent

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Actually you could exactly what is done for darwin targets to get it working on
PIE.

Also what do you mean by disabled?  Do you mean not doing a PCH for libstdc++
(there is already an option for that; can't remember offhand) or mean execute a
sorry for when someone tries it.  As I said there is a way to do PCH even with
PIE using mmap early on.

[Bug middle-end/71874] [4.9 Regression] memmove works wrong

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jul 19 17:42:26 2016
New Revision: 238487

URL: https://gcc.gnu.org/viewcvs?rev=238487=gcc=rev
Log:
PR middle-end/71874
* builtins.c (fold_builtin_memory_op): Use
get_addr_base_and_unit_offset instead of get_ref_base_and_extent.

* g++.dg/torture/pr71874.C: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/torture/pr71874.C
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/builtins.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug middle-end/71874] [4.9 Regression] memmove works wrong

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jul 19 17:39:26 2016
New Revision: 238486

URL: https://gcc.gnu.org/viewcvs?rev=238486=gcc=rev
Log:
PR middle-end/71874
* gimple-fold.c (fold_builtin_memory_op): Use
get_addr_base_and_unit_offset instead of get_ref_base_and_extent.

* g++.dg/torture/pr71874.C: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/torture/pr71874.C
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/gimple-fold.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug middle-end/71874] [4.9 Regression] memmove works wrong

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jul 19 17:33:58 2016
New Revision: 238485

URL: https://gcc.gnu.org/viewcvs?rev=238485=gcc=rev
Log:
PR middle-end/71874
* gimple-fold.c (fold_builtin_memory_op): Use
get_addr_base_and_unit_offset instead of get_ref_base_and_extent.

* g++.dg/torture/pr71874.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr71874.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/gimple-fold.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug libstdc++/71320] filesystem::permissions does not respect add_perms/remove_perms

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.5
  Known to fail||5.4.0, 6.1.0

--- Comment #5 from Jonathan Wakely  ---
Fixed for 5.5 and 6.2

[Bug pch/71934] New: pch cannot be disabled so gcc cannot be position independent

[nsz at gcc dot gnu.org]

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

Bug ID: 71934
   Summary: pch cannot be disabled so gcc cannot be position
independent
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pch
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

gcc should be possible to build as PIE by disabling PCH.
(e.g. for running gcc natively on an fdpic target)

some users might not care about PCH, but want PIE gcc,
making PCH position independent can make it slower,
but optionally disabling it should be non-controversial.

[Bug middle-end/71874] [4.9 Regression] memmove works wrong

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jul 19 17:30:05 2016
New Revision: 238484

URL: https://gcc.gnu.org/viewcvs?rev=238484=gcc=rev
Log:
PR middle-end/71874
* gimple-fold.c (fold_builtin_memory_op): Use
get_addr_base_and_unit_offset instead of get_ref_base_and_extent.

* g++.dg/torture/pr71874.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr71874.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/66319] [6 Regression] gcov-tool.c:84:65: error: invalid conversion from 'int (*)(const c har*, const stat*, int, FTW*)' to 'int (*)(const char*, const stat*, int, FTW)'

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #20 from The Written Word  
---
(In reply to dave.anglin from comment #17)
> On 2016-07-12, at 12:36 PM, bugzilla-gcc at thewrittenword dot com wrote:
> 
> >>  don't have any ia64 hardware and I also don't have an 11.31 box.  So,
> >> there's a support issue for ia64 and 11.31.  Albert, if you or one of
> >> your staff could help in this regard, I would support the addition of
> >> a new hpux maintainer.
> > 
> > We can provide access to HP-UX 11.23/ia and 11.31/ia. Sadly, apart from
> > building GCC, we don't have any intricate ia64 knowledge to help with
> > maintainership.
> 
> What I was hoping for was someone to handle the hpux aspect on ia64.  Do
> occasional builds and tests, etc.

We might be able to do this. Will look into getting something automated over
the next few weeks.

[Bug libstdc++/71320] filesystem::permissions does not respect add_perms/remove_perms

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Tue Jul 19 17:17:05 2016
New Revision: 238483

URL: https://gcc.gnu.org/viewcvs?rev=238483=gcc=rev
Log:
libstdc++/71320 Add or remove file permissions correctly

Backport from mainline
2016-06-06  Jonathan Wakely  

PR libstdc++/71320
* src/filesystem/ops.cc (permissions(const path&, perms, error_code&)):
Add or remove permissions according to perms argument.
* testsuite/experimental/filesystem/operations/permissions.cc: New
test.

Added:
   
branches/gcc-5-branch/libstdc++-v3/testsuite/experimental/filesystem/operations/permissions.cc
Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/src/filesystem/ops.cc

[Bug c/71932] internal compiler error: in push_reload, at reload.c:1360

[RichardFalk at comcast dot net]

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

--- Comment #3 from Richard Falk  ---
Created attachment 38936
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38936=edit
Slightly simpler pre-processed C file that demonstrates bug

Slightly simpler in that only one parameter is needed in the "func" function. 
I also made some log_printf calls have more consistent types, but I can't
convert the variadic function "printf10fixed" to two fixed parameter functions
without the bug going away.

[Bug testsuite/71933] New: plugin tests fail when host!=target but tests are run locally

[nsz at gcc dot gnu.org]

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

Bug ID: 71933
   Summary: plugin tests fail when host!=target but tests are run
locally
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

if the test system is run locally (unix.exp) then
LD_LIBRARY_PATH set during compilation and linking.

this affects the dynamic linking of gcc and ld,
not just the linking and execution of the test binary.

normally this is not a problem because gcc does not depend
on target libs that can be confused with host libraries
(other than the libc), but plugins do.

so glibc to musl cross compiler plugin tests fail.
(i think other cross compilers that can be tested without
remote target board setup would also fail.)

gcc depends on host libc and the plugin.so depends on host
libc, libgcc_s and libstdc++, but the dynamic linker finds
the target libs first. (musl libc.so and glibc .so happen
to have different name so plain gcc uses the right libc,
but loading the plugin deps fail which depend on libc.so
instead of libc.so.6.)

i think only LD_RUN_PATH should be set for compilation
and linking.


example failures when running 
make check-gcc RUNTESTFLAGS=plugin.exp

FAIL: gcc.dg/plugin/self-assign-test-1.c -fplugin=./selfassign.so (test for
excess errors)
Excess errors:
cc1: error: cannot load plugin ./selfassign.so
   /usr/lib/x86_64-linux-gnu/libc.so: invalid ELF header
FAIL: gcc.dg/plugin/ggcplug-test-1.c -fplugin=./ggcplug.so (test for excess
errors)
Excess errors:
cc1: error: cannot load plugin ./ggcplug.so
   /usr/lib/x86_64-linux-gnu/libc.so: invalid ELF header

[Bug middle-end/71734] [7 Regression] FAIL: libgomp.fortran/simd4.f90 -O3 -g execution test

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jul 19 16:47:30 2016
New Revision: 238482

URL: https://gcc.gnu.org/viewcvs?rev=238482=gcc=rev
Log:
PR middle-end/71734
* g++.dg/vect/pr70729.cc: Don't include string.h or xmmintrin.h.
(my_alloc): Rewritten to use __builtin_posix_memalign and
__SIZE_TYPE__.
(my_free): Use __builtin_free instead of _mm_free.
(Vec::operator=): Use __builtin_memcpy.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/vect/pr70729.cc

[Bug debug/71855] duplicate unspecified_parameters DIE in DWARF for functions with variable arguments

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #8 from Aldy Hernandez  ---
Mine.

[Bug fortran/64945] Structure constructors and non-NULL-data-targets and polymorphic pointer components

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #4 from Dominique d'Humieres  ---
Wrong resolution!-(

[Bug fortran/64945] Structure constructors and non-NULL-data-targets and polymorphic pointer components

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Dominique d'Humieres  ---
.

[Bug fortran/64945] Structure constructors and non-NULL-data-targets and polymorphic pointer components

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
> A test showing the problem is missing. As such the PR is useless for anyone,
> but the reporter.

No feedback, closing as INVALID.

[Bug fortran/71027] -fsanitize=address catches out of bounds access on assumed size array only with -O0

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Dominique d'Humieres  ---
> Yes, you are right, and probably in real programs the subroutine would
> not be optimized away.
> Thank you for the explanation.

Closing as INVALID.

[Bug libstdc++/71320] filesystem::permissions does not respect add_perms/remove_perms

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Tue Jul 19 16:34:23 2016
New Revision: 238480

URL: https://gcc.gnu.org/viewcvs?rev=238480=gcc=rev
Log:
libstdc++/71320 Add or remove file permissions correctly

Backport from mainline
2016-06-06  Jonathan Wakely  

PR libstdc++/71320
* src/filesystem/ops.cc (permissions(const path&, perms, error_code&)):
Add or remove permissions according to perms argument.
* testsuite/experimental/filesystem/operations/permissions.cc: New
test.

Added:
   
branches/gcc-6-branch/libstdc++-v3/testsuite/experimental/filesystem/operations/permissions.cc
Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/src/filesystem/ops.cc

[Bug fortran/59438] DWARF: Fortran mishandles ALLOCATABLE/ASSOCIATED in debug output

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
*** Bug 68889 has been marked as a duplicate of this bug. ***

[Bug fortran/24546] [meta-bug] gfortran debugging problems

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24546
Bug 24546 depends on bug 68889, which changed state.

Bug 68889 Summary: Fortran/DWARF: Possible bug in the handling of 
DW_AT_associated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68889

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

[Bug fortran/68889] Fortran/DWARF: Possible bug in the handling of DW_AT_associated

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Dominique d'Humieres  ---
> What is the point to open a new PR for an issue already tracked by pr59438?

No feedback, closing as duplicate.

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

[Bug debug/71855] duplicate unspecified_parameters DIE in DWARF for functions with variable arguments

[aldyh at gcc dot gnu.org]

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

--- Comment #7 from Aldy Hernandez  ---
Created attachment 38935
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38935=edit
patch being tested

gen_unspecified_parameters_die() is being called in early dwarf and again for
the same parent DIE in late dwarf.  IMO, we should only be calling it in early
dwarf.

Testing attached patch.

[Bug fortran/58667] Add -Wfloat-conversion

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
The gfortran documentation says

-Wconversion
Warn about implicit conversions that are likely to change the value of the
expression after conversion. Implied by -Wall. 
-Wconversion-extra
Warn about implicit conversions between different types and kinds. This option
does not imply -Wconversion. 

Isn't it enough?

Without feedback I'll close this PR as WONTFIX.

[Bug c/71932] internal compiler error: in push_reload, at reload.c:1360

[RichardFalk at comcast dot net]

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

--- Comment #2 from Richard Falk  ---
Adding "-fno-move-loop-invariants" to the compilation request makes the problem
go away, but I've seen some situations where even this is not sufficient.

A discussion about this bug is in the following thread:

http://www.avrfreaks.net/forum/atmel-studio-62-issue-pushreload-reloadc1360q

where post #12 indicates that the problem exists in gcc versions from 4.8.0 to
6.1.1 but that 4.7.1 works fine.

[Bug c/71932] internal compiler error: in push_reload, at reload.c:1360

[RichardFalk at comcast dot net]

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

--- Comment #1 from Richard Falk  ---
Note that there are minor variations of this code that do not generate a
compiler error but generate bad compiler code, but I no longer have that case
available.  Hopefully the fix to this problem will also fix the bad compiler
output.  This may indicate that the bug generates an internal compiler
condition that is not always detected and reported as an error.

[Bug fortran/71688] [4.9/5/6/7 Regression] ICE in analyze, at cgraphunit.c:632 with -fcoarray=lib

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor  ---
Author: jamborm
Date: Tue Jul 19 15:44:56 2016
New Revision: 238477

URL: https://gcc.gnu.org/viewcvs?rev=238477=gcc=rev
Log:
Fix PR fortran/71688

2016-07-19  Martin Jambor  

PR fortran/71688
* trans-decl.c (gfc_generate_function_code): Use cgraph_get_create_node
rather than cgraph_create_node to get a call graph node.

testsuite/
* gfortran.dg/pr71688.f90: New test.



Added:
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/pr71688.f90
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/fortran/trans-decl.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug c/71932] New: internal compiler error: in push_reload, at reload.c:1360

[RichardFalk at comcast dot net]

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

Bug ID: 71932
   Summary: internal compiler error: in push_reload, at
reload.c:1360
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: RichardFalk at comcast dot net
  Target Milestone: ---

Created attachment 38934
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38934=edit
Pre-processed C file with the minimum amount of code to generate this bug.

The push_reload error is very sensitive to any changes to the source code.  The
minimum subset to reproduce the error is attached.

The error with the attached pre-processed C file is as follows:

reload_bug.c: In function 'push_reload_error':
reload_bug.c:96:1: internal compiler error: in push_reload, at reload.c:1360

and is generated with the following minimum call where the -Os optimization is
required and is the only optimization setting that fails:

avr-gcc -Os -S reload_bug_pre.c

The details of the avr-gcc build are as follows:

Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/local/Cellar/avr-gcc/4.9.3/libexec/gcc/avr/4.9.3/lto-wrapper
Target: avr
Configured with: ../configure --target=avr
--prefix=/usr/local/Cellar/avr-gcc/4.9.3 --enable-languages=c,c++ --with-gnu-as
--with-gnu-ld --with-ld=/usr/local/opt/avr-binutils/bin/avr-ld
--with-as=/usr/local/opt/avr-binutils/bin/avr-as --disable-nls --disable-shared
--disable-threads --disable-libssp --disable-libstdcxx-pch --disable-libgomp
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-system-zlib
Thread model: single
gcc version 4.9.3 (GCC)

Note that the following construct seen (and required) in the file:

(__extension__({static const char __c[] = (""); &__c[0];}))

comes from the macro PSTR defined in the AVR header pgmspace.h

[Bug fortran/71688] [4.9/5/6/7 Regression] ICE in analyze, at cgraphunit.c:632 with -fcoarray=lib

[jamborm at gcc dot gnu.org]

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

--- Comment #7 from Martin Jambor  ---
Author: jamborm
Date: Tue Jul 19 15:40:43 2016
New Revision: 238476

URL: https://gcc.gnu.org/viewcvs?rev=238476=gcc=rev
Log:
Fix PR fortran/71688

2016-07-19  Martin Jambor  

PR fortran/71688
* trans-decl.c (gfc_generate_function_code): Use cgraph_get_create_node
rather than cgraph_create_node to get a call graph node.

testsuite/
gfortran.dg/pr71688.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/pr71688.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/54367] [meta-bug] lambda expressions

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367
Bug 54367 depends on bug 62052, which changed state.

Bug 62052 Summary: function parameter has wrong address in lambda converted to 
pointer-to-function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62052

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug c++/62052] function parameter has wrong address in lambda converted to pointer-to-function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
The testcases give the right results with r233733 (fix for the ICE in Bug
69889).

r232166 gives the wrong result, r232167 gives the ICE, so maybe it was fixed
somewhere between r232167 and r233733 but it's not possible to tell.

[Bug debug/71855] duplicate unspecified_parameters DIE in DWARF for functions with variable arguments

[aldyh at gcc dot gnu.org]

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

--- Comment #6 from Aldy Hernandez  ---
Some idiot wrote this:

commit 3a1c9df24981c5068334726a0d92fd80c455eb6e
Author: aldyh 
Date:   Fri Jun 5 18:44:53 2015 +

Merge debug-early branch into mainline.
...

And that's where it all started ;-).

[Bug tree-optimization/71769] Invalid warning from -Wunsafe-loop-optimizations for a finite loop

[amker at gcc dot gnu.org]

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

--- Comment #6 from amker at gcc dot gnu.org ---
(In reply to nightstrike from comment #5)
> Could you backport to the branches?

Well, that's release manager's call.  Richard?

[Bug c/71855] duplicate unspecified_parameters DIE in DWARF for functions with variable arguments

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

Version|6.1.0   |7.0

--- Comment #5 from Aldy Hernandez  ---
Confirmed on mainline as well.  Changing tag.

[Bug tree-optimization/71916] [6/7 Regression] ICE at -O3 on valid code on x86_64-linux-gnu in "maybe_record_trace_start"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #14 from Jakub Jelinek  ---
The following patch fixes this:

--- gcc/cfgrtl.c.jj 2016-05-11 15:15:49.0 +0200
+++ gcc/cfgrtl.c2016-07-19 16:38:20.362303955 +0200
@@ -574,8 +574,10 @@ contains_no_active_insn_p (const_basic_b
 {
   rtx_insn *insn;

-  if (bb == EXIT_BLOCK_PTR_FOR_FN (cfun) || bb == ENTRY_BLOCK_PTR_FOR_FN
(cfun)
-  || !single_succ_p (bb))
+  if (bb == EXIT_BLOCK_PTR_FOR_FN (cfun)
+  || bb == ENTRY_BLOCK_PTR_FOR_FN (cfun)
+  || !single_succ_p (bb)
+  || (single_succ_edge (bb)->flags & EDGE_FAKE) != 0)
 return false;

   for (insn = BB_HEAD (bb); insn != BB_END (bb); insn = NEXT_INSN (insn))

Normally, empty bbs that fall through into nowhere aren't considered as
forwarders, because those require single_succ_p.  But if there are fake edges
added, this doesn't work anymore.

[Bug tree-optimization/71769] Invalid warning from -Wunsafe-loop-optimizations for a finite loop

[nightstrike at gmail dot com]

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

--- Comment #5 from nightstrike  ---
Could you backport to the branches?

[Bug rtl-optimization/71916] [6/7 Regression] ICE at -O3 on valid code on x86_64-linux-gnu in "maybe_record_trace_start"

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
Created attachment 38933
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38933=edit
gcc7-pr71916.patch

I'll test this.

[Bug tree-optimization/71916] [6/7 Regression] ICE at -O3 on valid code on x86_64-linux-gnu in "maybe_record_trace_start"

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
This looks like a bug in handling of __builtin_unreachable (in RTL basic blocks
without successors) during cross-jumping in jump2 pass.
In *.csa there are 2 such basic blocks in the IL, but in *.jump2 only one.
The __builtin_unreachable blocks are bb 34 and bb 39, and we have 4 bbs that
contain d = 0 memory store following to branch to one of these basic blocks
(two to bb 34, two to bb 39).  Cross-jumping the d = 0 bbs that branch to the
same empty block with no successors is of course fine, the problem is with
cross-jumping the ones that branch to different empty blocks with no
successors.

For noreturn calls which is a similar case, we avoid this with
  /* For noreturn calls when not accumulating outgoing args force
 REG_ARGS_SIZE note to prevent crossjumping of calls with different
 args sizes.  */
  else if (!ACCUMULATE_OUTGOING_ARGS && (ecf_flags & ECF_NORETURN) != 0)
add_reg_note (call_insn, REG_ARGS_SIZE, GEN_INT (stack_pointer_delta));
but of course for the multiple __builtin_unreachable () cases there is no
instruction to stick the REG_ARGS_SIZE to.

[Bug c/71855] duplicate unspecified_parameters DIE in DWARF for functions with variable arguments

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Target||x86-64-Linux
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-19
 Ever confirmed|0   |1

--- Comment #4 from Aldy Hernandez  ---
Reduced on x86-64 Linux to:

void foobar (const char *format, ...)
{
}

Confirmed compiling with -g.

$ ./xgcc -B./ -c a.i -g -save-temps
$ readelf --debug-dump a.o



<1><2d>: Abbrev Number: 2 (DW_TAG_subprogram)
<2e>   DW_AT_external: 1
<2e>   DW_AT_name: (indirect string, offset: 0x0): foobar   
<32>   DW_AT_decl_file   : 1
<33>   DW_AT_decl_line   : 1
<34>   DW_AT_prototyped  : 1
<34>   DW_AT_low_pc  : 0x0  
<3c>   DW_AT_high_pc : 0x59 
<44>   DW_AT_frame_base  : 1 byte block: 9c (DW_OP_call_frame_cfa)
<46>   DW_AT_GNU_all_call_sites: 1  
<46>   DW_AT_sibling : <0x5c>   
 <2><4a>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<4b>   DW_AT_name: (indirect string, offset: 0x3e): format  
<4f>   DW_AT_decl_file   : 1
<50>   DW_AT_decl_line   : 1
<51>   DW_AT_type: <0x5c>   
<55>   DW_AT_location: 3 byte block: 91 b8 7e   (DW_OP_fbreg: -200)
 <2><59>: Abbrev Number: 4 (DW_TAG_unspecified_parameters)
 <2><5a>: Abbrev Number: 4 (DW_TAG_unspecified_parameters)

Notice foobar() has two DW_TAG_unspecified_parameters DIEs.  I'm not a dwarf
person, but it looks like there should only be one.

[Bug c/71855] duplicate unspecified_parameters DIE in DWARF for functions with variable arguments

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #3 from Aldy Hernandez  ---
It isn't clear from the bug what OS or set of header files where used to
generate the dwarf.  It would be ideal to include a pre-processed reduced
testcase to help in analyzing this bug.

You can use:

/your/version/gcc -E  -c foo.c -save-temps

-save-temps will create the preprocessed foo.i automatically.  Then, reduce
this foo.i to the bare minimum, and attach it to this PR.

Also, what flags did you use for GCC in order to get this faulty behavior?

What flags did you use for readelf, or eu-readelf, etc?

Here are some general guidelines for reporting bugs for GCC:

https://gcc.gnu.org/bugs/

[Bug tree-optimization/71916] [6/7 Regression] ICE at -O3 on valid code on x86_64-linux-gnu in "maybe_record_trace_start"

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška  ---
Created attachment 38932
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38932=edit
--dbg-cnt="registered_jump_thread:4" dump

[Bug tree-optimization/71916] [6/7 Regression] ICE at -O3 on valid code on x86_64-linux-gnu in "maybe_record_trace_start"

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška  ---
Created attachment 38931
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38931=edit
--dbg-cnt="registered_jump_thread:3" dump

[Bug tree-optimization/71916] [6/7 Regression] ICE at -O3 on valid code on x86_64-linux-gnu in "maybe_record_trace_start"

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
Couple of observations:

1) the second test-case triggers undefined behavior in:
g[i] = 9;

/home/marxin/Programming/testcases/pr71916-2-original.c:20:8: runtime error:
index 4 out of bounds for type 'char [4]'
/home/marxin/Programming/testcases/pr71916-2-original.c:20:12: runtime error:
store to address 0xffe64530 with insufficient space for an object of type
'char'

2) cunrolli pass determines that following loop iterates 5 times (because of
g[4] array):

pr71916-2-original.c:11:6: note: loop with 5 iterations completely unrolled
Latch of last iteration was marked by __builtin_unreachable ().

3) --dbg-cnt="registered_jump_thread:4" is the first jump threading which
triggers the ICE. It adds jump to the BB with __builtin_unreachable.

[Bug preprocessor/68854] isystem and ansi cause assembly preprocessing problem

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org
Summary|isystem and ansi cause arm  |isystem and ansi cause
   |assembly preprocessing  |assembly preprocessing
   |problem |problem

--- Comment #3 from Ramana Radhakrishnan  ---
Nothing below suggests this is "arm" specific ... The compiler used is
targeting x86_64-linux-gnu and the problem really is in the pre-processor or
the compiler driver if anything. 

I've not tried reproducing this with an arm compiler.

[Bug fortran/71703] [4.9/5/6/7 Regression] ICE in wide_int_to_tree, at tree.c:1488

[tom.k.cook at gmail dot com]

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

--- Comment #6 from Tom  ---
I'll have a go.  Not sure how much time I'll get to put into it.

On Tue, 19 Jul 2016 at 13:55 dominiq at lps dot ens.fr <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71703
>
> --- Comment #5 from Dominique d'Humieres  ---
> > ICE started with GCC 4.8.0, former releases report:
> >
> > /home/marxin/Programming/testcases/pr71073.f90:6.14:
> >
> >  class(*), allocatable :: a
> >  1
> > Fatal Error: Unlimited polymorphism at (1) not yet supported
>
> Unlimited polymorphism has been implemented starting at r194622. AFAICT I
> get
> the ICE for all the following revisions and I don't think this PR qualify
> for a
> regression.
>
> > We build the same source with a GFortran 5.3.0 which we built
> > ourselves without problems.
>
> From the above you see a different bug. Could you please try to reduce your
> code to something compiling with 5.3.0 and not with 5.3.1?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug lto/71920] request to backport commit trunk@234239 to gcc 4.9 and 5

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Martin Liška  ---
Fixed on both branches.

[Bug tree-optimization/71916] [6/7 Regression] ICE at -O3 on valid code on x86_64-linux-gnu in "maybe_record_trace_start"

[helloqirun at gmail dot com]

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

--- Comment #9 from Qirun Zhang  ---
(In reply to Martin Liška from comment #7)
> Hm, the second test-case works fine with r233209, but started to fail with
> r236831:
> 
> Author: law 
> Date:   Fri May 27 16:32:38 2016 +
> 
> * tree-ssa-threadedge.c: Remove include of tree-ssa-threadbackward.h.
> (thread_across_edge): Remove calls to find_jump_threads_backwards.
> * passes.def: Add jump threading passes before DOM/VRP.
> * tree-ssa-threadbackward.c (find_jump_threads_backwards): Change
> argument to a basic block from an edge.  Remove tests which are
> handled elsewhere.
> (pass_data_thread_jumps, class pass_thread_jumps): New.
> (pass_thread_jumps::gate, pass_thread_jumps::execute): New.
> (make_pass_thread_jumps): Likewise.
> * tree-pass.h (make_pass_thread_jumps): Declare.
> 
> * gcc.dg/tree-ssa/pr21417.c: Update expected output.
> * gcc.dg/tree-ssa/pr66752-3.c: Likewise.
> * gcc.dg/tree-ssa/pr68198.c: Likewise.
> * gcc.dg/tree-ssa/pr69196-1.c: Likewise.
> * gcc.dg/tree-ssa/pr69270-3.c: Likewise.
> * gcc.dg/tree-ssa/ssa-dom-thread-2b.c: Likewise.
> * gcc.dg/tree-ssa/ssa-dom-thread-2g.c: Likewise.
> * gcc.dg/tree-ssa/ssa-dom-thread-2h.c: Likewise.
> * gcc.dg/tree-ssa/ssa-dom-thread-6.c: Likewise.
> * gcc.dg/tree-ssa/ssa-dom-thread-7.c: Likewise.
> * gcc.dg/tree-ssa/ssa-dom-thread-12.c: Likewise.
> * gcc.dg/tree-ssa/ssa-dom-thread-13.c: Likewise.
> * gcc.dg/tree-ssa/vrp56.c: Likewise.

Will it be a good idea to separate the two bugs (i.e., to create a new PR for
the second case)?

[Bug driver/71930] g++ invokes the wrong preprocessor

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Jonathan Wakely from comment #5)
> > But this is a dup of PR 67023 anyway.
> > 
> > *** This bug has been marked as a duplicate of bug 67023 ***
> 
> Which I've pointed you to before:
> https://gcc.gnu.org/ml/gcc-help/2015-09/msg00081.html

And here when I first created that bug!
https://gcc.gnu.org/ml/gcc-help/2015-07/msg00110.html

[Bug target/71921] missed vectorization optimization

[arjan at linux dot intel.com]

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

--- Comment #5 from Arjan van de Ven  ---
I don't think that's completely true; it does use maxss (the non-vector one)
for this code, so at least something thinks its safe to use max, just likely
that something is after the vector phase?

[Bug tree-optimization/71916] [6/7 Regression] ICE at -O3 on valid code on x86_64-linux-gnu in "maybe_record_trace_start"

[rth at gcc dot gnu.org]

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

--- Comment #8 from Richard Henderson  ---
(gdb) call debug_cfi_row(cur_row)
.cfi_def_cfa 7, 16
.cfi_offset 3, -16
.cfi_offset 16, -8
(gdb) call debug_cfi_row(ti->beg_row)
.cfi_def_cfa 7, 8
.cfi_offset 16, -8

(gdb) call debug_rtx(start)
(code_label 377 83 109 25 46 "" [3 uses])

(gdb) call debug_rtx(origin)
(jump_insn:TI 187 186 395 36 (set (pc)
(if_then_else (ne (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref:DI 377)
(pc))) z.c:16 635 {*jcc_1}
 (expr_list:REG_DEAD (reg:CCZ 17 flags)
(int_list:REG_BR_PROB 9500 (nil)))
 -> 377)

On one code path we've saved RBX, and on another code path we haven't.
The label in question appears in jump2, presumably jump threading, but
I haven't actually traced the blocks to be sure this is true.

I imagine it's got something to do with the infinite loop vs shrink-wrapping.
We perhaps ought to have added a restore of RBX, but didn't because it
doesn't appear to be needed.

[Bug fortran/59438] DWARF: Fortran mishandles ALLOCATABLE/ASSOCIATED in debug output

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
Related to/ duplicate of pr71906?

[Bug debug/71906] [6/7 Regression] Fortran allocatable strings debug info type size regression

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
Related to/ duplicate of pr59438?

[Bug driver/71930] g++ invokes the wrong preprocessor

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #5)
> But this is a dup of PR 67023 anyway.
> 
> *** This bug has been marked as a duplicate of bug 67023 ***

Which I've pointed you to before:
https://gcc.gnu.org/ml/gcc-help/2015-09/msg00081.html

[Bug driver/71930] g++ invokes the wrong preprocessor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #5 from Jonathan Wakely  ---
Since g++ usually implies -x c++ it is reasonable to expect it to also do so
when reading from standard input. This error message isn't clear that you need
*both* -E and -x to get the desired behaviour:

$ g++ - <<< 'int main() { throw 1; }'
g++: error: -E or -x required when input is from standard input

Since the driver invoked was g++ it is fairly certain the user wanted -x c++ to
be implied. Obeying the error and adding -E *seems* to work, but loses the -x
c++ default.

But this is a dup of PR 67023 anyway.

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

[Bug driver/67023] "g++" does not set preprocessor language to C++ when reading from standard input

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||noloader at gmail dot com

--- Comment #1 from Jonathan Wakely  ---
*** Bug 71930 has been marked as a duplicate of this bug. ***

[Bug fortran/71703] [4.9/5/6/7 Regression] ICE in wide_int_to_tree, at tree.c:1488

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> ICE started with GCC 4.8.0, former releases report:
>
> /home/marxin/Programming/testcases/pr71073.f90:6.14:
>
>  class(*), allocatable :: a
>  1
> Fatal Error: Unlimited polymorphism at (1) not yet supported

Unlimited polymorphism has been implemented starting at r194622. AFAICT I get
the ICE for all the following revisions and I don't think this PR qualify for a
regression.

> We build the same source with a GFortran 5.3.0 which we built
> ourselves without problems.

>From the above you see a different bug. Could you please try to reduce your
code to something compiling with 5.3.0 and not with 5.3.1?

[Bug driver/71930] g++ invokes the wrong preprocessor

[noloader at gmail dot com]

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

--- Comment #4 from Jeffrey Walton  ---
(In reply to Jakub Jelinek from comment #3)
> (1) so what?

I suppose I should thank my lucky stars g++ did not invoke the preprocessor for
Fortran or Java then.

Maybe GCC could make it round robin so defines from different languages are
provided since it seems to ignore the obvious signals used by developers.

[Bug driver/71930] g++ invokes the wrong preprocessor

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
(1) so what?  The behavior for - input without -x is the same for all drivers. 
gfortran -E - will not preprocess as if it is Fortran source, gcj -E - will not
preprocess as if it is a Java source (after all, there is no preprocessing for
Java), etc.
And (2), the fact that -std=c++17 is C++/ObjC++ specific option is not known to
the driver, all it knows is that it should pass options starting with -std down
to the preprocessor and/or compiler.  Why should that affect which preprocessor
is used?  Should it pick up ObjC++ or C++?

There is a standard option to choose the language, and that is -x.  If the
source has an extension, then the language is generally determined from the
file extension (but it can be still overridden).  -std= is just about choosing
a particular revision of the language.

[Bug middle-end/71734] [7 Regression] FAIL: libgomp.fortran/simd4.f90 -O3 -g execution test

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Created attachment 38930
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38930=edit
gcc7-pr71734.patch

The bug is of course in using (uselessly) an x86_64/i?86 specific intrinsic
headers in a generic test on all architectures.
There is no need to use that header though, it fails the same way with
__builtin_posix_memalign/__builtin_free, and as it is a compile time only test,
we don't care if the library implements it or not.

[Bug driver/71930] g++ invokes the wrong preprocessor

[noloader at gmail dot com]

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

--- Comment #2 from Jeffrey Walton  ---
(In reply to Jakub Jelinek from comment #1)
> What makes you think that this is a bug?

I think its a bug (1) g++ is being used, and (2) -std=c++17 is being used. What
does a file extension have to do with a C++ define, like __cplusplus?

[Bug driver/71930] g++ invokes the wrong preprocessor

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Jakub Jelinek  ---
What makes you think that this is a bug?  If the source is on stdin, then
obviously file extension determination of the source type doesn't apply, so you
need to supply it explicitly, using -xc or -xc++ etc.
Without -x and with - input, the driver errors unless -E is used, in which case
it is always the C preprocessing.  The driver doesn't try to guess that because
you've used some C++-ish option you want C++ preprocessing.  Just use -xc++.

[Bug testsuite/71931] New: build sysroot flags are not passed to target lib tests

[nsz at gcc dot gnu.org]

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

Bug ID: 71931
   Summary: build sysroot flags are not passed to target lib tests
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

when gcc is built --with-build-sysroot then $CC for the target libs
includes --sysroot, but when the test is run for these target libs
CC=xgcc is used without --sysroot

libstdc++ tests have special workaround to pass build time CC and
CFLAGS settings to the test system, same for libgfortran, but
libatomic or libgomp tests fail when --with-build-sysroot is used.

it was reported earlier but i could not find it in bugzilla:
https://gcc.gnu.org/ml/gcc-patches/2013-05/msg01181.html

the root cause is that the dejagnu 'find_gcc' function is used
as CC in the tests which is wrong if any special flag
(like --sysroot) is needed for compilation/linking.

[Bug driver/71930] New: g++ invokes the wrong preprocessor

[noloader at gmail dot com]

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

Bug ID: 71930
   Summary: g++ invokes the wrong preprocessor
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: noloader at gmail dot com
  Target Milestone: ---

I don't believe this is expected behavior, especially since (1) g++ is being
used, and (2) -std=c++17 is being used.

$ /opt/local/bin/g++ -std=c++17 -dM -E - 

[Bug middle-end/71874] [4.9 Regression] memmove works wrong

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 38929
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38929=edit
gcc49-pr71874-2.patch

Another patch, using get_addr_base_and_unit_offset.  This one optimizes
__builtin_memmove (str + 20, str + 15, 4);
into memcpy while the other patch doesn't.

[Bug middle-end/71874] [4.9 Regression] memmove works wrong

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 38928
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38928=edit
gcc49-pr71874-1.patch

One possible untested patch.

[Bug c/71929] New: libcilkrts build failure because broken __cilkrts_yield and __cilkrts_idle

[nsz at gcc dot gnu.org]

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

Bug ID: 71929
   Summary: libcilkrts build failure because broken
__cilkrts_yield and __cilkrts_idle
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

os-unix.c is broken on *linux-musl targets.

the portable way to yield is sched_yield, this should be called on all
platforms including linux, except on systems where it does not exist (only
__MIC__).

pthread_yield should not be called on *linux-gnu either.

sched_yield is declared in sched.h so it should be included on all targets.

../../../src_toolchain/libcilkrts/runtime/os-unix.c: In function
'__cilkrts_yield':
../../../src_toolchain/libcilkrts/runtime/os-unix.c:471:5: warning: implicit
declaration of function 'pthread_yield'; did you mean 'pthread_self'?
[-Wimplicit-function-declaration]
 pthread_yield();
 ^

[Bug tree-optimization/71916] [6/7 Regression] ICE at -O3 on valid code on x86_64-linux-gnu in "maybe_record_trace_start"

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Hm, the second test-case works fine with r233209, but started to fail with
r236831:

Author: law 
Date:   Fri May 27 16:32:38 2016 +

* tree-ssa-threadedge.c: Remove include of tree-ssa-threadbackward.h.
(thread_across_edge): Remove calls to find_jump_threads_backwards.
* passes.def: Add jump threading passes before DOM/VRP.
* tree-ssa-threadbackward.c (find_jump_threads_backwards): Change
argument to a basic block from an edge.  Remove tests which are
handled elsewhere.
(pass_data_thread_jumps, class pass_thread_jumps): New.
(pass_thread_jumps::gate, pass_thread_jumps::execute): New.
(make_pass_thread_jumps): Likewise.
* tree-pass.h (make_pass_thread_jumps): Declare.

* gcc.dg/tree-ssa/pr21417.c: Update expected output.
* gcc.dg/tree-ssa/pr66752-3.c: Likewise.
* gcc.dg/tree-ssa/pr68198.c: Likewise.
* gcc.dg/tree-ssa/pr69196-1.c: Likewise.
* gcc.dg/tree-ssa/pr69270-3.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-2b.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-2g.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-2h.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-6.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-7.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-12.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-13.c: Likewise.
* gcc.dg/tree-ssa/vrp56.c: Likewise.

[Bug target/71874] [4.9 Regression] memmove works wrong

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
This happens only with C++, seems it has started with r208554 and got fixed
with r221532.