[Bug tree-optimization/70614] GCC gets stuck with -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70614 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-10 CC||trippels at gcc dot gnu.org Component|c |tree-optimization Ever confirmed|0 |1 Known to fail||4.9.3, 5.3.0, 6.0 --- Comment #1 from Markus Trippelsdorf --- Looping in tree-scalar-evolution: #0 chrec_contains_symbols_defined_in_loop (chrec=0x76ba7948, loop_nb=1) at ../../gcc/gcc/tree-scalar-evolution.c:402 #1 0x00c02843 in no_evolution_in_loop_p (res=, loop_num=1, chrec=0x76ba7948) at ../../gcc/gcc/tree-chrec.h:118 #2 compute_scalar_evolution_in_loop (wrto_loop=0x7728ad20, def_loop=, ev=) at ../../gcc/gcc/tree-scalar-evolution.c:2002 #3 0x00bfcbb5 in analyze_scalar_evolution_1 (loop=0x7728ad20, var=0x76b64bd0, res=0x0) at ../../gcc/gcc/tree-scalar-evolution.c:2048 #4 0x00bfd778 in analyze_scalar_evolution (loop=loop@entry=0x7728ad20, var=0x76b64bd0) at ../../gcc/gcc/tree-scalar-evolution.c:2111 #5 0x00bfcd34 in interpret_condition_phi (condition_phi=, loop=0x7728ad20) at ../../gcc/gcc/tree-scalar-evolution.c:1687 #6 analyze_scalar_evolution_1 (loop=0x7728ad20, var=0x76ba3828, res=) at ../../gcc/gcc/tree-scalar-evolution.c:2063 #7 0x00bfcbb5 in analyze_scalar_evolution_1 (loop=0x7728ad20, var=0x76b64ca8, res=0x0) at ../../gcc/gcc/tree-scalar-evolution.c:2048 #8 0x00bfd778 in analyze_scalar_evolution (loop=loop@entry=0x7728ad20, var=0x76b64ca8) at ../../gcc/gcc/tree-scalar-evolution.c:2111 #9 0x00bfcd34 in interpret_condition_phi (condition_phi=, loop=0x7728ad20) at ../../gcc/gcc/tree-scalar-evolution.c:1687 #10 analyze_scalar_evolution_1 (loop=0x7728ad20, var=0x76b9b678, res=) at ../../gcc/gcc/tree-scalar-evolution.c:2063 ...
[Bug c++/69066] SFINAE compilation error on lambda with trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69066 Paolo Carlini changed: What|Removed |Added Severity|major |normal --- Comment #1 from Paolo Carlini --- This works in trunk (for gcc6.0). I'm adding the testcase and closing the bug.
[Bug c++/69066] SFINAE compilation error on lambda with trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69066 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Sun Apr 10 09:32:46 2016 New Revision: 234869 URL: https://gcc.gnu.org/viewcvs?rev=234869&root=gcc&view=rev Log: 2016-04-10 Paolo Carlini PR c++/69066 * g++.dg/cpp1y/pr69066.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp1y/pr69066.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/69066] SFINAE compilation error on lambda with trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69066 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #3 from Paolo Carlini --- Done.
[Bug c++/64519] variadic template as the first argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64519 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-10 Ever confirmed|0 |1
[Bug fortran/58000] Accept OPEN( ... NAME=) with -std=legacy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58000
--- Comment #3 from Dominique d'Humieres ---
Patch I am planning to submit
--- ../_clean/gcc/fortran/gfortran.texi 2016-01-04 19:51:09.0 +0100
+++ gcc/fortran/gfortran.texi 2016-04-10 14:00:11.0 +0200
@@ -2148,6 +2148,7 @@ code that uses them running with the GNU
@c * Omitted arguments in procedure call::
* Alternate complex function syntax::
* Volatile COMMON blocks::
+* OPEN( ... NAME=)::
@end menu
@@ -2355,6 +2356,19 @@ invalid standard Fortran syntax and is n
+@node OPEN( ... NAME=)
+@subsection @code{OPEN( ... NAME=)}
+@cindex @code{NAM}
+
+Some Fortran compilers, including @command{g77}, let the user declare
+@code{OPEN( ... NAME=)}. This is
+invalid standard Fortran syntax and is not supported by
+@command{gfortran}. @code{OPEN( ... NAME=)} should be replaced
+with @code{OPEN( ... FILE=)}.
+
+
+
+@c -
@c -
@c Mixed-Language Programming
@c -
[Bug fortran/68401] improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING --- Comment #9 from Dominique d'Humieres --- Any progress?
[Bug fortran/68600] Inlined MATMUL is too slow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68600 --- Comment #12 from Thomas Koenig --- (In reply to Jerry DeLisle from comment #11) > 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. May I suggest reading the docs? ;-) `-finline-matmul-limit=N' When front-end optimiztion is active, some calls to the `MATMUL' intrinsic function will be inlined. This may result in code size increase if the size of the matrix cannot be determined at compile time, as code for both cases is generated. Setting `-finline-matmul-limit=0' will disable inlining in all cases. Setting this option with a value of N will produce inline code for matrices with size up to N. If the matrices involved are not square, the size comparison is performed using the geometric mean of the dimensions of the argument and result matrices. > 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.) We can give this option a reasonable default value. The current status is The default value for N is the value specified for `-fblas-matmul-limit' if this option is specified, or unlimitited otherwise.
[Bug testsuite/69807] FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite "number of SCoPs: 0" 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69807 John David Anglin changed: What|Removed |Added Target|x86_64-apple-darwin15 |x86_64-apple-darwin15 ||hppa64-hp-hpux11.11 Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-10 CC||danglin at gcc dot gnu.org Host|x86_64-apple-darwin15 |x86_64-apple-darwin15 ||hppa64-hp-hpux11.11 Ever confirmed|0 |1 Build|x86_64-apple-darwin15 |x86_64-apple-darwin15 ||hppa64-hp-hpux11.11
[Bug target/70416] [SH]: error: 'asm' operand requires impossible reload when building ruby2.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70416 --- Comment #30 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #28) > Fixed for GCC 6 and GCC 5. Ok, great. Matthias just imported r234858 for gcc-5 yesterday. I'll report back in case the issue persists. Thanks for your work! Adrian
[Bug c++/70617] New: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70617 Bug ID: 70617 Summary: internal compiler error: Segmentation fault Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jan.sm...@alcatel-lucent.com Target Milestone: --- gcc (GCC) 5.3.1 20160404 Unfortunately I have been unable to get a reduced testcase to upload. Creduce keeps running in loops and minor modifications to the source make it go away. The code is proprietary and therefor I can not share it. C++ , -O0 file.cpp:1335:1: internal compiler error: Segmentation fault 0xa3dd85 crash_signal .././gcc-5.3.1/gcc/toplev.c:383 0x6cd7e3 lookup_page_table_entry .././gcc-5.3.1/gcc/ggc-page.c:659 0x6cd7e3 ggc_set_mark(void const*) .././gcc-5.3.1/gcc/ggc-page.c:1540 0x638e97 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:236 0x63a33c gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:594 0x63a246 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:567 0x63a18d gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:543 0x63a20e gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:563 0x63a1d3 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:548 0x63a33c gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:594 0x63a373 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:602 0x63a373 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:602 0x63a373 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:602 0x89db2e gt_ggc_mx_gimple_statement_base(void*) /toolchains/gcc53/gcc-builddir/gcc/gtype-desc.c:2397 0x89b90d gt_ggc_mx_basic_block_def(void*) /toolchains/gcc53/gcc-builddir/gcc/gtype-desc.c:2055 0x89d7fd gt_ggc_mx_gimple_statement_base(void*) /toolchains/gcc53/gcc-builddir/gcc/gtype-desc.c:2428 0x89f2c1 gt_ggc_mx_cgraph_edge(void*) /toolchains/gcc53/gcc-builddir/gcc/gtype-desc.c:907 0x89f2b3 gt_ggc_mx_cgraph_edge(void*) /toolchains/gcc53/gcc-builddir/gcc/gtype-desc.c:906 0x89f2b3 gt_ggc_mx_cgraph_edge(void*) /toolchains/gcc53/gcc-builddir/gcc/gtype-desc.c:906 0x89eded gt_ggc_mx_symtab_node(void*) /toolchains/gcc53/gcc-builddir/gcc/gtype-desc.c:1712 Please submit a full bug report,
[Bug c++/69095] internal compiler error: in dependent_type_p, at cp/pt.c:19399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69095 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #3 from Paolo Carlini --- Mine.
[Bug c++/70617] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70617 --- Comment #1 from Jan Smets --- with checking=all ../pchip_code/vfp_combined_c.cpp:85:1: internal compiler error: Segmentation fault 0xd42735 crash_signal .././gcc-5.3.1/gcc/toplev.c:383 0x732f37 c_tree_chain_next .././gcc-5.3.1/gcc/c-family/c-common.h:1269 0x732f37 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:237 0x734651 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:567 0x734598 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:543 0x734619 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:563 0x7345de gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:548 0x733aa8 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:382 0x734673 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:569 0x734619 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:563 0x734192 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:437 0x75ede5 gt_ggc_mx_cp_binding_level(void*) ./gt-cp-name-lookup.h:64 0x733395 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:758 0x7341ae gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:439 0x734651 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:567 0x733aa8 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:382 0x734673 gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:569 0xa34e55 ggc_mark_root_tab .././gcc-5.3.1/gcc/ggc-common.c:81 0xa34e55 ggc_mark_roots() .././gcc-5.3.1/gcc/ggc-common.c:98 0x8269ff ggc_collect() .././gcc-5.3.1/gcc/ggc-page.c:2199 Please submit a full bug report,
[Bug c++/70617] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70617 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Try to reduce with --param ggc-min-expand=0 --param ggc-min-heapsize=0 (although it will be slow).
[Bug c++/36159] C++ compiler should issue a warning with missing new operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36159 --- Comment #18 from Martin Sebor --- The link works for me. An older version of the paper is here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3396.htm If that doesn't work for you either try searching for the paper titled Dynamic memory allocation for over-aligned data by Clark Nelson.
[Bug c++/70617] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70617 --- Comment #3 from Jan Smets --- output is the same
[Bug c++/70617] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70617 --- Comment #4 from Jakub Jelinek --- Yeah, but with the always collect options presumably it might be easier to reduce the testcase more, so creduce and/or delta might be successful on it.
[Bug c/70618] New: better error messages for missing/too many arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70618
Bug ID: 70618
Summary: better error messages for missing/too many arguments
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
When doing API refactorings it is reasonable common to have too many or not
enough arguments in function calls. The existing errors in gcc/g++ are not very
good for that, i get at least two consecutive ones and they are not very clear.
Since that is common it would be much better if the compiler could compute the
minimum edit distance to the real prototype (or the nearest for C++) and then
directl ysuggest what arguments are missing or which are too many.
void foo(int *xp, float *yp, double *zp)
{
}
int x;
float y;
double z;
short k;
void f2(void)
{
foo(&y, &z);/* forgot x */
foo(&x, &z);/* forgot y */
foo(&x, &z);/* forgot z */
foo(&x);/* forgot y and z */
foo(&z);/* forgot x and y*/
foo(&x, &y, &z, &x);/* x too many at end */
foo(&x, &x, &y, &z);/* x too man at start */
foo(&x, &y, &y, &z);/* y too much in the middle */
foo(&x, &y, &k, &z);/* different y in middle */
foo(&k, &x, &y, &z);/* different x at start */
foo(&x, &y, &z, &k);/* different x at end */
}
gcc/tsrc/tmissing.c: In function ‘f2’:
gcc/tsrc/tmissing.c:14:6: warning: passing argument 1 of ‘foo’ from
incompatible pointer type [-Wincompatible-pointer-types]
foo(&y, &z); /* forgot x */
^
gcc/tsrc/tmissing.c:3:6: note: expected ‘int *’ but argument is of type ‘float
*’
void foo(int *xp, float *yp, double *zp)
^
gcc/tsrc/tmissing.c:14:10: warning: passing argument 2 of ‘foo’ from
incompatible pointer type [-Wincompatible-pointer-types]
foo(&y, &z); /* forgot x */
^
gcc/tsrc/tmissing.c:3:6: note: expected ‘float *’ but argument is of type
‘double *’
void foo(int *xp, float *yp, double *zp)
^
gcc/tsrc/tmissing.c:14:2: error: too few arguments to function ‘foo’
foo(&y, &z); /* forgot x */
^
gcc/tsrc/tmissing.c:3:6: note: declared here
void foo(int *xp, float *yp, double *zp)
^
gcc/tsrc/tmissing.c:15:10: warning: passing argument 2 of ‘foo’ from
incompatible pointer type [-Wincompatible-pointer-types]
foo(&x, &z); /* forgot y */
^
gcc/tsrc/tmissing.c:3:6: note: expected ‘float *’ but argument is of type
‘double *’
void foo(int *xp, float *yp, double *zp)
^
gcc/tsrc/tmissing.c:15:2: error: too few arguments to function ‘foo’
foo(&x, &z); /* forgot y */
[Bug c/70619] New: Wrong warning with VLA, comma and sizeof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70619
Bug ID: 70619
Summary: Wrong warning with VLA, comma and sizeof
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
Compiling the program:
int main()
{
int a[1][(0, 1)];
int i = 0;
sizeof a[i++];
}
gives such warnings:
$ gcc -Wall example.c
example.c: In function ‘main’:
example.c:3:14: warning: left-hand operand of comma expression has no effect
[-Wunused-value]
int a[1][(0, 1)];
^
example.c:5:10: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
sizeof a[i++];
~~~^~
The first one is fine but the second one is wrong and confusing.
[Bug c++/70610] [6 regression] error: invalid initialization of non-const reference of type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70610 --- Comment #1 from Patrick Palka --- The problem is that during template processing we think the operand to the unary + is an lvalue (because it's wrapped in a NON_DEPENDENT_EXPR node) and so during overload resolution we select the non-const overload of operator+. Then during instantiation, since the operand is actually an rvalue we reject the function call since it requires the operand to be an lvalue.
[Bug c++/70610] [6 regression] error: invalid initialization of non-const reference of type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70610
--- Comment #2 from Patrick Palka ---
This general issue about the unconditional lvalue-ness of NON_DEPENDENT_EXPR
existed before my patch for PR c++/21802 though. For example, ere's a test
case that should compile cleanly but doesn't since at least g++ 4.4 (-std=c++98
is required) for basically the same reason:
struct A { };
void operator+ (const A &, A &);
void operator+ (A &, const A &);
void operator+ (const A &, const A &);
template
void
foo ()
{
A () + A ();
}
unary_plus.C: In function ‘void foo()’:
unary_plus.C:11:8: error: ambiguous overload for ‘operator+’ (operand types are
‘A’ and ‘A’)
A () + A ();
~^~
unary_plus.C:3:6: note: candidate: void operator+(const A&, A&)
void operator+ (const A &, A &);
^~~~
unary_plus.C:4:6: note: candidate: void operator+(A&, const A&)
void operator+ (A &, const A &);
^~~~
unary_plus.C:5:6: note: candidate: void operator+(const A&, const A&)
void operator+ (const A &, const A &);
^~~~
[Bug c++/70610] [6 regression] error: invalid initialization of non-const reference of type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70610
--- Comment #3 from Patrick Palka ---
Not limited to operator overloads either:
void bar (const int &, int &);
void bar (int &, const int &);
void bar (const int &, const int &);
int a, b;
template
void
foo ()
{
bar (a + 1, b + 2);
}
[Bug c++/70620] New: possible wrong code at -Os on x86_64-linux-gnu for C++ code with multiple inheritance and casting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70620
Bug ID: 70620
Summary: possible wrong code at -Os on x86_64-linux-gnu for C++
code with multiple inheritance and casting
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 current gcc trunk possibly miscompiles the following code on
x86_64-linux-gnu at -Os in both 32-bit and 64-bit modes.
It also affects 5.x at -Os and above and seems to be a regression from 4.9.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 20160410 (experimental) [trunk revision 234869] (GCC)
$
$ g++-trunk -O1 small.cpp; ./a.out; echo $?
0
$ g++-4.9 -Os small.cpp; ./a.out; echo $?
0
$
$ g++-trunk -Os small.cpp
$ ./a.out
Segmentation fault (core dumped)
$
int a;
class A
{
public:
virtual ~A () {}
};
class B1 : public A {};
class B2 : public A {};
class C
{
public:
virtual ~C () {}
};
class D : public C, public B2
{
public:
virtual ~D () {}
};
class E : public B1, virtual public D
{
public:
virtual ~E () { a = 0; }
};
int
main ()
{
a = 1;
delete (D *) (B1 *) new E; // Does this lead to undefined behavior?
if (a)
return 1;
return 0;
}
[Bug c++/70621] New: ICE on invalid code at -O1 and above on x86_64-linux-gnu in record_reference, at cgraphbuild.c:64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70621
Bug ID: 70621
Summary: ICE on invalid code at -O1 and above on
x86_64-linux-gnu in record_reference, at
cgraphbuild.c:64
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 20160410 (experimental) [trunk revision 234869] (GCC)
$
$ g++-trunk -O0 -c small.cpp
small.cpp:30:12: error: conflicting declaration ‘const B D::e’
const B D::e = { 0, (fp) &E::foo };
^
small.cpp:20:12: note: previous declaration as ‘B D::e’
static B e;
^
small.cpp:30:12: error: declaration of ‘B D::e’ outside of class is not
definition [-fpermissive]
const B D::e = { 0, (fp) &E::foo };
^
$
$ g++-5.3 -O1 -c small.cpp
small.cpp:30:12: error: conflicting declaration ‘const B D::e’
const B D::e = { 0, (fp) &E::foo };
^
small.cpp:20:12: note: previous declaration as ‘B D::e’
static B e;
^
small.cpp:30:12: error: declaration of ‘B D::e’ outside of class is not
definition [-fpermissive]
const B D::e = { 0, (fp) &E::foo };
^
$
$ g++-trunk -O1 -c small.cpp
small.cpp:30:12: error: conflicting declaration ‘const B D::e’
const B D::e = { 0, (fp) &E::foo };
^
small.cpp:20:12: note: previous declaration as ‘B D::e’
static B e;
^
small.cpp:30:12: error: declaration of ‘B D::e’ outside of class is not
definition [-fpermissive]
const B D::e = { 0, (fp) &E::foo };
^
cc1plus: internal compiler error: in record_reference, at cgraphbuild.c:64
0x95ef53 record_reference
../../gcc-source-trunk/gcc/cgraphbuild.c:64
0x100fec4 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc-source-trunk/gcc/tree.c:11531
0x1010474 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc-source-trunk/gcc/tree.c:11848
0x1010474 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc-source-trunk/gcc/tree.c:11848
0x96008a record_references_in_initializer(tree_node*, bool)
../../gcc-source-trunk/gcc/cgraphbuild.c:404
0x1051957 varpool_node::analyze()
../../gcc-source-trunk/gcc/varpool.c:526
0x966359 analyze_functions
../../gcc-source-trunk/gcc/cgraphunit.c:1133
0x966f98 symbol_table::finalize_compilation_unit()
../../gcc-source-trunk/gcc/cgraphunit.c:2542
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.
$
--
class A;
typedef void (A::*fp) (void);
struct B
{
int n;
fp f;
};
struct C
{
const C *c;
const B b;
};
class D
{
public:
static B e;
static C m;
};
class E : public D
{
public:
void foo ();
};
// OK: B D::e = { 0, (fp) &E::foo };
const B D::e = { 0, (fp) &E::foo };
C D::m = { &D::m, E::e };
[Bug fortran/58000] Accept OPEN( ... NAME=) with -std=legacy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58000
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment #4 from Jerry DeLisle ---
(In reply to Dominique d'Humieres from comment #3)
> Patch I am planning to submit
>
> --- ../_clean/gcc/fortran/gfortran.texi 2016-01-04 19:51:09.0
> +0100
> +++ gcc/fortran/gfortran.texi 2016-04-10 14:00:11.0 +0200
> @@ -2148,6 +2148,7 @@ code that uses them running with the GNU
> @c * Omitted arguments in procedure call::
> * Alternate complex function syntax::
> * Volatile COMMON blocks::
> +* OPEN( ... NAME=)::
> @end menu
>
>
> @@ -2355,6 +2356,19 @@ invalid standard Fortran syntax and is n
>
>
>
> +@node OPEN( ... NAME=)
> +@subsection @code{OPEN( ... NAME=)}
> +@cindex @code{NAM}
> +
> +Some Fortran compilers, including @command{g77}, let the user declare
> +@code{OPEN( ... NAME=)}. This is
> +invalid standard Fortran syntax and is not supported by
> +@command{gfortran}. @code{OPEN( ... NAME=)} should be replaced
> +with @code{OPEN( ... FILE=)}.
> +
> +
> +
> +@c -
> @c -
> @c Mixed-Language Programming
> @c -
Approved! Please proceed.
[Bug fortran/51820] [doc] underscoring documentation incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51820
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment #3 from Jerry DeLisle ---
(In reply to Dominique d'Humieres from comment #2)
> Is the following patch a step in the right direction?
---snip---
This all looks good to me except the following:
> @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.
It is confusing to me about names with underscores. For example, on internal
names, does foo_ become foo__ or foo___, appending one underscore to the
existing for a total of two or appending two more to the existing for a total
of three underscores. I think the wording needs to be a little more concise.
[Bug fortran/60751] Extra comma in WRITE statement not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751 --- Comment #18 from Jerry DeLisle --- (In reply to Dominique d'Humieres from comment #17) > Note that the extra comma is used in the following tests: > > gfortran.dg/array_constructor_49.f90 > gfortran.dg/integer_exponentiation_6.F90 > gfortran.dg/graphite/pr38083.f90 > > Any reason to keep it? No, and I am planning to fix the diagnostic on this.
[Bug fortran/67039] Documentation of pseudorandom number intrinsics is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67039
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment #7 from Jerry DeLisle ---
(In reply to Dominique d'Humieres from comment #6)
> I am planning to submit the following patch
---snip---
I think this word should be singular.
> +@code{RANDOM_SEED} to initialize the pseudo-random numbers <= no 's'
> +generator and @code{RANDOM_NUMBER} to generate pseudo-random numbers.
> +These subroutines should be used in new codes.
Even if internally there may be multiple 'generators' involved, from the user
perspective it is just one generator.
[Bug c++/70622] New: auto specifier don't deduce value type and its pointer type within single declaration.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70622
Bug ID: 70622
Summary: auto specifier don't deduce value type and its pointer
type within single declaration.
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: flast at flast dot jp
Target Milestone: ---
GCC 6 doesn't compile following code, but others (e.g. GCC 5, clang) do.
```
int main()
{
auto x = 0, *y = &x;
}
```
GCC 6 20160410: http://melpon.org/wandbox/permlink/kBVR4JiKMCMnfWe6
GCC 5.3.0: http://melpon.org/wandbox/permlink/61qqamq6MeInqgXF
clang 3.8.0: http://melpon.org/wandbox/permlink/qdw2lwZE17Rf4Ioz
[dcl.spec.auto]/4 indicates that code should be well-formed.
[Bug fortran/52884] double precision constants promoted to 16 byte by -fdefault-real-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52884 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #3 from Jerry DeLisle --- May I suggest the following wording: -fdefault-real-8 Set the default real type to an 8 byte wide type. This option also affects the kind of non-double real constants like 1.0. This option promotes the default width of DOUBLE PRECISION and double real constants like 1.d0 to 16 bytes if possible. If -fdefault-double-8 is given along with -fdefault-real-8, DOUBLE PRECISION and double real constants are not promoted. Note, -fdefault-real-8, does not promote variables with explicit kind declarations. -fdefault-double-8 Set the DOUBLE PRECISION type to an 8 byte wide type. Do nothing if this is already the default. This option prevents -fdefault-real-8 from promoting DOUBLE PRECISION and double real constants like 1.d0 to 16 bytes.
[Bug sanitizer/65479] sanitizer stack trace missing frames past #0 on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65479 --- Comment #14 from Bill Schmidt --- I wonder if this is just support that hasn't been updated in the GCC copy of libsanitizer. I recall fixing this bug (or one very similar to it) on the Clang side in 2015. There is some Power-specific logic in there for doing the stack unwinding. I will try to dig that information up and compare the two.
[Bug tree-optimization/70623] New: [6 Regression] ICE in compute_antic at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70623
Bug ID: 70623
Summary: [6 Regression] ICE in compute_antic at -O2
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-6.0.0-alpha20160403 and gcc-6.0.0-alpha20160410 snippets ICE when compiling
the following reduced snippet at -O2:
int nm;
int *av;
void
h9(void)
{
for (;;) {
int wk, rc;
int **ptr_10 = &av;
if (*av != 0) {
}
u4:
wk = 0;
for (rc = 0; rc < 3; ++rc) {
int bc = (rc ? rc : nm);
int ud = bc ? (*av ? 0 : rc) : 1;
if (ud != 0) {
if (*av != 0)
goto u4;
for (;;) {
}
}
}
while (wk < 3) {
av = **ptr_10;
++wk;
}
}
}
% gcc-6.0.0-alpha20160410 -c -O2 oqqpkhyr.c
oqqpkhyr.c: In function 'h9':
oqqpkhyr.c:25:10: warning: assignment makes pointer from integer without a cast
[-Wint-conversion]
av = **ptr_10;
^
oqqpkhyr.c:5:1: internal compiler error: in compute_antic, at
tree-ssa-pre.c:2403
h9(void)
^~
gcc-6.0.0-alpha20160110 doesn't ICE for me.
[Bug fortran/68600] Inlined MATMUL is too slow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68600 --- Comment #13 from Jerry DeLisle --- (In reply to Thomas Koenig from comment #12) > (In reply to Jerry DeLisle from comment #11) ---snip-- > > May I suggest reading the docs? ;-) > --- snip --- > The default value for N is the value specified for > `-fblas-matmul-limit' if this option is specified, or unlimitited > otherwise. Oh gosh!, Sorry about that Thomas. I just did not see it. And I was even looking for it because I thought it was there! This is excellent because I am working on a modification to the run-time libraries. This will give us something like: Matmul fixed Size Loops explicit NewMatmul 16 2000 1.496 1.719 32 2000 2.427 1.784 64 2000 1.343 1.967 128 2000 1.657 2.113 256 477 2.660 2.185 51259 2.027 2.195 1024 7 1.530 2.208 2048 1 1.516 2.210 On this particular machine, the inlining at high levels of optimization has some sweet spots at size of 32 x 32 for example, so allowing the tuning is essential depending on users application.
