[Bug ada/70867] New: access discriminant in return aggregate detected as dangling if set from an implicit dereference in generic package

[nicolas.boulenguez at free dot fr]

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

Bug ID: 70867
   Summary: access discriminant in return aggregate detected as
dangling if set from an implicit dereference in
generic package
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nicolas.boulenguez at free dot fr
  Target Milestone: ---

Hello.
With GCC-6 (Debian 6.0.1-2) 6.0.1 20160423 (prerelease),
compiling the following package with "gcc-6 -c p.adb" fails:
p.adb:4:20: access discriminant in return aggregate would be a dangling
reference
The code compiles
- if the "generic" line is removed
- or if ".all" is inserted between "Position" and ".Item'Access"
I am not sure whether returning this reference is allowed by the Ada Reference
Manual,
but the semantics of "generic" and ".all" should certainly not affect the
answer.

-- Content of p.ads.
generic
package P is   
   type T (D : access Integer) is null record; 
   type R is record
  Item : aliased Integer;  
   end record; 
   function F (Position : access R) return T;  
end P; 
-- Content of p.adb.
package body P is  
   function F (Position : access R) return T is
   begin   
  return (D => Position.Item'Access);  
   end F;  
end P;

[Bug c++/47226] [C++0x] GCC doesn't expand template parameter pack that appears in a lambda-expression

[ishitatsuyuki at gmail dot com]

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

Tatsuyuki Ishi  changed:

   What|Removed |Added

 CC||ishitatsuyuki at gmail dot com

--- Comment #7 from Tatsuyuki Ishi  ---
I'm suffering from this bug too. It currently break my CI since I can't use
clang too due to ABI changes.

This is 3 years-old: I hope someone will take a look on it.

[Bug target/70866] powerpc64le -ffixed-cr2 -ffixed-cr3 -ffixed-cr4 ICE

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Target||powerpc64le
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-04-29
   Assignee|unassigned at gcc dot gnu.org  |amodra at gmail dot com
 Ever confirmed|0   |1

[Bug target/70866] New: powerpc64le -ffixed-cr2 -ffixed-cr3 -ffixed-cr4 ICE

[amodra at gmail dot com]

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

Bug ID: 70866
   Summary: powerpc64le -ffixed-cr2 -ffixed-cr3 -ffixed-cr4 ICE
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amodra at gmail dot com
  Target Milestone: ---

/* { dg-do compile } */
/* { dg-options "-ffixed-cr2 -ffixed-cr3 -ffixed-cr4" } */

#define SET_CR(R,V) __asm__ __volatile__ ("mtcrf %0,%1" : : "n" (1<<(7-R)), "r"
(V<<(4*(7-R))) : "cr" #R)

void foo (void)
{
  SET_CR (2, 7);
  SET_CR (3, 8);
  SET_CR (4, 9);
}

[Bug target/70063] msp430 stack corruption for naked functions

[awygle at gmail dot com]

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

--- Comment #3 from Andrew Wygle  ---
This appears to be fixed in GCC 6.1

[Bug middle-end/70831] [6/7 Regression] FTBFS: Build fails with bootstrap-lto and profiledbootstrap

[jeffbai at aosc dot xyz]

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

--- Comment #3 from Jeff Bai  ---
(In reply to Richard Biener from comment #2)
> You'll eventually run into PR60277 as well.  Probably requires
> --enable-checking=release to trigger.

I do apologize for my limited knowledge, but what is the relevance in this
report with that?

[Bug rtl-optimization/70826] [7 regression] many test cases fail starting with r235442

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-04-29
   Assignee|unassigned at gcc dot gnu.org  |amodra at gmail dot com
 Ever confirmed|0   |1

--- Comment #9 from Alan Modra  ---
It looks like a testcase bug.  -frename-regs happens to make main() use cr2,
and there doesn't seem to be anything to prevent that.

[Bug rtl-optimization/70826] [7 regression] many test cases fail starting with r235442

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #8 from Alan Modra  ---
cr2, cr3 and cr4 are supposed to be non-volatile, ie. callee saved.  INIT_REGS
initialises cr2,3,4 to particular values, that are checked later.

[Bug c/68120] can't easily deal with integer overflow at compile time

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #4 from Martin Sebor  ---
Testing a patch for this bug as well as bug 70507.

[Bug java/70839] [5/6/7 regression] Every libjava execution test FAILs: Incorrect library ABI version detected

[jonwilliams0000 at gmail dot com]

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

--- Comment #9 from jonwilliams at gmail dot com ---
unsubscribe

On Thu, Apr 28, 2016 at 10:37 AM, doko at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70839
>
> --- Comment #7 from Matthias Klose  ---
> Author: doko
> Date: Thu Apr 28 16:37:27 2016
> New Revision: 235582
>
> URL: https://gcc.gnu.org/viewcvs?rev=235582=gcc=rev
> Log:
> 2016-04-28  Rainer Orth  
>
> PR java/70839
> * decl.c (parse_version): Remove minor handling.
>
> Modified:
> branches/gcc-5-branch/gcc/java/ChangeLog
> branches/gcc-5-branch/gcc/java/decl.c

[Bug c++/63142] gcc-cilk can not spawn a function template

[ryan.burn at gmail dot com]

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

ryan.burn at gmail dot com changed:

   What|Removed |Added

 CC||ryan.burn at gmail dot com

--- Comment #2 from ryan.burn at gmail dot com ---
I checked and this looks like it compiles fine with gcc7.

[Bug middle-end/70843] [7 Regression] ICE in add_expr, at tree.c:7913

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug other/69582] [meta-bug] Cilk+

[ryan.burn at gmail dot com]

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

--- Comment #6 from ryan.burn at gmail dot com ---
There's also some issues with cilk features and precompiled headers. I put in
70865 to track.

[Bug middle-end/70843] [7 Regression] ICE in add_expr, at tree.c:7913

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Thu Apr 28 22:23:01 2016
New Revision: 235615

URL: https://gcc.gnu.org/viewcvs?rev=235615=gcc=rev
Log:
PR middle-end/70843
* fold-const.c (operand_equal_p): Don't verify hash value equality
if arg0 == arg1.
* tree.c (inchash::add_expr): Handle STATEMENT_LIST.  Ignore BLOCK
and OMP_CLAUSE.

* gcc.dg/pr70843.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr70843.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c

[Bug c++/70865] New: [cilkplus] errors when using cilk features with precompiled headers

[ryan.burn at gmail dot com]

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

Bug ID: 70865
   Summary: [cilkplus] errors when using cilk features with
precompiled headers
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

Created attachment 38372
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38372=edit
example that reproduces the problem

Using cilk features in a precompiled header file causes various compilation
bugs if the options "-std=c++1z" and "-fconcepts" are also used. I attached an
example that reproduces the bug. The code should compile fine (and does so, if
not using a pch or not using cilk features), but depending on what options are
used, gcc produces these different errors.

Using both "-std=c++1z -fconcepts -fcilkplus" (reproduced with Makefile),
causes the error:

cc1plus: error: using result of function returning ‘void’
(null):0: confused by earlier errors, bailing out
make: *** [a] Error 1



Using just "-std=c++1z" (Makefile.v2), causes the error:

cc1plus: internal compiler error: Segmentation fault
0xb45bff crash_signal
../../gcc/gcc/toplev.c:333
0x95565c gimplify_call_expr
../../gcc/gcc/gimplify.c:2486
0x94d339 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:10258
0x95a381 force_gimple_operand_1(tree_node*, gimple**, bool (*)(tree_node*),
tree_node*)
../../gcc/gcc/gimplify-me.c:78
0x95a47f force_gimple_operand_gsi_1(gimple_stmt_iterator*, tree_node*, bool
(*)(tree_node*), tree_node*, bool, gsi_iterator_update)
../../gcc/gcc/gimplify-me.c:115
0xa5a757 expand_task_call
../../gcc/gcc/omp-low.c:6865
0xa5a757 expand_omp_taskreg
../../gcc/gcc/omp-low.c:7423
0xa6103f expand_omp
../../gcc/gcc/omp-low.c:13799
0xa637ad execute_expand_omp
../../gcc/gcc/omp-low.c:14028
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make: *** [a] Error 1

[Bug middle-end/65960] ICE in Cilk spawn with argument with non-trivial constructor

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #3 from Jeffrey A. Law  ---
Per c#2.

[Bug other/69582] [meta-bug] Cilk+

[law at redhat dot com]

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

Bug 65960 Summary: ICE in Cilk spawn with argument with non-trivial constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65960

   What|Removed |Added

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

[Bug middle-end/65960] ICE in Cilk spawn with argument with non-trivial constructor

[ryan.burn at gmail dot com]

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

ryan.burn at gmail dot com changed:

   What|Removed |Added

 CC||ryan.burn at gmail dot com

--- Comment #2 from ryan.burn at gmail dot com ---
This should be fixed now. I just checked with gcc-7.

[Bug middle-end/70861] Improve code generation of switch tables

[wdijkstr at arm dot com]

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

--- Comment #3 from Wilco  ---
(In reply to Andrew Pinski from comment #2)
> Note I think if we had gotos instead of assignment here we should do the
> similar thing for the switch table itself.

Absolutely, that was my point.

> Note also the assignment to i is getting in the way for the switch to
> constant table form.

In SSA form you can sink the assignments into a shared block, so it should be
able deal with an identical assignment to a global, pointer, array or even
returning directly. Also it's common that the default or a few other cases are
doing something different, so those need to be pulled out separately.

However that's icing on the cake - the key issue is that GCC doesn't even do
the basic stuff yet. Most compilers are able to split off cases with high
profile counts, dense switch tables, ranges that all go to the same block etc.

[Bug fortran/70855] [6 Regression] ICE with -fopenmp in gfc_trans_omp_workshare(): Bad statement code

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #1 from Harald Anlauf  ---
The ICE disappears with -fno-frontend-optimize.

Possibly related to the recent attempts to inline matmul?

[Bug c++/70552] __builtin_constant_p fails to reflect the constness of constexpr calls

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
See also bug 54021 for additional background.

[Bug go/70850] Bootstrap fails building libgo: gccgo: error: ../x86_64-pc-linux-gnu/libgo/zstdpkglist.go: No such file or directory

[bill at baddogconsulting dot com]

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

Bill Deegan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Bill Deegan  ---
That did the trick. Thanks!.

[Bug c++/70507] integer overflow builtins not constant expressions

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-04-28
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Martin Sebor  ---
Testing a patch.

[Bug fortran/70864] New: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1403

[weiqun.zhang at gmail dot com]

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

Bug ID: 70864
   Summary: internal compiler error: in gfc_get_symbol_decl, at
fortran/trans-decl.c:1403
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: weiqun.zhang at gmail dot com
  Target Milestone: ---

Created attachment 38371
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38371=edit
code demonstrating the problem

Internal compiler error is encountered when compiling the attached code:

$ gfortran -c mymod.f90 
mymod.f90:31:0:

 end module multifab_module

internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1403
0x69f0eb gfc_get_symbol_decl(gfc_symbol*)
../../../src/gcc-6.1.0/gcc/fortran/trans-decl.c:1403
0x6a13a7 generate_local_decl
../../../src/gcc-6.1.0/gcc/fortran/trans-decl.c:5220
0x66a1db do_traverse_symtree
../../../src/gcc-6.1.0/gcc/fortran/symbol.c:3817
0x6a1fda generate_local_vars
../../../src/gcc-6.1.0/gcc/fortran/trans-decl.c:5410
0x6a1fda gfc_generate_function_code(gfc_namespace*)
../../../src/gcc-6.1.0/gcc/fortran/trans-decl.c:6089
0x682281 gfc_generate_module_code(gfc_namespace*)
../../../src/gcc-6.1.0/gcc/fortran/trans.c:2058
0x63af8d translate_all_program_units
../../../src/gcc-6.1.0/gcc/fortran/parse.c:5600
0x63af8d gfc_parse_file()
../../../src/gcc-6.1.0/gcc/fortran/parse.c:5819
0x67c0d5 gfc_be_parse_file
../../../src/gcc-6.1.0/gcc/fortran/f95-lang.c:201

[Bug target/68803] gcc.vect/powerpc/20050603-3.c failures since r230167

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|SUSPENDED   |ASSIGNED

[Bug target/70668] nds32-elf toolchain fails to compile on OSX

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-28
 CC||segher at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #7 from Segher Boessenkool  ---
Fixed on trunk, backports pending.

[Bug fortran/70863] New: Finalization of array of derived type causes segfault

[weiqun.zhang at gmail dot com]

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

Bug ID: 70863
   Summary: Finalization of array of derived type causes segfault
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: weiqun.zhang at gmail dot com
  Target Milestone: ---

Created attachment 38370
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38370=edit
A program demonstrating the problem.

In the attached program, there is a derived type named c, which contains an
array of derived type b.  The finalization of a c object causes segfault.

[Bug libstdc++/70845] [6/7 Regression] inherited piecewise_construct_t constructor from std::pair by "using-declarations" is missing

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||jason at redhat dot com

--- Comment #7 from Ville Voutilainen  ---
If I use my_pair directly, gcc accepts the code. Once the inherited constructor
and my_real_pair are thrown into the mix, gcc starts rejecting the code.

[Bug libstdc++/70845] [6/7 Regression] inherited piecewise_construct_t constructor from std::pair by "using-declarations" is missing

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #6 from Ville Voutilainen  ---
Here's a test snippet without library types. Clang accepts the code, gcc
rejects it.

template 
struct holder
{
T t;
};

template  
struct tuple_holder : holder
{
tuple_holder(Args&&... args) : holder{static_cast(args)}...
{}
tuple_holder(const tuple_holder&) = default;
tuple_holder(tuple_holder&&) = default;
};

template 
struct my_pair
{
template 
my_pair(tuple_holder) {}
my_pair(const my_pair&) = default;
};

template 
struct my_real_pair : my_pair
{
using my_pair::my_pair;
};

int main()
{
my_real_pair(tuple_holder(1));
}

prog.cc: In constructor 'my_real_pair::my_real_pair(tuple_holder) [with Args = {int&&}]':
prog.cc:26:26: error: use of deleted function
'tuple_holder::tuple_holder(const tuple_holder&) [with Args =
{int&&}]'
 using my_pair::my_pair;
  ^~~
prog.cc:11:5: note: 'tuple_holder::tuple_holder(const
tuple_holder&) [with Args = {int&&}]' is implicitly deleted because the
default definition would be ill-formed:
 tuple_holder(const tuple_holder&) = default;
 ^~~~
prog.cc:11:5: error: use of deleted function 'holder::holder(const
holder&)'
prog.cc:2:8: note: 'holder::holder(const holder&)' is implicitly
deleted because the default definition would be ill-formed:
 struct holder
^~
prog.cc:2:8: error: copying non-static data member 'int&& holder::t' of
rvalue reference type
prog.cc: In function 'int main()':
prog.cc:31:52: note: synthesized method 'my_real_pair::my_real_pair(tuple_holder) [with Args = {int&&}]' first
required here 
 my_real_pair(tuple_holder(1));
^

[Bug target/70858] __builtin_ia32_bextr_u64 ICE with '-m32 -march=core-avx2'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed everywhere.

[Bug target/70858] __builtin_ia32_bextr_u64 ICE with '-m32 -march=core-avx2'

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Thu Apr 28 19:52:02 2016
New Revision: 235611

URL: https://gcc.gnu.org/viewcvs?rev=235611=gcc=rev
Log:
PR target/70858
* config/i386/i386.c (bdesc_special_args): Add | OPTION_MASK_ISA_64BIT
to __builtin_ia32_lwpval64 and __builtin_ia32_lwpins64.
(bdesc_args): Add | OPTION_MASK_ISA_64BIT to __builtin_ia32_bextr_u64,
__builtin_ia32_bextri_u64, __builtin_ia32_bzhi_di,
__builtin_ia32_pdep_di and __builtin_ia32_pext_di.

* gcc.target/i386/pr70858.c: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr70858.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/i386/i386.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug target/70858] __builtin_ia32_bextr_u64 ICE with '-m32 -march=core-avx2'

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Thu Apr 28 19:47:06 2016
New Revision: 235610

URL: https://gcc.gnu.org/viewcvs?rev=235610=gcc=rev
Log:
PR target/70858
* config/i386/i386.c (bdesc_special_args): Add | OPTION_MASK_ISA_64BIT
to __builtin_ia32_lwpval64 and __builtin_ia32_lwpins64.
(bdesc_args): Add | OPTION_MASK_ISA_64BIT to __builtin_ia32_bextr_u64,
__builtin_ia32_bextri_u64, __builtin_ia32_bzhi_di,
__builtin_ia32_pdep_di and __builtin_ia32_pext_di.

* gcc.target/i386/pr70858.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr70858.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/i386.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/70858] __builtin_ia32_bextr_u64 ICE with '-m32 -march=core-avx2'

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Apr 28 19:45:48 2016
New Revision: 235609

URL: https://gcc.gnu.org/viewcvs?rev=235609=gcc=rev
Log:
PR target/70858
* config/i386/i386.c (bdesc_special_args): Add | OPTION_MASK_ISA_64BIT
to __builtin_ia32_lwpval64 and __builtin_ia32_lwpins64.
(bdesc_args): Add | OPTION_MASK_ISA_64BIT to __builtin_ia32_bextr_u64,
__builtin_ia32_bextri_u64, __builtin_ia32_bzhi_di,
__builtin_ia32_pdep_di and __builtin_ia32_pext_di.

* gcc.target/i386/pr70858.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr70858.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/i386.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/70861] Improve code generation of switch tables

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Note I think if we had gotos instead of assignment here we should do the
similar thing for the switch table itself.

Note also the assignment to i is getting in the way for the switch to constant
table form.

[Bug middle-end/70861] Improve code generation of switch tables

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I think we should turn this into the following:

((unsigned)a) <= 9 ? table[a] : (a == 110 ? 27 : 77);

That is pull out the 110/default case so table would be small.

[Bug target/70858] __builtin_ia32_bextr_u64 ICE with '-m32 -march=core-avx2'

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Apr 28 19:33:34 2016
New Revision: 235607

URL: https://gcc.gnu.org/viewcvs?rev=235607=gcc=rev
Log:
PR target/70858
* config/i386/i386.c (bdesc_special_args): Add | OPTION_MASK_ISA_64BIT
to __builtin_ia32_lwpval64 and __builtin_ia32_lwpins64.
(bdesc_args): Add | OPTION_MASK_ISA_64BIT to __builtin_ia32_bextr_u64,
__builtin_ia32_bextri_u64, __builtin_ia32_bzhi_di,
__builtin_ia32_pdep_di and __builtin_ia32_pext_di.

* gcc.target/i386/pr70858.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr70858.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/70862] [concepts] adding a concept-constrained version of a variable template causes multiple definition assembler error

[ryan.burn at gmail dot com]

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

--- Comment #1 from ryan.burn at gmail dot com ---
Simpler reproduction:

template 
concept bool C = true;

template 
constexpr bool a = false;

template 
  requires C
constexpr bool a = true;

template 
  requires a
void f(Tx...) {
}

int main() {
  f();
  f(3);
  return 0;
}

[Bug c++/70862] New: [concepts] adding a concept-constrained version of a variable template causes multiple definition assembler error

[ryan.burn at gmail dot com]

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

Bug ID: 70862
   Summary: [concepts] adding a concept-constrained version of a
variable template causes multiple definition assembler
error
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

Created attachment 38369
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38369=edit
reproduces the bug

The attached code should be valid and compiles with an older version of gcc
(20160120), but now breaks with (20160428) giving the following error:

/tmp/ccthKyXf.s: Assembler messages:
/tmp/ccthKyXf.s:269: Error: symbol
`_ZN4echo3htl14detail_conceptL23mappable_predicate_implE' is already defined

[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 CC||steven at gcc dot gnu.org

--- Comment #26 from Steven Bosscher  ---
Maybe make something like "-Wno-unused-result=[pedantic|nodiscard]", make 
strict the current semantics of the flag and nodiscard the C++17 semantics
(and make that the default)?

[Bug c++/54379] Suggestion for type attribute similar to warn_unused_result

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Thu Apr 28 19:01:19 2016
New Revision: 235597

URL: https://gcc.gnu.org/viewcvs?rev=235597=gcc=rev
Log:
Implement C++17 [[nodiscard]] attribute.

PR c++/38172
PR c++/54379
gcc/c-family/
* c-lex.c (c_common_has_attribute): Handle nodiscard.
gcc/cp/
* parser.c (cp_parser_std_attribute): Handle [[nodiscard]].
* tree.c (handle_nodiscard_attribute): New.
(cxx_attribute_table): Add [[nodiscard]].
* cvt.c (cp_get_fndecl_from_callee, cp_get_callee_fndecl): New.
(maybe_warn_nodiscard): New.
(convert_to_void): Call it.

Added:
trunk/gcc/testsuite/c-c++-common/attr-warn-unused-result.c
  - copied, changed from r235596,
trunk/gcc/testsuite/gcc.dg/attr-warn-unused-result.c
trunk/gcc/testsuite/g++.dg/cpp1z/nodiscard1.C
trunk/gcc/testsuite/g++.dg/cpp1z/nodiscard2.C
trunk/gcc/testsuite/g++.dg/cpp1z/nodiscard3.C
trunk/gcc/testsuite/g++.dg/warn/Wunused-result-2.C
Removed:
trunk/gcc/testsuite/gcc.dg/attr-warn-unused-result.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-lex.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/cvt.c
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/g++.dg/cpp1z/feat-cxx1z.C
trunk/gcc/testsuite/g++.dg/warn/unused-result1.C

[Bug c++/38172] warn_unused_result does not work with structs not containing a copy constructor

[jason at gcc dot gnu.org]

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

--- Comment #12 from Jason Merrill  ---
Author: jason
Date: Thu Apr 28 19:01:19 2016
New Revision: 235597

URL: https://gcc.gnu.org/viewcvs?rev=235597=gcc=rev
Log:
Implement C++17 [[nodiscard]] attribute.

PR c++/38172
PR c++/54379
gcc/c-family/
* c-lex.c (c_common_has_attribute): Handle nodiscard.
gcc/cp/
* parser.c (cp_parser_std_attribute): Handle [[nodiscard]].
* tree.c (handle_nodiscard_attribute): New.
(cxx_attribute_table): Add [[nodiscard]].
* cvt.c (cp_get_fndecl_from_callee, cp_get_callee_fndecl): New.
(maybe_warn_nodiscard): New.
(convert_to_void): Call it.

Added:
trunk/gcc/testsuite/c-c++-common/attr-warn-unused-result.c
  - copied, changed from r235596,
trunk/gcc/testsuite/gcc.dg/attr-warn-unused-result.c
trunk/gcc/testsuite/g++.dg/cpp1z/nodiscard1.C
trunk/gcc/testsuite/g++.dg/cpp1z/nodiscard2.C
trunk/gcc/testsuite/g++.dg/cpp1z/nodiscard3.C
trunk/gcc/testsuite/g++.dg/warn/Wunused-result-2.C
Removed:
trunk/gcc/testsuite/gcc.dg/attr-warn-unused-result.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-lex.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/cvt.c
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/g++.dg/cpp1z/feat-cxx1z.C
trunk/gcc/testsuite/g++.dg/warn/unused-result1.C

[Bug other/70346] [libvtv] 6.0-20160313 build succeeds, install fails: cannot stat '.libs/libvtv.a': No such file or directory

[gregnietsky at gmail dot com]

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

Bill Gates  changed:

   What|Removed |Added

 CC||gregnietsky at gmail dot com

--- Comment #3 from Bill Gates  ---
Can confirm this problem using make v4 on x86_x32 build ... 

make[10]: Entering directory
'/var/opt/dtsbuild/src/gcc/gcc-6.1.0/build-x86_32/x86_64-linux-gnux32/32/libvtv'
true  DO=install multi-do # make
 /usr/bin/mkdir -p '/usr/libx32/../lib'
 /bin/sh ./libtool   --mode=install /usr/bin/ginstall -c   libvtv.la
'/usr/libx32/../lib'
libtool: install: /usr/bin/ginstall -c .libs/libvtv.so.0.0.0
/usr/libx32/../lib/libvtv.so.0.0.0
libtool: install: (cd /usr/libx32/../lib && { ln -s -f libvtv.so.0.0.0
libvtv.so.0 || { rm -f libvtv.so.0 && ln -s libvtv.so.0.0.0 libvtv.so.0; }; })
libtool: install: (cd /usr/libx32/../lib && { ln -s -f libvtv.so.0.0.0
libvtv.so || { rm -f libvtv.so && ln -s libvtv.so.0.0.0 libvtv.so; }; })
libtool: install: /usr/bin/ginstall -c .libs/libvtv.lai
/usr/libx32/../lib/libvtv.la
libtool: install: /usr/bin/ginstall -c .libs/libvtv.a
/usr/libx32/../lib/libvtv.a
/usr/bin/ginstall: cannot stat '.libs/libvtv.a': No such file or directory
Makefile:414: recipe for target 'install-toolexeclibLTLIBRARIES' failed
make[10]: *** [install-toolexeclibLTLIBRARIES] Error 1
make[10]: Leaving directory
'/var/opt/dtsbuild/src/gcc/gcc-6.1.0/build-x86_32/x86_64-linux-gnux32/32/libvtv'
Makefile:703: recipe for target 'install-am' failed
make[9]: *** [install-am] Error 2
make[9]: Leaving directory
'/var/opt/dtsbuild/src/gcc/gcc-6.1.0/build-x86_32/x86_64-linux-gnux32/32/libvtv'
Makefile:560: recipe for target 'install-recursive' failed
make[8]: *** [install-recursive] Error 1
make[8]: Leaving directory
'/var/opt/dtsbuild/src/gcc/gcc-6.1.0/build-x86_32/x86_64-linux-gnux32/32/libvtv'
Makefile:697: recipe for target 'install' failed
make[7]: *** [install] Error 2
make[7]: Leaving directory
'/var/opt/dtsbuild/src/gcc/gcc-6.1.0/build-x86_32/x86_64-linux-gnux32/32/libvtv'
Makefile:853: recipe for target 'multi-do' failed
make[6]: *** [multi-do] Error 1
make[6]: Leaving directory
'/var/opt/dtsbuild/src/gcc/gcc-6.1.0/build-x86_32/x86_64-linux-gnux32/libvtv'
Makefile:521: recipe for target 'install-multi' failed
make[5]: *** [install-multi] Error 2
make[5]: Leaving directory
'/var/opt/dtsbuild/src/gcc/gcc-6.1.0/build-x86_32/x86_64-linux-gnux32/libvtv'
Makefile:703: recipe for target 'install-am' failed
make[4]: *** [install-am] Error 2
make[4]: Leaving directory
'/var/opt/dtsbuild/src/gcc/gcc-6.1.0/build-x86_32/x86_64-linux-gnux32/libvtv'
Makefile:560: recipe for target 'install-recursive' failed
make[3]: *** [install-recursive] Error 1
make[3]: Leaving directory
'/var/opt/dtsbuild/src/gcc/gcc-6.1.0/build-x86_32/x86_64-linux-gnux32/libvtv'
Makefile:697: recipe for target 'install' failed
make[2]: *** [install] Error 2
make[2]: Leaving directory
'/var/opt/dtsbuild/src/gcc/gcc-6.1.0/build-x86_32/x86_64-linux-gnux32/libvtv'
Makefile:15399: recipe for target 'install-target-libvtv' failed
make[1]: *** [install-target-libvtv] Error 2
make[1]: Leaving directory '/var/opt/dtsbuild/src/gcc/gcc-6.1.0/build-x86_32'
Makefile:2323: recipe for target 'install' failed
make: *** [install] Error 2

[Bug middle-end/70861] New: Improve code generation of switch tables

[wdijkstr at arm dot com]

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

Bug ID: 70861
   Summary: Improve code generation of switch tables
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wdijkstr at arm dot com
  Target Milestone: ---

GCC uses a very basic check to determine whether to use a switch table. A
simple example from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11823 still
generates a huge table with mostly default entries with -O2:

int i;
int func(int a)
{
  switch(a)
  {
case 0:   i = 20; break;
case 1:   i = 50; break;
case 2:   i = 29; break;
case 3:   i = 20; break;
case 4:   i = 50; break;
case 5:   i = 29; break;
case 6:   i = 20; break;
case 7:   i = 50; break;
case 8:   i = 29; break;
case 9:   i = 79; break;
case 110: i = 27; break;
default:  i = 77; break;
  }
  return i;
}

This shows several issues:

1. The density calculation is not adjustable depending on the expected size of
switch table entries (which depends on the target).
2. A table may contain not only 90% default entries, but they can be
consecutive as well. To avoid this the maximum number of default cases should
be limited to say 3x the average gap between real cases.
3. There is no reduction in minimum required density for larger switches - the
wastage becomes quite significant for larger switches and targets that use 4
bytes per table entry.
4. Dense regions and outlier values are not split off and handled seperately.

[Bug target/70858] __builtin_ia32_bextr_u64 ICE with '-m32 -march=core-avx2'

[steven at uplinklabs dot net]

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

--- Comment #3 from Steven Noonan  ---
Cool. I'll let the project maintainer know to not use the __builtin_* variants.
_bextr_u32 and _bextr_u64 look much more friendly, too.

[Bug target/70821] x86_64: __atomic_fetch_add/sub() uses XADD rather than DECL in some cases

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed for 7.1+.  As this is not a regression, not backporting this to release
branches.

[Bug target/70858] __builtin_ia32_bextr_u64 ICE with '-m32 -march=core-avx2'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-04-28
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

Untested fix.

Note, these builtins aren't meant to be used directly, instead one should use
the wrappers in x86intrin.h (and headers that it includes), the underlying
implementation of those intrinsics can change.

[Bug target/70821] x86_64: __atomic_fetch_add/sub() uses XADD rather than DECL in some cases

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Apr 28 17:10:14 2016
New Revision: 235586

URL: https://gcc.gnu.org/viewcvs?rev=235586=gcc=rev
Log:
PR target/70821
* config/i386/sync.md (define_peephole2 *atomic_fetch_add_cmp):
Add new peephole2 where the first insn is *mov_or instead of
*mov_internal.

* gcc.target/i386/pr70821.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr70821.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sync.md
trunk/gcc/testsuite/ChangeLog

[Bug target/70858] __builtin_ia32_bextr_u64 ICE with '-m32 -march=core-avx2'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |6.2

[Bug target/70668] nds32-elf toolchain fails to compile on OSX

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
Author: segher
Date: Thu Apr 28 16:50:41 2016
New Revision: 235583

URL: https://gcc.gnu.org/viewcvs?rev=235583=gcc=rev
Log:
nds32: Fix casesi (PR70668)

Expanders do not have more elements in the operands array than declared
in the pattern.  So, we cannot use operands[5] here.  Instead just
declare and use another rtx.


PR target/70668
* config/nds32/nds32.md (casesi): Don't access the operands array
out of bounds.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/nds32/nds32.md

[Bug java/70839] [5/6/7 regression] Every libjava execution test FAILs: Incorrect library ABI version detected

[doko at gcc dot gnu.org]

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

--- Comment #8 from Matthias Klose  ---
and 5.4.

[Bug java/70839] [5/6/7 regression] Every libjava execution test FAILs: Incorrect library ABI version detected

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

   Target Milestone|6.2 |5.4
Summary|[6/7 regression] Every  |[5/6/7 regression] Every
   |libjava execution test  |libjava execution test
   |FAILs: Incorrect library|FAILs: Incorrect library
   |ABI version detected|ABI version detected

[Bug java/70839] [6/7 regression] Every libjava execution test FAILs: Incorrect library ABI version detected

[doko at gcc dot gnu.org]

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

--- Comment #7 from Matthias Klose  ---
Author: doko
Date: Thu Apr 28 16:37:27 2016
New Revision: 235582

URL: https://gcc.gnu.org/viewcvs?rev=235582=gcc=rev
Log:
2016-04-28  Rainer Orth  

PR java/70839
* decl.c (parse_version): Remove minor handling.

Modified:
branches/gcc-5-branch/gcc/java/ChangeLog
branches/gcc-5-branch/gcc/java/decl.c

[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))

[jakub at gcc dot gnu.org]

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

--- Comment #25 from Jakub Jelinek  ---
(In reply to Jason Merrill from comment #24)
> I agree that (void) should suppress the warning.  Jakub, do you remember why
> you made a different choice?

I think the request came from Uli that it isn't that easy to suppress it, at
least initially the warning was meant for cases where it would be a major
security problem to ignore the return value.

[Bug fortran/70842] [4.9/5/6/7 Regression] internal compiler error with character members within a polymorphic pointer

[nathanael.huebbe at informatik dot uni-hamburg.de]

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

--- Comment #3 from nathanael.huebbe at informatik dot uni-hamburg.de ---
This is getting even nastier. As it turns out, even though the code I gave
above compiles, it does not produce correct results. To be precise, if I use a
routine like

subroutine bar(me)
class(t_Intermediate), pointer, intent(in) :: me
class(*), pointer :: meAlias
character(len = :), pointer :: textAlias

meAlias => me

select type(meAlias)
type is(t_Foo)
textAlias => meAlias%string
print*, "'"//textAlias//"', len = ", len(textAlias)
!OK
print*, "'"//meAlias%string//"', len = ",
len(meAlias%string)   !string ok, len = nonsense
end select
end subroutine

I get some completely wrong length in the second `print` statement (like
`152660480`), even though the string itself is output correctly. Again, the
indirection via an additional pointer produces correct results.

Another curious fact is, that the large number is constant across objects
within a single run, but different when I restart my program. So I'm willing to
speculate that somehow the vtable pointer is mistaken for the string length,
but that may be completely wrong.

[Bug c++/54379] Suggestion for type attribute similar to warn_unused_result

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-04-28
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jason Merrill  ---
C++17 adds the [[nodiscard]] attribute which can be applied to classes.

[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #24 from Jason Merrill  ---
I agree that (void) should suppress the warning.  Jakub, do you remember why
you made a different choice?

[Bug tree-optimization/70841] reassoc fails to handle FP division

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Related to PR55912.

[Bug java/70839] [6/7 regression] Every libjava execution test FAILs: Incorrect library ABI version detected

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org

--- Comment #6 from Rainer Orth  ---
Fixed for 6.2, 7.1.

[Bug target/70858] __builtin_ia32_bextr_u64 ICE with '-m32 -march=core-avx2'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
This builtin is not meant for -m32, only for -m64/-mx32.  I'll tweak it so that
we don't allow this builtin there (the headers are doing the right thing
already).

[Bug java/70839] [6/7 regression] Every libjava execution test FAILs: Incorrect library ABI version detected

[ro at gcc dot gnu.org]

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

--- Comment #5 from Rainer Orth  ---
Author: ro
Date: Thu Apr 28 16:21:41 2016
New Revision: 235578

URL: https://gcc.gnu.org/viewcvs?rev=235578=gcc=rev
Log:
Don't include minor version in GCJ ABI version (PR java/70839)

PR java/70839
* decl.c (parse_version): Remove minor handling.

Modified:
branches/gcc-6-branch/gcc/java/ChangeLog
branches/gcc-6-branch/gcc/java/decl.c

[Bug middle-end/61229] warn_unused_result doesn't warn in unused inline function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-28
 CC||jason at gcc dot gnu.org
  Component|c++ |middle-end
Summary|warn_unused_result fails to |warn_unused_result doesn't
   |work with member functions  |warn in unused inline
   ||function
 Ever confirmed|0   |1

--- Comment #4 from Jason Merrill  ---
The testcases in comments 2 and 3 are covered by bug 38172.  The original issue
is with unused inline functions, and affects C as well:

__attribute__((warn_unused_result)) int callme( ) { return 42; }

inline void foo()
{
  callme();
}

[Bug tree-optimization/70729] Loop marked with omp simd pragma is not vectorized

[ysrumyan at gmail dot com]

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

--- Comment #12 from Yuri Rumyantsev  ---
Created attachment 38367
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38367=edit
modified patch

[Bug target/70860] New: [nvptx] Revisit cfun->machine->doing_call

[tschwinge at gcc dot gnu.org]

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

Bug ID: 70860
   Summary: [nvptx] Revisit cfun->machine->doing_call
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: amonakov at gcc dot gnu.org, bernds at gcc dot gnu.org,
nathan at gcc dot gnu.org
  Target Milestone: ---
Target: nvptx

The r235511 changes for PR70760 exposed a problem in
gcc/config/nvptx/nvptx.c:nvptx_libcall_value, and Richard generally found that
one "fishy", and "suggest[ed] to remove cfun->machine->doing_call and revisit
the reason why it was added for PTX", see

and following.

[Bug ada/61027] gnatcmd gets SIGABRT during exception handling

[simon at pushface dot org]

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

simon at pushface dot org changed:

   What|Removed |Added

  Known to fail||5.1.0, 5.2.0

--- Comment #6 from simon at pushface dot org ---
Checked; fails (for cross-compilers - native compilers OK) with 
6.0.1-RC-20160415. Will send in the patch now 6.1.0 is out.

I see I never sent in a patch - no wonder it’s not fixed.

[Bug tree-optimization/70729] Loop marked with omp simd pragma is not vectorized

[ysrumyan at gmail dot com]

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

--- Comment #11 from Yuri Rumyantsev  ---
Richard,

I slightly modify the patch proposed by you:
1. Apply loop->safelen check only if lim is invoked before loop vectorization
since its value could be non-correct (I simply add bool param to it).
2. I prohibit to apply this check if loop contains unanalyzed memory references
(e.g. calls, clobbers etc.).
With these changes all regressions related to omp simd support were disappeared
and the following failures left (because of changing order of transformation):

 FAIL: gcc.dg/autopar/outer-6.c scan-tree-dump-times parloops2 "parallelizing
inner loop" 0
FAIL: gcc.dg/pr41783.c scan-tree-dump pre "pretmp[^\\n]* = a_global_var;"
FAIL: gcc.dg/tree-ssa/loadpre10.c scan-tree-dump-times pre "Eliminated: 1" 1
FAIL: gcc.dg/tree-ssa/loadpre23.c scan-tree-dump-times pre "Eliminated: 1" 1
FAIL: gcc.dg/tree-ssa/loadpre24.c scan-tree-dump-times pre "Eliminated: 1" 1
FAIL: gcc.dg/tree-ssa/loadpre25.c scan-tree-dump-times pre "Eliminated: 1" 1
FAIL: gcc.dg/tree-ssa/loadpre4.c scan-tree-dump-times pre "Eliminated: 1" 1
FAIL: gcc.dg/tree-ssa/loadpre8.c scan-tree-dump-times pre "Eliminated: 1" 1
FAIL: gcc.dg/tree-ssa/ssa-pre-16.c scan-tree-dump-times pre "Eliminated: 1" 1
FAIL: gcc.dg/tree-ssa/ssa-pre-18.c scan-tree-dump pre "Replaced foo \\(f.y\\)"
FAIL: gcc.dg/tree-ssa/ssa-pre-20.c scan-tree-dump pre "New PHIs: 2"
FAIL: gcc.dg/tree-ssa/ssa-pre-3.c scan-tree-dump-times pre "Eliminated: 2" 1
FAIL: gfortran.dg/pr42108.f90   -O   scan-tree-dump pre "in all uses of
countm1[^\n]* / "
FAIL: gfortran.dg/vect/fast-math-vect-8.f90   -O   scan-tree-dump-times vect
"vectorized 1 loops" 1

What is your opinion?

[Bug c++/38172] warn_unused_result does not work with structs not containing a copy constructor

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||tkrimer at epochlabs dot com

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

[Bug c++/70487] warn_unused_result attribute doesn't warn when return type is class

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

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

[Bug c++/38172] warn_unused_result does not work with structs not containing a copy constructor

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||dushistov at mail dot ru

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

[Bug c++/68469] warn_unused_result attribute ignored for templates return templates

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  ---
Dup.

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

[Bug c++/38172] warn_unused_result does not work with structs not containing a copy constructor

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||gcc at bobbyperu dot info

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

[Bug c++/66177] warn_unused_result doesn't work for non-PODs

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Dup.

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

[Bug go/70850] Bootstrap fails building libgo: gccgo: error: ../x86_64-pc-linux-gnu/libgo/zstdpkglist.go: No such file or directory

[bill at baddogconsulting dot com]

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

--- Comment #4 from Bill Deegan  ---
If it's not supported, perhaps it should issue error and exit?
(Build still running..)

[Bug c/70859] New: Bad column number in type-generic function errors

[jsm28 at gcc dot gnu.org]

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

Bug ID: 70859
   Summary: Bad column number in type-generic function errors
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---

The errors for calling type-generic floating-point built-in functions with bad
argument types point to the start of the line, not to the argument in question:

int f (void) { return __builtin_isfinite (0); }
int g (void) { return __builtin_isless (0, 0); }

t.c: In function 'f':
t.c:1:1: error: non-floating-point argument in call to function
'__builtin_isfinite'
 int f (void) { return __builtin_isfinite (0); }
 ^~~
t.c: In function 'g':
t.c:2:1: error: non-floating-point arguments in call to function
'__builtin_isless'
 int g (void) { return __builtin_isless (0, 0); }
 ^~~

For C++, they point to the closing parenthesis, which is closer, but still
wrong.

t.c: In function 'int f()':
t.c:1:44: error: non-floating-point argument in call to function
'__builtin_isfinite'
 int f (void) { return __builtin_isfinite (0); }
^
t.c: In function 'int g()':
t.c:2:45: error: non-floating-point arguments in call to function
'__builtin_isless'
 int g (void) { return __builtin_isless (0, 0); }
 ^

[Bug c/70852] ice in warn_for_memset

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
/* PR c/70852 */
/* { dg-do compile } */
/* { dg-options "-Wall" } */

extern void *memset (void *, int, __SIZE_TYPE__);
extern int A[];
void
fn1 (void)
{
  memset (A, 0, 1);
}

[Bug target/70858] New: __builtin_ia32_bextr_u64 ICE with '-m32 -march=core-avx2'

[steven at uplinklabs dot net]

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

Bug ID: 70858
   Summary: __builtin_ia32_bextr_u64 ICE with '-m32
-march=core-avx2'
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: steven at uplinklabs dot net
  Target Milestone: ---

$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/6.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc-multilib/src/gcc-6.1.0/configure
--host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu
--target=x86_64-unknown-linux-gnu --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://www.uplinklabs.net/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --disable-libssp
--disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror
--enable-checking=release --enable-clocale=gnu --enable-__cxa_atexit
--enable-gnu-indirect-function --enable-gnu-unique-object
--enable-install-libiberty --enable-libmpx --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --with-isl --with-linker-hash-style=gnu
--with-multilib-list=m32,m64,mx32 --with-system-zlib
Thread model: posix
gcc version 6.1.0 (GCC)


Reduced testcase via creduce:

$ cat test.i
int a, b, c;
int d() { c = __builtin_ia32_bextr_u64(a, b); }

$ gcc -m32 -march=core-avx2 -c test.i
test.i: In function ‘d’:
test.i:2:1: error: unrecognizable insn:
 int d() { c = __builtin_ia32_bextr_u64(a, b); }
 ^~~
(insn 9 8 10 2 (parallel [
(set (reg:DI 91 [ _6 ])
(unspec:DI [
(reg:DI 90 [ _5 ])
(reg:DI 88 [ _3 ])
] UNSPEC_BEXTR))
(clobber (reg:CC 17 flags))
]) test.i:2 -1
 (nil))
test.i:2:1: internal compiler error: in extract_insn, at recog.c:2287

[Bug driver/66849] Incorrect multilib chosen with -mthumb -mfloat-abi=hard

[simon at pushface dot org]

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

--- Comment #7 from simon at pushface dot org ---
t-aprofile produced an excellent result - for me, anyway; it includes
everything I need (cortex-*), as well as a whole lot more - just lots of disk
space for multilibs.

[Bug fortran/70857] New: [6 Regression] ICE with -fopenmp -fopenacc in insert_vi_for_tree, at tree-ssa-structalias.c:2813

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

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

Bug ID: 70857
   Summary: [6 Regression] ICE with -fopenmp -fopenacc in
insert_vi_for_tree, at tree-ssa-structalias.c:2813
   Product: gcc
   Version: 6.1.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: ---

For testcase .../gcc/testsuite/gfortran.dg/gomp/gridify-1.f90
and optimization level -Og, -Os, -O1 or higher :

$ gfortran-6 -O2 -fopenmp -fopenacc -c gridify-1.f90
internal compiler error: in insert_vi_for_tree, at tree-ssa-structalias.c:2813

[Bug c/70852] ice in warn_for_memset

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
The fix should be just:

--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -11796,6 +11796,7 @@ warn_for_memset (location_t loc, tree arg0, tree arg2,
  tree elt_type = TREE_TYPE (type);
  tree domain = TYPE_DOMAIN (type);
  if (!integer_onep (TYPE_SIZE_UNIT (elt_type))
+ && domain != NULL_TREE
  && TYPE_MAXVAL (domain)
  && TYPE_MINVAL (domain)
  && integer_zerop (TYPE_MINVAL (domain))

[Bug fortran/70856] New: [6 Regression] ICE with -fopenacc in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2952

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

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

Bug ID: 70856
   Summary: [6 Regression] ICE with -fopenacc in
get_constraint_for_ssa_var, at
tree-ssa-structalias.c:2952
   Product: gcc
   Version: 6.1.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: ---

Compiling the following snippet with optimization level -Os, -O2 or higher :


$ cat z1.f90
program p
   print *, sin([1.0, 2.0])
   print *, cos([1.0, 2.0])
end


$ gfortran-6 -O2 -fopenacc z1.f90
internal compiler error: in get_constraint_for_ssa_var, at
tree-ssa-structalias.c:2952


Affects several files from gfortran testsuite, too.

$ make check-fortran RUNTESTFLAGS="--target_board=unix/-fopenacc"
...
# of expected passes40537
# of unexpected failures1377
# of expected failures  62
# of unresolved testcases   609

[Bug fortran/70854] New: ICE in gfc_process_block_locals, at fortran/trans-decl.c:6447

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

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

Bug ID: 70854
   Summary: ICE in gfc_process_block_locals, at
fortran/trans-decl.c:6447
   Product: gcc
   Version: 6.1.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: ---

The following code with an inner block aborts when combined with
an appropriate option -finit-*. Here "integer" and -finit-integer :


$ cat z1.f90
program p
   integer :: x(2), y(2)
   block
  integer, parameter :: a(2) = 0
  x = a
  block
 y = 0
  end block
   end block
end


$ gfortran-6 -finit-integer=-7 -c z1.f90
internal compiler error: in gfc_process_block_locals, at
fortran/trans-decl.c:6447

$ gfortran-6 -finit-local-zero -c z1.f90
internal compiler error: in gfc_process_block_locals, at
fortran/trans-decl.c:6447

---

Compiles fine without that inner block :

$ cat z2.f90
program p
   integer :: x(2), y(2)
   block
  integer, parameter :: a(2) = 0
  x = a
  y = 0
   end block
end

$ gfortran-6 -finit-integer=-7 -c z2.f90
$ gfortran-6 -finit-local-zero -c z2.f90
# no ICE

[Bug go/70850] Bootstrap fails building libgo: gccgo: error: ../x86_64-pc-linux-gnu/libgo/zstdpkglist.go: No such file or directory

[ian at airs dot com]

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

--- Comment #3 from Ian Lance Taylor  ---
Do we support ./configure these days?

Historically we have only supported SRCDIR/configure run in an empty directory.

[Bug fortran/70855] New: [6 Regression] ICE with -fopenmp in gfc_trans_omp_workshare(): Bad statement code

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

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

Bug ID: 70855
   Summary: [6 Regression] ICE with -fopenmp in
gfc_trans_omp_workshare(): Bad statement code
   Product: gcc
   Version: 6.1.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 GNU Fortran (SUSE Linux) 6.1.0 20160427
and optimization level -Og, -Os, -O1 or higher :


$ cat z1.f90
program p
   integer, parameter :: m = 4
   integer, parameter :: n = 2
   real :: a(m,n)
   real :: x(n)
   real :: y(m)
   a = 1.0
   x = 1.0
!$omp parallel
!$omp workshare
   y(1:m) = matmul ( a(1:m,1:n), x(1:n) )
!$omp end workshare
!$omp end parallel
end


$ gfortran-6 -O2 -fopenmp -c z1.f90
f951: internal compiler error: gfc_trans_omp_workshare(): Bad statement code

[Bug fortran/70854] ICE in gfc_process_block_locals, at fortran/trans-decl.c:6447

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

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

--- Comment #1 from Gerhard Steinmetz  
---

Similar for other intrinsic types :


$ cat z3.f90
program p
   real :: x(2), y(2)
   block
  real, parameter :: a(2) = 0.0
  x = a
  block
 y = 0.0
  end block
   end block
end


$ gfortran-6 -finit-real=zero -c z3.f90
internal compiler error: in gfc_process_block_locals, at
fortran/trans-decl.c:6447

$ gfortran-6 -finit-real=inf -c z3.f90
internal compiler error: in gfc_process_block_locals, at
fortran/trans-decl.c:6447

$ gfortran-6 -finit-local-zero -c z3.f90
internal compiler error: in gfc_process_block_locals, at
fortran/trans-decl.c:6447

---

$ cat z5.f90
program p
   logical :: x(2), y(2)
   block
  logical, parameter :: a(2) = .true.
  x = a
  block
 y = .false.
  end block
   end block
end


$ gfortran-6 -finit-logical=true -c z5.f90
internal compiler error: in gfc_process_block_locals, at
fortran/trans-decl.c:6447

$ gfortran-6 -finit-local-zero -c z5.f90
internal compiler error: in gfc_process_block_locals, at
fortran/trans-decl.c:6447

---

$ cat z7.f90
program p
   character :: x(2), y(2)
   block
  character, parameter :: a(2) = 'a'
  x = a
  block
 y = 'y'
  end block
   end block
end


$ gfortran-6 -finit-character=7 -c z7.f90
internal compiler error: in gfc_process_block_locals, at
fortran/trans-decl.c:6447

$ gfortran-6 -finit-local-zero -c z7.f90
internal compiler error: in gfc_process_block_locals, at
fortran/trans-decl.c:6447

[Bug java/70839] [6/7 regression] Every libjava execution test FAILs: Incorrect library ABI version detected

[ro at gcc dot gnu.org]

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

--- Comment #4 from Rainer Orth  ---
Author: ro
Date: Thu Apr 28 15:25:14 2016
New Revision: 235575

URL: https://gcc.gnu.org/viewcvs?rev=235575=gcc=rev
Log:
Don't include minor version in GCJ ABI version (PR java/70839)

PR java/70839
* decl.c (parse_version): Remove minor handling.

Modified:
trunk/gcc/java/decl.c

[Bug fortran/69659] [6/7 Regression] ICE on using option -frepack-arrays, in gfc_conv_descriptor_data_get

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

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

--- Comment #8 from Gerhard Steinmetz  
---
> Can you confirm that the patch fixes the issue in all cases
> and does not raise new issues?

Yes, I can confirm this now.

FYI, there is a separate/independed issue, see pr70853 comment 1.

My best regards.

[Bug testsuite/70595] Cilk Plus testsuite needs massive cleanup

[ro at gcc dot gnu.org]

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

--- Comment #5 from Rainer Orth  ---
Initial patch installed for 7.1, more TBD, to keep PR open.

[Bug c/70852] ice in warn_for_memset

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-28
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed, will reduce & fix.

[Bug testsuite/70595] Cilk Plus testsuite needs massive cleanup

[ro at gcc dot gnu.org]

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

--- Comment #4 from Rainer Orth  ---
Author: ro
Date: Thu Apr 28 15:16:57 2016
New Revision: 235574

URL: https://gcc.gnu.org/viewcvs?rev=235574=gcc=rev
Log:
Cilk Plus testsuite needs massive cleanup (PR testsuite/70595)

gcc:
PR testsuite/70595
* doc/sourcebuild.texi (Effective-Target Keywords, Other
attributes): Document cilkplus_runtime.

gcc/testsuite:
PR testsuite/70595
* lib/target-supports.exp (check_libcilkrts_available): Rename to ...
(check_effective_target_cilkplus_runtime): ... this.
* g++.dg/cilk-plus/cilk-plus.exp: Adapt to it.
* gcc.dg/cilk-plus/cilk-plus.exp: Likewise.

* c-c++-common/cilk-plus/CK/cilk-for-2.c: Remove dg-do target selector.
Require cilkplus_runtime.
Don't add -lcilkrts.
* c-c++-common/cilk-plus/CK/cilk-fors.c: Likewise.
* c-c++-common/cilk-plus/CK/cilk_for_grain.c: Likewise.
* c-c++-common/cilk-plus/CK/cilk_for_ptr_iter.c: Likewise.
* c-c++-common/cilk-plus/CK/fib.c: Likewise.
* c-c++-common/cilk-plus/CK/fib_init_expr_xy.c: Likewise.
* c-c++-common/cilk-plus/CK/fib_no_return.c: Likewise.
* c-c++-common/cilk-plus/CK/fib_no_sync.c: Likewise.
* c-c++-common/cilk-plus/CK/nested_cilk_for.c: Likewise.
* c-c++-common/cilk-plus/CK/pr60586.c: Likewise.
* c-c++-common/cilk-plus/CK/pr69826-1.c: Likewise.
* c-c++-common/cilk-plus/CK/pr69826-2.c: Likewise.
* c-c++-common/cilk-plus/CK/spawnee_inline.c: Likewise.
* c-c++-common/cilk-plus/CK/spawner_inline.c: Likewise.
* c-c++-common/cilk-plus/CK/spawning_arg.c: Likewise.
* c-c++-common/cilk-plus/CK/steal_check.c: Likewise.
* c-c++-common/cilk-plus/CK/varargs_test.c: Likewise.
* g++.dg/cilk-plus/CK/catch_exc.cc: Likewise.
* g++.dg/cilk-plus/CK/cilk-for-tplt.cc: Likewise.
* g++.dg/cilk-plus/CK/const_spawn.cc: Likewise.
* g++.dg/cilk-plus/CK/fib-opr-overload.cc: Likewise.
* g++.dg/cilk-plus/CK/fib-tplt.cc: Likewise.
* g++.dg/cilk-plus/CK/for1.cc: Likewise.
* g++.dg/cilk-plus/CK/lambda_spawns.cc: Likewise.
* g++.dg/cilk-plus/CK/lambda_spawns_tplt.cc: Likewise.
* g++.dg/cilk-plus/CK/pr60586.cc: Likewise.
* g++.dg/cilk-plus/CK/pr66326.cc: Likewise.
* g++.dg/cilk-plus/CK/stl_iter.cc: Likewise.
* g++.dg/cilk-plus/CK/stl_rev_iter.cc: Likewise.
* g++.dg/cilk-plus/CK/stl_test.cc: Likewise.

* c-c++-common/cilk-plus/CK/pr63307.c: Remove dg-do target selector.
* c-c++-common/cilk-plus/SE/ef_error3.c: Likewise.

* c-c++-common/cilk-plus/SE/ef_error2.c: Explain target selector.

* c-c++-common/cilk-plus/CK/test__cilk.c: Run if
cilkplus_runtime.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/sourcebuild.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/cilk-for-2.c
trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/cilk-fors.c
trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/cilk_for_grain.c
trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/cilk_for_ptr_iter.c
trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/fib.c
trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/fib_init_expr_xy.c
trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/fib_no_return.c
trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/fib_no_sync.c
trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/nested_cilk_for.c
trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/pr60586.c
trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/pr63307.c
trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/pr69826-1.c
trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/pr69826-2.c
trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/spawnee_inline.c
trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/spawner_inline.c
trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/spawning_arg.c
trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/steal_check.c
trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/test__cilk.c
trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/varargs_test.c
trunk/gcc/testsuite/c-c++-common/cilk-plus/SE/ef_error2.c
trunk/gcc/testsuite/c-c++-common/cilk-plus/SE/ef_error3.c
trunk/gcc/testsuite/g++.dg/cilk-plus/CK/catch_exc.cc
trunk/gcc/testsuite/g++.dg/cilk-plus/CK/cilk-for-tplt.cc
trunk/gcc/testsuite/g++.dg/cilk-plus/CK/const_spawn.cc
trunk/gcc/testsuite/g++.dg/cilk-plus/CK/fib-opr-overload.cc
trunk/gcc/testsuite/g++.dg/cilk-plus/CK/fib-tplt.cc
trunk/gcc/testsuite/g++.dg/cilk-plus/CK/for1.cc
trunk/gcc/testsuite/g++.dg/cilk-plus/CK/lambda_spawns.cc
trunk/gcc/testsuite/g++.dg/cilk-plus/CK/lambda_spawns_tplt.cc
trunk/gcc/testsuite/g++.dg/cilk-plus/CK/pr60586.cc
trunk/gcc/testsuite/g++.dg/cilk-plus/CK/pr66326.cc
trunk/gcc/testsuite/g++.dg/cilk-plus/CK/stl_iter.cc

[Bug fortran/70853] ICE on pointing to null, in gfc_add_block_to_block, at fortran/trans.c:1599

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

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

--- Comment #1 from Gerhard Steinmetz  
---
Messages interchanged (v5/v6) with a user defined type :

$ cat z3.f90
program p
   type t
   end type
   type(t), pointer :: z(:)
   z(1:2) => null()
end

$ gfortran-6 -c z3.f90
internal compiler error: Segmentation fault

$ gfortran-5.3.1 -c z3.f90
internal compiler error: in gfc_add_block_to_block, at fortran/trans.c:1630



Another error message with "class" instead of "type" :

$ cat z4.f90
program p
   type t
   end type
   class(t), pointer :: z(:)
   z(1:2) => null()
end

$ gfortran-6 -c z4.f90
internal compiler error: in gfc_conv_descriptor_data_get, at
fortran/trans-array.c:144

$ gfortran-5.3.1 -c z4.f90
internal compiler error: Segmentation fault

[Bug fortran/70853] New: ICE on pointing to null, in gfc_add_block_to_block, at fortran/trans.c:1599

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

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

Bug ID: 70853
   Summary: ICE on pointing to null, in gfc_add_block_to_block, at
fortran/trans.c:1599
   Product: gcc
   Version: 6.1.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 the following codes :


$ cat z1.f90
program p
   real, pointer :: z(:)
   z(1:2) => null()
end

$ gfortran-6 -c z1.f90
internal compiler error: in gfc_add_block_to_block, at fortran/trans.c:1599



$ cat z2.f90
program p
   real, pointer :: z(:)
   z(2:1) => null()
end

$ gfortran-6 -c z2.f90
internal compiler error: in gfc_add_block_to_block, at fortran/trans.c:1599

$ gfortran-5.3.1 -c z2.f90
internal compiler error: Segmentation fault

[Bug c/70852] New: ice in warn_for_memset

[dcb314 at hotmail dot com]

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

Bug ID: 70852
   Summary: ice in warn_for_memset
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 38366
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38366=edit
C source code

The attached C code, when compiled by gcc trunk dated 20160428, does this

/home/dcb/rpmbuild/BUILD/allegro-4.4.2/addons/jpgalleg/src/decode.c:1054:2:
internal compiler error: Segmentation fault
  memset(_jpeg_huffman_dc_table, 0, 4 * sizeof(HUFFMAN_TABLE));
  ^~
0xc438df crash_signal
../../src/trunk/gcc/toplev.c:333
0x6ed3da tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../src/trunk/gcc/tree.h:3147
0x6ed3da warn_for_memset(unsigned int, tree_node*, tree_node*, int)
../../src/trunk/gcc/c-family/c-common.c:11800
0x69cc49 c_parser_postfix_expression_after_primary
../../src/trunk/gcc/c/c-parser.c:8301

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

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

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

--- Comment #9 from Gerhard Steinmetz  
---
Update, using fresh new release  gfortran-6 --version
GNU Fortran (SUSE Linux) 6.1.0 20160427 [gcc-6-branch revision 235475]


The error message has changed :

$ gfortran-6 -c z1.f90
internal compiler error: in conv_function_val, at fortran/trans-expr.c:3683

$ gfortran-6 -c z2.f90
internal compiler error: in conv_function_val, at fortran/trans-expr.c:3683

$ gfortran-6 -fcoarray=single -c z4.f90
$ gfortran-6 -fcoarray=lib -c z4.f90
# NO error now


As noted in comment 2, the error message depends on configuration,
still differs for --enable-checking=release and --enable-checking=yes.


---

And for the following examples there seems to be no ICEs for many
different combinations of compile options. Only one problem remaining
with -fcoarray=lib and -finit-real. For example -finit-real=zero :


$ gfortran-6 -fcoarray=single -finit-real=zero -c z4.f90
# NO error

$ gfortran-6 -fcoarray=lib -finit-real=zero -c z4.f90
internal compiler error: in fold_convert_loc, at fold-const.c:2256


$ gfortran-6 -fcoarray=lib -finit-real=zero -c z5_harald_anlauf.f90
internal compiler error: in fold_convert_loc, at fold-const.c:2256

$ gfortran-6 -fcoarray=lib -finit-real=zero -c z6_harald_anlauf.f90
internal compiler error: in fold_convert_loc, at fold-const.c:2256

$ gfortran-6 -fcoarray=lib -finit-real=zero -c z8_harald_anlauf.f90
internal compiler error: in fold_convert_loc, at fold-const.c:2256


---

Running some examples, with suboptimal results :


$ gfortran-6 -fcoarray=single z6_harald_anlauf_print_z.f90
$ a.out
 ( -4.75674592E-16,  1.53246000E-41)


$ gfortran-6 -fcoarray=single z8_harald_anlauf.f90
$ a.out
 (  42.000,  0.)   42.000
 (  42.000,  0.)   42.000
 (  1.,  0.)   2.
 (  1.,  0.)   2.
 (  1.,  0.) (  1.54857493E-41, -9.79143559E+14)
   2.   2. (  1.54857493E-41, -9.79143559E+14)

[Bug middle-end/70828] broken array-type subarrays inside acc data in openacc

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||openmp
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-28
 CC||jakub at gcc dot gnu.org
   Assignee|cesar at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
(In reply to cesar from comment #0)
> Created attachment 38351 [details]
> broken subarray

Translating that one to OpenMP ("acc data copy(a[10:80])" -> "omp target data
map(a[10:80])", and "acc parallel loop" -> "omp target"), the issue also
reproduces for OpenMP.

> Given an array-typed subarray with a non-zero base element on an acc data
> construct, the gimplifier will implicitly add a pcopy clause for any
> parallel and kernels construct which uses that array. The pcopy is correct,
> but this pcopy expects the entire array to be present on the accelerator.
> This ultimately results in a runtime failure when the base of the subarray
> is not element zero.
> 
> This problem can be reproduced with the attached test case in trunk and
> gcc-6.

OpenACC 2.0a says that "[...] the compiler will implicitly determine data
attributes for variables that are referenced in the compute construct that do
not appear in a data clause on the compute construct or a lexically containing
data construct and do not have predetermined data attributes [...]".  Indeed we
here have a "lexically containing data construct", so the compiler should use
that instead of implicitly determining conflicting (whole array) data
attributes.

Jakub, what's your take for OpenMP?  From a quick scan of OpenMP 4.5, 2.15.5
"Data-mapping Attribute Rules and Clauses", in combination with 2.10.4 "target
Construct", to me it also appears as if the intention is that the outer target
data construct already defines the definitive data attributes for the array
inside the target region, without wanting the compiler to implicitly determine
conflicting (whole array) data attributes for the target region?

[Bug c++/70847] [6/7 Regression] exponential time in cp_fold for chained virtual function calls

[ktietz at gcc dot gnu.org]

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

--- Comment #4 from Kai Tietz  ---
As side-note:  There is something pretty fishy in tree-pretty-print.c for
OBJ_TYPE_REF, too.  We do here recurse endless.  Simply add to command line
'-fdump-tree-original' for reproducing.

[Bug rtl-optimization/70826] [7 regression] many test cases fail starting with r235442

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||amodra at gcc dot gnu.org

--- Comment #7 from Bernd Schmidt  ---
So why is there any expectation that the condition register contains any
particular value?

Cc'ing Alan Modra who added the test.

[Bug libstdc++/70845] [6/7 Regression] inherited piecewise_construct_t constructor from std::pair by "using-declarations" is missing

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Yes, I think it's valid.

It started being rejected with r233719

PR c++/69842
* method.c (forward_parm): Handle parameter packs.
* lambda.c (maybe_add_lambda_conv_op): Use it for them.

[Bug driver/70132] ARM -mcpu=native can cause a double free abort.

[ktkachov at gcc dot gnu.org]

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

--- Comment #10 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Apr 28 14:44:07 2016
New Revision: 235573

URL: https://gcc.gnu.org/viewcvs?rev=235573=gcc=rev
Log:
[ARM] PR driver/70132: Avoid double fclose in driver-arm.c

Backport from mainline
2016-03-23  Kyrylo Tkachov  

PR driver/70132
* config/arm/driver-arm.c (host_detect_local_cpu): Reorder exit logic
to not call fclose twice on file.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/arm/driver-arm.c

[Bug c/70851] internal compiler error: in create_tmp_var, at gimple-expr.c:473

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
gcc34 worked ok:
$ gcc34 -c q.c
q.c:1: error: storage size of `e' isn't known

but even gcc44 ICEs.

[Bug c++/70847] [6/7 Regression] exponential time in cp_fold for chained virtual function calls

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #3 from Kai Tietz  ---
This seems to be related to cp_fold_r's behavior to walk subtree for
OBJ_TYPE_REF.
Normally we can assume that in case of an OBJ_TYPE_REF tree, it was already
folded.  So we don't need to walk it again .

The following patch solves the issue for me on m32c.

Index: ../gcc/cp/cp-gimplify.c
===
--- ../gcc/cp/cp-gimplify.c (revision 235430)
+++ ../gcc/cp/cp-gimplify.c (working copy)
@@ -986,7 +986,8 @@
   cp_walk_tree (_FOR_PRE_BODY (stmt), cp_fold_r, data, NULL);
   *walk_subtrees = 0;
 }
-
+  else if (code == OBJ_TYPE_REF)
+*walk_subtrees = 0;
   return NULL;
 }

[Bug go/70850] Bootstrap fails building libgo: gccgo: error: ../x86_64-pc-linux-gnu/libgo/zstdpkglist.go: No such file or directory

[bill at baddogconsulting dot com]

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

--- Comment #2 from Bill Deegan  ---
Rebuilding outside src dir. Will report.
It's a fairly slow machine so it may take a while.