[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117 --- Comment #20 from Markus Trippelsdorf --- I haven't seen this issue since Jason's GC related C++ patches went in: r230201 and r230202. But of course this may well be another statistical fluke.
[Bug tree-optimization/68198] [6 Regression]Excessive code size, compile time and memory usage bloat due to FSM threading in 453.povray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68198 --- Comment #6 from Jeffrey A. Law --- I see what's happening here (and boy it's much better to be debugging with real screens and a good night's sleep). So imagine what happens when you build a thread path and on that path you've got a block with a large switch statement. Say on the order of 1k unique destinations. Remember that we have to duplicate blocks on the thread path. For each block on the path we'll redirect *one* edge to the next block on the path, the remaining edges are copies from the original block and thus reach targets outside the thread path. Yup, given a thread path containing block with ~1k successors, we'll end up creating ~1k new edges for the duplicated block. Now imagine we do that a few hundred times (because the join block at the start of the thread path has hundreds of predecessors). Suddenly we're talking about tens of thousands of edges. That's what's happening here. In theory the old threader has the same problem, but it's just not strong enough to actually find enough paths to show the edge explosion. Fixing ought to be fairly easy...
[Bug libstdc++/68197] negative index to ios_base::iword lead to unpredictable result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68197 --- Comment #2 from Mickael Guene --- Anyway it's a bad usage since index must come from xalloc. I was unable to find what the specifications say in case of using a negative index (or invalid index), do you have some inputs in this case ?
[Bug tree-optimization/68327] New: ICE on valid code at -O3 on x86_64-linux-gnu in vect_is_simple_use, at tree-vect-stmts.c:8562
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68327
Bug ID: 68327
Summary: ICE on valid code at -O3 on x86_64-linux-gnu in
vect_is_simple_use, at tree-vect-stmts.c:8562
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
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
-O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes.
It is a regression from 5.2.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-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-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151112 (experimental) [trunk revision 230270] (GCC)
$
$ gcc-trunk -O2 -c small.c
$ gcc-5.2 -O3 -c small.c
$
$ gcc-trunk -O3 -c small.c
small.c: In function ‘fn1’:
small.c:5:1: internal compiler error: in vect_is_simple_use, at
tree-vect-stmts.c:8562
fn1 ()
^
0xd1c930 vect_is_simple_use(tree_node*, vec_info*, gimple**, vect_def_type*,
tree_node**)
../../gcc-trunk/gcc/tree-vect-stmts.c:8562
0x5a6d70 vect_determine_vectorization_factor
../../gcc-trunk/gcc/tree-vect-loop.c:612
0xd3f78d vect_analyze_loop_2
../../gcc-trunk/gcc/tree-vect-loop.c:1843
0xd3f78d vect_analyze_loop(loop*)
../../gcc-trunk/gcc/tree-vect-loop.c:2121
0xd5499f vectorize_loops()
../../gcc-trunk/gcc/tree-vectorizer.c:517
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.
$
int a, d;
char b, c;
void
fn1 ()
{
int i = 0;
for (; i < 1; i++)
d = 1;
for (; b; b++)
a = 1 && (d & b);
}
[Bug c/68311] gcc/ipa-icf.c:3041: possible sequence point error ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68311 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- In a list of initializers that's not a comma operator. So I think that's UB given the evaluations of the initialization list expressions are indeterminately sequenced.
[Bug tree-optimization/68326] ICE at -O3 on x86_64-linux-gnu in set_value_range, at tree-vrp.c:380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68326 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Markus Trippelsdorf --- dup. *** This bug has been marked as a duplicate of bug 68317 ***
[Bug tree-optimization/68317] [6 regression] ice in set_value_range, at tree-vrp.c:380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68317 Markus Trippelsdorf changed: What|Removed |Added CC||su at cs dot ucdavis.edu --- Comment #2 from Markus Trippelsdorf --- *** Bug 68326 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/68326] New: ICE at -O3 on x86_64-linux-gnu in set_value_range, at tree-vrp.c:380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68326
Bug ID: 68326
Summary: ICE at -O3 on x86_64-linux-gnu in set_value_range, at
tree-vrp.c:380
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
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
-O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes.
It is a regression from 5.2.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-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-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151112 (experimental) [trunk revision 230270] (GCC)
$
$ gcc-trunk -O2 -c small.c
small.c: In function ‘fn2’:
small.c:12:27: warning: iteration 2147483638 invokes undefined behavior
[-Waggressive-loop-optimizations]
for (e = -10; e; e--)
^
small.c:12:9: note: within this loop
for (e = -10; e; e--)
^
$ gcc-5.2 -O3 -c small.c
$ gcc-5.2 -O2 -c small.c
small.c: In function ‘fn2’:
small.c:12:27: warning: iteration 2147483638u invokes undefined behavior
[-Waggressive-loop-optimizations]
for (e = -10; e; e--)
^
small.c:12:9: note: containing loop
for (e = -10; e; e--)
^
$
$ gcc-trunk -O3 -c small.c
small.c: In function ‘fn2’:
small.c:6:1: internal compiler error: in set_value_range, at tree-vrp.c:380
fn2 ()
^
0xd5af36 set_value_range
../../gcc-trunk/gcc/tree-vrp.c:379
0xd6e5a1 adjust_range_with_scev
../../gcc-trunk/gcc/tree-vrp.c:4334
0xd6e5a1 vrp_visit_phi_node
../../gcc-trunk/gcc/tree-vrp.c:8853
0xc8f415 simulate_stmt
../../gcc-trunk/gcc/tree-ssa-propagate.c:327
0xc8f723 process_ssa_edge_worklist
../../gcc-trunk/gcc/tree-ssa-propagate.c:456
0xc90f2e ssa_propagate(ssa_prop_result (*)(gimple*, edge_def**, tree_node**),
ssa_prop_result (*)(gphi*))
../../gcc-trunk/gcc/tree-ssa-propagate.c:937
0xd6862c execute_vrp
../../gcc-trunk/gcc/tree-vrp.c:10315
0xd6862c execute
../../gcc-trunk/gcc/tree-vrp.c:10395
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.
$
-
int c, d, e, f, g, h;
short fn1 () { }
void
fn2 ()
{
unsigned int i = 4294967286;
if (g)
for (;;)
{
for (e = -10; e; e--)
for (h = 1; h; h = fn1 ())
{
if (f)
{
d = fn1 ();
if (d)
continue;
}
i = e;
}
break;
}
if (0)
;
c = i;
}
[Bug target/68293] [6 Regression] ICE: in prepare_cmp_insn, at optabs.c:3813 with vector compare with -O0 @ aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68293 --- Comment #7 from Zdenek Sojka --- At least for aarch64, this is fixed.
[Bug c/68311] gcc/ipa-icf.c:3041: possible sequence point error ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68311
--- Comment #1 from Andrew Pinski ---
Hmm, I though common inside {} are sequenced points.
[Bug c/68325] missing -Warray-bounds on a negative subscript into a flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68325 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-11-13 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- See also bug 67872. Working on a patch for both.
[Bug c/68325] New: missing -Warray-bounds on a negative subscript into a flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68325
Bug ID: 68325
Summary: missing -Warray-bounds on a negative subscript into a
flexible array member
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC issues a -Warray-bounds warning for negative subscripts into arrays of
non-zero size but fails to do the same for flexible array members, or "fake"
flexible array members (last array members of structs of any dimension). Since
GCC imposes a limit of SIZE_MAX / 2 on the size of any object it's safe to
assume that a negative subscript is invalid regardless of the number of
elements in the array, and array references with such indices should be
diagnosed.
$ cat z.c && gcc -DN=99 -O2 -S -Wall -Wextra -o/dev/null z.c
struct S {
int n;
int a[N];
} s;
int foo (void) {
return s.a [-__INT_MAX__];
}
int bar (struct S *p)
{
return p->a [-__INT_MAX__];
}
$
As a data point, Clang diagnoses negative subscripts into "fake" flexible array
members (those declared last, even with zero elements), but not those into C99
flexible array members.
$ clang -S -Wall -o/dev/null z.c -DN='0'
z.c:7:12: warning: array index -2147483647 is before the beginning of the array
[-Warray-bounds]
return s.a [-__INT_MAX__];
^
z.c:3:3: note: array 'a' declared here
int a[N];
^
z.c:12:12: warning: array index -2147483647 is before the beginning of the
array
[-Warray-bounds]
return p->a [-__INT_MAX__];
^
z.c:3:3: note: array 'a' declared here
int a[N];
^
2 warnings generated.
[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109 --- Comment #13 from David --- Rumor has it that Phase 1 may be closing soon. Is there something else I need to do here?
[Bug tree-optimization/68324] New: ICE on valid code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68324
Bug ID: 68324
Summary: ICE on valid code at -O3 on x86_64-linux-gnu
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
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
-O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes.
It is a regression from 5.2.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-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-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151112 (experimental) [trunk revision 230270] (GCC)
$
$ gcc-trunk -O2 -c small.c
$ gcc-5.2 -O3 -c small.c
$
$ gcc-trunk -O3 -c small.c
small.c: In function ‘fn1’:
small.c:4:1: internal compiler error: Segmentation fault
fn1 ()
^
0xaf782f crash_signal
../../gcc-trunk/gcc/toplev.c:336
0x12578a4 dr_misalignment(data_reference*)
../../gcc-trunk/gcc/tree-vectorizer.h:889
0x12578a4 aligned_access_p
../../gcc-trunk/gcc/tree-vectorizer.h:902
0x12578a4 vect_supportable_dr_alignment(data_reference*, bool)
../../gcc-trunk/gcc/tree-vect-data-refs.c:5863
0xd2a761 vectorizable_load
../../gcc-trunk/gcc/tree-vect-stmts.c:6706
0xd338d6 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
../../gcc-trunk/gcc/tree-vect-stmts.c:7997
0xd4b354 vect_schedule_slp_instance
../../gcc-trunk/gcc/tree-vect-slp.c:3468
0xd4b1a9 vect_schedule_slp_instance
../../gcc-trunk/gcc/tree-vect-slp.c:3349
0xd4cf46 vect_schedule_slp(vec_info*)
../../gcc-trunk/gcc/tree-vect-slp.c:3533
0xd505ec vect_slp_bb(basic_block_def*)
../../gcc-trunk/gcc/tree-vect-slp.c:2525
0xd52645 execute
../../gcc-trunk/gcc/tree-vectorizer.c:738
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.
$
-
int a[10], b, c, d;
void
fn1 ()
{
for (; b;)
for (d = 1; d < 5; d++)
for (c = 0; c < 2; c++)
a[c * 5 + d] = a[c];
}
[Bug driver/67613] spell suggestions for misspelled command line options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67613 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be implemented on trunk (for gcc 6) as r230285; resolving as fixed.
[Bug driver/67613] spell suggestions for misspelled command line options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67613 --- Comment #2 from David Malcolm --- Author: dmalcolm Date: Fri Nov 13 01:59:03 2015 New Revision: 230285 URL: https://gcc.gnu.org/viewcvs?rev=230285&root=gcc&view=rev Log: PR driver/67613 - spell suggestions for misspelled command line options gcc/ChangeLog: PR driver/67613 * Makefile.in (GCC_OBJS): Add spellcheck.o. (OBJS): Add spellcheck-tree.o. * gcc.c: Include "spellcheck.h". (suggest_option): New function. (driver::handle_unrecognized_options): Call suggest_option to provide a hint about misspelled options. * spellcheck.c: Update file comment. (levenshtein_distance): Convert 4-param implementation from static to extern scope. Remove note about unit tests from leading comment for const char * implementation. Move tree implementation to... * spellcheck-tree.c: New file. * spellcheck.h (levenshtein_distance): Add 4-param decl. gcc/testsuite/ChangeLog: PR driver/67613 * gcc/testsuite/gcc.dg/spellcheck-options-1.c: New file. * gcc/testsuite/gcc.dg/spellcheck-options-2.c: New file. Added: trunk/gcc/spellcheck-tree.c trunk/gcc/testsuite/gcc.dg/spellcheck-options-1.c trunk/gcc/testsuite/gcc.dg/spellcheck-options-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/gcc.c trunk/gcc/spellcheck.c trunk/gcc/spellcheck.h trunk/gcc/testsuite/ChangeLog
[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277 --- Comment #7 from Kazumoto Kojima --- (In reply to Kazumoto Kojima from comment #6) I've changed the predicate of the 2nd operand to arith_operand instead of const_int_operand in your patch and run testsuite. There is one new failure: FAIL: gfortran.dg/pr65450.f90 -O3 -g execution test which is Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Weird. I'm afraid that even my first patch makes wrong codes silently, though it doesn't fail for the above test.
[Bug fortran/68318] ICE on duplicate entry declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68318 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.3 --- Comment #6 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for the bug report.
[Bug fortran/68318] ICE on duplicate entry declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68318 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Nov 13 01:11:10 2015 New Revision: 230282 URL: https://gcc.gnu.org/viewcvs?rev=230282&root=gcc&view=rev Log: 2015-11-12 Steven G. Kargl PR fortran/68318 * decl.c (get_proc_name): Increment reference count for ENTRY. While here, fix comment and use postfix ++ for consistency. 2015-11-12 Steven G. Kargl PR fortran/68318 * gfortran.dg/pr68318_1.f90: New test. * gfortran.dg/pr68318_2.f90: Ditto. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr68318_1.f90 branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr68318_2.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/decl.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug libstdc++/68323] New: chrono reference to ‘literals’ namespace is ambiguous when using gnu-versioned-namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68323
Bug ID: 68323
Summary: chrono reference to ‘literals’ namespace is ambiguous
when using gnu-versioned-namespace
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dmorilha at gmail dot com
Target Milestone: ---
/home/y/lib/gcc/x86_64-redhat-linux/5.2.0/include/c++/chrono:873:19: error:
reference to ‘literals’ is ambiguous
using namespace literals::chrono_literals;
^
/home/y/lib/gcc/x86_64-redhat-linux/5.2.0/include/c++/chrono:788:3: note:
candidates are: namespace std::literals { }
{
^
In file included from
/home/y/lib/gcc/x86_64-redhat-linux/5.2.0/include/c++/string:52:0,
from
/home/y/lib/gcc/x86_64-redhat-linux/5.2.0/include/c++/random:40,
from
/home/y/lib/gcc/x86_64-redhat-linux/5.2.0/include/c++/bits/stl_algo.h:66,
from
/home/y/lib/gcc/x86_64-redhat-linux/5.2.0/include/c++/algorithm:62,
from logical.hpp:4,
from logical.cpp:1:
/home/y/lib/gcc/x86_64-redhat-linux/5.2.0/include/c++/bits/basic_string.h:5547:3:
note: namespace std::__7::literals { }
{
^
In file included from logical.hpp:5:0,
from logical.cpp:1:
/home/y/lib/gcc/x86_64-redhat-linux/5.2.0/include/c++/chrono:873:29: error:
‘chrono_literals’ is not a namespace-name
using namespace literals::chrono_literals;
^
/home/y/lib/gcc/x86_64-redhat-linux/5.2.0/include/c++/chrono:873:44: error:
expected namespace-name before ‘;’ token
using namespace literals::chrono_literals;
^
make[1]: *** [rhel.6.4.M64.gcov/logical.o] Error 1
make[1]: Leaving directory `/home/dmorilha/src/ats-galileo/src'
make: *** [gcov] Error 2
[Bug libfortran/68115] [6 Regression] Unsatisfied symbol "__sync_lock_test_and_set_4" in file /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgomp/../libgfortran/.libs/libgfortran.sl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68115
John David Anglin changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #3 from John David Anglin ---
The problem comes from the configure command used to build libbacktrace:
$ /test/gnu/gcc/gcc/libbacktrace/configure --srcdir=../../../gcc/libbacktrace
--cache-file=./config.cache --enable-multilib --with-gnu-as
--with-as=/opt/gnu64/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared
--with-local-prefix=/opt/gnu64 --prefix=/opt/gnu64/gcc/gcc-6
--enable-threads=posix --with-gmp=/opt/gnu64/gcc/gmp --enable-checking=release
--enable-languages=c,c++,fortran,lto,objc,obj-c++
--program-transform-name=s,y,y, --disable-option-checking
--with-target-subdir=hppa64-hp-hpux11.11 --build=hppa64-hp-hpux11.11
--host=hppa64-hp-hpux11.11 --target=hppa64-hp-hpux11.11
The --with-target-subdir option overrides the configure test for __sync
support:
# Test for __sync support.
AC_CACHE_CHECK([__sync extensions],
[libbacktrace_cv_sys_sync],
[if test -n "${with_target_subdir}"; then
libbacktrace_cv_sys_sync=yes
else
AC_LINK_IFELSE(
[AC_LANG_PROGRAM([int i;],
[__sync_bool_compare_and_swap (&i, i, i);
__sync_lock_test_and_set (&i, 1);
__sync_lock_release (&i);])],
[libbacktrace_cv_sys_sync=yes],
[libbacktrace_cv_sys_sync=no])
fi])
BACKTRACE_SUPPORTS_THREADS=0
if test "$libbacktrace_cv_sys_sync" = "yes"; then
BACKTRACE_SUPPORTS_THREADS=1
AC_DEFINE([HAVE_SYNC_FUNCTIONS], 1,
[Define to 1 if you have the __sync functions])
fi
AC_SUBST(BACKTRACE_SUPPORTS_THREADS)
Probably introduced by:
2015-08-23 Francois-Xavier Coudert
PR libfortran/54572
* Makefile.def: Make libgfortran depend on libbacktrace.
* Makefile.in: Regenerate.
Guess following would fix:
case "${host}" in
hppa*-*-hpux*) libbacktrace_cv_sys_sync=no ;;
*) libbacktrace_cv_sys_sync=yes ;;
esac
Still it would seem test could be done on a native build.
[Bug lto/68322] New: -Wodr warning on templates should list the instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68322 Bug ID: 68322 Summary: -Wodr warning on templates should list the instantiation Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: thiago at kde dot org Target Milestone: --- When compiling a certain part of Qt, I get: qshareddata.h:129:26: warning: type ‘struct QExplicitlySharedDataPointer’ violates one definition rule [-Wodr] template class QExplicitlySharedDataPointer ^ qshareddata.h:129:26: note: a different type is defined in another translation unit qshareddata.h:215:8: note: the first difference of corresponding definitions is field ‘d’ T *d; ^ The warning itself is bogus (probably bug 66180), but regardless of that, the warning output should list which instantiation of the template class the compiler is talking about.
[Bug fortran/68319] ICE on using interface with included entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68319 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-13 CC||kargl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from kargl at gcc dot gnu.org --- It seems that gfortran is missing a check for ENTRY. F2008 has C1206 (R1205) An interface-body shall not contain a data-stmt, format-stmt, entry-stmt, or stmt-function-stmt.
[Bug fortran/68318] ICE on duplicate entry declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68318 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Nov 13 00:14:32 2015 New Revision: 230278 URL: https://gcc.gnu.org/viewcvs?rev=230278&root=gcc&view=rev Log: 2015-11-12 Steven G. Kargl PR fortran/68318 * decl.c (get_proc_name): Increment reference count for ENTRY. While here, fix comment and use postfix ++ for consistency. 2015-11-12 Steven G. Kargl PR fortran/68318 * gfortran.dg/pr68318_1.f90: New test. * gfortran.dg/pr68318_2.f90: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/pr68318_1.f90 trunk/gcc/testsuite/gfortran.dg/pr68318_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c/67872] missing -Warray-bounds warning, bogus -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67872 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug fortran/68318] ICE on duplicate entry declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68318 kargl at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- I have a patch.
[Bug rtl-optimization/68269] [5/6 regression] FAIL: gcc.dg/pr68129_1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68269 Gary Funck changed: What|Removed |Added CC||gary at intrepid dot com --- Comment #2 from Gary Funck --- We're seeing a similar failure (on IA64) while trying to build the compiler, at -O3 (--with-build-config=bootstrap-O3). /eng/upc/dev/gary/gupc-dev/bld/gupc/./prev-gcc/xg++ -B/eng/upc/dev/gary/gupc-de v/bld/gupc/./prev-gcc/ -B/eng/upc/dev/gary/gupc-dev/rls/gupc/ia64-unknown-linux -gnu/bin/ -nostdinc++ -B/eng/upc/dev/gary/gupc-dev/bld/gupc/prev-ia64-unknown-l inux-gnu/libstdc++-v3/src/.libs -B/eng/upc/dev/gary/gupc-dev/bld/gupc/prev-ia64 -unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/eng/upc/dev/gary/gupc-dev/b ld/gupc/prev-ia64-unknown-linux-gnu/libstdc++-v3/include/ia64-unknown-linux-gnu -I/eng/upc/dev/gary/gupc-dev/bld/gupc/prev-ia64-unknown-linux-gnu/libstdc++-v 3/include -I/eng/upc/dev/gary/gupc-dev/src/gupc/libstdc++-v3/libsupc++ -L/eng/ upc/dev/gary/gupc-dev/bld/gupc/prev-ia64-unknown-linux-gnu/libstdc++-v3/src/.li bs -L/eng/upc/dev/gary/gupc-dev/bld/gupc/prev-ia64-unknown-linux-gnu/libstdc++- v3/libsupc++/.libs -c -DUSE_LIBUNWIND_EXCEPTIONS -O3 -g -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloade d-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I/eng/upc/ dev/gary/gupc-dev/src/gupc/gcc -I/eng/upc/dev/gary/gupc-dev/src/gupc/gcc/build -I/eng/upc/dev/gary/gupc-dev/src/gupc/gcc/../include -I/eng/upc/dev/gary/gupc- dev/src/gupc/gcc/../libcpp/include \ -o build/genmodes.o /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/gen modes.c /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/genmodes.c: In function 'void calc_wide r_mode()': /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/genmodes.c:895:1: internal compiler err or: in decompose, at rtl.h:2107 } ^ 0x4122b73f wi::int_traits >::decompos e(long*, unsigned int, std::pair const&) /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/rtl.h:2105 0x4122b73f wi::int_traits >::decompos e(long*, unsigned int, std::pair const&) /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/rtl.h:2105 0x4200166f simplify_const_binary_operation(rtx_code, machine_mode, rtx_ def*, rtx_def*) /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/simplify-rtx.c:3955 0x41fe42cf simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*) /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/simplify-rtx.c:1990 0x41ffc99f simplify_const_binary_operation(rtx_code, machine_mode, rtx_ def*, rtx_def*) /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/simplify-rtx.c:3764 0x41fe42cf simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*) /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/simplify-rtx.c:1990 0x4330d2ef fold_rtx /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/cse.c:3730 0x43314b6f cse_insn /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/cse.c:4632 0x433285cf cse_extended_basic_block /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/cse.c:6528 0x43329a6f cse_main /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/cse.c:6702 0x43330e3f rest_of_handle_cse /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/cse.c:7522 0x4333122f execute /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/cse.c:7565
[Bug c++/68290] g++.dg/concepts/auto1.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68290 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- Investigating.
[Bug c++/68290] g++.dg/concepts/auto1.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68290 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-12 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- I have it too.
[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67239
--- Comment #10 from H.J. Lu ---
(In reply to Richard Biener from comment #7)
> No, even for the false edge we can record proper expressions, see
> record_conds and how it handles the cases if the condition was true or false.
>
record_conds inserted many temporary expressions with both TRUE and FALSE
values. But
/* If that didn't simplify to a constant see if we have recorded
temporary expressions from taken edges. */
if (!val || TREE_CODE (val) != INTEGER_CST)
{
tree ops[2];
ops[0] = lhs;
ops[1] = rhs;
val = vn_nary_op_lookup_pieces (2, gimple_cond_code (stmt),
boolean_type_node, ops, NULL);
}
only lookups and uses one value.
[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117 --- Comment #19 from Gary Funck --- We see similar failure an x86-64 opensuse VM in the 32-bit libgfortran build but on a different file: eoshift.c. After removing the .lo and .o files and re-running make, the build completed without error. As described in earlier comments, this issue is not easily reproducible.
[Bug middle-end/67220] GCC fails to properly handle libcall symbol visibility of built functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67220 H.J. Lu changed: What|Removed |Added Attachment #36697|0 |1 is obsolete|| --- Comment #3 from H.J. Lu --- Comment on attachment 36697 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36697 tree dump Wrong bug.
[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67239 --- Comment #9 from H.J. Lu --- Created attachment 36699 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36699&action=edit tree dump It is compiled with -O2 -mx32.
[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117 --- Comment #18 from Gary Funck --- (In reply to Gary Funck from comment #17) > We're seeing this ICE on x86-64, while building the 32-bit libgfortran. > We're building the target libraries with -O3 with GCC compiler checks > enabled. Taking garbage collection out of the picture by adding --param ggc-min-heapsize=10 to the command line led to a successful compilation.
[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117 --- Comment #17 from Gary Funck --- We're seeing this ICE on x86-64, while building the 32-bit libgfortran. We're building the target libraries with -O3 with GCC compiler checks enabled. libtool: compile: /eng/upc/dev/gary/gupc-dev/bld/gupc/./gcc/xgcc -B/eng/upc/de v/gary/gupc-dev/bld/gupc/./gcc/ -B/eng/upc/dev/gary/gupc-dev/rls/gupc/x86_64-pc -linux-gnu/bin/ -B/eng/upc/dev/gary/gupc-dev/rls/gupc/x86_64-pc-linux-gnu/lib/ -isystem /eng/upc/dev/gary/gupc-dev/rls/gupc/x86_64-pc-linux-gnu/include -isyst em /eng/upc/dev/gary/gupc-dev/rls/gupc/x86_64-pc-linux-gnu/sys-include -DHAVE_C ONFIG_H -I. -I/eng/upc/dev/gary/gupc-dev/src/gupc/libgfortran -iquote/eng/upc/d ev/gary/gupc-dev/src/gupc/libgfortran/io -I/eng/upc/dev/gary/gupc-dev/src/gupc/ libgfortran/../gcc -I/eng/upc/dev/gary/gupc-dev/src/gupc/libgfortran/../gcc/con fig -I/eng/upc/dev/gary/gupc-dev/src/gupc/libgfortran/../libquadmath -I../../.. /./gcc -I/eng/upc/dev/gary/gupc-dev/src/gupc/libgfortran/../libgcc -I../../libg cc -I/eng/upc/dev/gary/gupc-dev/src/gupc/libgfortran/../libbacktrace -I../../li bbacktrace -I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-pro totypes -Wold-style-definition -Wextra -Wwrite-strings -Werror=implicit-functio n-declaration -Werror=vla -fcx-fortran-rules -ffunction-sections -fdata-section s -g3 -O3 -m32 -MT write.lo -MD -MP -MF .deps/write.Tpo -c /eng/upc/dev/gary/gu pc-dev/src/gupc/libgfortran/io/write.c -o write.o >/dev/null 2>&1 make[6]: *** [write.lo] Error 1 make[6]: Leaving directory `/eng/upc/dev/gary/gupc-dev/bld/gupc/x86_64-pc-linux -gnu/32/libgfortran' Above, that make step sends output /dev/null. Running the same command by hand, yields: /eng/upc/dev/gary/gupc-dev/src/gupc/libgfortran/io/write.c: In function ‘write_a’: /eng/upc/dev/gary/gupc-dev/src/gupc/libgfortran/io/write.c:232:1: error: invalid PHI argument write_a (st_parameter_dt *dtp, const fnode *f, const char *source, int len) ^ <<< Unknown tree: >>> /eng/upc/dev/gary/gupc-dev/src/gupc/libgfortran/io/write.c:232:1: internal compiler error: tree check: expected tree that contains ‘typed’ structure, have ‘’ in verify_gimple_phi, at tree-cfg.c:4658 0xe4fbe4 tree_contains_struct_check_failed(tree_node const*, tree_node_structure_enum, char const*, int, char const*) /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/tree.c:9839 0xbf13bc contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/tree.h:3173 0xbf13bc verify_gimple_phi /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/tree-cfg.c:4658 0xbf13bc verify_gimple_in_cfg(function*, bool) /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/tree-cfg.c:4952 0xab36f7 execute_function_todo /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/passes.c:1945 0xab4b7a do_per_function /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/passes.c:1632 0xab4b7a execute_todo /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/passes.c:2000
[Bug c/67784] Incorrect parsing when using declarations in for loops and typedefs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67784 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Marek Polacek --- Fixed.
[Bug c/67784] Incorrect parsing when using declarations in for loops and typedefs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67784 --- Comment #7 from Marek Polacek --- Author: mpolacek Date: Thu Nov 12 21:07:04 2015 New Revision: 230273 URL: https://gcc.gnu.org/viewcvs?rev=230273&root=gcc&view=rev Log: PR c/67784 * c-parser.c (c_parser_for_statement): Reclassify the token in a correct scope. * gcc.dg/pr67784-1.c: New test. * gcc.dg/pr67784-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr67784-1.c trunk/gcc/testsuite/gcc.dg/pr67784-2.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/testsuite/ChangeLog
[Bug c/68162] [5/6 Regression] Incompatible pointer type using a typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68162 --- Comment #10 from Joseph S. Myers --- I have verified that the patch in comment#7, (a) on its own and (b) together with my patch, does not cause any regressions on x86_64-pc-linux-gnu. My inclination would be that this patch should go in, with a separate issue being filed in Bugzilla for the extra qualifiers, and then I can put my patch in.
[Bug middle-end/68292] [6 regression] ICE in copy_blkmode_to_reg, at expr.c:2277
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68292 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- Investigating.
[Bug middle-end/68292] [6 regression] ICE in copy_blkmode_to_reg, at expr.c:2277
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68292 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-12 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- I have them too and it's before r230098.
[Bug fortran/68318] ICE on duplicate entry declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68318 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-12 CC||kargl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from kargl at gcc dot gnu.org --- Seems that in the case of errors, the clean up of the ref count is off by one.
[Bug rtl-optimization/68321] New: wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68321
Bug ID: 68321
Summary: wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The current gcc trunk (as well as 5.1.x and 5.2.x) miscompiles the following
code on x86_64-linux-gnu at -O3 in the 64-bit mode (but not in the 32-bit
mode).
This is a regression from 4.9.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-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-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 2015 (experimental) [trunk revision 230161] (GCC)
$
$ gcc-trunk -m64 -O2 small.c; ./a.out
$ gcc-trunk -m32 -O3 small.c; ./a.out
$ gcc-4.9 -m64 -O3 small.c; ./a.out
$
$ gcc-trunk -m64 -O3 small.c
$ ./a.out
Aborted (core dumped)
$
$ cat small.c
int e = 1, u = 5, t2, t5, i, k;
int a[1], b, m;
char n, t;
int
fn1 (int p1)
{
int g[1];
for (;;)
{
if (p1 / 3)
for (; t5;)
u || n;
t2 = p1 & 4;
if (b + 1)
return 0;
u = g[0];
}
}
int
main ()
{
for (; e >= 0; e--)
{
char c;
if (!m)
c = t;
fn1 (c);
}
if (a[t2] != 0)
__builtin_abort ();
return 0;
}
[Bug c/68320] New: internal compiler error: in declspecs_add_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68320
Bug ID: 68320
Summary: internal compiler error: in declspecs_add_type
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
As promised in PR67784:
void
h ()
{
for (typedef int T;;)
if (1)
;
T *x;
x = 0;
}
$ ./cc1 -quiet tt.c
tt.c: In function ‘h’:
tt.c:4:3: error: declaration of non-variable ‘T’ in ‘for’ loop initial
declaration
for (typedef int T;;)
^
tt.c:7:3: internal compiler error: Segmentation fault
T *x;
^
0xce9826 crash_signal
/home/marek/src/gcc/gcc/toplev.c:336
0x6aca7c declspecs_add_type(unsigned int, c_declspecs*, c_typespec)
/home/marek/src/gcc/gcc/c/c-decl.c:9539
0x701ae0 c_parser_declspecs
/home/marek/src/gcc/gcc/c/c-parser.c:2315
0x6ffe99 c_parser_declaration_or_fndef
/home/marek/src/gcc/gcc/c/c-parser.c:1560
0x706670 c_parser_compound_statement_nostart
/home/marek/src/gcc/gcc/c/c-parser.c:4655
0x7062cf c_parser_compound_statement
/home/marek/src/gcc/gcc/c/c-parser.c:4566
0x701139 c_parser_declaration_or_fndef
/home/marek/src/gcc/gcc/c/c-parser.c:1987
0x6ffc23 c_parser_external_declaration
/home/marek/src/gcc/gcc/c/c-parser.c:1431
0x6ff82b c_parser_translation_unit
/home/marek/src/gcc/gcc/c/c-parser.c:1318
0x72f99d c_parse_file()
/home/marek/src/gcc/gcc/c/c-parser.c:17360
0x799abb c_common_parse_file()
/home/marek/src/gcc/gcc/c-family/c-opts.c:1062
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug c/68320] internal compiler error: in declspecs_add_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68320 Marek Polacek changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-11-12 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1
[Bug c/67784] Incorrect parsing when using declarations in for loops and typedefs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67784
--- Comment #6 from Marek Polacek ---
And another that seems to be caused by something else and isn't fixed by my
patch:
void
h ()
{
for (typedef int T;;)
if (1)
;
T *x;
x = 0;
}
I'm opening a separate PR for this one.
[Bug c/67784] Incorrect parsing when using declarations in for loops and typedefs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67784
--- Comment #5 from Marek Polacek ---
Note that I've found an ICE-on-invalid:
void
h ()
{
int T;
for (typedef int T;;)
if (1)
;
T *x;
}
[Bug fortran/68319] ICE on using interface with included entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68319 --- Comment #1 from Gerhard Steinmetz --- Same issue with interface of a function. Compiles if interface is effectivly not used : $ cat z1x.f90 module m interface subroutine s entry e end end interface contains subroutine g end end $ gfortran -g -O0 -Wall -fcheck=all -c z1x.f90
[Bug fortran/68319] New: ICE on using interface with included entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68319 Bug ID: 68319 Summary: ICE on using interface with included entry Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- An interface declaration with an included entry : $ cat z1.f90 module m interface subroutine s entry e end end interface contains subroutine g call s end end $ gfortran -g -O0 -Wall -fcheck=all -c z1.f90 z1.f90:9:0: call s 1 internal compiler error: in gfc_get_extern_function_decl, at fortran/trans-decl.c:1776
[Bug c++/68316] GCC C++ compiler cannot compile a program using RDESED intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68316 --- Comment #4 from Jonathan Wakely --- The documentation Marc referred to doesn't say anything about which header to use. If you followed what it says in the #error you quoted it would have worked.
[Bug fortran/68318] ICE on duplicate entry declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68318 --- Comment #1 from Gerhard Steinmetz --- Somehow similar for functions : $ cat z3.f90 module m contains real function f1() entry e() end real function f2() entry e() end end module $ gfortran -g -O0 -Wall -fcheck=all -c z3.f90 z3.f90:7.10: entry e() 1 z3.f90:4.10: entry e() 2 Error: Procedure 'e' at (1) is already defined at (2) f951: internal compiler error: in gfc_release_symbol, at fortran/symbol.c:2591 --- And interestingly, detected with explicit declaration of e : $ cat z4.f90 module m implicit none contains real function f1() real :: e entry e() end real function f2() real :: e entry e() end end module $ gfortran -g -O0 -Wall -fcheck=all -c z4.f90 z4.f90:10.10: entry e() 1 z4.f90:5.15: real :: e 2 Error: Procedure 'e' at (1) is already defined at (2)
[Bug fortran/68318] New: ICE on duplicate entry declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68318 Bug ID: 68318 Summary: ICE on duplicate entry declarations Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- With duplicate entry declarations in scope : $ cat z1.f90 module m implicit none contains subroutine s1 entry e end subroutine s2 entry e end end module $ gfortran -g -O0 -Wall -fcheck=all -c z1.f90 z1.f90:8.10: entry e 1 z1.f90:5.10: entry e 2 Error: Procedure 'e' at (1) is already defined at (2) f951: internal compiler error: in gfc_release_symbol, at fortran/symbol.c:2591 --- $ cat z7.f90 module m1 implicit none contains subroutine s1 entry e end end module module m2 use m1 implicit none contains subroutine s2 entry e end end module $ gfortran -g -O0 -Wall -fcheck=all -c z7.f90 z7.f90:14.10: entry e 1 z7.f90:10.7: use m1 2 Error: Procedure 'e' at (1) is already defined at (2) f951: internal compiler error: in gfc_release_symbol, at fortran/symbol.c:2591
[Bug c++/68316] GCC C++ compiler cannot compile a program using RDESED intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68316 --- Comment #3 from Jeffrey Walton --- (In reply to Jonathan Wakely from comment #1) > As the comment says, you need to include not OK, thanks. Here we were told to follow Intels docs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68081. We had to go grepping when that did not work. Its very frustrating to determine what we should be doing when the rules become a moving target. Perhaps GCC could document some of this to remove the confusion and ambiguity.
[Bug tree-optimization/68317] [6 regression] ice in set_value_range, at tree-vrp.c:380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68317
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-11-12
CC||trippels at gcc dot gnu.org
Component|c |tree-optimization
Summary|ice in set_value_range, at |[6 regression] ice in
|tree-vrp.c:380 |set_value_range, at
||tree-vrp.c:380
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf ---
markus@x4 tmp % cat bug243.c
extern int fn2(int);
void fn1() {
int i = 7;
for (;; i--)
fn2((8184 + i) * 524288);
}
markus@x4 tmp % gcc -c -O2 bug243.c
bug243.c: In function ‘fn1’:
bug243.c:2:6: internal compiler error: in set_value_range, at tree-vrp.c:380
[Bug c/68317] New: ice in set_value_range, at tree-vrp.c:380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68317 Bug ID: 68317 Summary: ice in set_value_range, at tree-vrp.c:380 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 36698 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36698&action=edit C source code I just tried to compile the attached code with gcc trunk dated 20151112 and the compiler flag -O2 and the compiler said ../results/bin/gcc -c -O2 bug243.c chipset_enable.c: In function ‘enable_flash_ich_fwh_decode’: chipset_enable.c:380:12: internal compiler error: in set_value_range, at tree-vrp.c:380 0xddf4b0 set_value_range ../../src/trunk/gcc/tree-vrp.c:379 0xdf2d1f adjust_range_with_scev ../../src/trunk/gcc/tree-vrp.c:4334 0xdf2d1f vrp_visit_phi_node ../../src/trunk/gcc/tree-vrp.c:8853 0xd05d0d simulate_stmt ../../src/trunk/gcc/tree-ssa-propagate.c:327 0xd0604f process_ssa_edge_worklist ../../src/trunk/gcc/tree-ssa-propagate.c:456 0xd07655 ssa_propagate(ssa_prop_result (*)(gimple*, edge_def**, tree_node**), ssa_prop_result (*)(gphi*)) ../../src/trunk/gcc/tree-ssa-propagate.c:937 0xded7b4 execute_vrp ../../src/trunk/gcc/tree-vrp.c:10315 0xded7b4 execute ../../src/trunk/gcc/tree-vrp.c:10395 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.
[Bug c++/68316] GCC C++ compiler cannot compile a program using RDESED intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68316
--- Comment #2 from Jonathan Wakely ---
(In reply to Jeffrey Walton from comment #0)
> Adding a __has_include to guard appears to open another can of
> worms:
>
> $ g++ -mrdseed rdseed.cxx -o rdseed.exe
> rdseed.cxx:4:45: error: missing binary operator before token "("
> #if defined(__has_include) && (__has_include())
> ^
This is because you're using GCC 4.8 which doesn't support __has_include, and
you're using it wrong. It should be:
#ifdef __has_include
# if __has_include()
# include
# endif
#endif
If you don't put the __has_include on the same line as the test for it then it
works correctly.
[Bug middle-end/68291] [6 regression] ICE in emit_move_insn, at expr.c:3540
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68291 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #4 from Eric Botcazou --- Investigating.
[Bug middle-end/68291] [6 regression] ICE in emit_move_insn, at expr.c:3540
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68291 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-12 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Eric Botcazou --- I have them too and it's before r230098.
[Bug c++/68316] GCC C++ compiler cannot compile a program using RDESED intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68316 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- As the comment says, you need to include not
[Bug libstdc++/56158] bad enum values computed by operator~ in ios_base.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158 --- Comment #15 from Jonathan Wakely --- Fixed on trunk, probably worth backporting.
[Bug libstdc++/56158] bad enum values computed by operator~ in ios_base.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158 --- Comment #14 from Jonathan Wakely --- Author: redi Date: Thu Nov 12 17:08:42 2015 New Revision: 230267 URL: https://gcc.gnu.org/viewcvs?rev=230267&root=gcc&view=rev Log: Extend valid values of iostream bitmask types PR libstdc++/56158 * include/bits/ios_base.h (_Ios_Fmtflags, _Ios_Openmode, _Ios_Iostate): Define enumerators to ensure all values of type int are valid values of the enumeration type. * testsuite/27_io/ios_base/types/fmtflags/case_label.cc: Add new cases. * testsuite/27_io/ios_base/types/iostate/case_label.cc: Likewise. * testsuite/27_io/ios_base/types/openmode/case_label.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/ios_base.h trunk/libstdc++-v3/testsuite/27_io/ios_base/types/fmtflags/case_label.cc trunk/libstdc++-v3/testsuite/27_io/ios_base/types/iostate/case_label.cc trunk/libstdc++-v3/testsuite/27_io/ios_base/types/openmode/case_label.cc
[Bug c++/68312] [6 Regression] Memory leaks in cilkplus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68312 --- Comment #2 from Martin Liška --- One another: algrind --leak-check=yes --num-callers=100 --trace-children=yes --suppressions=/home/marxin/Programming/gcc2/gcc.supp --error-exitcode=111 -q /home/marxin/Programming/gcc2/objdir/gcc/xgcc -B/home/marxin/Programming/gcc2/objdir/gcc/ /home/marxin/Programming/gcc2/gcc/testsuite/c-c++-common/cilk-plus/CK/spawner_inline.c -B/home/marxin/Programming/gcc2/objdir/x86_64-pc-linux-gnu/./libcilkrts/ -L/home/marxin/Programming/gcc2/objdir/x86_64-pc-linux-gnu/./libcilkrts/.libs -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -ftree-vectorize -fcilkplus -lcilkrts -lm -o ./spawner_inline.exe ==20990== 8 bytes in 1 blocks are definitely lost in loss record 7 of 1,100 ==20990==at 0x4C2A00F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==20990==by 0x1162FE7: xmalloc (xmalloc.c:148) ==20990==by 0x6A1A76: gimplify_cilk_spawn(tree_node**) (cilk.c:810) ==20990==by 0x830057: gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) (gimplify.c:9561) ==20990==by 0x833646: gimplify_stmt(tree_node**, gimple**) (gimplify.c:5559) ==20990==by 0x8317F3: gimplify_statement_list (gimplify.c:1481) ==20990==by 0x8317F3: gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) (gimplify.c:10069) ==20990==by 0x833646: gimplify_stmt(tree_node**, gimple**) (gimplify.c:5559) ==20990==by 0x831906: gimplify_and_add (gimplify.c:416) ==20990==by 0x831906: gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) (gimplify.c:9991) ==20990==by 0x833646: gimplify_stmt(tree_node**, gimple**) (gimplify.c:5559) ==20990==by 0x8317F3: gimplify_statement_list (gimplify.c:1481) ==20990==by 0x8317F3: gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) (gimplify.c:10069) ==20990==by 0x833646: gimplify_stmt(tree_node**, gimple**) (gimplify.c:5559) ==20990==by 0x83403D: gimplify_bind_expr(tree_node**, gimple**) (gimplify.c:1130) ==20990==by 0x83081D: gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) (gimplify.c:9851) ==20990==by 0x833646: gimplify_stmt(tree_node**, gimple**) (gimplify.c:5559) ==20990==by 0x83B29A: gimplify_body(tree_node*, bool) (gimplify.c:10783) ==20990==by 0x83B5E7: gimplify_function_tree(tree_node*) (gimplify.c:10939) ==20990==by 0x70E6D7: cgraph_node::analyze() (cgraphunit.c:623) ==20990==by 0x711027: analyze_functions(bool) (cgraphunit.c:1078) ==20990==by 0x711A9C: symbol_table::finalize_compilation_unit() (cgraphunit.c:2518) ==20990==by 0xA1E4AF: compile_file() (toplev.c:491) ==20990==by 0x5F3445: do_compile (toplev.c:1954) ==20990==by 0x5F3445: toplev::main(int, char**) (toplev.c:2061) ==20990==by 0x10F5CDD: main (main.c:39) ==20990== Thanks, Martin
[Bug c++/68316] New: GCC C++ compiler cannot compile a program using RDESED intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68316
Bug ID: 68316
Summary: GCC C++ compiler cannot compile a program using RDESED
intrinsics
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
According the Intel docs, RDSEED intrinsics are available in .
Confer,
http://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=rdseed.
However, GCC cannot compile a program using RDSEED and the advertised header.
The same program compiles fine using RDRAND.
It appears the header needed (in this case) is , which does not
appear to be documented anywhere other than this grep:
$ grep -R rdseed /usr/include
/usr/include/clang/3.4/include/rdseedintrin.h:#error "Never use
directly; include instead."
^
This affects GCC 4.8 and 5.2, perhaps more.
**
$ cat rdseed.cxx
#include
#include
int main()
{
unsigned long long val = 0;
_rdseed64_step(&val);
_rdseed32_step(&val);
_rdseed16_step(&val);
std::cout << val << std::endl;
return !val;
}
$ g++ -mrdseed rdseed.cxx -o rdseed.exe
rdseed.cxx: In function ‘int main()’:
rdseed.cxx:7:22: error: ‘_rdseed64_step’ was not declared in this scope
_rdseed64_step(&val);
^
rdseed.cxx:8:22: error: ‘_rdseed32_step’ was not declared in this scope
_rdseed32_step(&val);
^
rdseed.cxx:9:22: error: ‘_rdseed16_step’ was not declared in this scope
_rdseed16_step(&val);
^
**
$ g++ --version
g++ (Debian 5.2.1-20) 5.2.1 20151002
$ g++ --version
g++ (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4
**
Adding a __has_include to guard appears to open another can of
worms:
$ g++ -mrdseed rdseed.cxx -o rdseed.exe
rdseed.cxx:4:45: error: missing binary operator before token "("
#if defined(__has_include) && (__has_include())
^
[Bug c++/68313] "using" shadows declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68313 wd11 at leicester dot ac.uk changed: What|Removed |Added Version|unknown |5.1.0 --- Comment #2 from wd11 at leicester dot ac.uk --- Johannes, regarding the case with nested classes (in analogy to the second code snippet), void f() and void f(X) don't have the same type (signature, or what is referred to with 'type of a function' here), so the program would still be okay. > What happens if you use unqualified names, i.e. if you declare the explicit > instantiation directly in namespace N2? I presume you refer to the first code snippet: same error > And what happens if you use a "<>" to try and explicitly refer to the > template? no error in either code snippet.
[Bug c/67784] Incorrect parsing when using declarations in for loops and typedefs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67784 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 --- Comment #4 from Marek Polacek --- Thanks. I think I've a fix now.
[Bug ipa/68035] [5/6 Regression] ipa performance issue when no procedures are present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68035 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Liška --- Fixed.
[Bug ipa/68035] [5/6 Regression] ipa performance issue when no procedures are present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68035 --- Comment #4 from Martin Liška --- Author: marxin Date: Thu Nov 12 15:16:00 2015 New Revision: 230263 URL: https://gcc.gnu.org/viewcvs?rev=230263&root=gcc&view=rev Log: Fix PR ipa/68035 PR ipa/68035 * ipa-icf.c (void sem_item::set_hash): New function. (sem_function::get_hash): Use renamed m_hash member variable. (sem_item::update_hash_by_addr_refs): Utilize get_hash. (sem_item::update_hash_by_local_refs): Likewise. (sem_variable::get_hash): Use renamed m_hash member variable. (sem_item_optimizer::update_hash_by_addr_refs): Utilize get_hash. (sem_item_optimizer::build_hash_based_classes): Utilize set_hash. (sem_item_optimizer::build_graph): As the hash value of an item is lazy initialized, force the calculation. * ipa-icf.h (set_hash): Declare new function and rename hash member variable to m_hash. * gcc.dg/ipa/pr68035.c: New test. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-icf.c trunk/gcc/ipa-icf.h trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/68315] New: ivdep has no effect in parloops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68315
Bug ID: 68315
Summary: ivdep has no effect in parloops
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider testcase ivdep.c:
...
void
foo (int n, int *a, int *b, int *c)
{
int i, j;
#pragma GCC ivdep
for (i = 0; i < n; ++i)
a[i] = b[i] + c[i];
}
...
When compiling it with autopar on:
...
$ gcc -O2 -ftree-parallelize-loops=2 -fdump-tree-all-details ivdep.c -S
...
We find in the dump-file:
...
FAILED: data dependencies exist across iterations
...
Although the definition of the pragma is in terms of SIMD:
...
With this pragma, the programmer asserts that there are no loop-carried
dependencies which would prevent consecutive iterations of the following loop
from executing concurrently with SIMD (single instruction multiple data)
instructions.
...
I'd say the no loop-carried dependencies bit means that we can use it for
autopar.
[Bug c++/68313] "using" shadows declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68313 Johannes Schaub changed: What|Removed |Added CC||schaub.johannes@googlemail. ||com --- Comment #1 from Johannes Schaub --- If instead of namespaces you would have used a class, and class N1 would be a baseclass of N2, your code would be ill-formed to the letter of the Standard: "A non-template member function ([dcl.fct]) with a given name and type and a member function template of the same name, which could be used to generate a specialization of the same type, can both be declared in a class. When both exist, a use of that name and type refers to the non-template member unless an explicit template argument list is supplied." What happens if you use unqualified names, i.e. if you declare the explicit instantiation directly in namespace N2. And what happens if you use a "<>" to try and explicitly refer to the template? Just as a question of interest.
[Bug tree-optimization/68306] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5651
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68306
Markus Trippelsdorf changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #7 from Markus Trippelsdorf ---
(In reply to Richard Biener from comment #6)
> Fixed.
Unfortunately, no.
trippels@gcc2-power8 linux % cat ucm.i
extern void fn2();
struct {
unsigned qp_num;
unsigned starting_psn;
void *private_data;
} a;
struct {
unsigned id;
unsigned qpn;
unsigned psn;
} b;
void fn1() {
a.qp_num = b.qpn;
a.starting_psn = b.psn;
fn2(b.id);
}
trippels@gcc2-power8 linux % gcc -mno-altivec -mno-vsx -O3 -c ucm.i
ucm.i: In function ‘fn1’:
ucm.i:12:6: internal compiler error: in vectorizable_load, at
tree-vect-stmts.c:6707
void fn1() {
^
[Bug middle-end/68314] [6 Regression] Invalid read in build_pbb_minimal_scattering_polyhedrons (graphite-sese-to-poly.c:148)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68314 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||spop at gcc dot gnu.org Target Milestone|--- |6.0
[Bug middle-end/68314] New: [6 Regression] Invalid read in build_pbb_minimal_scattering_polyhedrons (graphite-sese-to-poly.c:148)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68314 Bug ID: 68314 Summary: [6 Regression] Invalid read in build_pbb_minimal_scattering_polyhedrons (graphite-sese-to-poly.c:148) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Hello. Running valgrind following invalid read in graphite: valgrind --leak-check=yes --trace-children=yes --suppressions=/home/marxin/Programming/gcc2/gcc.supp --error-exitcode=111 -q /home/marxin/Programming/gcc2/objdir/gcc/xgcc -B/home/marxin/Programming/gcc2/objdir/gcc/ /home/marxin/Programming/gcc2/gcc/testsuite/gcc.dg/graphite/pr42211.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -floop-interchange -S -o pr42211.s ==28667== Invalid read of size 4 ==28667==at 0x15540D2: build_pbb_minimal_scattering_polyhedrons(isl_aff*, poly_bb*, int*, int) (graphite-sese-to-poly.c:148) ==28667==by 0x15545E2: build_scop_minimal_scattering(scop*) (graphite-sese-to-poly.c:304) ==28667==by 0x155693A: build_poly_scop(scop*) (graphite-sese-to-poly.c:1198) ==28667==by 0x15451A7: graphite_transform_loops() (graphite.c:332) ==28667==by 0x1545287: graphite_transforms(function*) (graphite.c:371) ==28667==by 0x15453AD: (anonymous namespace)::pass_graphite_transforms::execute(function*) (graphite.c:448) ==28667==by 0xC2006A: execute_one_pass(opt_pass*) (passes.c:2325) ==28667==by 0xC2036D: execute_pass_list_1(opt_pass*) (passes.c:2398) ==28667==by 0xC2039E: execute_pass_list_1(opt_pass*) (passes.c:2399) ==28667==by 0xC2039E: execute_pass_list_1(opt_pass*) (passes.c:2399) ==28667==by 0xC2039E: execute_pass_list_1(opt_pass*) (passes.c:2399) ==28667==by 0xC203F6: execute_pass_list(function*, opt_pass*) (passes.c:2409) ==28667== Address 0x78f43a4 is 0 bytes after a block of size 4 alloc'd ==28667==at 0x4C2A00F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==28667==by 0x1690A87: xmalloc (xmalloc.c:148) ==28667==by 0x155445F: build_scop_minimal_scattering(scop*) (graphite-sese-to-poly.c:268) ==28667==by 0x155693A: build_poly_scop(scop*) (graphite-sese-to-poly.c:1198) ==28667==by 0x15451A7: graphite_transform_loops() (graphite.c:332) ==28667==by 0x1545287: graphite_transforms(function*) (graphite.c:371) ==28667==by 0x15453AD: (anonymous namespace)::pass_graphite_transforms::execute(function*) (graphite.c:448) ==28667==by 0xC2006A: execute_one_pass(opt_pass*) (passes.c:2325) ==28667==by 0xC2036D: execute_pass_list_1(opt_pass*) (passes.c:2398) ==28667==by 0xC2039E: execute_pass_list_1(opt_pass*) (passes.c:2399) ==28667==by 0xC2039E: execute_pass_list_1(opt_pass*) (passes.c:2399) ==28667==by 0xC2039E: execute_pass_list_1(opt_pass*) (passes.c:2399) Breakpoint 1, build_pbb_minimal_scattering_polyhedrons (static_sched=0x2535ca0, pbb=0x24ec3f0, sequence_dims=0x0, nb_sequence_dim=0) at ../../gcc/graphite-sese-to-poly.c:148 148 if (sequence_dims && sequence_dims[j] == i) Missing separate debuginfos, use: zypper install libisl13-debuginfo-0.14-1.21.x86_64 (gdb) p j $1 = 0 Problem is that nb_sequence_dim=0 == 0. Thanks, Martin
[Bug libstdc++/67478] gcc-5.1.0/gcc-5.2.0 undefined symbol std::__once_callable in AIX 6.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67478 David Edelsohn changed: What|Removed |Added Target||powerpc-ibm-aix* Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-12 CC||dje at gcc dot gnu.org Target Milestone|--- |5.3 Ever confirmed|0 |1 --- Comment #5 from David Edelsohn --- This is caused by AIX TLS symbols labeled as type "L" in AIX nm output and not recognized by GNU Libtool. There is a patch waiting for review to fix this.
[Bug target/68192] AIX libstdc++ TLS symbols not exported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68192 David Edelsohn changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from David Edelsohn --- Same as PR67478
[Bug target/68192] AIX libstdc++ TLS symbols not exported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68192 Torbjörn Gard changed: What|Removed |Added CC||tgard at opentext dot com --- Comment #4 from Torbjörn Gard --- I suppose this is the same problem I reported on in 67478
[Bug tree-optimization/68306] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5651
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68306 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug tree-optimization/68306] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5651
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68306 --- Comment #5 from Richard Biener --- Author: rguenth Date: Thu Nov 12 14:02:44 2015 New Revision: 230260 URL: https://gcc.gnu.org/viewcvs?rev=230260&root=gcc&view=rev Log: 2015-11-12 Richard Biener PR tree-optimization/68306 * tree-vect-data-refs.c (verify_data_ref_alignment): Remove relevant and vectorizable checks here. (vect_verify_datarefs_alignment): Add relevant check here. * gcc.dg/pr68306.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr68306.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug other/68247] Remove pass_first_instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68247 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-12 Ever confirmed|0 |1 --- Comment #2 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01504.html : ... It's good to get rid of the first_pass_instance hack. ... I'd say that means confirmed.
[Bug other/68247] Remove pass_first_instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68247 --- Comment #1 from vries at gcc dot gnu.org --- RFC: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01492.html
[Bug c/67784] Incorrect parsing when using declarations in for loops and typedefs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67784 --- Comment #3 from joseph at codesourcery dot com --- The reason is as stated in comment#1: it's necessary to examine the token after "if ( 1 ) ;" to see if it's the "else" keyword; if it were "else", that token would be within the C99/C11 block scope of the "for" loop, but if it's something else then it's outside that block scope. But examining it to determine whether it's "else" also classifies it as not a typedef, using information from the wrong scope. So on leaving such a scope for a "for" loop, any previously-lexed identifier token after the loop may need reclassifying based on the correct scope.
[Bug c++/68313] New: "using" shadows declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68313
Bug ID: 68313
Summary: "using" shadows declaration
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wd11 at leicester dot ac.uk
Target Milestone: ---
The following valid code (modified from bug 37374)
namespace N1 { void f() {} }
namespace N2 { template void f(X); using N1::f; }
template void N2::f(X) {}
template void N2::f(int);
main() { N2::f(0); }
is rejected (gcc 5.1.0), claiming that void N2::f(int) is not declared in
namespace N2. A similar error occurs in the following code:
namespace N1 { void f() {}
namespace N2 {
template void f(X);
using N1::f;
template void f(X) {}
template void f(int);
}
}
when the using declaration is redundant.
[Bug middle-end/67220] GCC fails to properly handle libcall symbol visibility of built functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67220 --- Comment #2 from H.J. Lu --- Created attachment 36697 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36697&action=edit tree dump It is compiled with -O2 -mx32.
[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67239
--- Comment #8 from H.J. Lu ---
(In reply to Richard Biener from comment #7)
> Can you please attach -details dumps of the pass instance that does this?
It is done in fre pass.
> Note that the large number '5368709811' (0x1fff) might point to a
> different issue elsewhere. Did you double-check that makes sense?
>
It came from
static size_type
_S_max_size(_Alloc2&, ...)
{
return __gnu_cxx::__numeric_traits::__max
/ sizeof(value_type);
}
[Bug c/67784] Incorrect parsing when using declarations in for loops and typedefs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67784 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-12 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- Confirmed. It seems that in the first case we parse "T *x;" using c_parser_statement_after_labels (that fails) while in the second case with c_parser_declaration_or_fndef (that succeeds). That is because in the first case the parser sees "T" as an ID while in the second case as a TYPENAME. I don't know yet why is that so.
[Bug c/68062] [4.9/5/6 Regression] ICE when comparing vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062 --- Comment #9 from rguenther at suse dot de --- On Thu, 12 Nov 2015, uweigand at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062 > > --- Comment #8 from Ulrich Weigand --- > (In reply to Richard Biener from comment #7) > > I think there was some inconsistencies in C vs. C++ FEs in this area (but as > > usual I don't remember exactly but I remember Uli complaining about it again > > at the Caulrdon). > > > > I believe it was sort-of automatic integer promotion rules should apply if > > they don't change vector sizes (thus, the sign promotion parts should > > apply). > > > > That's not "ignoring" signs but doing the appropriate (view-)conversions. > > Actually, the C vs. C++ FE inconsistency was about binary operators (+, -, > ...), not comparisons. > > For both binary and relational operators, the various applicable standards > (AltiVec + extensions, System z vector extensions, OpenCL) all agree that if > the two operands differ in signedness, the operation is not valid and should > result in an error. However, GCC has never done this, but has always accepted > these combinations (both C and C++). (At some point, we might want to change > this, but then we have to care that we don't break "vector bool" handling for > those platforms that support it.) > > The difference between C and C++ comes in when determining what to use as the > *result type* of a binary operator whose operands differ in signedness. This > does not apply to comparisons since those have a result type different from > the > input types in any case. Thanks for the clarification.
[Bug tree-optimization/68305] [6 regression] ICE on valid code at -O3 on x86_64-linux-gnu: tree check: expected class ‘expression’, have ‘exceptional’ (ssa_name) in tree_operand_check, at tree.h:3436
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68305 --- Comment #4 from Ilya Enkovich --- Author: ienkovich Date: Thu Nov 12 12:59:05 2015 New Revision: 230252 URL: https://gcc.gnu.org/viewcvs?rev=230252&root=gcc&view=rev Log: gcc/ PR tree-optimization/68305 * tree-vect-slp.c (vect_get_constant_vectors): Support COND_EXPR with SSA_NAME as a condition. gcc/testsuite/ PR tree-optimization/68305 * gcc.dg/vect/pr68305.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr68305.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug fortran/66408] deferred-length character & overloaded assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66408 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- Since my recent patch fixes it, I had better take it! Paul
[Bug fortran/63932] posible problem with allocatable character(:)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63932 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- Since my recent patch fixes it, I had better take it! Paul
[Bug fortran/50221] Allocatable string length fails with array assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50221 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #6 from Paul Thomas --- Since my recent patch fixes it, I had better take it! Paul
[Bug c/68062] [4.9/5/6 Regression] ICE when comparing vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062 --- Comment #8 from Ulrich Weigand --- (In reply to Richard Biener from comment #7) > I think there was some inconsistencies in C vs. C++ FEs in this area (but as > usual I don't remember exactly but I remember Uli complaining about it again > at the Caulrdon). > > I believe it was sort-of automatic integer promotion rules should apply if > they don't change vector sizes (thus, the sign promotion parts should apply). > > That's not "ignoring" signs but doing the appropriate (view-)conversions. Actually, the C vs. C++ FE inconsistency was about binary operators (+, -, ...), not comparisons. For both binary and relational operators, the various applicable standards (AltiVec + extensions, System z vector extensions, OpenCL) all agree that if the two operands differ in signedness, the operation is not valid and should result in an error. However, GCC has never done this, but has always accepted these combinations (both C and C++). (At some point, we might want to change this, but then we have to care that we don't break "vector bool" handling for those platforms that support it.) The difference between C and C++ comes in when determining what to use as the *result type* of a binary operator whose operands differ in signedness. This does not apply to comparisons since those have a result type different from the input types in any case.
[Bug tree-optimization/68306] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5651
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68306 Ulrich Weigand changed: What|Removed |Added CC||uweigand at gcc dot gnu.org --- Comment #4 from Ulrich Weigand --- I see the same ICE in a spu-elf libgfortran build: /home/uweigand/dailybuild/spu-tc-2015-11-11/gcc-head/src/libgfortran/generated/matmul_c8.c: In function 'matmul_c8': /home/uweigand/dailybuild/spu-tc-2015-11-11/gcc-head/src/libgfortran/generated/matmul_c8.c:79:1: internal compiler error: in vectorizable_store, at tree-vect-stmts.c:5651 matmul_c8 (gfc_array_c8 * const restrict retarray, ^ 0x10b10373 vectorizable_store /home/uweigand/dailybuild/spu-tc-2015-11-11/gcc-head/src/gcc/tree-vect-stmts.c:5651 0x10b1e553 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*, _slp_instance*) /home/uweigand/dailybuild/spu-tc-2015-11-11/gcc-head/src/gcc/tree-vect-stmts.c:8003 0x10b48b6f vect_schedule_slp_instance /home/uweigand/dailybuild/spu-tc-2015-11-11/gcc-head/src/gcc/tree-vect-slp.c:3484 0x10b4afeb vect_schedule_slp(vec_info*) /home/uweigand/dailybuild/spu-tc-2015-11-11/gcc-head/src/gcc/tree-vect-slp.c:3549 0x10b4f2f7 vect_slp_bb(basic_block_def*) /home/uweigand/dailybuild/spu-tc-2015-11-11/gcc-head/src/gcc/tree-vect-slp.c:2543 0x10b502c7 execute /home/uweigand/dailybuild/spu-tc-2015-11-11/gcc-head/src/gcc/tree-vectorizer.c:734
[Bug bootstrap/68271] [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68271 Dominique d'Humieres changed: What|Removed |Added Severity|blocker |normal --- Comment #19 from Dominique d'Humieres --- > Yes, so that we don't forget to apply a real fix. OK, downgrading to normal.
[Bug bootstrap/68271] [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68271 --- Comment #18 from Jakub Jelinek --- Yes, so that we don't forget to apply a real fix.
[Bug bootstrap/68271] [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68271 --- Comment #17 from Dominique d'Humieres --- Ny need to keep this PR opened?
[Bug target/68286] [6 Regression] ICE: in wide_int_to_tree, at tree.c:1468
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68286 Markus Trippelsdorf changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Markus Trippelsdorf --- fixed
[Bug target/67265] [x86] 'asm' operand has impossible constraints with -fstack-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67265 --- Comment #15 from Eric Botcazou --- Author: ebotcazou Date: Thu Nov 12 12:01:40 2015 New Revision: 230249 URL: https://gcc.gnu.org/viewcvs?rev=230249&root=gcc&view=rev Log: PR target/67265 * config/i386/i386.c (ix86_adjust_stack_and_probe): Remove obsolete assertion on the CFA register. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr67265-2.c - copied unchanged from r230247, trunk/gcc/testsuite/gcc.target/i386/pr67265-2.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/i386/i386.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug target/67265] [x86] 'asm' operand has impossible constraints with -fstack-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67265 --- Comment #14 from Eric Botcazou --- Author: ebotcazou Date: Thu Nov 12 11:59:23 2015 New Revision: 230247 URL: https://gcc.gnu.org/viewcvs?rev=230247&root=gcc&view=rev Log: PR target/67265 * config/i386/i386.c (ix86_adjust_stack_and_probe): Remove obsolete assertion on the CFA register. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr67265-2.c - copied unchanged from r230245, trunk/gcc/testsuite/gcc.target/i386/pr67265-2.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/i386/i386.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug target/67265] [x86] 'asm' operand has impossible constraints with -fstack-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67265 --- Comment #13 from Eric Botcazou --- Author: ebotcazou Date: Thu Nov 12 11:55:11 2015 New Revision: 230245 URL: https://gcc.gnu.org/viewcvs?rev=230245&root=gcc&view=rev Log: PR target/67265 * config/i386/i386.c (ix86_adjust_stack_and_probe): Remove obsolete assertion on the CFA register. Added: trunk/gcc/testsuite/gcc.target/i386/pr67265-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/68291] [6 regression] ICE in emit_move_insn, at expr.c:3540
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68291 --- Comment #2 from Ilya Enkovich --- Should be fixed by r230238.
[Bug target/68293] [6 Regression] ICE: in prepare_cmp_insn, at optabs.c:3813 with vector compare with -O0 @ aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68293 --- Comment #6 from Ilya Enkovich --- Should be fixed by r230238.
[Bug target/68286] [6 Regression] ICE: in wide_int_to_tree, at tree.c:1468
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68286 --- Comment #4 from Ilya Enkovich --- Should be fixed by r230238.
