[Bug sanitizer/68777] [UBSAN] Spurious warning with C++11 lambdas ("member call on null pointer")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68777 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- This is already fixed on trunk. I'm not sure about backporting the fix to 5, but maybe it'd be possible.
[Bug fortran/68778] Missing default initialization of finalized derived types type(C_PTR) component in subroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68778 --- Comment #3 from Bálint Aradi --- (In reply to Bálint Aradi from comment #2) > For me on x86_64-linux, with GNU Fortran (GCC) 5.2.0 it produces: > > TEST2: ASSOCIATED? (EXPECT: F) T > > Since, it is an uninitialized c-pointer, it probably depends pretty much on > the environment whether the test fails or not. Just to extend a little bit more, when testing on x86_64-linux, GCC 4.9.1 was fine, 5.1.0 failed again.
[Bug tree-optimization/68766] [6 regression] internal compiler error: in expand_LOOP_VECTORIZED, at internal-fn.c:1905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68766 --- Comment #4 from Ilya Enkovich --- Author: ienkovich Date: Tue Dec 8 07:16:04 2015 New Revision: 231395 URL: https://gcc.gnu.org/viewcvs?rev=231395&root=gcc&view=rev Log: gcc/ PR tree-optimization/68766 * tree-vectorizer.c (vectorize_loops): Check for if-converted loops when debug counters are used. gcc/testsuite/ PR tree-optimization/68766 * gcc.dg/pr68766.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr68766.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vectorizer.c
[Bug ada/65102] gnat-style.texi warning from including fdl.texi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65102 --- Comment #6 from vries at gcc dot gnu.org --- (In reply to Eric Botcazou from comment #5) > Is this still relevant? On the machine where I do my ada builds atm, I don't see this warning. I don't see any changes in the relevant source files since filing this issue, so I'm not sure why it has disappeared for me.
[Bug tree-optimization/68695] [6 Regression] Performance regression related to ssa patch / ifcvt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695 --- Comment #15 from Dominik Vogt --- Providing that macro does fix the problem: #define PROMOTE_MODE(MODE,UNSIGNEDP,TYPE) \ if (GET_MODE_CLASS (MODE) == MODE_INT \ && GET_MODE_SIZE (MODE) < (TARGET_ZARCH ? 8 : 4)) \ (MODE) = TARGET_ZARCH ? DImode : SImode; But is it a good idea to define it in the first place? And is it now required to provide a sensible implementation of PROMOTE_MODE?
[Bug other/68783] New: Improve verification of loop->latch in verify_loop_structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68783 Bug ID: 68783 Summary: Improve verification of loop->latch in verify_loop_structure Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- We can try harder to verify the loop latch against the loop state and actual cfg. I've committed a patch to implement this ( https://gcc.gnu.org/viewcvs?rev=230866&root=gcc&view=rev ), but reverted it due to PR68549.
[Bug c++/68782] New: [6 regression] bad reference member formed with constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68782
Bug ID: 68782
Summary: [6 regression] bad reference member formed with
constexpr
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
Using 6.0.0 20151208 the last two asserts fire, whereas they don't with GCC
5.2.1 (as expected). The issue seems constexpr related as not marking
from_value and from_aggr constexpr makes it go away.
Compiled using:
g++-trunk -std=c++11 main.cpp
-std=c++14 and -std=c++1z result in the same behaviour.
#include
struct holder { int& value; };
constexpr holder from_value(int& value)
{ return { value }; }
struct aggr { int i; };
constexpr holder from_aggr(aggr& a)
{ return from_value(a.i); }
int main()
{
aggr a { 42 };
// these don't fire
assert( &from_value(a.i).value != nullptr );
assert( &a.i == &from_value(a.i).value );
// those do
assert( &from_aggr(a).value != nullptr );
assert( &a.i == &from_aggr(a).value );
}
[Bug tree-optimization/68773] fpta-ipa with GOACC_parallel does not work due to node->force_output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68773 --- Comment #1 from vries at gcc dot gnu.org --- FTR, the actual failures: ... FAIL: c-c++-common/goacc/kernels-alias-ipa-pta-2.c scan-tree-dump-times optimized "(?n)= 0;$" 2 FAIL: c-c++-common/goacc/kernels-alias-ipa-pta-2.c scan-tree-dump-times optimized "(?n)= \\*a" 0 FAIL: c-c++-common/goacc/kernels-alias-ipa-pta.c scan-tree-dump-times optimized "(?n)= 0;$" 2 FAIL: c-c++-common/goacc/kernels-alias-ipa-pta.c scan-tree-dump-times optimized "(?n)= \\*_[0-9]\\[0\\];$" 0 ...
[Bug c++/68683] [concepts] function satisfy_argument_deduction_constraint modifies a type tree node but leaves TYPE_CANONICAL unchanged
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68683 ryan.burn at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from ryan.burn at gmail dot com --- fixed with 231385
[Bug ipa/66004] [6 Regression]: performance of 26_numerics/random/negative_binomial_distribution/operators/values.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66004 --- Comment #7 from Hans-Peter Nilsson --- (In reply to Jan Hubicka from comment #6) > HP, I think I need bit more analysis here. Do you know what inline decision > actually causes the trouble? Um, no. I have barely even tracked regression, much less got around to a useful investigation of what in r66004 caused the regression. I usually have a build tree around and can do the typing if you tell what dump-file or somesuch you want? (Though I'm not sure that it's just the single test-file; I should verify that first.) While I'm here, let me log recent results. Not getting better. :-( r231343: 42688158156
[Bug tree-optimization/68695] [6 Regression] Performance regression related to ssa patch / ifcvt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695 --- Comment #14 from Alexandre Oliva --- The reason we don't coalesce on s390 is that there's no PROMOTE_MODE defined there, so i_1 and j_2 promote to SImode, whereas x_3 and y_4, being function arguments, promote to DImode as per s390_promote_function_mode.
[Bug target/68759] [6 Regression] Linux kernel build failure on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68759 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #5 from Alan Modra --- I'm not familiar with recordmcount.pl, but it looks a reasonable approach for a post-compilation annotation of call sites. Given the same task I might have tried to write a filter for compiler assembler output instead.
[Bug c/68780] _mm256_mul_epi32 intrinsic not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68780 Guille changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Guille --- Thanks for the explanation, you are exactly right. Apologies for my misunderstanding. (In reply to James Almer from comment #1) > What i assume you want is _mm256_mullo_epi32(a, b), which maps to the > vpmulld instruction (Multiply the packed 32-bit integers in a and b, > producing intermediate 64-bit integers, and store the low 32 bits of the > intermediate integers in dst), which for your testcase would result in eight > 32-bit integers with value 2. > > _mm256_mul_epi32(a, b) maps to vpmuldq (Multiply the low 32-bit integers > from each packed 64-bit element in a and b, and store the signed 64-bit > results in dst), which for your testcase correctly gives four 64-bit > integers with value 2.
[Bug c/68780] _mm256_mul_epi32 intrinsic not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68780 --- Comment #1 from James Almer --- What i assume you want is _mm256_mullo_epi32(a, b), which maps to the vpmulld instruction (Multiply the packed 32-bit integers in a and b, producing intermediate 64-bit integers, and store the low 32 bits of the intermediate integers in dst), which for your testcase would result in eight 32-bit integers with value 2. _mm256_mul_epi32(a, b) maps to vpmuldq (Multiply the low 32-bit integers from each packed 64-bit element in a and b, and store the signed 64-bit results in dst), which for your testcase correctly gives four 64-bit integers with value 2.
[Bug c++/68781] New: [concepts] requires in member function is not unevaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68781
Bug ID: 68781
Summary: [concepts] requires in member function is not
unevaluated
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jarrydb at cse dot unsw.edu.au
Target Milestone: ---
The following correct code fails to compile in r231384
template
struct declval_helper
{
static constexpr bool stop = false;
static T value();
};
template
T
declval()
{
static_assert(declval_helper::stop, "declval must not be used");
return declval_helper::value();
}
template
struct A {
static void foo(int);
};
void bar(int);
template
requires requires {
bar(declval());
}
void foo(T t) {
}
class Foo {
public:
template
requires requires {
bar(declval());
}
void foo(T t) {
}
};
void test() {
Foo f;
f.foo(5);
foo(5);
}
with the error:
g++ -std=c++1z uneval.cpp -c
uneval.cpp: In instantiation of ‘T declval() [with T = int]’:
uneval.cpp:36:27: required by substitution of ‘template requires
predicate(requires{bar()((declval)());}) void Foo::foo(T) [with T = int]’
uneval.cpp:45:12: required from here
uneval.cpp:12:5: error: static assertion failed: declval must not be used
static_assert(declval_helper::stop, "declval must not be used");
^
Note that commenting out the line f.foo(5); works fine. So it is only a problem
for member functions.
[Bug c/68780] New: _mm256_mul_epi32 intrinsic not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68780
Bug ID: 68780
Summary: _mm256_mul_epi32 intrinsic not working
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: guille at cal dot berkeley.edu
Target Milestone: ---
Created attachment 36950
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36950&action=edit
Preprocessed source
Multiplying:
_mm256_mul_epi32([1,1,1,1, 1,1,1,1],
[2,2,2,2, 2,2,2,2])
results in:
[2,0,2,0, 2,0,2,0]
$ cat t.c
#include
#include
int main()
{
__m256i a = _mm256_set1_epi32(1);
__m256i b = _mm256_set1_epi32(2);
__m256i c = _mm256_mul_epi32(a, b);
printf("%d%d%d%d%d%d%d%d\n", ((const int32_t *)&a)[0], ((const int32_t
*)&a)[1],
((const int32_t *)&a)[2], ((const int32_t
*)&a)[3],
((const int32_t *)&a)[4], ((const int32_t
*)&a)[5],
((const int32_t *)&a)[6], ((const int32_t
*)&a)[7]);
printf("%d%d%d%d%d%d%d%d\n", ((const int32_t *)&b)[0], ((const int32_t
*)&b)[1],
((const int32_t *)&b)[2], ((const int32_t
*)&b)[3],
((const int32_t *)&b)[4], ((const int32_t
*)&b)[5],
((const int32_t *)&b)[6], ((const int32_t
*)&b)[7]);
printf("%d%d%d%d%d%d%d%d\n", ((const int32_t *)&c)[0], ((const int32_t
*)&c)[1],
((const int32_t *)&c)[2], ((const int32_t
*)&c)[3],
((const int32_t *)&c)[4], ((const int32_t
*)&c)[5],
((const int32_t *)&c)[6], ((const int32_t
*)&c)[7]);
return 0;
}
--
(Note the -Wa,-q is needed because without on OSX 10.9.5 the assembler
complains "...no such instruction: `vmovdqa...")
$ gcc t.c -o t -mavx2 -Wa,-q -v -save-temps
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/6.0.0/lto-wrapper
Target: x86_64-apple-darwin13.4.0
Configured with: ..//configure --enable-languages=c,c++
Thread model: posix
gcc version 6.0.0 20151108 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-o' 't' '-mavx2' '-v' '-save-temps'
'-mmacosx-version-min=10.9.4' '-mtune=core2'
/usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/6.0.0/cc1 -E -quiet -v
-D__DYNAMIC__ t.c -fPIC -mavx2 -mmacosx-version-min=10.9.4 -mtune=core2
-fpch-preprocess -o t.i
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0/../../../../x86_64-apple-darwin13.4.0/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0/include
/usr/local/include
/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0/include-fixed
/usr/include
/System/Library/Frameworks
/Library/Frameworks
End of search list.
COLLECT_GCC_OPTIONS='-o' 't' '-mavx2' '-v' '-save-temps'
'-mmacosx-version-min=10.9.4' '-mtune=core2'
/usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/6.0.0/cc1 -fpreprocessed t.i
-fPIC -quiet -dumpbase t.c -mavx2 -mmacosx-version-min=10.9.4 -mtune=core2
-auxbase t -version -o t.s
GNU C11 (GCC) version 6.0.0 20151108 (experimental) (x86_64-apple-darwin13.4.0)
compiled by GNU C version 6.0.0 20151108 (experimental), GMP version
6.0.0, MPFR version 3.1.3-p2, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C11 (GCC) version 6.0.0 20151108 (experimental) (x86_64-apple-darwin13.4.0)
compiled by GNU C version 6.0.0 20151108 (experimental), GMP version
6.0.0, MPFR version 3.1.3-p2, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 638918875426438b832445196361a1ea
COLLECT_GCC_OPTIONS='-o' 't' '-mavx2' '-v' '-save-temps'
'-mmacosx-version-min=10.9.4' '-mtune=core2'
as -arch x86_64 -force_cpusubtype_ALL -q -o t.o t.s
COMPILER_PATH=/usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/6.0.0/:/usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/6.0.0/:/usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/:/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0/:/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/
LIBRARY_PATH=/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0/:/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0/../../../
COLLECT_GCC_OPTIONS='-o' 't' '-mavx2' '-v' '-save-temps'
'-mmacosx-version-min=10.9.4' '-mtune=core2'
/usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/6.0.0/collect2 -dynamic -arch
x86_64 -macosx_version_min 10.9.4 -weak_reference_mismatches non-weak -o t
-L/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0
-L/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0/../../.. t.o
-no_compact_unwind -lSystem -lgcc_ex
[Bug target/63668] -mstd-struct-return fails for non-leaf functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63668 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #4 from Eric Botcazou --- .
[Bug target/63668] -mstd-struct-return fails for non-leaf functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63668 --- Comment #3 from Eric Botcazou --- Author: ebotcazou Date: Mon Dec 7 23:18:29 2015 New Revision: 231387 URL: https://gcc.gnu.org/viewcvs?rev=231387&root=gcc&view=rev Log: PR target/63668 * doc/invoke.texi (SPARC options): Document -mstd-struct-return. * config/sparc/sparc.c (sparc_struct_value_rtx): Minor tweaks. * config/sparc/sparc.h (CALL_REALLY_USED_REGISTERS): Define. * config/sparc/sparc.opt (mstd-struct-return): Accept negative form. Added: trunk/gcc/testsuite/gcc.target/sparc/struct-ret-check-1.c - copied unchanged from r231372, trunk/gcc/testsuite/gcc.target/sparc/struct-ret-check.c trunk/gcc/testsuite/gcc.target/sparc/struct-ret-check-2.c Removed: trunk/gcc/testsuite/gcc.target/sparc/struct-ret-check.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.c trunk/gcc/config/sparc/sparc.h trunk/gcc/config/sparc/sparc.opt trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug target/68759] [6 Regression] Linux kernel build failure on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68759
Ulrich Weigand changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2015-12-07
CC||amodra at gcc dot gnu.org,
||dje.gcc at gmail dot com
Assignee|unassigned at gcc dot gnu.org |uweigand at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #4 from Ulrich Weigand ---
OK, with this .config I was able to recreate the problem. Thanks!
The immediate cause for the ERROR (which is reported by the kernel's modpost
tool) is that object files contain undefined references against symbols that
are actually *defined* in the same object file as local symbols.
This weird situation is the result of some very special object file magic
performed by the perl script ./scripts/recordmcount.pl, which is apparently
supposed to record all call sites to the _mcount routine into a special
section, and uses rather complex logic to do so, which involves parsing the
output of objdump.
This objdump parsing in turn seems to get thrown out of sync if the object
file's .text sections contain data blocks outside of functions (or at least,
before the very first function). For the sparc64 target, there is special code
in the recordmcount.pl script to handle this situation, but not for powerpc.
This didn't matter so far since on powerpc, this could never happen. However,
it turns out that kernel modules are built with -mcmodel=large for some reason,
and therefore after my patch, we do indeed see a data block before the first
function.
Using the same trick as on sparc64 makes the build go through again:
diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
index 826470d..96e2486 100755
--- a/scripts/recordmcount.pl
+++ b/scripts/recordmcount.pl
@@ -263,7 +263,8 @@ if ($arch eq "x86_64") {
} elsif ($arch eq "powerpc") {
$local_regex = "^[0-9a-fA-F]+\\s+t\\s+(\\.?\\S+)";
-$function_regex = "^([0-9a-fA-F]+)\\s+<(\\.?.*?)>:";
+# See comment in the sparc64 section for why we use '\w'.
+$function_regex = "^([0-9a-fA-F]+)\\s+<(\\.?\\w*?)>:";
$mcount_regex = "^\\s*([0-9a-fA-F]+):.*\\s\\.?_mcount\$";
if ($bits == 64) {
Alan, have you seen this recordmcount.pl script before? Is there really no
simpler way to achieve what this wants to do?
B.t.w. given that kernel modules are build with -mcmodel=large, this probably
means that we'll now have to teach the kernel module loader to handle the
R_PPC64_ENTRY reloc. I guess we need to talk to the kernel folks.
[Bug fortran/68778] Missing default initialization of finalized derived types type(C_PTR) component in subroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68778 --- Comment #2 from Bálint Aradi --- For me on x86_64-linux, with GNU Fortran (GCC) 5.2.0 it produces: TEST2: ASSOCIATED? (EXPECT: F) T Since, it is an uninitialized c-pointer, it probably depends pretty much on the environment whether the test fails or not.
[Bug fortran/68748] FAIL: gfortran.dg/g77/20010430.f -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68748 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-12-07 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Duplicate of pr68743?
[Bug fortran/68745] FAIL: gfortran.dg/intrinsic_modulo_1.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68745 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-12-07 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Duplicate of pr68743?
[Bug fortran/68747] FAIL: gfortran.dg/specifics_1.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68747 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-12-07 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Duplicate of pr68743?
[Bug fortran/68743] FAIL: gfortran.dg/aint_anint_1.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68743 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-12-07 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- WORKSFORME. It seems you have a problem with aint and/or anint. Could you please investigate what is wrong with your libs?
[Bug fortran/68746] FAIL: gfortran.dg/read_dir.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68746 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-12-07 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Duplicate of pr68744?
[Bug fortran/68742] FAIL: gfortran.dg/coarray/event_2.f90 -fcoarray=lib -O2 -lcaf_single -latomic execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68742 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-12-07 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Duplicate of pr68744?
[Bug c++/68760] [6 Regression] ICE in pp_string (pretty-print.c:909)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68760 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Mon Dec 7 22:44:19 2015 New Revision: 231386 URL: https://gcc.gnu.org/viewcvs?rev=231386&root=gcc&view=rev Log: PR c++/68760 * error.c (dump_global_iord): Use DECL_SOURCE_FILE (t) instead of LOCATION_FILE (input_location). * g++.dg/tree-ssa/pr68760.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr68760.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/68778] Missing default initialization of finalized derived types type(C_PTR) component in subroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68778 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-12-07 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- On x86_64-apple-darwin14 and compiling the test with 4.9 up to trunk (6.0), running the test gives (compiling with 4.8 gives "Finalization at (1) is not yet implemented") TEST2: ASSOCIATED? (EXPECT: F) F What did I miss?
[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68302 --- Comment #11 from Steve Ellcey --- Could you try adding 'debug_rtx (x); debug_rtx (y);' to the front of rtx_equal_for_cselib_1? It looks like this routine is in an infinite loop, I would like to see what input it is working on and see if the same input keeps re-occurring over and over.
[Bug target/68779] New: [5.3 Regression] HPPA/PARISC 32-bit Linux kernel build triggers multiple ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68779
Bug ID: 68779
Summary: [5.3 Regression] HPPA/PARISC 32-bit Linux kernel build
triggers multiple ICEs
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: aaro.koskinen at iki dot fi
Target Milestone: ---
Created attachment 36949
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36949&action=edit
Preprocessed kernel source for a reproducer.
Multiple files trigger ICE when compiling 32-bit kernel for PARISC with GCC
5.3. GCC 5.2 works OK.
One example attached.
$ hppa-linux-gnu-gcc -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
-Wno-format-security -std=gnu89 -pipe -mno-space-regs -mfast-indirect-calls
-mdisable-fpregs -ffunction-sections -march=2.0 -mschedule=8000
-fno-delete-null-pointer-checks -O2 --param=allow-store-data-races=0
-Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable
-fno-omit-frame-pointer -fno-optimize-sibling-calls
-fno-var-tracking-assignments -Wdeclaration-after-statement -Wno-pointer-sign
-fno-strict-overflow -fconserve-stack -Werror=implicit-int
-Werror=strict-prototypes -Werror=date-time -mlong-calls -c initramfs.i
init/initramfs.c: In function 'unpack_to_rootfs':
init/initramfs.c:509:1: error: unable to generate reloads for:
}
^
(insn 96 97 98 7 (parallel [
(set (reg/v:DI 7 %r7 [orig:105 saved_offset ] [105])
(mem/c:DI (reg/f:SI 6 %r6 [312]) [0 this_header+0 S8 A64]))
(clobber (scratch:DI))
]) init/initramfs.c:467 1 {atomic_loaddi_1}
(expr_list:REG_EQUAL (mem/c:DI (symbol_ref:SI ("this_header") [flags
0x202] ) [0 this_header+0 S8 A64])
(nil)))
init/initramfs.c:509:1: internal compiler error: in find_reloads, at
reload.c:3862
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
[Bug c++/68683] [concepts] function satisfy_argument_deduction_constraint modifies a type tree node but leaves TYPE_CANONICAL unchanged
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68683 --- Comment #1 from Jason Merrill --- Author: jason Date: Mon Dec 7 21:45:13 2015 New Revision: 231385 URL: https://gcc.gnu.org/viewcvs?rev=231385&root=gcc&view=rev Log: PR c++/68683 * constraint.cc (satisfy_argument_deduction_constraint): Set TYPE_CANONICAL to NULL_TREE if PLACEHOLDER_TYPE_CONSTRAINTS are changed. Added: trunk/gcc/testsuite/g++.dg/concepts/pr68683.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constraint.cc
[Bug fortran/68778] New: Missing default initialization of finalized derived types type(C_PTR) component in subroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68778 Bug ID: 68778 Summary: Missing default initialization of finalized derived types type(C_PTR) component in subroutines Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: baradi09 at gmail dot com Target Milestone: --- When having a derived type with a type(C_PTR) component, which is default initialized to C_NULL_PTR, the default initialization is not carried out, when the derived type is declared within a subroutine, provided the derived type has a final method. The self containing example below demonstrates the problem. module testmod use, intrinsic :: iso_c_binding implicit none type :: testtype type(C_PTR) :: ptr = C_NULL_PTR contains ! If final binding is commented out here, the example works correctly final :: destroy end type testtype contains subroutine destroy(tt) type(testtype), intent(inout) :: tt continue end subroutine destroy subroutine test() type(testtype) :: aa print *, "TEST2: ASSOCIATED? (EXPECT: F)", c_associated(aa%ptr) end subroutine test end module testmod program showbug use testmod implicit none call test() end program showbug
[Bug pch/68758] [6 Regression] Invalid read of size 8 in gt_pch_save (ggc-common.c:551)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68758 --- Comment #4 from Martin Liška --- (In reply to Markus Trippelsdorf from comment #3) > BTW this option is undocumented. I will prepare a patch for that. Thanks, Martin
[Bug fortran/31190] minimum field width list-directed output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31190 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #10 from Jerry DeLisle --- I am working on a related PR that will require some overhaul on reals, so I may look at this while I am at it. (48852)
[Bug pch/68758] [6 Regression] Invalid read of size 8 in gt_pch_save (ggc-common.c:551)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68758 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #3 from Markus Trippelsdorf --- BTW this option is undocumented.
[Bug fortran/30802] out of bounds error array I/O not picked up with -fbounds-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30802 --- Comment #6 from Jerry DeLisle --- Intentionally not in the library for efficiency. However we can build in some runtime checks with -fcheck=. This one is on my radar and I was just looking at it a few days ago. Not taking assignment yet.
[Bug sanitizer/68777] New: [UBSAN] Spurious warning with C++11 lambdas ("member call on null pointer")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68777
Bug ID: 68777
Summary: [UBSAN] Spurious warning with C++11 lambdas ("member
call on null pointer")
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.conway at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
Created attachment 36948
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36948&action=edit
Reduced test case.
$ vi sync-test.cpp
vagrant@vagrant-ubuntu-wily-64:~$ g++ -fsanitize=undefined -std=c++11 -Wall -W
sync-test.cpp -o sync_test
vagrant@vagrant-ubuntu-wily-64:~$ ./sync_test
vagrant@vagrant-ubuntu-wily-64:~$ g++ -DUSE_LAMBDA -fsanitize=undefined
-std=c++11 -Wall -W sync-test.cpp -o sync_test
vagrant@vagrant-ubuntu-wily-64:~$ ./sync_test
sync-test.cpp:25:6: runtime error: member call on null pointer of type 'const
struct __lambda0'
#0 0x400832 in Synchronized
my_synchronize_warns(int*)::{lambda(int*)#1}::_FUN(int*)
(/home/vagrant/sync_test+0x400832)
#1 0x400a79 in Synchronized::Synchronized(int*, void (*)(int*), void
(*)(int*)) (/home/vagrant/sync_test+0x400a79)
#2 0x40091d in Synchronized my_synchronize_warns(int*)
(/home/vagrant/sync_test+0x40091d)
#3 0x4007df in main (/home/vagrant/sync_test+0x4007df)
#4 0x7fc3708eca3f in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x20a3f)
#5 0x4006e8 in _start (/home/vagrant/sync_test+0x4006e8)
sync-test.cpp:26:6: runtime error: member call on null pointer of type 'const
struct __lambda1'
#0 0x400880 in Synchronized
my_synchronize_warns(int*)::{lambda(int*)#2}::_FUN(int*)
(/home/vagrant/sync_test+0x400880)
#1 0x4009a6 in Synchronized::~Synchronized()
(/home/vagrant/sync_test+0x4009a6)
#2 0x4007eb in main (/home/vagrant/sync_test+0x4007eb)
#3 0x7fc3708eca3f in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x20a3f)
#4 0x4006e8 in _start (/home/vagrant/sync_test+0x4006e8)
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.2.1-22ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2)
$ uname -a
Linux vagrant-ubuntu-wily-64 4.2.0-19-generic #23-Ubuntu SMP Wed Nov 11
11:39:30 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
As far as I can see, my_synchronize_warns() and my_synchronize_no_warning() are
equivalent.
[Bug tree-optimization/66726] missed optimization, factor conversion out of COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66726 --- Comment #15 from Jakub Jelinek --- Author: jakub Date: Mon Dec 7 21:05:51 2015 New Revision: 231384 URL: https://gcc.gnu.org/viewcvs?rev=231384&root=gcc&view=rev Log: PR middle-end/66726 * g++.dg/tree-ssa/pr66726.c: Renamed to... * g++.dg/tree-ssa/pr66726.C: ... this. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr66726.C - copied, changed from r231383, trunk/gcc/testsuite/g++.dg/tree-ssa/pr66726.c Removed: trunk/gcc/testsuite/g++.dg/tree-ssa/pr66726.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug pch/68758] [6 Regression] Invalid read of size 8 in gt_pch_save (ggc-common.c:551)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68758 --- Comment #2 from Martin Liška --- Yes. Configured with: ../configure --enable-languages=c,c++ --prefix=/home/marxin/Programming/bin/gcc3 -disable-multilib --disable-libsanitizer --enable-checking=release --enable-valgrind-annotations --disable-bootstrap
[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|jason at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #28 from Jason Merrill --- Unassigning myself; I suggested a fix at https://gcc.gnu.org/ml/gcc-patches/2015-11/threads.html#03102 but richi and honza have been discussing other ways of addressing the bug. honza checked in one of the patches we were discussing today, along with the ipa/61886 fix; I'm guessing that was unintended but should mean the bug is fixed.
[Bug target/68759] [6 Regression] Linux kernel build failure on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68759 --- Comment #3 from Markus Trippelsdorf --- Just double-checked and it also happens without the kernel patch. So no need to bother with it... ld.bfd reports: ... ERROR: "__connect" [virt/lib/irqbypass.ko] undefined! WARNING: ".TOC." [virt/lib/irqbypass.ko] has no CRC! ERROR: "snd_us428ctls_poll" [sound/usb/usx2y/snd-usb-usx2y.ko] undefined! ERROR: "snd_usX2Y_pcm_pointer" [sound/usb/usx2y/snd-usb-usx2y.ko] undefined! ERROR: "i_usX2Y_Out04Int" [sound/usb/usx2y/snd-usb-usx2y.ko] undefined! WARNING: ".TOC." [sound/usb/usx2y/snd-usb-usx2y.ko] has no CRC! ERROR: "snd_usbmidi_output_standard_packet" [sound/usb/snd-usbmidi-lib.ko] undefined! WARNING: ".TOC." [sound/usb/snd-usbmidi-lib.ko] has no CRC! ERROR: "get_sample_rate_v2" [sound/usb/snd-usb-audio.ko] undefined! ERROR: "wait_clear_urbs" [sound/usb/snd-usb-audio.ko] undefined! ...
[Bug target/68774] gcc should allow disabling markup in Xcode 7 assembler messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68774 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-07 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- -fno-diagnostics-show-caret -fdiagnostics-color=never is not obeyed. IIRC there has been a PR about the order of these options working or not.
[Bug tree-optimization/68776] New: [6 regression] gcc.dg/vect/vect-widen-mult-const-[su]16.c failures since r226675
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68776
Bug ID: 68776
Summary: [6 regression]
gcc.dg/vect/vect-widen-mult-const-[su]16.c failures
since r226675
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Host: powerpc*-*-linux*
Target: powerpc*-*-linux*
Build: powerpc*-*-linux*
Created attachment 36946
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36946&action=edit
Vectorization dump for r226674
Since r226675, we have been seeing these failures:
FAIL: gcc.dg/vect/vect-widen-mult-const-s16.c -flto -ffat-lto-objects
scan-tree-dump-times vect "pattern recognized" 2
FAIL: gcc.dg/vect/vect-widen-mult-const-s16.c scan-tree-dump-times vect
"pattern recognized" 2
FAIL: gcc.dg/vect/vect-widen-mult-const-u16.c -flto -ffat-lto-objects
scan-tree-dump-times vect "pattern recognized" 2
FAIL: gcc.dg/vect/vect-widen-mult-const-u16.c scan-tree-dump-times vect
"pattern recognized" 2
Comparing the vect-details dumps from r226674 to r226675, I see these as
the reason:
63a64,66
> /home/wschmidt/gcc/gcc-mainline-base/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-s16.c:16:3:
> note: vect_recog_mult_pattern: detected:
> /home/wschmidt/gcc/gcc-mainline-base/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-s16.c:16:3:
> note: patt_47 = _6 << 2;
> /home/wschmidt/gcc/gcc-mainline-base/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-s16.c:16:3:
> note: pattern recognized: patt_47 = _6 << 2;
70a74,76
> /home/wschmidt/gcc/gcc-mainline-base/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-s16.c:16:3:
> note: vect_recog_mult_pattern: detected:
> /home/wschmidt/gcc/gcc-mainline-base/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-s16.c:16:3:
> note: patt_40 = _6 << 1;
> /home/wschmidt/gcc/gcc-mainline-base/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-s16.c:16:3:
> note: pattern recognized: patt_40 = _6 << 1;
747a754,756
> /home/wschmidt/gcc/gcc-mainline-base/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-s16.c:31:3:
> note: vect_recog_mult_pattern: detected:
> /home/wschmidt/gcc/gcc-mainline-base/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-s16.c:31:3:
> note: patt_47 = _6 << 2;
> /home/wschmidt/gcc/gcc-mainline-base/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-s16.c:31:3:
> note: pattern recognized: patt_47 = _6 << 2;
754a764,766
> /home/wschmidt/gcc/gcc-mainline-base/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-s16.c:31:3:
> note: vect_recog_mult_pattern: detected:
> /home/wschmidt/gcc/gcc-mainline-base/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-s16.c:31:3:
> note: patt_40 = _6 << 1;
> /home/wschmidt/gcc/gcc-mainline-base/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-s16.c:31:3:
> note: pattern recognized: patt_40 = _6 << 1;
These do not show up for x86_64, so the DejaGnu patterns:
/* { dg-final { scan-tree-dump-times "pattern recognized" 2 "vect" { target
vect_widen_mult_hi_to_si_pattern } } } */
have different results for these different targets, even though both support
vect_widen_mult_hi_to_si_pattern.
Detailed vectorization dumps from powerpc64le-unknown-linux-gnu before and
after this revision are attached.
[Bug tree-optimization/68776] [6 regression] gcc.dg/vect/vect-widen-mult-const-[su]16.c failures since r226675
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68776 --- Comment #1 from Bill Schmidt --- Created attachment 36947 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36947&action=edit Vectorization dump for r226675
[Bug target/68774] gcc should allow disabling markup in Xcode 7 assembler messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68774 --- Comment #2 from Iain Sandoe --- (In reply to m...@gcc.gnu.org from comment #1) > I glanced around and didn't find how to turn it off. First step, ask around > and find the option to turn it off. From there, we can pass it when the gcc > option to not color is given. AFAIR cctools 'as' invokes clang -x assembler -integrated-as -c so you'd need to look up the method to switch off colour in clang (-fno-color-diagnostics) and maybe do -Wa,-fno=color-diagnostics .. if that works, perhaps raise a radar saying that we'd prefer no colour there. I have a draft of an "las" driver which calls the MC layer directly (i.e. replaces as but using the llvm assembler without going via clang) .. not ready for production yet.. but will try to share asap.
[Bug target/68759] [6 Regression] Linux kernel build failure on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68759
--- Comment #2 from Markus Trippelsdorf ---
Created attachment 36945
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36945&action=edit
kernel config
I'm building the latest vanilla kernel tree:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git.
The kernel config is attached.
Binutils is latest trunk. (Both ld.bfd and ld.gold hit the issue,
although the error messages are slightly different.)
I'm also using the following kernel patch, to enable -O3 instead
of the default -O2. (The rest are compare-debug related changes,
that are uninteresting in the current context.)
diff --git a/Makefile b/Makefile
index d644f6e..0922f17 100644
--- a/Makefile
+++ b/Makefile
@@ -610,7 +610,7 @@ KBUILD_CFLAGS += $(call
cc-option,-fno-delete-null-pointer-checks,)
ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
KBUILD_CFLAGS += -Os $(call cc-disable-warning,maybe-uninitialized,)
else
-KBUILD_CFLAGS += -O2
+KBUILD_CFLAGS += -O3 -w
endif
# Tell gcc to never replace conditional load with a non-conditional one
@@ -700,7 +700,6 @@ KBUILD_CFLAGS += -fomit-frame-pointer
endif
endif
-KBUILD_CFLAGS += $(call cc-option, -fno-var-tracking-assignments)
ifdef CONFIG_DEBUG_INFO
ifdef CONFIG_DEBUG_INFO_SPLIT
diff --git a/scripts/gcc-goto.sh b/scripts/gcc-goto.sh
index c9469d3..fad4c94 100755
--- a/scripts/gcc-goto.sh
+++ b/scripts/gcc-goto.sh
@@ -2,6 +2,8 @@
# Test for gcc 'asm goto' support
# Copyright (C) 2010, Jason Baron
+GCC_COMPARE_DEBUG=0
+
cat << "END" | $@ -x c - -c -o /dev/null >/dev/null 2>&1 && echo "y"
int main(void)
{
[Bug target/68774] gcc should allow disabling markup in Xcode 7 assembler messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68774 --- Comment #1 from mrs at gcc dot gnu.org --- I glanced around and didn't find how to turn it off. First step, ask around and find the option to turn it off. From there, we can pass it when the gcc option to not color is given.
[Bug c++/68170] [6 Regression] Declaring friend template class template in C++1z produces error: specialization of ‘template class A’ must appear at namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68170 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Merrill --- Fixed.
[Bug c++/68464] [6 Regression] ICE in valid constexpr function: ../../src/gcc/tree.c:11497
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68464 --- Comment #5 from Jason Merrill --- Author: jason Date: Mon Dec 7 19:34:11 2015 New Revision: 231381 URL: https://gcc.gnu.org/viewcvs?rev=231381&root=gcc&view=rev Log: PR c++/68464 * cp-gimplify.c (cp_fold): Don't assume X has TREE_TYPE. (cp_genericize): Don't do cp_fold_r here. (cp_fold_function): New. * cp-tree.h: Declare it. * decl.c (finish_function): Call it and the pre-genericize plugin before NRV processing. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c
[Bug c++/68170] [6 Regression] Declaring friend template class template in C++1z produces error: specialization of ‘template class A’ must appear at namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68170 --- Comment #2 from Jason Merrill --- Author: jason Date: Mon Dec 7 19:34:04 2015 New Revision: 231380 URL: https://gcc.gnu.org/viewcvs?rev=231380&root=gcc&view=rev Log: PR c++/68170 * pt.c (maybe_new_partial_specialization): The injected-class-name is not a new partial specialization. Added: trunk/gcc/testsuite/g++.dg/template/friend60.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/68464] [6 Regression] ICE in valid constexpr function: ../../src/gcc/tree.c:11497
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68464 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #4 from Jason Merrill --- Fixed.
[Bug target/68759] [6 Regression] Linux kernel build failure on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68759 --- Comment #1 from Ulrich Weigand --- I've tried to reproduce this, but with no success so far. This is primarily because I cannot manage to get a current mainline Linux kernel built with allyesconfig for powerpc64le in the first place (various issues, but mostly it ends up too big and we get relocation overflows in built-in.o). With other settings (like defconfig or allmodconfig), it builds fine for me with the new compiler as well. Could you provide more information on the exact source tree and .config settings you're attempting to build? Also, which binutils are you using?
[Bug target/67973] All the tests for -gstabs* fail on x86_64-apple-darwin14 with Xcode 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67973 Dominique d'Humieres changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #3 from Dominique d'Humieres --- *** Bug 68772 has been marked as a duplicate of this bug. ***
[Bug target/68772] Many -gstabs tests FAIL with Xcode 7 as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68772 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Dominique d'Humieres --- Duplicate of pr67973. *** This bug has been marked as a duplicate of bug 67973 ***
[Bug tree-optimization/68775] New: spec2006 test case 465.tonto fails with the gcc 6.0 fortran compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68775 Bug ID: 68775 Summary: spec2006 test case 465.tonto fails with the gcc 6.0 fortran compiler Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: seurer at linux dot vnet.ibm.com Target Milestone: --- The spec2006 test case 465.tonto fails with the gcc 6.0 fortran compiler on powerpc. The failure started with revision r230855. The compilation works but the output of the test is wrong. r230855 | rguenth | 2015-11-25 02:53:22 -0600 (Wed, 25 Nov 2015) | 6 lines 2015-11-25 Richard Biener PR tree-optimization/68492 * tree-vect-slp.c (vect_build_slp_tree): Consistently build up op from scalars after operand swapping. Options used were: -m64 -O3 -mcpu=power8 -fpeel-loops -funroll-loops -ffast-math -fvect-cost-model -mpopcntd -mrecip=rsqrt Minimal option set to cause the failure: -m64 -O3 -mcpu=power8 -ffast-math Note that it succeeds with -mcpu=power7
[Bug middle-end/68762] link error for inline function decorated with OpenMP declare simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68762 --- Comment #2 from gilles --- TBH I don't know anything about the C inline keyword, aside from it existence. My issue has definitely to do with the C++ inline keyword. And the important point I (hope I) know about it is that the full definition of the function should be available in every compilation unit where the function is used. This is commonly done by putting the definition of the function into a header file. Another very important point is that the inline keyword is a suggestion given to the compiler, which it is at liberty to follow or to ignore. Therefore, an inline function can (should?) also have an external linkage. But since it is compiled as many times as there are of compilation units where it was defined, all its identical binary definitions have somehow to be "merge" at link time. I must admit that this part is a bit of black magic to me, but I seen that the use of weak symbols into the object files does the trick. Now about the "omp declare simd" attribute: nowhere in the OpenMP standard is it mentioned that an inline function cannot be declared as such. Therefore, considering that some explicit restrictions on the type of functions that can be are listed, it seems fair to assume that inline functions (as not listed as unfit) can be declared simd. And actually, so long as the simd-inline function get inlned by the complier, all goes well even with GCC (it works in any case with the Intel compler BTW). But as soon as, for a reason or another, the function isn't inlined, the compilation fails at the linking stage with a "multiple definition" error. And it looks like the reason is that the symbols for the vectorised versions of the out-of-line inline function are strong symbols instead of weak symbols. So my guess, and please forgive me if what I say is stupid, is that these symbols would only need to be defined weak for the bug to get fixed. I hope this makes (even a little) sense since I feel I'm playing way off my league here.
[Bug c++/68464] [6 Regression] ICE in valid constexpr function: ../../src/gcc/tree.c:11497
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68464 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/43745] [avr] g++ puts VTABLES in SRAM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43745
--- Comment #10 from Oscar García ---
This problem can be mitigated using "pointer to interfaces".
Instead of:
class A
{
public:
A();
void FncEatingVTableRamA();
void FncEatingVTableRamB();
void FncEatingVTableRamC();
void FncEatingVTableRamD();
void FncEatingVTableRamE();
void FncEatingVTableRamF();
virtual void FncASingleVirtualFunctionPutAllVTableInRam();
}
I use to change it to:
class IVirtual
{
virtual void FncASingleVirtualFunctionPutAllVTableInRam();
}
class ANotInRamVTable
{
IVirtual* pVirtual;
public:
A(IVirtual* pV)
{
pVirtual=pV
};
void FncEatingVTableRamA();
void FncEatingVTableRamB();
void FncEatingVTableRamC();
void FncEatingVTableRamD();
void FncEatingVTableRamE();
void FncEatingVTableRamF();
void FncNOTVirtual()
{
pVirtual->FncASingleVirtualFunctionPutAllVTableInRam();
}
class DerivedA:public IVirtual //Not derived actually
{
//REALIZE DerivedA will have VTABLE in ram because of IVirtual
ANotInRamVTable aNotInRam;
DerivedA():aNotInRam(this){};
void FncASingleVirtualFunctionPutAllVTableInRam();
}
It will not solve the problem, and I agree this is an important obstacle to
make reusable/scalable code in reduced-RAM environments but it helps sometimes.
[Bug rtl-optimization/68755] [5 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68755 Markus Trippelsdorf changed: What|Removed |Added CC||amker at gcc dot gnu.org Known to work|5.2.0 | --- Comment #9 from Markus Trippelsdorf --- It started with r208165.
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 --- Comment #2 from Markus Trippelsdorf --- (In reply to Jakub Jelinek from comment #1) > Try to preprocess with -fdirectives-only, and compile the result as > *.cpp/*.C rather than *.ii? If that triggers the ICE, you could attach the > result here, and/or reduce. Thanks. Unfortunately -fdirectives-only doesn't help.
[Bug c/68668] [6 Regression] bogus error: invalid use of array with unspecified bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68668 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- Fixed.
[Bug c/68668] [6 Regression] bogus error: invalid use of array with unspecified bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68668 --- Comment #5 from Marek Polacek --- Author: mpolacek Date: Mon Dec 7 17:52:23 2015 New Revision: 231374 URL: https://gcc.gnu.org/viewcvs?rev=231374&root=gcc&view=rev Log: PR c/68668 * c-decl.c (grokdeclarator): If ORIG_QUAL_INDIRECT is indirect, use TREE_TYPE of ORIG_QUAL_TYPE, otherwise decrement ORIG_QUAL_INDIRECT. * gcc.dg/pr68668.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr68668.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/testsuite/ChangeLog
[Bug target/68772] New: Many -gstabs tests FAIL with Xcode 7 as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68772 Bug ID: 68772 Summary: Many -gstabs tests FAIL with Xcode 7 as Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: iains at gcc dot gnu.org, mrs at gcc dot gnu.org Target Milestone: --- Host: x86_64-apple-darwin15.2.0 Target: x86_64-apple-darwin15.2.0 Build: x86_64-apple-darwin15.2.0 When using the LLVM-based assembler bundled with Xcode 7 and up, many -gstabs* tests FAIL: FAIL: gcc.dg/debug/20020220-1.c -gstabs1 (test for excess errors) Excess errors: ^[[1m/var/folders/1d/k16rgv6d5039jhvlj8_dzk4h00021y/T//cclVnbR6.s:1:9: ^[[0;1;31merror: ^[[0m^[[1munsupported directive '.stabs' ^[[0m.stabs "/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/debug/20020220-1.c",100,0,2,Ltext0 ^[[0;1;32m^ Obviously, the new assembler, unlike the old gas-based one, no longer supports Stabs. Apart from using a copy of an older assembler, I found that Xcode 7 still includes the old one, which is invoked if as -Q is called. Unfortunately, that -Q option, while available in some previous versions of Xcode (6.4 for example, which still defaults to the gas-based assembler), older ones lack it, so this cannot be used unconditionally. While one could argue that the testsuite, which currently only checks if the compiler accepts the -gstabs* options, should also check if the assembler groks the output, there's not much point in the compiler acception options when it's known that the assembler cannot deal with the output. So the correct fix seems to check for .stabs support in the assembler and only enable Stabs support if so. Rainer
[Bug target/68774] New: gcc should allow disabling markup in Xcode 7 assembler messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68774 Bug ID: 68774 Summary: gcc should allow disabling markup in Xcode 7 assembler messages Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: iains at gcc dot gnu.org, mrs at gcc dot gnu.org Target Milestone: --- Host: x86_64-apple-darwin15.2.0 Target: x86_64-apple-darwin15.2.0 Build: x86_64-apple-darwin15.2.0 While looking at PR target/68772, I noticed that the LLVM-based assembler in Xcode 7 emits color markup by default, turning the testsuite log files close to unreadable: ^[[1m/var/folders/1d/k16rgv6d5039jhvlj8_dzk4h00021y/T//cclVnbR6.s:1:9: ^[[0;1;31merror: ^[[0m^[[1munsupported directive '.stabs' ^[[0m.stabs "/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/debug/20020220-1.c",100,0,2,Ltext0 ^[[0;1;32m^ There should be a way to disable that markup if at all possible. On first glance, I didn't find anything in as(1), though. Rainer
[Bug c++/68738] call to overridden function segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68738
--- Comment #3 from Rian Quinn ---
Just for completeness, here is the exact code out objdump output:
class Blah1
{
public:
Blah1() {}
virtual ~Blah1() {}
virtual int foo() { return 0; }
};
class Blah2 : public Blah1
{
public:
Blah2() {}
~Blah2() {}
int foo() override { return 1; }
};
Blah2 g_blah2;
void
do_something()
{
Blah2 *bp1 = &g_blah2;
Blah2 &bp2 = g_blah2;
bp1->foo(); // Crashes
bp2.foo();// Does not crash
}
Using the cross-compiler (TARGET=x86_64-elf) you get the following:
0cd5 <_Z12do_somethingv>:
cd5: 55 push %rbp
cd6: 48 89 e5mov%rsp,%rbp
cd9: 48 83 ec 10 sub$0x10,%rsp
cdd: 48 8b 05 3c 07 20 00mov0x20073c(%rip),%rax# 201420
<_DYNAMIC+0x150>
ce4: 48 89 45 f8 mov%rax,-0x8(%rbp)
ce8: 48 8b 05 31 07 20 00mov0x200731(%rip),%rax# 201420
<_DYNAMIC+0x150>
cef: 48 89 45 f0 mov%rax,-0x10(%rbp)
cf3: 48 8b 45 f8 mov-0x8(%rbp),%rax
cf7: 48 8b 00mov(%rax),%rax
cfa: 48 83 c0 10 add$0x10,%rax
cfe: 48 8b 00mov(%rax),%rax
d01: 48 8b 55 f8 mov-0x8(%rbp),%rdx
d05: 48 89 d7mov%rdx,%rdi
d08: ff d0 callq *%rax
d0a: 48 8b 45 f0 mov-0x10(%rbp),%rax
d0e: 48 89 c7mov%rax,%rdi
d11: e8 5a fe ff ff callq b70 <_ZN5Blah23fooEv@plt>
d16: 90 nop
d17: c9 leaveq
d18: c3 retq
For the Native Ubuntu compiler I get:
00400b58 <_Z12do_somethingv>:
400b58: 55 push %rbp
400b59: 48 89 e5mov%rsp,%rbp
400b5c: 48 83 ec 10 sub$0x10,%rsp
400b60: 48 c7 45 f0 50 22 60movq $0x602250,-0x10(%rbp)
400b67: 00
400b68: 48 c7 45 f8 50 22 60movq $0x602250,-0x8(%rbp)
400b6f: 00
400b70: 48 8b 45 f0 mov-0x10(%rbp),%rax
400b74: 48 8b 00mov(%rax),%rax
400b77: 48 83 c0 10 add$0x10,%rax
400b7b: 48 8b 00mov(%rax),%rax
400b7e: 48 8b 55 f0 mov-0x10(%rbp),%rdx
400b82: 48 89 d7mov%rdx,%rdi
400b85: ff d0 callq *%rax
400b87: 48 8b 45 f8 mov-0x8(%rbp),%rax
400b8b: 48 89 c7mov%rax,%rdi
400b8e: e8 9f 06 00 00 callq 401232 <_ZN5Blah23fooEv>
400b93: 90 nop
400b94: c9 leaveq
400b95: c3 retq
The flags I am passing to the cross-compiler are:
-fpic -fno-rtti -fno-sized-deallocation -fno-exceptions -fno-use-cxa-atexit
-fno-threadsafe-statics
- Rian
[Bug lto/61886] [4.9/5/6 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #39 from Jan Hubicka --- Author: hubicka Date: Mon Dec 7 17:36:54 2015 New Revision: 231373 URL: https://gcc.gnu.org/viewcvs?rev=231373&root=gcc&view=rev Log: PR ipa/61886 * symtab.c (ultimate_transparent_alias_target): New inline function. (symbol_table::assembler_names_equal_p): New method; break out from ... (symbol_table::decl_assembler_name_equal): ... here. (symbol_table::change_decl_assembler_name): Also update names and translation links of transparent aliases. (symtab_node::dump_base): Dump transparent_alias. (symtab_node::verify_base): Implement basic transparent alias verification. (symtab_node::make_decl_local): Support localization of weakrefs; recurse to transparent aliases; set TREE_STATIC. (symtab_node::ultimate_alias_target_1): Handle visibility of transparent aliases. (symtab_node::resolve_alias): New parmaeter transparent; handle transparent aliases; recurse to aliases of aliases to fix comdat groups. (symtab_node::get_partitioning_class): Handle transparent aliases. * ipa-visibility.c (cgraph_externally_visible_p, varpool_node::externally_visible_p): Visibility of transparent alias depends on its target. (function_and_variable_visibility): Do not tweak visibility of transparent laiases. (function_and_variable_visibility): Likewise. * ipa.c (symbol_table::remove_unreachable_nodes): Clear transparent_alias flag. * alias.c (cgraph_node::create_alias, cgraph_node::get_availability): Support transparent aliases. * cgraph.h (symtab_node): Update prototype of resolve_alias; add transparent_alias flag. (symbol_table: Add assembler_names_equal_p. (symtab_node::real_symbol_p): Skip transparent aliases. * cgraphunit.c (cgraph_node::reset): Reset transparent_alias flag. (handle_alias_pairs): Set transparent_alias for weakref. (cgraph_node::assemble_thunks_and_aliases): Do not asemble transparent aliases. * lto-cgraph.c (lto_output_node): When outputting same_comdat_group skip symbols not put into boundary; stream transparent_alias. (lto_output_varpool_node): Likewise. (input_overwrite_node, input_varpool_node): Stream transparent alias. * varpool.c (ctor_for_folding, varpool_node::get_availability, varpool_node::assemble_aliases, symbol_table::remove_unreferenced_decls): Handle transparent aliase. (varpool_node::create_alias): Set transparent_alias. * lto-partition.c (add_symbol_to_partition_1, contained_in_symbol, rename_statics, rename_statics): Handle transparent aliases. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.c trunk/gcc/cgraph.h trunk/gcc/cgraphunit.c trunk/gcc/ipa-visibility.c trunk/gcc/ipa.c trunk/gcc/lto-cgraph.c trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto-partition.c trunk/gcc/symtab.c trunk/gcc/tree.c trunk/gcc/varpool.c
[Bug c++/68679] [5/6 Regression] gcc-5.2.1 ICE in C++11 anon union of structs with template fns, OK in gcc <= 4.9.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68679
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Reduced testcase:
typedef struct {
struct {
unsigned d[4];
template
unsigned operator[] (T i) const { return d[i]; }
} c;
} A;
The ICE is because TYPENAME_DECL appears among the methods.
[Bug tree-optimization/68773] New: fpta-ipa with GOACC_parallel does not work due to node->force_output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68773
Bug ID: 68773
Summary: fpta-ipa with GOACC_parallel does not work due to
node->force_output
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: ---
As reported here ( https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00330.html ),
some c-c++-common/goacc/kernels-alias-ipa-pta-{,2}.c scan tests fail. The tests
pass for a compiler configured without accelerator, and fail for a compiler
configure with accelerator.
For the configuration with accelerator, the test fails because the force_output
flag is set for the offloaded function, which causes the thread function to be
handled as a non-local function in fipa-pta.
The force_output flag is set by this bit here in expand_omp_target (which
explains why we don't see the problem in the configuration without accelerator,
which doesn't have ENABLE_OFFLOADING set):
...
12682 /* Prevent IPA from removing child_fn as unreachable,
since there are no
12683refs from the parent function to child_fn in offload
LTO mode. */
12684 if (ENABLE_OFFLOADING)
12685 cgraph_node::get (child_fn)->mark_force_output ();
...
[Bug c++/68738] call to overridden function segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68738 --- Comment #2 from Rian Quinn --- Yeah I'm am pretty sure it is specific to TARGET=elf-x86_64 (i.e. no OS specified). When I ran the same test on Ubuntu's native GCC it ran fine. objdump showed pretty different assembly for the Ubuntu case, vs. the cross-compiled case. For the code that does not crash (using the reference instead of the pointer) the code is identical.
[Bug c++/68728] ice: unexpected expression ‘(const char*)__s’ of kind implicit_conv_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68728 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-07 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug target/68701] [4.9/5/6 Regression] "gcc -m32 -finstrument-functions -ffixed-ebp" produces internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68701
Jakub Jelinek changed:
What|Removed |Added
CC||rth at gcc dot gnu.org,
||uros at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
As main needs dynamic stack realignment, I wonder if we just shouldn't error
out on trying to compile it with -ffixed-ebp.
void foo (void);
int
main (int argc, char *argv[])
{
foo ();
return argc - 1;
}
ICEs with -m32 -O0 -ffixed-ebp too.
[Bug c++/68732] Internal error while compiling CLRadeonExtender
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68732 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-12-07 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Marek Polacek --- Waiting then.
[Bug c++/68738] call to overridden function segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68738 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Doesn't crash on x86_64-linux.
[Bug rtl-optimization/68755] [5 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68755 --- Comment #8 from H.J. Lu --- (In reply to ktkachov from comment #4) > > but the e[8000] is inside the "while (a)" loop and should not be reachable > since 'a' is always 0? 'a' can be initialized via a constructor.
[Bug target/68701] [4.9/5/6 Regression] "gcc -m32 -finstrument-functions -ffixed-ebp" produces internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68701 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- With additional -mno-accumulate-outgoing-args this started with r163196, without that extra option it started with r206947.
[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|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Eric Botcazou --- .
[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|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Eric Botcazou --- .
[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 #12 from Eric Botcazou --- Author: ebotcazou Date: Mon Dec 7 16:45:45 2015 New Revision: 231372 URL: https://gcc.gnu.org/viewcvs?rev=231372&root=gcc&view=rev Log: PR middle-end/68291 PR middle-end/68292 * cfgexpand.c (set_rtl): Always accept PARALLELs with BLKmode for SSA names based on RESULT_DECLs. * function.c (expand_function_start): Do not create BLKmode REGs for GIMPLE registers when coalescing is enabled. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/function.c
[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 --- Comment #4 from Eric Botcazou --- Author: ebotcazou Date: Mon Dec 7 16:45:45 2015 New Revision: 231372 URL: https://gcc.gnu.org/viewcvs?rev=231372&root=gcc&view=rev Log: PR middle-end/68291 PR middle-end/68292 * cfgexpand.c (set_rtl): Always accept PARALLELs with BLKmode for SSA names based on RESULT_DECLs. * function.c (expand_function_start): Do not create BLKmode REGs for GIMPLE registers when coalescing is enabled. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/function.c
[Bug rtl-optimization/68730] [6 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68730 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- And I can reproduce the hang but not the ICE ;).
[Bug rtl-optimization/68755] [5 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68755 Markus Trippelsdorf changed: What|Removed |Added CC||mjambor at suse dot cz --- Comment #7 from Markus Trippelsdorf --- --param=allow-store-data-races=1 fixes the issue. With --param=allow-store-data-races=0 even 4.9 generates wrong code.
[Bug rtl-optimization/68730] [6 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68730 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Weird, can't reproduce either the hang (with -O3 -m32) nor the ICE (-O3 -m32 -fno-if-conversion).
[Bug pch/68758] [6 Regression] Invalid read of size 8 in gt_pch_save (ggc-common.c:551)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68758 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Is your gcc configured with --enable-valgrind-annotations ?
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Try to preprocess with -fdirectives-only, and compile the result as *.cpp/*.C rather than *.ii? If that triggers the ICE, you could attach the result here, and/or reduce.
[Bug tree-optimization/68659] [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68659 Sebastian Pop changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE |--- --- Comment #10 from Sebastian Pop --- Thanks for reporting. I will have a look at what happens on arm.
[Bug c++/66460] ICE using __func__ in constexpr function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66460 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- Started with r217663.
[Bug testsuite/68751] FAIL: gcc.dg/sancov/asan.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68751 --- Comment #5 from Yury Gribov --- You most probably can't.
[Bug tree-optimization/68659] [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68659 mwahab at gcc dot gnu.org changed: What|Removed |Added CC||mwahab at gcc dot gnu.org --- Comment #9 from mwahab at gcc dot gnu.org --- I still see this on arm-none-eabi.
[Bug debug/68771] New: Darwin: Profile guided optimisation with cold sections and invalid symbol redefinition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68771 Bug ID: 68771 Summary: Darwin: Profile guided optimisation with cold sections and invalid symbol redefinition Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: zerolo at gmail dot com Target Milestone: --- Created attachment 36944 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36944&action=edit Patch to make cold section label unique(r?) I'm not sure which component to attach this report to, the problem seems to be specific to Darwin (and stem from its format for debug symbols but is present whether generating debug info or not), but relates to both PGO (which causes the cold and hot splits) and is exacerbate by LTO. On the Darwin platform, a label is inserted for debugging / EH purposes when a function is split into hot / hold (with info generated from PGO). Rough repo steps for Mac OS 10.11.1 El Yosemite with Homebrew gcc 5.3.0 1) Compile/link C++ project with -Ofast -DNDEBUG -flto -fprofile-generate 2) Run to generate profiling files 3) Compile/link C++ project with -Ofast -DNDEBUG -flto -fprofile-use Step 3's link aborts on multiple temporary assembler files with errors such as /var/folders/02/yl3m8d4d0397mk6dxn6dpcqwgp/T//ccgBAKOU.s:3430:1: error: invalid symbol redefinition ___cold_sect_of_ComputeBoundingBox: ^ /var/folders/02/yl3m8d4d0397mk6dxn6dpcqwgp/T//ccHiavMh.s:1652:1: error: invalid symbol redefinition ___cold_sect_of_GetInterpolationMatrix: ^ /var/folders/02/yl3m8d4d0397mk6dxn6dpcqwgp/T//ccjQlEWp.s:11019:1: error: invalid symbol redefinition ___cold_sect_of_GetReferencePoints: ^ The methods mentioned exist multiple times, but either as different overloads (different C++ arguments, so distinct mangled name), or in completely difference classes (or static in distinct files). The machinery that actually generates those __cold_sect_of_ seems to be set up in gcc/config/darwin.c:3682. Originally this seems to come from a patch for debugging information here https://gcc.gnu.org/ml/gcc-patches/2010-12/msg01609.html These label are derived *only* from the name of the function, so it fails when multiple overloads are present, also seems to cause problems with LTO. When I change darwin.c to use DECL_ASSEMBLER_NAME instead (and increase the buffer size for really long mangled names), the link works, although I'm not sure about the accuracy of debug information.
[Bug ipa/66896] ipa-prop.c:2479 runtime error: member call on null pointer of type 'struct ipa_polymorphic_call_context'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66896 --- Comment #16 from Martin Liška --- (In reply to Jakub Jelinek from comment #15) > The commits mentioned a test being added to the testsuite, but it doesn't > seem to have been added. Also, the ChangeLog entry mentioned wrong > extension (in g++.dg/ipa/ it should be *.C instead of *.c). Thanks for pointing out, fixed both for gcc-5-branch and trunk. Martin
[Bug rtl-optimization/68755] [5 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68755 --- Comment #6 from Markus Trippelsdorf --- Also happens with -m64 with gcc-5.3.
[Bug testsuite/68751] FAIL: gcc.dg/sancov/asan.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68751 --- Comment #4 from Dmitry Vyukov --- Do I have rights to change status? Can't find how to close this...
[Bug testsuite/68751] FAIL: gcc.dg/sancov/asan.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68751 --- Comment #3 from Dmitry Vyukov --- Committed fix as 231364.
[Bug rtl-optimization/68755] [5 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68755 Markus Trippelsdorf changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #5 from Markus Trippelsdorf --- (In reply to ktkachov from comment #4) > but the e[8000] is inside the "while (a)" loop and should not be reachable > since 'a' is always 0? Fair enough. Good vs.bad: ... - testl %ebx, %ebx - je .L9 movzbl 7987(%ebp), %ecx + testl %ebx, %ebx + je .L24
[Bug c++/68760] [6 Regression] ICE in pp_string (pretty-print.c:909)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68760 --- Comment #2 from Martin Liška --- (In reply to Jakub Jelinek from comment #1) > Created attachment 36943 [details] > gcc6-pr68760.patch > > Using input_location in this routine doesn't make any sense. Works for me for the original test-case which is tramp3d. Thanks, Martin
[Bug c++/68170] [6 Regression] Declaring friend template class template in C++1z produces error: specialization of ‘template class A’ must appear at namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68170 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/68770] New: [6 Regression] Conditional jump or move depends on uninitialised value(s) default_secondary_reload() targhooks.c:940
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68770 Bug ID: 68770 Summary: [6 Regression] Conditional jump or move depends on uninitialised value(s) default_secondary_reload() targhooks.c:940 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Target Milestone: --- Host: powerpc64-unknown-linux-gnu Target: powerpc64-unknown-linux-gnu Build: powerpc64-unknown-linux-gnu checking=valgrind shows: ==115918== Conditional jump or move depends on uninitialised value(s) ==115918==at 0x107D29F4: default_secondary_reload(bool, rtx_def*, int, machine_mode, secondary_reload_info*) (targhooks.c:940) ==115918==by 0x10AD9B93: rs6000_secondary_reload(bool, rtx_def*, int, machine_mode, secondary_reload_info*) (rs6000.c:18414) ==115918==by 0x105FBCB7: copy_cost(rtx_def*, machine_mode, int, bool, secondary_reload_info*) [clone .part.7] (ira-costs.c:445) ==115918==by 0x105FBD27: copy_cost (ira-costs.c:434) ==115918==by 0x105FBD27: copy_cost(rtx_def*, machine_mode, int, bool, secondary_reload_info*) [clone .part.7] (ira-costs.c:452) ==115918==by 0x105FC243: copy_cost (ira-costs.c:434) ==115918==by 0x105FC243: record_reg_classes(int, int, rtx_def**, machine_mode*, char const**, rtx_insn*, reg_class*) [clone .constprop.42] (ira-costs.c:984) ==115918==by 0x105FE11F: record_operand_costs(rtx_insn*, reg_class*) (ira-costs.c:1325) ==115918==by 0x105FE657: scan_one_insn (ira-costs.c:1462) ==115918==by 0x105FE657: process_bb_for_costs(basic_block_def*) (ira-costs.c:1583) ==115918==by 0x105F488F: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1798) ==115918==by 0x10600E3B: find_costs_and_classes(_IO_FILE*) (ira-costs.c:1680) ==115918==by 0x1060160F: ira_costs() (ira-costs.c:2213) ==115918==by 0x105F9F0F: ira_build() (ira-build.c:3419) ==115918==by 0x105EDE03: ira (ira.c:5219) ==115918==by 0x105EDE03: (anonymous namespace)::pass_ira::execute(function*) (ira.c:5511) ==115918==
[Bug c++/68760] [6 Regression] ICE in pp_string (pretty-print.c:909)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68760 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-12-07 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 36943 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36943&action=edit gcc6-pr68760.patch Using input_location in this routine doesn't make any sense.
[Bug rtl-optimization/68755] [5 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68755
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
--- Comment #4 from ktkachov at gcc dot gnu.org ---
(In reply to Markus Trippelsdorf from comment #3)
> (In reply to H.J. Lu from comment #2)
> > (In reply to Zhendong Su from comment #0)
> > >
> > > int
> > > main ()
> > > {
> > > char e[5];
> >
> > > for (; c < 5; c++)
> > > {
> > > while (a)
> > > {
> > > b = d;
> > > if (e[8000])
> > ^ Is this valid C code?
>
> No, it isn't.
but the e[8000] is inside the "while (a)" loop and should not be reachable
since 'a' is always 0?
[Bug ipa/66896] ipa-prop.c:2479 runtime error: member call on null pointer of type 'struct ipa_polymorphic_call_context'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66896 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #15 from Jakub Jelinek --- The commits mentioned a test being added to the testsuite, but it doesn't seem to have been added. Also, the ChangeLog entry mentioned wrong extension (in g++.dg/ipa/ it should be *.C instead of *.c).
