[Bug c++/70616] New: ICE on valid code on x86_64-linux-gnu in build_base_path, at cp/class.c:303

[su at cs dot ucdavis.edu]

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

Bug ID: 70616
   Summary: ICE on valid code on x86_64-linux-gnu in
build_base_path, at cp/class.c:303
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current GCC trunk (and
4.7.x and later) on x86_64-linux-gnu in both 32-bit and 64-bit modes.  

This is a regression from 4.6.x. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20160409 (experimental) [trunk revision 234848] (GCC) 
$ 
$ g++-4.6 small.cpp
$ 
$ g++-trunk small.cpp
small.cpp: In instantiation of ‘void test() [with int  = 0]’:
small.cpp:20:15:   required from here
small.cpp:15:9: internal compiler error: in build_base_path, at cp/class.c:303
   b->~A ();
   ~~^~
0x6f98e9 build_base_path(tree_code, tree_node*, tree_node*, int, int)
../../gcc-source-trunk/gcc/cp/class.c:303
0x612878 build_over_call
../../gcc-source-trunk/gcc/cp/call.c:7396
0x61e735 build_new_method_call_1
../../gcc-source-trunk/gcc/cp/call.c:8419
0x61e735 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc-source-trunk/gcc/cp/call.c:8489
0x68d380 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-source-trunk/gcc/cp/pt.c:16624
0x67db4f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15802
0x67e1f0 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15118
0x67d573 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15104
0x67f090 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15290
0x6c1ef0 instantiate_decl(tree_node*, int, bool)
../../gcc-source-trunk/gcc/cp/pt.c:22014
0x6c8e72 instantiate_pending_templates(int)
../../gcc-source-trunk/gcc/cp/pt.c:22133
0x70aed7 c_parse_final_cleanups()
../../gcc-source-trunk/gcc/cp/decl2.c:4599
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


-


struct A
{
  virtual ~A () {}
};

struct B : public A
{
  virtual ~B () {}
};

template < int >
void test ()
{
  B *b = new B;
  b->~A ();
} 

int main ()
{
  test < 0 > ();
  return 0; 
}

[Bug c++/70615] New: ICE on valid code at -O1 and above on x86_64-linux-gnu in add_expr, at tree.c:7870

[su at cs dot ucdavis.edu]

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

Bug ID: 70615
   Summary: ICE on valid code at -O1 and above on x86_64-linux-gnu
in add_expr, at tree.c:7870
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current GCC trunk at
-O1 and above on x86_64-linux-gnu in both 32-bit and 64-bit modes.  

This is a regression from 5.3.x.


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20160409 (experimental) [trunk revision 234848] (GCC) 
$ 
$ g++-trunk -O0 small.cpp
$ g++-5.3 -O1 small.cpp
$ 
$ g++-trunk -O1 small.cpp
small.cpp: In function ‘int main()’:
small.cpp:26:21: internal compiler error: in add_expr, at tree.c:7870
   (d->*(D_f) fptr) ();
 ^
0xff677b inchash::add_expr(tree_node const*, inchash::hash&)
../../gcc-source-trunk/gcc/tree.c:7870
0xff6297 inchash::add_expr(tree_node const*, inchash::hash&)
../../gcc-source-trunk/gcc/tree.c:7882
0xff65f3 inchash::add_expr(tree_node const*, inchash::hash&)
../../gcc-source-trunk/gcc/tree.c:7898
0xff6297 inchash::add_expr(tree_node const*, inchash::hash&)
../../gcc-source-trunk/gcc/tree.c:7882
0xff612f inchash::add_expr(tree_node const*, inchash::hash&)
../../gcc-source-trunk/gcc/tree.c:7843
0xae6148 iterative_hash_expr
../../gcc-source-trunk/gcc/tree.h:4759
0xae6148 gimplify_hasher::hash(gimple_temp_hash_elt const*)
../../gcc-source-trunk/gcc/gimplify.c:11773
0xae6148 hash_table::find_slot(gimple_temp_hash_elt* const&, insert_option)
../../gcc-source-trunk/gcc/hash-table.h:414
0xae6148 lookup_tmp_var
../../gcc-source-trunk/gcc/gimplify.c:528
0xae6148 internal_get_tmp_var
../../gcc-source-trunk/gcc/gimplify.c:563
0xade68e gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-source-trunk/gcc/gimplify.c:11213
0xaec501 gimplify_compound_lval
../../gcc-source-trunk/gcc/gimplify.c:2114
0xade94e gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-source-trunk/gcc/gimplify.c:10229
0xadea6c gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-source-trunk/gcc/gimplify.c:10217
0xadecd4 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-source-trunk/gcc/gimplify.c:10992
0xadecd4 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-source-trunk/gcc/gimplify.c:10992
0xaed0b6 gimplify_cond_expr
../../gcc-source-trunk/gcc/gimplify.c:3184
0xae0485 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-source-trunk/gcc/gimplify.c:10233
0xae3616 gimplify_stmt(tree_node**, gimple**)
../../gcc-source-trunk/gcc/gimplify.c:5684
0xaed41c gimplify_cond_expr
../../gcc-source-trunk/gcc/gimplify.c:3143
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


-


struct C
{
  virtual void f () {}
};

struct B
{
  virtual ~B () {}
};

class D : public B, public C
{
public:
  D () {}
};

typedef void (C::*FP) ();
typedef void (D::*D_f) ();

int
main ()
{
  D *d = new D ();
  C *c = d;
  const FP fptr = (FP) & D::f;
  (d->*(D_f) fptr) ();
  return 0;
}

[Bug c/70614] New: GCC gets stuck with -O

[kazunori.ueda.ku at gmail dot com]

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

Bug ID: 70614
   Summary: GCC gets stuck with -O
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kazunori.ueda.ku at gmail dot com
  Target Milestone: ---

Created attachment 38231
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38231&action=edit
obtained by "gcc -c -save-temps -v wave.c"  (without -O)

Compilation of the attached (machine-generated) program gets stuck with -On
(n>0)
(i.e., without reporting the next "COLLECT_GCC_OPTIONS=" message).  Happens
also with -m32.  Does not happen with -O0.  The same problem happened in
several (but not all) previous versions of gcc (Linux and Cygwin).  
(FYI, compilation of all other machine-generated programs from the same
software we have tested works fine with -O.)  Thanks for your help.

$ gcc -c -O -v wave.i
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.2.1-22ubuntu2'
--with-bugurl=file:///usr/share/doc/\
gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++
--prefix=/usr --program-suffix=-5 --en\
able-shared --enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdi\
r=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes -\
-with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin -\
-with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/ja\
va-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-d\
ir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64
--with-ecj-jar=/usr/share/java/eclipse-ec\
j.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m\
32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-l\
inux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2)
COLLECT_GCC_OPTIONS='-c' '-O' '-v' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/5/cc1 -fpreprocessed wave.i -quiet -dumpbase
wave.i -mtune=generic -march=x86-64 -aux\
base wave -O -version -fstack-protector-strong -Wformat -Wformat-security -o
/tmp/ccyZdX3r.s
GNU C11 (Ubuntu 5.2.1-22ubuntu2) version 5.2.1 20151010 (x86_64-linux-gnu)
compiled by GNU C version 5.2.1 20151010, GMP version 6.0.0, MPFR
version 3.1.3, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (Ubuntu 5.2.1-22ubuntu2) version 5.2.1 20151010 (x86_64-linux-gnu)
compiled by GNU C version 5.2.1 20151010, GMP version 6.0.0, MPFR
version 3.1.3, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: ae1f57641df2bca5e5adf4e90874d7ef

(then enters an infinite loop.)

[Bug c++/70613] New: -fabi-version docs don't match implementation

[wilson at gcc dot gnu.org]

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

Bug ID: 70613
   Summary: -fabi-version docs don't match implementation
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wilson at gcc dot gnu.org
  Target Milestone: ---

In docs/invoke.texi, it says that 8 is the highest value for -fabi-version.  In
c-family/c-opts.c, flag_abi_version gets set to 9.  I see two places that check
for abi_version of 9 in cp/class.c.  And one place in cp/decl.c.

At first glance it appears that this is just a documentation bug.  I haven't
verified this yet.

Since gcc-5 is the first version that defaults to -fabi-version=0, we really
should get the -fabi-version docs correct.

[Bug c++/70603] gcc alignas issue with pointers to class

[mhadji at gmail dot com]

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

--- Comment #4 from Marios Hadjieleftheriou  ---
But of course. I am checking the alignment of the wrong things, in my
example...

[Bug c++/70603] gcc alignas issue with pointers to class

[mhadji at gmail dot com]

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

--- Comment #3 from Marios Hadjieleftheriou  ---
I am trying to use posix_memalign and a double pointer to double, and that is
also failing. Is this an overalignment issue as well?

#include 
#include 

struct B { 
B() {
x = new double*[1];
void* p = x[0];
posix_memalign(&p, 32, 1); 
}   

double** x;
};

struct A
{
A() { b1 = new B(); b2 = new B(); }

B* b1; 
B* b2; 
};

int main(int argc, char** argv) {
A a;

int ret = reinterpret_cast(a.b1->x) % 32 +
reinterpret_cast(a.b2->x) % 32; 

return ret;
}

[Bug fortran/30792] DATA implied-do substring allowed with -std=f95/f2003

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
Still present at revision r234859.

[Bug libfortran/25830] [libgfortran] Optionally support multi-process locking

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #5 from Dominique d'Humieres  ---
This PR did not get any attention for almost five years. Any point to keep it
open?

[Bug libstdc++/70607] The return type of std::conj must be std::complex

[Alexander.Voigt at desy dot de]

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

--- Comment #2 from Alexander Voigt  ---
I absolutely agree, that the definition of the std::conj() overloads in C++11
is problematic.  However, in my opinion one has to be strict when implementing
the standard.  Otherwise, people might accidentally write non-portable C++11
code and g++ does not complain.

[Bug testsuite/70150] Additonal test failures with --enable-default-pie

[hjl.tools at gmail dot com]

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

--- Comment #12 from H.J. Lu  ---
Patches are posted at

https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00929.html
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00995.html

[Bug testsuite/66402] gcc.dg/uninit-19.c FAILs with PIE

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #2 from H.J. Lu  ---
Dup.

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

[Bug testsuite/70150] Additonal test failures with --enable-default-pie

[hjl.tools at gmail dot com]

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

--- Comment #11 from H.J. Lu  ---
*** Bug 66402 has been marked as a duplicate of this bug. ***

[Bug fortran/68566] ICE on using unusable array in reshape (double free or corruption)

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sat Apr  9 19:09:02 2016
New Revision: 234864

URL: https://gcc.gnu.org/viewcvs?rev=234864&root=gcc&view=rev
Log:
2016-04-09  Jerry DeLisle  

PR fortran/68566
* array.c (match_array_element_spec): Add check for non-integer.
* simplify.c (gfc_simplify_reshape): If source shape is NULL return.

PR fortran/68566
* gfortran.dg/pr36192.f90: Update test.
* gfortran.dg/pr36192_1.f90: Update test.
* gfortran.dg/real_dimension_1.f: Update test.
* gfortran.dg/parameter_array_init_7.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/parameter_array_init_7.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/pr36192.f90
trunk/gcc/testsuite/gfortran.dg/pr36192_1.f90
trunk/gcc/testsuite/gfortran.dg/real_dimension_1.f

[Bug fortran/47040] Make error message for empty array constructor more helpful/correct

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||kargl at troutmask dot 
apl.washing
   ||ton.edu
 Resolution|--- |INVALID

--- Comment #7 from Dominique d'Humieres  ---
> Patch submitted at https://gcc.gnu.org/ml/fortran/2016-04/msg00024.html.

Flatly rejected at https://gcc.gnu.org/ml/fortran/2016-04/msg00025.html.

Per https://gcc.gnu.org/ml/fortran/2016-04/msg00030.html

> The above error is correct.  Adding any text referring
> to type-spec is wrong.

closing as INVALID.

[Bug fortran/68600] Inlined MATMUL is too slow.

[jvdelisle at gcc dot gnu.org]

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

--- Comment #11 from Jerry DeLisle  ---
(In reply to Jerry DeLisle from comment #8)
> Created attachment 36887 [details]
> A faster version
> 
> I took the example code found in
> http://wiki.cs.utexas.edu/rvdg/HowToOptimizeGemm/ where the register based
> vector computations are explicitly called via the SSE registers and
> converted it to use the builtin gcc vector extensions.  I had to experiment
> a little to get some of the equivalent operations of the original code.
> 
> With only -O2 and march=native I am getting good results. I need to roll
> this into the other test program yet to confirm the gflops are being
> computed correctly.  The diff value is comparing to the reference naive
> results to check the computation is correct.
> 
> MY_MMult = [
> Size: 40, Gflops: 1.828571e+00, Diff: 2.664535e-15 
> Size: 80, Gflops: 3.696751e+00, Diff: 7.105427e-15 
> Size: 120, Gflops: 4.051583e+00, Diff: 1.065814e-14 
> Size: 160, Gflops: 4.015686e+00, Diff: 1.421085e-14 
> Size: 200, Gflops: 4.029212e+00, Diff: 2.131628e-14 
> Size: 240, Gflops: 3.972414e+00, Diff: 2.486900e-14 
> Size: 280, Gflops: 3.881188e+00, Diff: 2.842171e-14 
> Size: 320, Gflops: 3.872371e+00, Diff: 3.552714e-14 
> Size: 360, Gflops: 3.887676e+00, Diff: 4.973799e-14 
> Size: 400, Gflops: 3.862052e+00, Diff: 4.973799e-14 
> Size: 440, Gflops: 3.886575e+00, Diff: 4.973799e-14 
> Size: 480, Gflops: 3.910124e+00, Diff: 6.039613e-14 
> Size: 520, Gflops: 3.863706e+00, Diff: 6.394885e-14 
> Size: 560, Gflops: 3.976947e+00, Diff: 6.750156e-14 
> Size: 600, Gflops: 4.002631e+00, Diff: 7.460699e-14 
> Size: 640, Gflops: 3.992507e+00, Diff: 8.171241e-14 
> Size: 680, Gflops: 3.964570e+00, Diff: 9.237056e-14 
> Size: 720, Gflops: 3.973661e+00, Diff: 1.101341e-13 
> Size: 760, Gflops: 3.982346e+00, Diff: 1.065814e-13 
> Size: 800, Gflops: 3.869291e+00, Diff: 8.881784e-14 
> Size: 840, Gflops: 3.936271e+00, Diff: 1.065814e-13 
> Size: 880, Gflops: 3.931259e+00, Diff: 1.030287e-13 
> Size: 920, Gflops: 3.912907e+00, Diff: 1.207923e-13 
> Size: 960, Gflops: 3.938391e+00, Diff: 1.278977e-13 
> Size: 1000, Gflops: 3.945754e+00, Diff: 1.421085e-13

(In reply to Dominique d'Humieres from comment #10)
> > I think you are seeing the effects of inefficiencies of assumed-shape 
> > arrays.
> >
> > If you want to use matmul on very small matrix sizes, it is best to
> > use fixed-size explicit arrays.
> 
> Then IMO the matmul inlining should be restricted to fixed-size explicit
> arrays. Could this be done before the release of gcc-6?

I was experimenting some more here a few days ago.  I really think that
inlineing shold be disabled above some threshold.  On larger arrays, the
runtime library outperforms inline and right now by default the runtime
routines are never used unless you provide -fno-frontend-optimize which is
counter intuitive for the larger arrays.

If one compiles with -march=native -mavx -Ofast etc etc, the inline can do
fairly well on the larger, however when we update the runtime routines to
something like shown in comment #8 it will make even more sense to not do
inline all the time. (Unless of course we further optimize the
frontend-optimize to do better.)

[Bug fortran/52393] I/O: "READ format" statement with parenthesed default-char-expr

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #8 from Jerry DeLisle  ---
Let me add this to my list and then I will investigate in a little while

[Bug testsuite/64039] [5 Regression] FAIL: gcc.dg/tree-ssa/ssa-dom-cse-2.c scan-tree-dump optimized "return 28;"

[danglin at gcc dot gnu.org]

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

--- Comment #4 from John David Anglin  ---
Author: danglin
Date: Sat Apr  9 17:36:24 2016
New Revision: 234863

URL: https://gcc.gnu.org/viewcvs?rev=234863&root=gcc&view=rev
Log:
PR testsuite/64039
* gcc.dg/tree-ssa/ssa-dom-cse-2.c: xfail scan-tree-dump on
hppa*64*-*-*.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-2.c

[Bug rtl-optimization/66669] FAIL: gcc.dg/loop-8.c

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2015-12-01 00:00:00 |2016-04-09
 Ever confirmed|0   |1

[Bug rtl-optimization/66669] FAIL: gcc.dg/loop-8.c

[danglin at gcc dot gnu.org]

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

--- Comment #2 from John David Anglin  ---
Author: danglin
Date: Sat Apr  9 17:15:15 2016
New Revision: 234861

URL: https://gcc.gnu.org/viewcvs?rev=234861&root=gcc&view=rev
Log:
PR rtl-optimization/9
* gcc.dg/loop-8.c: Skip on hppa*-*-*.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/loop-8.c

[Bug testsuite/66402] gcc.dg/uninit-19.c FAILs with PIE

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  ---
Duplicate of pr65364?

[Bug testsuite/70324] FAIL: gcc.dg/pic-1.c (test for excess errors)

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|target  |testsuite
 Resolution|--- |FIXED

--- Comment #1 from John David Anglin  ---
Fixed by commit 234859.
https://gcc.gnu.org/ml/gcc-cvs/2016-04/msg00200.html

[Bug fortran/70592] Addressing error in dynamically-allocated character array

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #7 from Dominique d'Humieres  ---
Test committed to trunk and the gcc-5 branch, closing as FIXED.

[Bug fortran/68241] [meta-bug] Deferred-length character

[dominiq at lps dot ens.fr]

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

Bug 70592 Summary: Addressing error in dynamically-allocated character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70592

   What|Removed |Added

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

[Bug target/70612] -mtune=native -maes does not detect that AES is not present

[daniel.gutson at tallertechnologies dot com]

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

Daniel Gutson  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #2 from Daniel Gutson  
---
My bad, I meant -march.

But in case this is not a bug, I still think we could do better at least with a
warning.

[Bug fortran/70592] Addressing error in dynamically-allocated character array

[dominiq at gcc dot gnu.org]

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

--- Comment #6 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sat Apr  9 16:14:02 2016
New Revision: 234858

URL: https://gcc.gnu.org/viewcvs?rev=234858&root=gcc&view=rev
Log:
2016-04-09  Dominique d'Humieres  

PR fortran/70592
* gfortran.dg/deferred_character_17.f90: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_17.f90
Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/70612] -mtune=native -maes does not detect that AES is not present

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
-mtune=native is just about tuning, not ISA selection, that is what
-march=native is for.  But even that just expands to the particular options
determined from the host CPU, you can always override it through other options.
So I don't see any bug from your description.

[Bug tree-optimization/68953] [6 Regression] [graphite] Wrong code w/ -O[12] -floop-nest-optimize

[vries at gcc dot gnu.org]

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

--- Comment #10 from vries at gcc dot gnu.org ---
asked follow-up question (
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00444.html ), waiting for answer
before marking fixed-resolved.

[Bug tree-optimization/68644] [6 Regression] FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "PHI

[danglin at gcc dot gnu.org]

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

--- Comment #4 from John David Anglin  ---
Author: danglin
Date: Sat Apr  9 15:55:42 2016
New Revision: 234855

URL: https://gcc.gnu.org/viewcvs?rev=234855&root=gcc&view=rev
Log:
PR tree-optimization/68644
* gcc.dg/tree-ssa/ivopts-lt-2.c: Skip on hppa*-*-*.


Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/gcc.dg/tree-ssa/ivopts-lt-2.c

[Bug tree-optimization/68644] [6 Regression] FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "PHI

[danglin at gcc dot gnu.org]

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

--- Comment #3 from John David Anglin  ---
Author: danglin
Date: Sat Apr  9 15:54:29 2016
New Revision: 234854

URL: https://gcc.gnu.org/viewcvs?rev=234854&root=gcc&view=rev
Log:
PR tree-optimization/68644
* gcc.dg/tree-ssa/ivopts-lt-2.c: Skip on hppa*-*-*.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopts-lt-2.c

[Bug rtl-optimization/64886] FAIL: gcc.dg/pr64434.c scan-rtl-dump-times expand "Swap operands" 1

[danglin at gcc dot gnu.org]

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

--- Comment #4 from John David Anglin  ---
Author: danglin
Date: Sat Apr  9 15:47:50 2016
New Revision: 234853

URL: https://gcc.gnu.org/viewcvs?rev=234853&root=gcc&view=rev
Log:
PR rtl-optimization/64886
* gcc.dg/pr64434.c: Skip on hppa*-*-hpux*.


Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr64434.c

[Bug rtl-optimization/64886] FAIL: gcc.dg/pr64434.c scan-rtl-dump-times expand "Swap operands" 1

[danglin at gcc dot gnu.org]

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

--- Comment #3 from John David Anglin  ---
Author: danglin
Date: Sat Apr  9 15:43:05 2016
New Revision: 234852

URL: https://gcc.gnu.org/viewcvs?rev=234852&root=gcc&view=rev
Log:
PR rtl-optimization/64886
* gcc.dg/pr64434.c: Skip on hppa*-*-hpux*.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr64434.c

[Bug target/70612] New: -mtune=native -maes does not detect that AES is not present

[daniel.gutson at tallertechnologies dot com]

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

Bug ID: 70612
   Summary: -mtune=native -maes does not detect that AES is not
present
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.gutson at tallertechnologies dot com
  Target Milestone: ---

I didn't investigate this, but despite /proc/cpuinfo does not list aes as a
capability, I think that the combination -mtune=native -maes should fail.

[Bug fortran/56149] 64 bit gFortran-C interop hidden character argument length passed as 32 bit value

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #10 from Dominique d'Humieres  ---
> Is there still some interest for this PR?

No feedback, closing as WONTFIX. It may be related to pr66310.

[Bug c++/70584] constexpr variables cannot be used as intrinsic arguments where an immediate is expected

[daniel.gutson at tallertechnologies dot com]

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

--- Comment #5 from Daniel Gutson  
---
(In reply to Daniel Gutson from comment #4)
> Thanks Martin.
> 
> Andres is finishing 70210 soon next week, and he can address this after

s/70210/70201/

> solving it. Feel free to assign this issue to him
> (andres.tirabos...@tallertechnologies.com).

[Bug c++/70584] constexpr variables cannot be used as intrinsic arguments where an immediate is expected

[daniel.gutson at tallertechnologies dot com]

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

--- Comment #4 from Daniel Gutson  
---
Thanks Martin.

Andres is finishing 70210 soon next week, and he can address this after solving
it. Feel free to assign this issue to him
(andres.tirabos...@tallertechnologies.com).

[Bug tree-optimization/68953] [6 Regression] [graphite] Wrong code w/ -O[12] -floop-nest-optimize

[vries at gcc dot gnu.org]

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

--- Comment #9 from vries at gcc dot gnu.org ---
Author: vries
Date: Sat Apr  9 15:28:24 2016
New Revision: 234851

URL: https://gcc.gnu.org/viewcvs?rev=234851&root=gcc&view=rev
Log:
Fix pdr accesses order

2016-04-09  Tom de Vries  

PR tree-optimization/68953
* graphite-sese-to-poly.c (pdr_add_memory_accesses): Order accesses
from
first to last subscript.

* gcc.dg/graphite/pr68953.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr68953.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-sese-to-poly.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/70611] New: Compiling binutils with -flto -Wstack-usage fails.

[dilyan.palauzov at aegee dot org]

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

Bug ID: 70611
   Summary: Compiling binutils with -flto -Wstack-usage fails.
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dilyan.palauzov at aegee dot org
  Target Milestone: ---

After binutils introduced passing -Wstack-usgage when compiling gas
(https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=9780e045073b1719a7a4c6cbe00e4aa7525bd180),
it does not compile anymore with -flto:


export CFLAGS="-pipe -O3 -fno-fat-lto-objects -flto"
export CXXFLAGS="-pipe -O3 -fno-fat-lto-objects -flto"
export LDFLAGS="-Wl,-O1,-z,relro,-s"

/git/binutils-gdb/gas/configure --with-system-zlib --enable-lto 
--enable-threads --with-system-zlib --enable-compressed-debug-sections=none

make 
[...]
make[2]: Entering directory '/root/binutils/gas'
/bin/bash ./libtool --tag=CC   --mode=link gcc -W -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Werror -Wwrite-strings 
-pipe -O3 -fno-fat-lto-objects -flto  -Wl,-O1,-z,relro,-s -flto=8  -L/lib64 -o
as-new app.o as.o atof-generic.o compress-debug.o cond.o depend.o dwarf2dbg.o
dw2gencfi.o ecoff.o ehopt.o expr.o flonum-copy.o flonum-konst.o flonum-mult.o
frags.o hash.o input-file.o input-scrub.o listing.o literal.o macro.o
messages.o output-file.o read.o remap.o sb.o stabs.o subsegs.o symbols.o
write.o tc-i386.o obj-elf.o atof-ieee.o  ../opcodes/libopcodes.la
../bfd/libbfd.la ../libiberty/libiberty.a   -ldl 
libtool: link: gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow
-Wstack-usage=262144 -Werror -Wwrite-strings -pipe -O3 -fno-fat-lto-objects
-flto -Wl,-O1 -Wl,-z -Wl,relro -Wl,-s -flto=8 -o as-new app.o as.o
atof-generic.o compress-debug.o cond.o depend.o dwarf2dbg.o dw2gencfi.o ecoff.o
ehopt.o expr.o flonum-copy.o flonum-konst.o flonum-mult.o frags.o hash.o
input-file.o input-scrub.o listing.o literal.o macro.o messages.o output-file.o
read.o remap.o sb.o stabs.o subsegs.o symbols.o write.o tc-i386.o obj-elf.o
atof-ieee.o  -L/lib64 ../opcodes/.libs/libopcodes.a ../bfd/.libs/libbfd.a -lz
../libiberty/libiberty.a -ldl
/git/binutils-gdb/libiberty/make-relative-prefix.c: In function
'make_relative_prefix_1.constprop':
/git/binutils-gdb/libiberty/make-relative-prefix.c:228:1: error: stack usage
might be unbounded [-Werror=stack-usage=]
 make_relative_prefix_1 (const char *progname, const char *bin_prefix,
 ^
lto1: all warnings being treated as errors
make[3]: *** [/tmp/ccGFedJA.ltrans24.ltrans.o] Error 1
make[3]: *** Waiting for unfinished jobs
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/local/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
Makefile:769: recipe for target 'as-new' failed
make[2]: *** [as-new] Error 1
make[2]: Leaving directory '/root/binutils/gas'

I use gcc (GCC) 5.3.1 20160407 and in /usr/local and have symlink
/usr/local/lib/bfd-plugins/liblto_plugin.so ->
/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.3.1/liblto_plugin.so .

This happens also when compiling ld.bfd, gprof, binutils/size .

I guess the problem is not in binutils, as it fails in libiberty, which comes
from gcc.  I fails also when I replace libiberty bundled with binutils/master
with libiberty comming with gcc/gcc-5-branch .

[Bug fortran/63469] Automatic reallocation of allocatable scalar length even when substring implicitly specified

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
The test in comment 4 works with trunk (6.0), but not with 5.3.1.

[Bug ipa/70583] [6 Regression] FAIL: g++.old-deja/g++.abi/vtable2.C -std=gnu++98 execution test

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Target|hppa64-hp-hpux11.11 |hppa*-*-* (elf)
 CC||hubicka at gcc dot gnu.org
  Component|c++ |ipa
   Host|hppa64-hp-hpux11.11 |
  Build|hppa64-hp-hpux11.11 |

--- Comment #1 from John David Anglin  ---
Introduced by:

Author: hubicka
Date: Mon Apr  4 09:26:29 2016
New Revision: 234708

URL: https://gcc.gnu.org/viewcvs?rev=234708&root=gcc&view=rev
Log:

PR ipa/68881
* cgraph.h (symtab_node::copy_visibility_from): New function.
* symtab.c (symtab_node::copy_visibility_from): New function.
* ipa-visibility.c (optimize_weakref): New function.
(function_and_variable_visibility): Use it.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.h
trunk/gcc/ipa-visibility.c
trunk/gcc/symtab.c

[Bug fortran/47469] Check whether arrayfunc_assign_needs_temporary misses TBP/PPC attributes

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
PING!

[Bug fortran/57778] Missing warning for -Wimplicit-procedure for dummy arguments

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
> From Richard Maine's answer at
> https://groups.google.com/forum/#!topic/comp.lang.fortran/3idUN6kMjjo
> it looks to me that the warning expectation is wrong. Am I making a mistake?
> If not, I'll close this PR as INVALID.

No feedback, closing.

[Bug fortran/58667] Add -Wfloat-conversion

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #2 from Dominique d'Humieres  ---
Another WONTFIX?

Note that the GCC documentation

-Wfloat-conversion
Warn for implicit conversions that reduce the precision of a real value. This
includes conversions from real to integer, and from higher precision real to
lower precision real values. This option is also enabled by -Wconversion. 

should mention that the command line option '-Wfloat-conversion' is valid for
C/C++/ObjC/ObjC++ but not for Fortran.

[Bug fortran/58001] Make it possible to silence "Extension: Tab character in format" warning

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #10 from Dominique d'Humieres  ---
What happened with patch in comment 9?

[Bug fortran/51820] [doc] underscoring documentation incorrect

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
Is the following patch a step in the right direction?

--- ../_clean/gcc/fortran/invoke.texi   2016-03-13 09:07:16.0 +0100
+++ gcc/fortran/invoke.texi 2016-04-09 15:58:43.0 +0200
@@ -1283,9 +1284,18 @@ Do not transform names of entities speci
 source file by appending underscores to them.

 With @option{-funderscoring} in effect, GNU Fortran appends one
-underscore to external names with no underscores.  This is done to ensure
+underscore to external names.  This is done to ensure
 compatibility with code produced by many UNIX Fortran compilers.

+Note that this applies  only to "F77" names, as modules, OOP stuff,
+@code{bind(c)}, and other modernities are mangled differently
+(or for plain @code{bind(C)}, never mangled), and is not modifiable
+by these command-line options.
+
+Also note that @code{bind(C)} is a more robust way to create external
+symbols with some specific name, rather than playing with compiler
+options.
+
 @emph{Caution}: The default behavior of GNU Fortran is
 incompatible with @command{f2c} and @command{g77}, please use the
 @option{-ff2c} option if you want object files compiled with
@@ -1306,7 +1316,7 @@ I = J() + MAX_COUNT (MY_VAR, LVAR)
 @noindent
 is implemented as something akin to:
 @smallexample
-i = j_() + max_count__(&my_var__, &lvar);
+i = j_() + max_count_(&my_var_, &lvar);
 @end smallexample

 With @option{-fno-underscoring}, the same statement is implemented as:
@@ -1336,11 +1346,11 @@ could make finding unresolved-reference 
 cases---they might occur at program run time, and show up only as
 buggy behavior at run time.

-In future versions of GNU Fortran we hope to improve naming and linking
-issues so that debugging always involves using the names as they appear
-in the source, even if the names as seen by the linker are mangled to
-prevent accidental linking between procedures with incompatible
-interfaces.
+%In future versions of GNU Fortran we hope to improve naming and linking
+%issues so that debugging always involves using the names as they appear
+%in the source, even if the names as seen by the linker are mangled to
+%prevent accidental linking between procedures with incompatible
+%interfaces.

 @item -fsecond-underscore
 @opindex @code{fsecond-underscore}
@@ -1355,8 +1365,7 @@ By default, GNU Fortran appends an under
 names.  If this option is used GNU Fortran appends two
 underscores to names with underscores and one underscore to external names
 with no underscores.  GNU Fortran also appends two underscores to
-internal names with underscores to avoid naming collisions with external
-names.
+internal names with underscores.

 This option has no effect if @option{-fno-underscoring} is
 in effect.  It is implied by the @option{-ff2c} option.

[Bug fortran/70592] Addressing error in dynamically-allocated character array

[dominiq at gcc dot gnu.org]

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

--- Comment #5 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sat Apr  9 13:29:32 2016
New Revision: 234850

URL: https://gcc.gnu.org/viewcvs?rev=234850&root=gcc&view=rev
Log:
2016-04-09  Dominique d'Humieres  

PR fortran/70592
* gfortran.dg/deferred_character_16.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/deferred_character_16.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/52403] coarray component gives error with CLASS( ) declaration

[dominiq at lps dot ens.fr]

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

Bug 51632 Summary: [OOP] Bogus argument checking for generated _def_init 
parameter and _copy procedure with CAF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51632

   What|Removed |Added

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

[Bug fortran/51632] [OOP] Bogus argument checking for generated _def_init parameter and _copy procedure with CAF

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #5 from Dominique d'Humieres  ---
> > TODO: Check that this patch doesn't worsen the handling of (non)polymorphic
> > coarray components of a polymorphic variable are properly handled for
> > DEALLOCATE/ALLOCATE/intrinsic assignment.
>
> Any hint about how to do that?

No feedback, closing as FIXED. Please open new PR(s) with relevant information
for remaining issue(s).

[Bug c++/70610] New: [6 regression] error: invalid initialization of non-const reference of type

[david.abdurachmanov at gmail dot com]

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

Bug ID: 70610
   Summary: [6 regression] error: invalid initialization of
non-const reference of type
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.abdurachmanov at gmail dot com
  Target Milestone: ---

This is a follow up of comment:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21802#c8

Caused by:

d175f0193ed47b61eafd213ca2d3dde73f8f5996 is the first bad commit
commit d175f0193ed47b61eafd213ca2d3dde73f8f5996
Author: ppalka 
Date:   Tue Dec 15 03:33:53 2015 +

Fix PR c++/21802 (two-stage name lookup fails for operators)

Works fine with GCC 5.3.0, Clang 3.7.0 and ICC (16.0.2 20160204).

Minimal reproducer by Patrick Palka:

struct A { };

A operator+ (A &) { return A (); }
A operator+ (const A &) { return A (); }


template 
void
foo ()
{
  +A ();
}

void
bar ()
{
  foo ();
}

$ g++ -c -ansi test.cc
test.cc: In instantiation of 'void foo() [with T = int]':
test.cc:17:13:   required from here
test.cc:11:3: error: invalid initialization of non-const reference of type 'A&'
from an rvalue of type 'A'
   +A ();
   ^
test.cc:3:3: note:   initializing argument 1 of 'A operator+(A&)'
 A operator+ (A &) { return A (); }
   ^~~~

Note, that removing -ansi solves the issue.

[Bug fortran/63158] Possible wrong code with absend optional BT_CLASS -> optional BT_DERIVED dummy argument

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #4 from Dominique d'Humieres  ---
> Should I close this PR as INVALID to get an answer?

No feedback, let's try it!-(

[Bug c++/36159] C++ compiler should issue a warning with missing new operator

[mhadji at gmail dot com]

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

--- Comment #17 from Marios Hadjieleftheriou  ---
(In reply to Martin Sebor from comment #12)
> Confirmed.  As noted in bug 67911, the solution proposed for the next
> version of C++ is the following:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0035r0.html
> Until it's accepted and implemented, issuing a warning would help users
> avoid the trap.  I happen to be working in this area so I'll see if I can
> come up with something.

The link posted above appears to be broken.

[Bug fortran/27436] gfortran: Abort compiling if there are insufficient data descriptors in format after reversion

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
See also pr28397.

[Bug fortran/28397] Check format mismatches at compile time

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
See also pr27436.

[Bug fortran/38979] OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #13 from Dominique d'Humieres  ---
> > Any progress after six years?
>
> PING!

No feedback, closing as WONTFIX.

[Bug fortran/42478] [meta-bug] gfortran OpenMP bugs

[dominiq at lps dot ens.fr]

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

Bug 38979 Summary: OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38979

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

[Bug fortran/62007] default(none) conflicts with iteration variable in openmp parallel loop simd

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #11 from Dominique d'Humieres  ---
> Could this PR be closed as FIXED?

No feedback, closing.

[Bug fortran/61628] [MinGW)Write of medium sized or larger matrix fails without error message.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #24 from Dominique d'Humieres  ---
> > Arjen, any further results or information on this bug?
>
> PING!

No feedback for over a year, closing as FIXED.

[Bug libstdc++/70609] std::experimental::filesystem::copy fails if the file size is 0 bytes

[fruko_eto at hotmail dot com]

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

--- Comment #1 from furkan  ---
Also worth to note that I've tested a similar program with Boost::Filesystem,
QFile and Poco::File they all worked, so I don't think there is a
system-related bug

[Bug tree-optimization/70586] [7 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu in 32-bit and 64-bit modes

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|4.9.4   |7.0
Summary|[4.9/5/6 Regression] wrong  |[7 Regression] wrong code
   |code at -O2 and -O3 on  |at -O2 and -O3 on
   |x86_64-linux-gnu in 32-bit  |x86_64-linux-gnu in 32-bit
   |and 64-bit modes|and 64-bit modes

--- Comment #5 from Jakub Jelinek  ---
This particular issue fixed for 6.x.  Retargetting at 7.0+ for the general
issue whether pure/const functions can trap or raise FPU exceptions and how we
should handle them.

[Bug libstdc++/70609] New: std::experimental::filesystem::copy fails if the file size is 0 bytes

[fruko_eto at hotmail dot com]

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

Bug ID: 70609
   Summary: std::experimental::filesystem::copy fails if the file
size is 0 bytes
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fruko_eto at hotmail dot com
  Target Milestone: ---

#include 
#include 
int main() {
std::ofstream o("1.txt");
o.close();
std::experimental::filesystem::copy("1.txt", "2.txt");
}


The above code fails and when the exception caught, it gives 

filesystem error: cannot copy: Input/output error [1.txt] [2.txt]
generic:5

It also gives the same error when I create the file with touch instead of
std::ofstream. However, it works when I write something to the & save & delete
everything & save again. After these operations even though file looks empty
its size is 1 byte and it works without a problem.


g++ version 5.3.1 20151207 (Red Hat 5.3.1-2)
Fedora 23

Only parameters given to g++ is -std=c++17 and -lstdc++fs

[Bug tree-optimization/70586] [4.9/5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu in 32-bit and 64-bit modes

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Sat Apr  9 11:23:51 2016
New Revision: 234849

URL: https://gcc.gnu.org/viewcvs?rev=234849&root=gcc&view=rev
Log:
PR tree-optimization/70586
* tree-ssa-ifcombine.c (bb_no_side_effects_p): Return false
for any calls.

* gcc.c-torture/execute/pr70586.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr70586.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ifcombine.c

[Bug fortran/70592] Addressing error in dynamically-allocated character array

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> I am using OSX but I agree, after building the compiler from the tip
> of gcc-5-branch, that the problem does not exist there, but is present
> at gcc-5_3_0_release.

Indeed! but nothing can be done for 5.3.0 and 5.4.0 will be released soon.

[Bug c++/21802] Two-stage name lookup fails for operators

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #10 from Patrick Palka  ---
Yes, it looks like a bug.  Could you please file a separate bug report?  You
can use this as the minimal reproducer:

struct A { };

A operator+ (A &) { return A (); }
A operator+ (const A &) { return A (); }


template 
void
foo ()
{
  +A ();
}

void
bar ()
{
  foo ();
}

[Bug fortran/70592] Addressing error in dynamically-allocated character array

[KnowlesPJ at Cardiff dot ac.uk]

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

--- Comment #3 from Peter Knowles  ---
I am using OSX but I agree, after building the compiler from the tip of
gcc-5-branch, that the problem does not exist there, but is present at
gcc-5_3_0_release.

[Bug libfortran/70311] libgfortran build dies on "implicit declaration of function strncasecmp"

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-04-09
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Could some mingw32 guru assign this PR to her/himself?

[Bug fortran/68600] Inlined MATMUL is too slow.

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
> I think you are seeing the effects of inefficiencies of assumed-shape arrays.
>
> If you want to use matmul on very small matrix sizes, it is best to
> use fixed-size explicit arrays.

Then IMO the matmul inlining should be restricted to fixed-size explicit
arrays. Could this be done before the release of gcc-6?

[Bug testsuite/70516] Regtesting acats hangs on x86_64-apple-darwin15.4

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |SUSPENDED
   Last reconfirmed||2016-04-09
Summary|[4.9/5/6 Regression]|Regtesting acats hangs on
   |Regtesting acats hangs on   |x86_64-apple-darwin15.4
   |x86_64-apple-darwin15.4 |
 Ever confirmed|0   |1

--- Comment #7 from Dominique d'Humieres  ---
AFAICT this seems related to the current state of my system, thus I am removing
the regression marker and setting the status to SUSPENDED (allow me for some
time before closing this PR as INVALID).

[Bug sanitizer/70573] FAIL: c-c++-common/asan/halt_on_error-1.c -O* execution test x86_64-apple-darwin15

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #12 from Dominique d'Humieres  ---
Closing as FIXED. Thanks for the quick feedback.

[Bug sanitizer/70573] FAIL: c-c++-common/asan/halt_on_error-1.c -O* execution test x86_64-apple-darwin15

[dominiq at gcc dot gnu.org]

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

--- Comment #11 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sat Apr  9 09:24:45 2016
New Revision: 234848

URL: https://gcc.gnu.org/viewcvs?rev=234848&root=gcc&view=rev
Log:
2016-04-09  Dominique d'Humieres  

PR sanitizer/70573
* c-c++-common/asan/halt_on_error-1.c: Replace memset
with __builtin_memset
* c-c++-common/asan/halt_on_error-2.c: Likewise.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/asan/halt_on_error-1.c
trunk/gcc/testsuite/c-c++-common/asan/halt_on_error-2.c

[Bug fortran/70592] Addressing error in dynamically-allocated character array

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-04-09
 Blocks||68241
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
This PR has been fixed on trunk (6.0) between revisions r232023 (2016-01-01,
wrong code) and r232451 (2016-01-15, OK), likely r232450 and r234093 for the
gcc-5 branch.

I did not find any duplicate. Should the test be added to the gfortran test
suite?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
[Bug 68241] [meta-bug] Deferred-length character

[Bug fortran/67674] Incorrect result or ICE for deferred-length character component

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||nuclearlee at gmail dot com

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

[Bug fortran/70605] allocatable character scalar in type empty after assign

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Blocks||68241
 Resolution|--- |DUPLICATE

--- Comment #4 from Dominique d'Humieres  ---
This PR has been fixed on trunk (6.0) between revisions r230172 (2015-11-11,
wrong code) and r230421 (2015-11-16, OK), likely r230396 for trunk and r232203
for the gcc-5 branch.

I think it is a duplicate of pr67674.

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


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
[Bug 68241] [meta-bug] Deferred-length character

[Bug fortran/68241] [meta-bug] Deferred-length character

[dominiq at lps dot ens.fr]

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

Bug 70605 Summary: allocatable character scalar in type empty after assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70605

   What|Removed |Added

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

[Bug c++/21802] Two-stage name lookup fails for operators

[david.abdurachmanov at gmail dot com]

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

--- Comment #9 from David Abdurachmanov  
---
Created attachment 38230
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38230&action=edit
Failing file (pre-processed)

[Bug c++/21802] Two-stage name lookup fails for operators

[david.abdurachmanov at gmail dot com]

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

David Abdurachmanov  changed:

   What|Removed |Added

 CC||david.abdurachmanov at gmail 
dot c
   ||om

--- Comment #8 from David Abdurachmanov  
---
While looking at the last compilation issues while reg testing GCC 6.0.0, I
bumped into this one. The code compiles file with GCC 5.3.0. The code compiles
fine with Clang 3.7.0 (have not checked 3.8.0 or ICC yet, but can be done on
request).

git bisect pointed me to this fix (full bisect log is below).

d175f0193ed47b61eafd213ca2d3dde73f8f5996 is the first bad commit
commit d175f0193ed47b61eafd213ca2d3dde73f8f5996
Author: ppalka 
Date:   Tue Dec 15 03:33:53 2015 +

Fix PR c++/21802 (two-stage name lookup fails for operators)

Failing file (pre-processed) is attached and I am running C-Reduce to get
something more minimal. I am currently not sure if this a compiler issue or not
thus not creating a separate BZ item.

### COMPILE LINE ###

c++ -c -ansi -fPIC -O2  Algorithm.ii

Removing -ansi seems to solve compilation issue.

### ERROR ### 

Algorithm.cc: In instantiation of 'Algorithm::grammar::grammar()
[with Iterator = __gnu_cxx::__normal_iterator >]':
Algorithm.cc:119:11:   required from here
Algorithm.cc:76:16: error: invalid initialization of non-const reference of
type 'boost::proto::exprns_::expr, boost::fusion::vector1 > >, 0l>&' from an rvalue of type
'boost::spirit::terminal >::result::type {aka
boost::proto::exprns_::expr, boost::fusion::vector1 > >, 0l>}'
   = lexeme[+char_("a-zA-Z0-9{}[],_.+-")]
^~~~
In file included from
/home/david.abdurachmanov/gcc600/test/fc22_ppc64le_gcc600/external/boost/1.57.0/include/boost/proto/core.hpp:26:0,
 from
/home/david.abdurachmanov/gcc600/test/fc22_ppc64le_gcc600/external/boost/1.57.0/include/boost/proto/proto.hpp:12,
 from
/home/david.abdurachmanov/gcc600/test/fc22_ppc64le_gcc600/external/boost/1.57.0/include/boost/spirit/home/support/meta_compiler.hpp:19,
 from
/home/david.abdurachmanov/gcc600/test/fc22_ppc64le_gcc600/external/boost/1.57.0/include/boost/spirit/home/qi/meta_compiler.hpp:14,
 from
/home/david.abdurachmanov/gcc600/test/fc22_ppc64le_gcc600/external/boost/1.57.0/include/boost/spirit/home/qi/action/action.hpp:14,
 from
/home/david.abdurachmanov/gcc600/test/fc22_ppc64le_gcc600/external/boost/1.57.0/include/boost/spirit/home/qi/action.hpp:14,
 from
/home/david.abdurachmanov/gcc600/test/fc22_ppc64le_gcc600/external/boost/1.57.0/include/boost/spirit/home/qi.hpp:14,
 from
/home/david.abdurachmanov/gcc600/test/fc22_ppc64le_gcc600/external/boost/1.57.0/include/boost/spirit/include/qi.hpp:16,
 from Algorithm.cc:7:

/home/david.abdurachmanov/gcc600/test/fc22_ppc64le_gcc600/external/boost/1.57.0/include/boost/proto/operators.hpp:116:5:
note:   initializing argument 1 of 'const typename
boost::proto::detail::enable_unary,
boost::proto::tagns_::tag::unary_plus, Arg&>::type
boost::proto::exprns_::operator+(Arg&) [with Arg =
boost::proto::exprns_::expr, boost::fusion::vector1 > >, 0l>; typename
boost::proto::detail::enable_unary,
boost::proto::tagns_::tag::unary_plus, Arg&>::type =
boost::proto::exprns_::expr, boost::fusion::vector1 > >, 0l>&>, 1l>]'
 operator OP(Arg &arg BOOST_PROTO_UNARY_OP_IS_POSTFIX_ ## POST)
 \
 ^
/home/david.abdurachmanov/gcc600/test/fc22_ppc64le_gcc600/external/boost/1.57.0/include/boost/proto/operators.hpp:236:5:
note: in expansion of macro 'BOOST_PROTO_DEFINE_UNARY_OPERATOR'
 BOOST_PROTO_DEFINE_UNARY_OPERATOR(+, boost::proto::tag::unary_plus, TRAIT,
DOMAIN, 0)   \
 ^
/home/david.abdurachmanov/gcc600/test/fc22_ppc64le_gcc600/external/boost/1.57.0/include/boost/proto/operators.hpp:295:9:
note: in expansion of macro 'BOOST_PROTO_DEFINE_OPERATORS'
 BOOST_PROTO_DEFINE_OPERATORS(is_extension, deduce_domain)
 ^~~~

### BISECT LOG ###

git bisect start
# good: [c05c1b41d370b14bc94421f138d13e76831253d1] [5/n] Fix minor SSA_NAME
leaks
git bisect good c05c1b41d370b14bc94421f138d13e76831253d1
# bad: [078970398ca084fe81435464b0434dcdd4a56fc7] Daily bump.
git bisect bad 078970398ca084fe81435464b0434dcdd4a56fc7
# bad: [141d7d6e93a44d509f0be246231b46939e728c97] 2015-12-16  Richard Biener 

git bisect bad 141d7d6e93a44d509f0be246231b46939e728c97
# good: [296008a9d4e2305dbf691ffcae802abcb0fe29a9] missed error format change
in previous commit
git bisect good 296008a9d4e2305dbf691ffcae802abcb0fe29a9
# good: [5a9e96d29263540947275d331b2b3efc0b0b4536] [AArch64] Add builtins for
ARMv8.1 Adv.SIMD instructions.
git bisect good 5a9e96d29263540947275d331b2b3efc0b0b4536

[Bug fortran/70598] Fortran OpenACC host_data construct ICE

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
(In reply to vries from comment #1)
> On trunk

Sorry, that should have been gomp-4_0-branch

[Bug fortran/70598] Fortran OpenACC host_data construct ICE

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #1 from vries at gcc dot gnu.org ---
On trunk, for -m64, we have XFAIL/UNRESOLVED:
...
XFAIL: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O0  (internal compiler error)
XFAIL: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O0  (test for excess errors)
UNRESOLVED: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O0  compilation failed to produce
executa
ble
XFAIL: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O1  (internal compiler error)
XFAIL: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O1  (test for excess errors)
UNRESOLVED: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O1  compilation failed to produce
executa
ble
XFAIL: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O2  (internal compiler error)
XFAIL: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O2  (test for excess errors)
UNRESOLVED: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O2  compilation failed to produce
executa
ble
XFAIL: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error)
XFAIL: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
UNRESOLVED: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O3 -fomit-frame-pointer -funroll-loops
-f
peel-loops -ftracer -finline-functions  compilation failed to produce
executable
XFAIL: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O3 -g  (internal compiler error)
XFAIL: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O3 -g  (test for excess errors)
UNRESOLVED: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O3 -g  compilation failed to produce
exec
utable
XFAIL: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -Os  (internal compiler error)
XFAIL: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -Os  (test for excess errors)
UNRESOLVED: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -Os  compilation failed to produce
executa
ble
...

But for -m32, we have XPASS/FAIL:
...
XPASS: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O0  (test for excess errors)
FAIL: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O0  execution test
XPASS: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O1  (test for excess errors)
FAIL: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O1  execution test
XPASS: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O2  (test for excess errors)
FAIL: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O2  execution test
XPASS: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
XPASS: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O3 -g  (test for excess errors)
FAIL: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O3 -g  execution test
XPASS: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -Os  (test for excess errors)
FAIL: libgomp.oacc-fortran/host_data-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -

[Bug c++/70608] New: Braced initializer in default argument misses friendship

[potswa at mac dot com]

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

Bug ID: 70608
   Summary: Braced initializer in default argument misses
friendship
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: potswa at mac dot com
  Target Milestone: ---

A braced-init-list in a default function argument does not receive friendship
as it should.

class A {
A() {}

friend int ok(A);
friend int f(A);
friend int g(A);
};

int ok(A = A()); // OK.
int f(A = {}); // Error. Should be same as previous.
int g(A (&&)[1] = { A() }); // Error.

[Bug tree-optimization/68953] [6 Regression] [graphite] Wrong code w/ -O[12] -floop-nest-optimize

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org

--- Comment #8 from vries at gcc dot gnu.org ---
stage1 approved: https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00430.html