[Bug c++/65869] Incorrect overload resolution in function return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65869
--- Comment #2 from Botond Ballo botond at mozilla dot com ---
(In reply to Marc Glisse from comment #1)
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579
I don't think the resolution of this issue affects the validity of my code
example, i.e. it remains invalid.
The resolution of this issue makes the following code valid:
Derived foo() {
Base result;
return result;
}
(because it allows [class.copy] p32 to apply at all, where previously it didn't
apply because the type of the object to be copied, Base, was different from the
return type of the function Derived).
In my example, however:
Derived foo() {
Derived result;
return result;
}
p32 already applies, with or without the added wording. The problem is wording
further down in the paragraph which prevents the 'Derived(Base)' constructor
from being selected in the first overload resolution when the type of the
object is Derived.
[Bug c/61534] Wlogical-op should not warn when either operand comes from macro expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61534 --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Fri Apr 24 11:49:52 2015 New Revision: 222406 URL: https://gcc.gnu.org/viewcvs?rev=222406root=gccview=rev Log: PR c/61534 * input.h (from_macro_expansion_at): Define. * c-common.c (warn_logical_operator): Bail if either operand comes from a macro expansion. * c-c++-common/pr61534-1.c: New test. Added: trunk/gcc/testsuite/c-c++-common/pr61534-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/input.h trunk/gcc/testsuite/ChangeLog
[Bug target/65867] [5 Regression] bootstrap fails for mingw32 due to missing header in ssp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65867 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||build Target Milestone|--- |5.2
[Bug other/53313] Add warning levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53313 --- Comment #10 from Marc Glisse glisse at gcc dot gnu.org --- Manuel, you seem to want a -Wsuper-extra that you can use everyday (maybe with a couple -Wno-*). What some other people want with -Weverything is a way to discover what warnings are available in the compiler. For instance, they discover a bug or a performance issue in their code, extract a small reproducer, and want to find if there exists a flag that would help them narrow down the places they need to review in the rest of their code base for similar issues. So yes, it should warn all over the place and give contradictory advice, it should even include the warning that just tells you how large your function is. As a bonus, this makes it obvious to users that they are not supposed to make their code -Weverything clean. Maybe the name -Wrant would make it more acceptable?
[Bug other/53313] Add warning levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53313
--- Comment #9 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to David Stone from comment #8)
I have changed my opinion on this and agree that warning levels are probably
not the way to go. The two things from this that I do still want are
-Weverything-and-I-really-mean-it-this-time
Do you really want -Wdouble-promotion:
float area(float radius)
{
return 3.14159 * radius * radius; // warns!
}
And -Wtraditional? It warns for example for:
* The unary plus operator.
* A switch statement has an operand of type long.
And what should happen for -Wc90-c99-compat -Wc99-c11-compat and -Wc++-compat?
They will warn for bool, long long, etc, even if you use '-std=c11'.
As an exercise, you can take the list given by:
wget https://gcc.gnu.org/svn/gcc/trunk/gcc/doc/invoke.texi
grep '@item -W[^ ]\+' -o invoke.texi | grep -v '@item -Wno-\|-Werror\|-Wfatal-'
and try to build any large piece of software with it and see if you still want
-Weverything-and-I-really-mean-it-this-time.
[Bug c++/65872] Multiple class prefixes in method implementation are accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65872 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- The code is valid, X::X finds the injected-class-name in the scope of X.
[Bug c++/65869] Incorrect overload resolution in function return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65869 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-24 Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Botond Ballo from comment #0) - However, p32 says that if the type of the first parameter of the selected constructor is not an rvalue reference to the object's type, then overload resolution is performed again, treating the object as an rvalue. Typo, this should say lvalue.
[Bug tree-optimization/65818] [6 Regression] libiberty/vprintf-support.c:41:1: ICE: in expand_i fn_va_arg_1, at tree-stdarg.c:1095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65818 --- Comment #9 from dave.anglin at bell dot net --- On 2015-04-22, at 12:40 PM, vries at gcc dot gnu.org wrote: this patch is more conservative: ... diff --git a/gcc/gimplify.c b/gcc/gimplify.c index 7786e16..e23f510 100644 --- a/gcc/gimplify.c +++ b/gcc/gimplify.c @@ -9336,7 +9336,12 @@ gimplify_va_arg_internal (tree valist, tree type, location_t loc, else gimplify_expr (valist, pre_p, post_p, is_gimple_min_lval, fb_lvalue); - return targetm.gimplify_va_arg_expr (valist, type, pre_p, post_p); + tree expr = targetm.gimplify_va_arg_expr (valist, type, pre_p, post_p); + gcc_assert (TREE_CODE (expr) == MEM_REF); + if (!is_gimple_mem_ref_addr (TREE_OPERAND (expr, 0))) +gimplify_expr (TREE_OPERAND (expr, 0), pre_p, post_p, + is_gimple_mem_ref_addr, fb_rvalue); + return expr; } /* Gimplify __builtin_va_arg, aka VA_ARG_EXPR, which is not really a This patch has the following new failure: /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/pr65802.C: In function 'void fn1()': /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/pr65802.C:20:23: error: impossible constraint in 'asm' FAIL: g++.dg/pr65802.C -std=gnu++98 (test for excess errors) FAIL: g++.dg/pr65802.C -std=gnu++11 (test for excess errors) FAIL: g++.dg/pr65802.C -std=gnu++14 (test for excess errors) -- John David Anglindave.ang...@bell.net
[Bug rtl-optimization/65805] [5 Regression] Chromium gets miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65805 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug target/65867] [5/6 Regression] bootstrap fails for mingw32 due to missing header in ssp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65867 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||ktietz at gcc dot gnu.org Summary|[5 Regression] bootstrap|[5/6 Regression] bootstrap |fails for mingw32 due to|fails for mingw32 due to |missing header in ssp.c |missing header in ssp.c --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Supposedly started with r220559.
[Bug middle-end/65874] New: [5.2 Regression] bootstrap comparison failure (gcc/ira.o) on ia64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65874 Bug ID: 65874 Summary: [5.2 Regression] bootstrap comparison failure (gcc/ira.o) on ia64-linux-gnu Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org seen with the 5.1 release on ia64-linux-gnu, make[5]: Leaving directory `/build/buildd/gcc-5-5.1.0/build' Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1objplus-checksum.o differs Bootstrap comparison failure! gcc/ira.o differs make[4]: *** [compare] Error 1 make[4]: Leaving directory `/build/buildd/gcc-5-5.1.0/build' make[3]: *** [stage3-bubble] Error 2 make[3]: Leaving directory `/build/buildd/gcc-5-5.1.0/build' make[2]: *** [bootstrap] Error 2
[Bug c/65830] -Wno-shift-count-negative -Wno-shift-count-overflow don't work with const ints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65830 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Fri Apr 24 11:53:27 2015 New Revision: 222407 URL: https://gcc.gnu.org/viewcvs?rev=222407root=gccview=rev Log: PR c/65830 * c-common.c (c_fully_fold_internal): Use OPT_Wshift_count_negative and OPT_Wshift_count_overflow. * c-c++-common/pr65830.c: New test. Added: trunk/gcc/testsuite/c-c++-common/pr65830.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/testsuite/ChangeLog
[Bug c/65830] -Wno-shift-count-negative -Wno-shift-count-overflow don't work with const ints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65830 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug ipa/65873] New: [5/6 Regression] Failure to inline always_inline memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65873
Bug ID: 65873
Summary: [5/6 Regression] Failure to inline always_inline
memcpy
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
typedef __SIZE_TYPE__ size_t;
extern inline __attribute__ ((__always_inline__, __gnu_inline__,
__artificial__, __nothrow__, __leaf__)) void *
memcpy (void *__restrict __dest, const void *__restrict __src, size_t __len)
{
return __builtin___memcpy_chk (__dest, __src, __len, __builtin_object_size
(__dest, 0));
}
__attribute__((optimize (Ofast))) void
bar (void *d, void *s, size_t l)
{
memcpy (d, s, l);
}
fails to compile starting with r221706 (or r221707, neither of those versions
compile, r221704 works, r221710 fails).
This makes with -D_FORTIFY_SOURCE=2 all fortified functions unusable in
functions with explicit (non-default) optimize attribute.
As the always_inline function doesn't have a specific optimize attribute, I'd
say at least for always_inline functions it is undesirable to refuse to inline
them. For target attribute, do we also refuse to inline, if say the whole CU
is compiled with -mavx2 and some function uses __attribute__((target (sse2)))
and calls memcpy?
[Bug ipa/65873] [5/6 Regression] Failure to inline always_inline memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65873 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-24 CC||hubicka at gcc dot gnu.org Ever confirmed|0 |1
[Bug ipa/65873] [5/6 Regression] Failure to inline always_inline memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65873 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |5.2
[Bug c++/65870] Explicit function instantiation with default valued lambda causes duplicate symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65870 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-24 Ever confirmed|0 |1
[Bug c/63357] Warn for P P and P || P (same expression used multiple times in a condition)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63357 --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Fri Apr 24 12:10:52 2015 New Revision: 222408 URL: https://gcc.gnu.org/viewcvs?rev=222408root=gccview=rev Log: PR c/63357 * c-common.c (warn_logical_operator): Warn if the operands have the same expressions. * doc/invoke.texi: Update description of -Wlogical-op. * c-c++-common/Wlogical-op-1.c: New test. Added: trunk/gcc/testsuite/c-c++-common/Wlogical-op-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug c++/65876] [5/6 Regression] [C++11] ICE in cxx_eval_call_expression, at cp/constexpr.c:1358
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65876 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-24 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |5.2 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r220544.
[Bug middle-end/65877] New: ICE: various internal errors with attribute(target) when mixing generic and non-generic vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65877
Bug ID: 65877
Summary: ICE: various internal errors with attribute(target)
when mixing generic and non-generic vectors
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: robert.suchanek at imgtec dot com
I came across some ICEs whilst implementing target attribute for MIPS and it
appears to be more generic. At least the following test case (with target
attribute adapted for x86) fails in the same place:
/* Excerpt from emmintrin.h */
#pragma GCC push_options
#pragma GCC target(sse2)
typedef char __v16qi __attribute__ ((__vector_size (16)))
#pragma GCC pop_options
__v16qi a, b, c;
__attribute__((target(sse2)))
__v16qi foo()
{
return a;
}
gcc -O1 -msse -mno-sse2 fails with error (reproducible on the trunk and likely
in older releases):
t-x86.c: In function`foo`:
t-x86.c:41:10: internal compiler error: in emit_move_insn, at expr.c:3601
return b;
^
0x9a754d emit_move_insn(rtx_def*, rtx_def*)
/scratch/mips-gcc/src/gcc/gcc/expr.c:3600
0x87b031 expand_value_return
/scratch/mips-gcc/src/gcc/gcc/cfgexpand.c:3177
0x87b851 expand_return
/scratch/mips-gcc/src/gcc/gcc/cfgexpand.c:3300
0x87ba89 expand_gimple_stmt_1
/scratch/mips-gcc/src/gcc/gcc/cfgexpand.c:3373
0x87bff2 expand_gimple_stmt
/scratch/mips-gcc/src/gcc/gcc/cfgexpand.c:3497
0x8830c2 expand_gimple_basic_block
/scratch/mips-gcc/src/gcc/gcc/cfgexpand.c:5509
0x884d39 execute
/scratch/mips-gcc/src/gcc/gcc/cfgexpand.c:6127
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
It doesn't crash when I do an assignment in the function e.g. a = b; since
during expansion convert_move is called that appears to fix up the modes but it
does not seem to work for a simple addition i.e. a = b + c, and throws a
different internal error.
The test cases for the target attribute avoid using a global variable and I've
seen only an example of using an array of vectors that doesn't expose this.
Wrapping declarations of variables with #pragma GCC push_options/pop_options
and adding #pragma GCC target forces to use vector modes as if it was compiled
with -msse2 and no error is thrown.
One of the problems I see is that TYPE_MODE(TREE_TYPE(a)) has V16QImode but the
DECL_MODE(a) has TImode because during layout the current target did not have
SSE2. This is pretty much the same analysis as Jakub's
https://gcc.gnu.org/ml/gcc-patches/2013-05/msg00708.html but it relates to AVX.
I imagine __m256 failing for target(avx) too having BLKmode instead of
TImode.
__v4si works for target(sse2) as ix86_vector_mode_supported_p returns true
since SSE supports V4SImode but I'm almost confident that all SSE2 supported
modes would crash.
There are other failing cases with the one already mentioned above:
__attribute__((target(sse2)))
__void foo2()
{
a = b + c;
}
__attribute__((target(sse2)))
__v16qi foo3(__v16qi x)
{
return x;
}
ICEing differently.
Or maybe I missed something obvious and vectors shouldn't be used like that?
Mixing generic and non-generic vectors does not seem to be a good idea but I
think ICEs are still bad and this would need either fixing or some diagnostics.
[Bug other/53313] Add warning levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53313 --- Comment #11 from David Stone david at doublewise dot net --- If the warnings are so ridiculous that no one could possibly want them on, then maybe we should remove them. Otherwise, I would want -Weverything and I can use -Wno-warnings-I-do-not-want
[Bug tree-optimization/65802] [6 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65802 --- Comment #11 from vries at gcc dot gnu.org --- Author: vries Date: Fri Apr 24 14:18:57 2015 New Revision: 222413 URL: https://gcc.gnu.org/viewcvs?rev=222413root=gccview=rev Log: Replace g++.dg/pr65802.C with gcc.dg/pr65802.c 2015-04-24 Tom de Vries t...@codesourcery.com PR tree-optimization/65802 * g++.dg/pr65802.C: Move to ... * gcc.dg/pr65802.c: ... here. Add -fexceptions to dg-options. Include stdarg.h. Rewrite for C. (fn1): Use va_list and va_arg. Make variable args function. Add use of va_start and va_end. Remove unnecessary inline asm. Added: trunk/gcc/testsuite/gcc.dg/pr65802.c Removed: trunk/gcc/testsuite/g++.dg/pr65802.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c/63357] Warn for P P and P || P (same expression used multiple times in a condition)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63357 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65875
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
Summary|internal compiler error |[5/6 Regression] ICE:
|with gcc 5.1|Segmentation fault
--- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
int a, b, c, d, e, f, g;
void
fn1 ()
{
long h = 0, i;
if (g 0)
i = -g;
for (; b;)
for (; c;)
if (e)
h = 1;
for (; f;)
if (a)
break;
if (h i)
while (h i)
{
d = 0;
h--;
}
}
[Bug c++/65876] New: [5/6 Regression] [C++11] ICE in cxx_eval_call_expression, at cp/constexpr.c:1358
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65876
Bug ID: 65876
Summary: [5/6 Regression] [C++11] ICE in
cxx_eval_call_expression, at cp/constexpr.c:1358
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: maltsevm at gmail dot com
Consider the following code:
$ cat test.cc
templateint
struct duration
{
constexpr duration() : r(0) {}
templateint TPeriod
constexpr duration(durationTPeriod x) : r(x.count()) {}
constexpr int count() { return 0; }
int r;
};
struct Config {
duration1 timeout { duration2() };
};
Config make_config()
{
return {};
}
struct ConfigArray {
ConfigArray();
Config all_configs[1];
};
ConfigArray::ConfigArray()
{
}
When trying to compile it with GCC 5.1 or trunk r222403 using the following
options:
$ g++ -c -std=c++11 ./test.cc
I get the following error:
./test.cc: In constructor 'ConfigArray::ConfigArray()':
./test.cc:28:26: in constexpr expansion of 'Config()'
./test.cc:28:26: in constexpr expansion of 'duration1(duration2())'
./test.cc:7:58: in constexpr expansion of 'x.durationanonymous
::count2()'
./test.cc:28:26: internal compiler error: in cxx_eval_call_expression, at
cp/constexpr.c:1331
ConfigArray::ConfigArray()
^
0x7eb08e cxx_eval_call_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:1331
0x7ebf0c cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3038
0x7ef0ca cxx_eval_store_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:2651
0x7ec869 cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3112
0x7ec052 cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3365
0x7ec310 cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3229
0x7ec310 cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3229
0x7ebf64 cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3406
0x7f229e cxx_eval_statement_list
/home/miyuki/gcc/src/gcc/cp/constexpr.c:2828
0x7ec76c cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3400
0x7eb188 cxx_eval_call_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:1365
0x7ebf0c cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3038
0x7ecc94 cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3097
0x7ef0ca cxx_eval_store_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:2651
0x7ec869 cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3112
0x7ec052 cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3365
0x7ec310 cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3229
0x7ec310 cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3229
0x7ebf64 cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3406
0x7f229e cxx_eval_statement_list
/home/miyuki/gcc/src/gcc/cp/constexpr.c:2828
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 other/53313] Add warning levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53313 --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to David Stone from comment #11) If the warnings are so ridiculous that no one could possibly want them on, then maybe we should remove them. No because there's a difference between something that is only useful in very specialized cases and not useful at all. Having spoken to core LLVM developers about -Weverything it was *not* added for users, it was added for internal reasons, and is seen by some as a bad idea.
[Bug c/65875] New: internal compiler error with gcc 5.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65875
Bug ID: 65875
Summary: internal compiler error with gcc 5.1
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: megahallon at gmail dot com
Created attachment 35394
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35394action=edit
Preprocessed C file causing gcc crash
The enclosed file crashes gcc when compiled with -O2 as seen below. -O1 works.
It works with gcc 4.9.0.
$ gcc -v -O2 -c ~/gcc5.1bug.c
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/usr/local --enable-languages=c,c++
--disable-multilib
Thread model: posix
gcc version 5.1.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-O2' '-c' '-mtune=generic' '-march=x86-64'
/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/cc1 -quiet -v
/home/hallon/gcc5.1bug.c -quiet -dumpbase gcc5.1bug.c -mtune=generic
-march=x86-64 -auxbase gcc5.1bug -O2 -version -o /tmp/cccJihQs.s
GNU C11 (GCC) version 5.1.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.1.0, GMP version 6.0.0, MPFR version 3.1.2, MPC
version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/include
/usr/local/include
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/include-fixed
/usr/include
End of search list.
GNU C11 (GCC) version 5.1.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.1.0, GMP version 6.0.0, MPFR version 3.1.2, MPC
version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2f2bc897849713002cc329f649d8
src/sets/bitset.c: In function ‘mutbitset_iop_PyLongObject’:
src/sets/bitset.c:2021:20: warning: passing argument 1 of ‘_PyLong_Frexp’ from
incompatible pointer type [-Wincompatible-pointer-types]
In file included from
/srv/sdb1/jenkins/workspaces/develop-5.x/tmp/deploy/include/python2.7/Python.h:88:0,
from src/sets/bitset.c:3:
/srv/sdb1/jenkins/workspaces/develop-5.x/tmp/deploy/include/python2.7/longobject.h:43:8:
note: expected ‘PyLongObject * {aka struct _longobject *}’ but argument is of
type ‘PyObject * {aka struct _object *}’
src/sets/bitset.c:2021:23: warning: passing argument 2 of ‘_PyLong_Frexp’ from
incompatible pointer type [-Wincompatible-pointer-types]
In file included from
/srv/sdb1/jenkins/workspaces/develop-5.x/tmp/deploy/include/python2.7/Python.h:88:0,
from src/sets/bitset.c:3:
/srv/sdb1/jenkins/workspaces/develop-5.x/tmp/deploy/include/python2.7/longobject.h:43:8:
note: expected ‘Py_ssize_t * {aka long int *}’ but argument is of type ‘int *’
src/sets/bitset.c:2034:20: warning: passing argument 1 of ‘_PyLong_Frexp’ from
incompatible pointer type [-Wincompatible-pointer-types]
In file included from
/srv/sdb1/jenkins/workspaces/develop-5.x/tmp/deploy/include/python2.7/Python.h:88:0,
from src/sets/bitset.c:3:
/srv/sdb1/jenkins/workspaces/develop-5.x/tmp/deploy/include/python2.7/longobject.h:43:8:
note: expected ‘PyLongObject * {aka struct _longobject *}’ but argument is of
type ‘PyObject * {aka struct _object *}’
src/sets/bitset.c:2034:23: warning: passing argument 2 of ‘_PyLong_Frexp’ from
incompatible pointer type [-Wincompatible-pointer-types]
In file included from
/srv/sdb1/jenkins/workspaces/develop-5.x/tmp/deploy/include/python2.7/Python.h:88:0,
from src/sets/bitset.c:3:
/srv/sdb1/jenkins/workspaces/develop-5.x/tmp/deploy/include/python2.7/longobject.h:43:8:
note: expected ‘Py_ssize_t * {aka long int *}’ but argument is of type ‘int *’
src/sets/bitset.c: In function ‘sf_slice’:
src/sets/bitset.c:2985:1: internal compiler error: Segmentation fault
0x9bab0f crash_signal
../.././gcc/toplev.c:383
0xb73110 compare_values_warnv
../.././gcc/tree-vrp.c:1337
0xb7371c compare_values
../.././gcc/tree-vrp.c:1533
0xb833bc vrp_visit_phi_node
../.././gcc/tree-vrp.c:8879
0xad932d simulate_stmt
../.././gcc/tree-ssa-propagate.c:344
0xad9467 process_ssa_edge_worklist
../.././gcc/tree-ssa-propagate.c:422
0xada1fd ssa_propagate(ssa_prop_result (*)(gimple_statement_base*, edge_def**,
tree_node**), ssa_prop_result (*)(gphi*))
../.././gcc/tree-ssa-propagate.c:896
0xb7b394 execute_vrp
../.././gcc/tree-vrp.c:10367
0xb7b394 execute
../.././gcc/tree-vrp.c:10447
[Bug tree-optimization/65875] internal compiler error with gcc 5.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65875 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-24 CC||mpolacek at gcc dot gnu.org Component|c |tree-optimization Target Milestone|--- |5.2 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed. Started with r220164.
[Bug fortran/64230] [4.9/5 Regression] Invalid memory reference in a compiler-generated finalizer for allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64230 Mat Cross mathewc at nag dot co.uk changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #9 from Mat Cross mathewc at nag dot co.uk --- Thanks for the progress so far. I built 4.9.3 to try on my larger piece of code. The problem still seems present: uname -a Linux whakarewarewa.nag.co.uk 3.19.4-200.fc21.x86_64 #1 SMP Mon Apr 13 21:43:26 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux gfortran --version GNU Fortran (GCC) 4.9.3 20150415 (prerelease) cat test.f90 Program test Implicit None Type :: t1 Integer, Allocatable :: i End Type Type :: t2 Integer, Allocatable :: i End Type Type, Extends (t1) :: t3 Type (t2) :: j End Type Type, Extends (t3) :: t4 Integer, Allocatable :: k End Type Class (t1), Allocatable :: x Allocate (t4 :: x) Deallocate (x) Print *, 'ok' End Program gfortran test.f90 ./a.out Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x2B51E7B11417 #1 0x2B51E7B11A2E #2 0x3265A3495F #3 0x401392 in __final_test_T3.2353 at test.f90:? #4 0x400D45 in __final_test_T4.2342 at test.f90:? #5 0x400E87 in MAIN__ at test.f90:? Segmentation fault (core dumped) Do you see this too? I hope that reopening this PR is acceptable. If not then just let me know and I will happily file a new one.
[Bug target/65456] powerpc64le autovectorized copy loop missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65456
--- Comment #19 from Bill Schmidt wschmidt at gcc dot gnu.org ---
Author: wschmidt
Date: Fri Apr 24 13:45:08 2015
New Revision: 222412
URL: https://gcc.gnu.org/viewcvs?rev=222412root=gccview=rev
Log:
[gcc]
2015-04-24 Bill Schmidt wschm...@linux.vnet.ibm.com
Backport from mainline r222349
2015-04-22 Bill Schmidt wschm...@linux.vnet.ibm.com
PR target/65456
* config/rs6000/rs6000.c (rs6000_option_override_internal): For
VSX + POWER8, enable TARGET_ALLOW_MOVMISALIGN and
TARGET_EFFICIENT_UNALIGNED_VSX if not selected by command line
option.
(rs6000_builtin_mask_for_load): Return 0 for targets with
efficient unaligned VSX accesses so that the vectorizer will use
direct unaligned loads.
(rs6000_builtin_support_vector_misalignment): Always return true
for targets with efficient unaligned VSX accesses.
(rs6000_builtin_vectorization_cost): Cost of unaligned loads and
stores on targets with efficient unaligned VSX accesses is almost
always the same as the cost of an aligned load or store, so model
it that way.
* config/rs6000/rs6000.h (SLOW_UNALIGNED_ACCESS): Return 0 for
unaligned vectors if we have efficient unaligned VSX accesses.
* config/rs6000/rs6000.opt (mefficient-unaligned-vector): New
undocumented option.
[gcc/testsuite]
2015-04-24 Bill Schmidt wschm...@linux.vnet.ibm.com
Backport from mainline r222349
2015-04-22 Bill Schmidt wschm...@linux.vnet.ibm.com
PR target/65456
* gcc.dg/vect/bb-slp-24.c: Exclude test for POWER8.
* gcc.dg/vect/bb-slp-25.c: Likewise.
* gcc.dg/vect/bb-slp-29.c: Likewise.
* gcc.dg/vect/bb-slp-32.c: Replace vect_no_align with
vect_no_align { ! vect_hw_misalign }.
* gcc.dg/vect/bb-slp-9.c: Likewise.
* gcc.dg/vect/costmodel/ppc/costmodel-slp-33.c: Exclude test for
vect_hw_misalign.
* gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c: Likewise.
* gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c: Adjust tests to
account for POWER8, where peeling for alignment is not needed.
* gcc.dg/vect/costmodel/ppc/costmodel-vect-outer-fir.c: Replace
vect_no_align with vect_no_align { ! vect_hw_misalign }.
* gcc.dg.vect.if-cvt-stores-vect-ifcvt-18.c: Likewise.
* gcc.dg/vect/no-scevccp-outer-6-global.c: Likewise.
* gcc.dg/vect/no-scevccp-outer-6.c: Likewise.
* gcc.dg/vect/no-vfa-vect-43.c: Likewise.
* gcc.dg/vect/no-vfa-vect-57.c: Likewise.
* gcc.dg/vect/no-vfa-vect-61.c: Likewise.
* gcc.dg/vect/no-vfa-vect-depend-1.c: Likewise.
* gcc.dg/vect/no-vfa-vect-depend-2.c: Likewise.
* gcc.dg/vect/no-vfa-vect-depend-3.c: Likewise.
* gcc.dg/vect/pr16105.c: Likewise.
* gcc.dg/vect/pr20122.c: Likewise.
* gcc.dg/vect/pr33804.c: Likewise.
* gcc.dg/vect/pr33953.c: Likewise.
* gcc.dg/vect/pr56787.c: Likewise.
* gcc.dg/vect/pr58508.c: Likewise.
* gcc.dg/vect/slp-25.c: Likewise.
* gcc.dg/vect/vect-105-bit-array.c: Likewise.
* gcc.dg/vect/vect-105.c: Likewise.
* gcc.dg/vect/vect-27.c: Likewise.
* gcc.dg/vect/vect-29.c: Likewise.
* gcc.dg/vect/vect-33.c: Exclude unaligned access test for
POWER8.
* gcc.dg/vect/vect-42.c: Replace vect_no_align with vect_no_align
{ ! vect_hw_misalign }.
* gcc.dg/vect/vect-44.c: Likewise.
* gcc.dg/vect/vect-48.c: Likewise.
* gcc.dg/vect/vect-50.c: Likewise.
* gcc.dg/vect/vect-52.c: Likewise.
* gcc.dg/vect/vect-56.c: Likewise.
* gcc.dg/vect/vect-60.c: Likewise.
* gcc.dg/vect/vect-72.c: Likewise.
* gcc.dg/vect/vect-75-big-array.c: Likewise.
* gcc.dg/vect/vect-75.c: Likewise.
* gcc.dg/vect/vect-77-alignchecks.c: Likewise.
* gcc.dg/vect/vect-77-global.c: Likewise.
* gcc.dg/vect/vect-78-alignchecks.c: Likewise.
* gcc.dg/vect/vect-78-global.c: Likewise.
* gcc.dg/vect/vect-93.c: Likewise.
* gcc.dg/vect/vect-95.c: Likewise.
* gcc.dg/vect/vect-96.c: Likewise.
* gcc.dg/vect/vect-cond-1.c: Likewise.
* gcc.dg/vect/vect-cond-3.c: Likewise.
* gcc.dg/vect/vect-cond-4.c: Likewise.
* gcc.dg/vect/vect-cselim-1.c: Likewise.
* gcc.dg/vect/vect-multitypes-1.c: Likewise.
* gcc.dg/vect/vect-multitypes-3.c: Likewise.
* gcc.dg/vect/vect-multitypes-4.c: Likewise.
* gcc.dg/vect/vect-multitypes-6.c: Likewise.
* gcc.dg/vect/vect-nest-cycle-1.c: Likewise.
* gcc.dg/vect/vect-nest-cycle-2.c: Likewise.
* gcc.dg/vect/vect-outer-3a-big-array.c: Likewise.
* gcc.dg/vect/vect-outer-3a.c: Likewise.
* gcc.dg/vect/vect-outer-5.c: Likewise.
* gcc.dg/vect/vect-outer-fir-big-array.c: Likewise.
* gcc.dg/vect/vect-outer-fir-lb-big-array.c: Likewise.
* gcc.dg/vect/vect-outer-fir-lb.c: Likewise.
* gcc.dg/vect/vect-outer-fir.c: Likewise.
* gcc.dg/vect/vect-peel-3.c: Likewise.
* gcc.dg/vect/vect-peel-4.c: Likewise.
* gcc.dg/vect/vect-pre-interact.c: Likewise.
* gcc.target/powerpc/pr65456.c: New
[Bug c++/65880] New: Member function issue with argument pointer to const array of member function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65880
Bug ID: 65880
Summary: Member function issue with argument pointer to const
array of member function pointers
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: habanero_pizza at yahoo dot com
CC: habanero_pizza at yahoo dot com
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Created attachment 35396
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35396action=edit
Test case source: fails if OKAY is not defined...
When a member function takes an argument of the form:
type (classname::* const *ptr)(void)
AND the implementation of the function appears BEFORE its reference by another
member function, the compiler believes (at reference time) that the argument
type should be:
type (classname::* *ptr)(void)
That is, the const seems to get dropped from the declaration. However, if
the implementation of the function appears AFTER references by other member
functions, the code compiles correctly.
This seems to be a new issue with gcc 5.1.0, as 4.9.2 compiles the problem case
properly.
Example run demonstrating the problem:
$ i386-eabi-g++ -v -save-temps -o test-const-mfp-table-arg
test-const-mfp-table-arg.cc
Using built-in specs.
COLLECT_GCC=i386-eabi-g++
COLLECT_LTO_WRAPPER=/usr/local/i386-eabi-5.1.0/libexec/gcc/i686-pc-linux-gnu/5.1
.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../../gcc-5.1.0/configure --prefix=/usr/local/i386-eabi-5.1.0
-
-program-prefix=i386-eabi- --enable-languages=c,c++
--with-gmp=/usr/local/i386-e
abi-5.1.0 --with-mpfr=/usr/local/i386-eabi-5.1.0
--with-mpc=/usr/local/i386-eabi
-5.1.0 --with-isl=/usr/local/i386-eabi-5.1.0 --with-zlib=/usr/local
--enable-lto
--enable-gold
Thread model: posix
gcc version 5.1.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'test-const-mfp-table-arg'
'-shared-
libgcc' '-mtune=generic' '-march=pentiumpro'
/usr/local/i386-eabi-5.1.0/libexec/gcc/i686-pc-linux-gnu/5.1.0/cc1plus -E
-quie
t -v -D_GNU_SOURCE test-const-mfp-table-arg.cc -mtune=generic -march=pentiumpro
-fpch-preprocess -o test-const-mfp-table-arg.ii
ignoring nonexistent directory
/usr/local/i386-eabi-5.1.0/lib/gcc/i686-pc-linux
-gnu/5.1.0/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/local/i386-eabi-5.1.0/lib/gcc/i686-pc-linux-gnu/5.1.0/../../../../include/
c++/5.1.0
/usr/local/i386-eabi-5.1.0/lib/gcc/i686-pc-linux-gnu/5.1.0/../../../../include/
c++/5.1.0/i686-pc-linux-gnu
/usr/local/i386-eabi-5.1.0/lib/gcc/i686-pc-linux-gnu/5.1.0/../../../../include/
c++/5.1.0/backward
/usr/local/i386-eabi-5.1.0/lib/gcc/i686-pc-linux-gnu/5.1.0/include
/usr/local/include
/usr/local/i386-eabi-5.1.0/include
/usr/local/i386-eabi-5.1.0/lib/gcc/i686-pc-linux-gnu/5.1.0/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'test-const-mfp-table-arg'
'-shared-
libgcc' '-mtune=generic' '-march=pentiumpro'
/usr/local/i386-eabi-5.1.0/libexec/gcc/i686-pc-linux-gnu/5.1.0/cc1plus
-fprepro
cessed test-const-mfp-table-arg.ii -quiet -dumpbase test-const-mfp-table-arg.cc
-mtune=generic -march=pentiumpro -auxbase test-const-mfp-table-arg -version -o
t
est-const-mfp-table-arg.s
GNU C++ (GCC) version 5.1.0 (i686-pc-linux-gnu)
compiled by GNU C version 5.1.0, GMP version 5.1.3, MPFR version 3.1.2,
MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 5.1.0 (i686-pc-linux-gnu)
compiled by GNU C version 5.1.0, GMP version 5.1.3, MPFR version 3.1.2,
MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 8a9e49c211f4d1d2fc149d62c24d84d4
test-const-mfp-table-arg.cc: In member function ‘bool Test::barl()’:
test-const-mfp-table-arg.cc:67:20: error: invalid conversion from ‘bool
(Test::*
const*)()’ to ‘bool (Test::**)()’ [-fpermissive]
return fool(fms);
^
test-const-mfp-table-arg.cc:40:6: note: initializing argument 1 of ‘bool
Test:
:fool(bool (Test::**)())’
bool Test::fool(bool (Test::* const *fms)(void))
^
Preprocessor output (test-const-mfp-table-arg.ii):
# 1 test-const-mfp-table-arg.cc
# 1 built-in
# 1 command-line
# 1 test-const-mfp-table-arg.cc
class Test
{
public:
Test();
~Test();
bool barl(void);
private:
bool fool(bool (Test::* const *fms)(void));
bool foo(void);
bool bar(void);
};
Test::Test()
{
}
Test::~Test()
{
}
# 40 test-const-mfp-table-arg.cc
bool Test::fool(bool (Test::* const *fms)(void))
{
bool retval = false;
int i = 0;
bool (Test::*f)(void) = fms[i++];
while (f) {
retval = (this-*f)();
if
[Bug target/65849] Add missing tuning knobs to #pragma target/attribute target support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65849 --- Comment #4 from Michael Meissner meissner at gcc dot gnu.org --- Author: meissner Date: Fri Apr 24 23:48:54 2015 New Revision: 222434 URL: https://gcc.gnu.org/viewcvs?rev=222434root=gccview=rev Log: 2015-04-24 Michael Meissner meiss...@linux.vnet.ibm.com Backport from mainline 2015-04-24 Michael Meissner meiss...@linux.vnet.ibm.com PR target/65849 * config/rs6000/rs6000.opt (-mvsx-align-128): Make options that save to independent variables use the Save attribute. This will allow these options to be modified with the #pragma/attribute target support. (-mallow-movmisalign): Likewise. (-mallow-df-permute): Likewise. (-msched-groups): Likewise. (-malways-hint): Likewise. (-malign-branch-targets): Likewise. (-mvectorize-builtins): Likewise. (-msave-toc-indirect): Likewise. * config/rs6000/rs6000.c (rs6000_opt_masks): Add more options that can be set via the #pragma/attribute target support. (rs6000_opt_vars): Likewise. (rs6000_inner_target_options): If VSX was set, also set -mno-avoid-indexed-addresses. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_8-branch/gcc/config/rs6000/rs6000.opt
[Bug target/65849] Add missing tuning knobs to #pragma target/attribute target support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65849 --- Comment #3 from Michael Meissner meissner at gcc dot gnu.org --- Author: meissner Date: Fri Apr 24 23:44:41 2015 New Revision: 222433 URL: https://gcc.gnu.org/viewcvs?rev=222433root=gccview=rev Log: 2015-04-24 Michael Meissner meiss...@linux.vnet.ibm.com Backport from mainline 2015-04-24 Michael Meissner meiss...@linux.vnet.ibm.com PR target/65849 * config/rs6000/rs6000.opt (-mvsx-align-128): Make options that save to independent variables use the Save attribute. This will allow these options to be modified with the #pragma/attribute target support. (-mallow-movmisalign): Likewise. (-mallow-df-permute): Likewise. (-msched-groups): Likewise. (-malways-hint): Likewise. (-malign-branch-targets): Likewise. (-mvectorize-builtins): Likewise. (-msave-toc-indirect): Likewise. * config/rs6000/rs6000.c (rs6000_opt_masks): Add more options that can be set via the #pragma/attribute target support. (rs6000_opt_vars): Likewise. (rs6000_inner_target_options): If VSX was set, also set -mno-avoid-indexed-addresses. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.opt
[Bug go/65616] libgobegin.a not compiled with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65616 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|4.9.2 |5.1.1 Resolution|--- |FIXED --- Comment #3 from Ian Lance Taylor ian at airs dot com --- Fixed on mainline and GCC 5 branch.
[Bug go/65616] libgobegin.a not compiled with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65616 --- Comment #2 from ian at gcc dot gnu.org ian at gcc dot gnu.org --- Author: ian Date: Fri Apr 24 22:08:32 2015 New Revision: 222431 URL: https://gcc.gnu.org/viewcvs?rev=222431root=gccview=rev Log: PR go/65616 libgo: Compile go-main, in libgobegin, with -fPIC. Modified: trunk/libgo/Makefile.am trunk/libgo/Makefile.in
[Bug go/65616] libgobegin.a not compiled with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65616 --- Comment #1 from ian at gcc dot gnu.org ian at gcc dot gnu.org --- Author: ian Date: Fri Apr 24 22:08:18 2015 New Revision: 222430 URL: https://gcc.gnu.org/viewcvs?rev=222430root=gccview=rev Log: PR go/65616 libgo: Compile go-main, in libgobegin, with -fPIC. Modified: branches/gcc-5-branch/libgo/Makefile.am branches/gcc-5-branch/libgo/Makefile.in
[Bug fortran/61907] load of invalid value for 'bool' in trans-array.c trans_array_constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61907 --- Comment #3 from Vittorio Zecca zeccav at gmail dot com --- Same behaviour in 4.9.2 in trans-array.c line 2206 typespec_chararray_ctor = (expr-ts.u.cl expr-ts.u.cl-length_from_typespec); It seems length_from_typespec is wrong, OR the sanitizer -fsanitize=undefined is wrong. Trying the following: ! taken from pr43808.f90 type :: a integer, allocatable :: i(:) end type a type :: b type (a), allocatable :: j(:) end type b type(a) :: x(1) type(b) :: y(1) y(1) = b((/x(1)/)) end I get /home/vitti/gcc-4.9.2-sanitize/test/f951 p.f90 MAIN__../../gcc-4.9.2/gcc/fortran/trans-array.c:2206:44: runtime error: load of value 172, which is not a valid value for type 'bool' main Analyzing compilation unit Performing interprocedural optimizations *free_lang_data visibility early_local_cleanups *free_inline_summary whole-program inlineAssembling functions: MAIN__ main
[Bug c++/65878] New: parse error in template argument list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65878
Bug ID: 65878
Summary: parse error in template argument list
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: xyshh94225 at hotmail dot com
The following code triggers 'parse error in template argument list' on my
computer:
1.cpp:
---
templatetypename T
struct A{
int B;
};
templatetypename T
void B(){
}
templatetypename T
void C(){
AT x;
x.B 2;
}
int main() {
return 0;
}
-
$ g++-4.9 1.cpp -o 1
1.cpp: In function 'bool C()':
1.cpp:10:4: error: parse error in template argument list
x.B 2;
^
This is specific to operator .
[Bug target/65871] bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65871 --- Comment #1 from James Almer jamrial at gmail dot com --- The same apparently happens with bextr, blsi, blsr, and most (if not all) of AMD's tbm instructions. They set the ZF flag but gcc still generates a test instruction. http://www.felixcloutier.com/x86/BEXTR.html http://www.felixcloutier.com/x86/BLSI.html http://www.felixcloutier.com/x86/BLSR.html http://support.amd.com/TechDocs/24594.pdf
[Bug c++/65879] [4.8/4.9/5/6 Regression] Bogus linkage errors for member class of anonymous class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65879 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-25 Summary|Bogus linkage errors for|[4.8/4.9/5/6 Regression] |member class of anonymous |Bogus linkage errors for |class |member class of anonymous ||class Ever confirmed|0 |1 Known to fail||4.5.4
[Bug c/65881] New: no documentation of __uint128_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65881 Bug ID: 65881 Summary: no documentation of __uint128_t Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: shawn at churchofgit dot com gcc on x86_64 recognizes __uint128_t, but this is not documented along with __int128, also there is no warning when a target does not support __uint128_t, like there is with __int128: triangle64.c:32:1: error: ‘__int128’ is not supported for this target A unsigned 128-bit type is needed because it has defined integer overflow.
[Bug c/65881] no documentation of __uint128_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65881 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Shawn Landden from comment #0) gcc on x86_64 recognizes __uint128_t, but this is not documented along with __int128, also there is no warning when a target does not support __uint128_t, like there is with __int128: triangle64.c:32:1: error: ‘__int128’ is not supported for this target e.c:2:3: error: unknown type name ‘__uint128_t’ __uint128_t i=42; ^ A unsigned 128-bit type is needed because it has defined integer overflow. https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html That type is called unsigned __int128. The other aliases are only for compatibility or legacy.
[Bug middle-end/65855] missing optimization: triangular numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65855 --- Comment #2 from Shawn Landden shawn at churchofgit dot com --- Created attachment 35399 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35399action=edit triange, 64-bit version This can also work with 128-bit multiple of course as well.
[Bug c++/65880] [5/6 Regression] Member function issue with argument pointer to const array of member function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65880 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-25 Summary|Member function issue with |[5/6 Regression] Member |argument pointer to const |function issue with |array of member function|argument pointer to const |pointers |array of member function ||pointers Ever confirmed|0 |1 Known to fail||6.0
[Bug c++/65869] Incorrect overload resolution in function return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65869 --- Comment #4 from Botond Ballo botond at mozilla dot com --- - The second overload resolution fails, because the only candidate (again, the explicit constructors are not candidates) has an rvalue reference parameter, which cannot bind to the lvalue that we're not treating the object as being. This is also a typo, should say cannot bind to the lvalue that we're treating the object as being.
[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852 --- Comment #10 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- gfortran currently does this with default formatting, list directed outout: - ( 1., 0.) ( -1.0002E-25, 0.) ( -1.0002E-25, 0.) ( 1., 0.) ( -3.4992E-24, -3.4992E-24) ( -4.1998E-24, -1.2703E-23) ( 1., 0.) ( -1.0002E-25, 0.) - I have my experimental doing this: case A - (1.,0.) (-0.1000E-24,0.) (-0.1000E-24,0.)(1.,0.) (-0.3499E-23,-0.3499E-23) (-0.4200E-23,-0.1270E-22) (1.,0.) (-0.1000E-24,0.) - I could also do this: case B - (1.,0. ) (-0.1000E-24,0. ) (-0.1000E-24,0. ) (1.,0. ) (-0.3499E-23,-0.3499E-23) (-0.4200E-23,-0.1270E-22) (1.,0. ) (-0.1000E-24,0. ) - or is there some other arrangement?
[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852 --- Comment #11 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- IFORT does this: - (1.00,0.000E+00) (-1.000E-25,0.000E+00) (-1.000E-25,0.000E+00) (1.00,0.000E+00) (-3.499E-24,-3.499E-24) (-4.200E-24,-1.270E-23) (1.00,0.000E+00) (-1.000E-25,0.000E+00) - The program I am using is this: print *, - print *, (1.0,0.0),(-1.0e-25,0.0) print *, (-1.0e-25,0.0),(1.0,0.0) print *, (-35.0e-25,-35.0e-25),(-42.0e-25,-127.0e-25) print *, (1.0,0.0),(-1.0e-25,0.0) print *, - end I think Case A in Comment 10 looks best.
[Bug c++/65879] New: Bogus linkage errors for member class of anonymous class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65879
Bug ID: 65879
Summary: Bogus linkage errors for member class of anonymous
class
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tim.bagot at hds dot com
The following C++ snippet:
static struct
{
void f();
struct Inner
{
void g();
};
} x;
results in:
$ gcc -c test.cpp
test.cpp:6:14: error: anonymous type with no linkage used to declare function
'voidanonymous struct::Inner::g()' with linkage [-fpermissive]
void g();
^
I think this error is incorrect.
- C++98 does not seem to define what it means for a type to be used in a
declaration. (C++11 is clearer - and indeed -std=c++11 makes the error
disappear.) But even if you take a broad interpretation, it is hard to see how
it could apply to g() but not to f().
- The function g() does not have linkage. As a class member, it can only have
linkage if Inner has linkage. Inner can only have linkage if the outer class
has linkage. The outer class, being anonymous, does not have linkage (else
there would be no error). Therefore g() does not have linkage. (And again if
g() did have linkage, then f() surely must as well.)
This is a regression, as 4.4 does not report this error.
The bug is perhaps somewhat related to PR 55877 - but that (as I read it)
involves specifically the typedef struct idiom, and is marked FIXED in 4.9.
For completeness:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--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-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --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 4.9.2 (Debian 4.9.2-10)
[Bug c++/65878] parse error in template argument list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65878 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-24 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Doesn't seem to be a regression. icc and clang++ accept this.
[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65875 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 35395 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35395action=edit gcc5-pr65875.patch Untested fix. IMHO vrp_visit_phi_node was missing the vr_result VR_VARING handling if the value range turned into varying only during update_value_range, and also update_value_range wasn't telling the caller if it changed it into varying late. That said, the testcase has conditionally undefined variable, and checking whether all the VRP decisions (first and second pass) are sane, would be nice, Richard, could you please have a look? E.g. I find it strange that h has VR [0, LONG_MAX] before VRP2, when it really has just values 0 or 1, so should be ideally [0, 1]. Or that i has value range [1, LONG_MAX] - it is conditionally undefined (that is ignored), and conditionally negation of an int variable (only if that int variable is negative). The negated int variable is [1, +INF(OVF)] because INT_MIN might overflow, perhaps if we really need to preserve the OVF flag, we have to use [1, +INF(OVF)] again rather than just [1, 0x7fff] :(.
[Bug tree-optimization/65818] [6 Regression] libiberty/vprintf-support.c:41:1: ICE: in expand_i fn_va_arg_1, at tree-stdarg.c:1095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65818 --- Comment #10 from vries at gcc dot gnu.org --- (In reply to dave.anglin from comment #9) This patch has the following new failure: /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/pr65802.C: In function 'void fn1()': /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/pr65802.C:20:23: error: impossible constraint in 'asm' FAIL: g++.dg/pr65802.C -std=gnu++98 (test for excess errors) FAIL: g++.dg/pr65802.C -std=gnu++11 (test for excess errors) FAIL: g++.dg/pr65802.C -std=gnu++14 (test for excess errors) That failure was probably already present without the patch. (see f.i. https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01482.html ). I've rewritten the test-case in C and cleaned it up. It's now called gcc.dg/pr65802.c. I tested the new test-case with and without the updated patch, it passes in both cases.
[Bug fortran/61908] load of invalid value for 'expr_t' in interface.c compare_actual_formal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61908 --- Comment #3 from Vittorio Zecca zeccav at gmail dot com --- I still have the same runtime error message in 4.9.2 Trying compilation of !from unlimited_polymorphic_16.f90 !../../gcc-4.9.2/gcc/fortran/interface.c:2667:43: runtime error: load of value 1818451807, which is not a valid value for type 'expr_t' contains subroutine FWRite(S) class(*) :: S end subroutine subroutine IO_OutputMargeStats() character tag call FWrite(tag) end subroutine end I get ./../gcc-4.9.2/gcc/fortran/interface.c:2667:43: runtime error: load of value 1818451807, which is not a valid value for type 'expr_t' MAIN__ __copy_character_1 io_outputmargestats fwrite main Analyzing compilation unit Performing interprocedural optimizations *free_lang_data visibility early_local_cleanups *free_inline_summary whole-program inlineAssembling functions: __copy_character_1 MAIN__ main
[Bug fortran/58233] null pointer cm in gfc_conv_structure at fortran/trans-expr.c:6132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58233 --- Comment #3 from Vittorio Zecca zeccav at gmail dot com --- Still there on 4.9.2 at trans-expr.c:6193 if (!c-expr || (cm-attr.allocatable cm-attr.flavor != FL_PROCEDURE)) /home/vitti/gcc-4.9.2-sanitize/test/f951 p.f MAIN__ p.f:1:0: internal compiler error: in gfc_conv_structure, at fortran/trans-expr.c:6193 type t ^ 0x7c45c2 gfc_conv_structure(gfc_se*, gfc_expr*, int) ../../gcc-4.9.2/gcc/fortran/trans-expr.c:6193 0x7c20c0 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc-4.9.2/gcc/fortran/trans-expr.c:5718 0x78e78f gfc_get_symbol_decl(gfc_symbol*) ../../gcc-4.9.2/gcc/fortran/trans-decl.c:1540 0x7a0846 generate_local_decl ../../gcc-4.9.2/gcc/fortran/trans-decl.c:4847 0x726945 do_traverse_symtree ../../gcc-4.9.2/gcc/fortran/symbol.c:3630 0x726a73 gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*)) ../../gcc-4.9.2/gcc/fortran/symbol.c:3655 0x7a178d generate_local_vars ../../gcc-4.9.2/gcc/fortran/trans-decl.c:5019 0x7a38ce gfc_generate_function_code(gfc_namespace*) ../../gcc-4.9.2/gcc/fortran/trans-decl.c:5595 0x75761d gfc_generate_code(gfc_namespace*) ../../gcc-4.9.2/gcc/fortran/trans.c:1945 0x6a2737 translate_all_program_units ../../gcc-4.9.2/gcc/fortran/parse.c:4953 0x6a2ebd gfc_parse_file() ../../gcc-4.9.2/gcc/fortran/parse.c:5150 0x7392c6 gfc_be_parse_file ../../gcc-4.9.2/gcc/fortran/f95-lang.c:212 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. Compiling type t integer g end type type(t) :: u=t(1) data u%g /2/ ! should emit diagnostic here end
[Bug target/65849] Add missing tuning knobs to #pragma target/attribute target support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65849 --- Comment #1 from Michael Meissner meissner at gcc dot gnu.org --- Author: meissner Date: Fri Apr 24 17:24:05 2015 New Revision: 222417 URL: https://gcc.gnu.org/viewcvs?rev=222417root=gccview=rev Log: [gcc] 2015-04-24 Michael Meissner meiss...@linux.vnet.ibm.com PR target/65849 * config/rs6000/rs6000.opt (-mvsx-align-128): Make options that save to independent variables use the Save attribute. This will allow these options to be modified with the #pragma/attribute target support. (-mallow-movmisalign): Likewise. (-mallow-df-permute): Likewise. (-msched-groups): Likewise. (-malways-hint): Likewise. (-malign-branch-targets): Likewise. (-mvectorize-builtins): Likewise. (-msave-toc-indirect): Likewise. * config/rs6000/rs6000.c (rs6000_opt_masks): Add more options that can be set via the #pragma/attribute target support. (rs6000_opt_vars): Likewise. (rs6000_inner_target_options): If VSX was set, also set -mno-avoid-indexed-addresses. [gcc/testsuite] 2015-04-24 Michael Meissner meiss...@linux.vnet.ibm.com PR target/65849 * gcc.target/powerpc/pr65849-1.c: New test to verify being able to set new options. * gcc.target/powerpc/pr65849-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr65849-1.c trunk/gcc/testsuite/gcc.target/powerpc/pr65849-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.opt trunk/gcc/testsuite/ChangeLog
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 Frédéric Buclin LpSolit at netscape dot net changed: What|Removed |Added Attachment #35354|0 |1 is obsolete|| --- Comment #10 from Frédéric Buclin LpSolit at netscape dot net --- Created attachment 35397 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35397action=edit GCC extension for 5.0, v2.0.1 This updated extension includes a RESTRICT_LOGIN boolean constant to easily enable/disable user account creation restrictions.
[Bug preprocessor/65852] Incorrect escaping in depfiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65852 Cary Coutant ccoutant at gmail dot com changed: What|Removed |Added CC||ccoutant at gmail dot com --- Comment #11 from Cary Coutant ccoutant at gmail dot com --- According to the comments in mkdeps.c, the bar\\#foo.h is actually correct: /* GNU make uses a weird quoting scheme for white space. A space or tab preceded by 2N+1 backslashes represents N backslashes followed by space; a space or tab preceded by 2N backslashes represents N backslashes at the end of a file name; and backslashes in other contexts should not be doubled. */ In this case, the '\' is not doubled, and the '#' is escaped as '\#', giving you the '\\#' sequence. But experimentation with make demonstrates that the scheme described in that comment also works for '#', so I guess that GCC ought to escape it the same way. Then again, the Gnu make manual, in section 4.4.2, says this about Windows filenames: Microsoft operating systems (MS-DOS and MS-Windows) use backslashes to separate directories in pathnames, like so: c:\foo\bar\baz.c This is equivalent to the Unix-style c:/foo/bar/baz.c (the c: part is the so-called drive letter). When make runs on these systems, it supports backslashes as well as the Unix-style forward slashes in pathnames. However, this support does not include the wildcard expansion, where backslash is a quote character. Therefore, you must use Unix-style slashes in these cases. It does not work the same way for escaping a wildcard character: writing foo\\\*.h gives this error: make: *** No rule to make target `foo\\\*.h', needed by `foo.o'. Stop. It works if you have a file literally named foo\\\*.h, but it's not a wildcard, while writing foo\\*.h will match a file named foo\\bar.h (so an odd number of backslashes escape the wildcard, but don't escape themselves, while an even number of backslashes remain as is). The whole thing seems horribly messed up in several respects. Still, it seems reasonable to expect GCC to escape a filename containing '#' such that GNU make can un-escape it properly.
[Bug c++/50800] Internal compiler error in finish_member_declarations, possibly related to may_alias attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50800 --- Comment #14 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Fri Apr 24 19:11:45 2015 New Revision: 222419 URL: https://gcc.gnu.org/viewcvs?rev=222419root=gccview=rev Log: PR c++/50800 gcc/ * tree.c (build_reference_type_for_mode): Don't pass can_alias_all down when building TYPE_CANONICAL. (build_pointer_type_for_mode): Likewise. gcc/cp/ * typeck.c (structural_comptypes): Don't check TYPE_REF_CAN_ALIAS_ALL. Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/tree.c
[Bug c++/65872] New: Multiple class prefixes in method implementation are accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65872 Bug ID: 65872 Summary: Multiple class prefixes in method implementation are accepted Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc at hazlewoods dot eu Created attachment 35393 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35393action=edit Preprocessed file The compiler quite happily compiles a method that declares multiple class prefixes. This is fairly benign, but still surprising. Not sure what the standard says on this, but it was detected when building the sources for another target using a different vendor's compiler; which did fail to compile. Originally found using 4.7 [g++ (Ubuntu/Linaro 4.7.3-2ubuntu1~12.04) 4.7.3], but tested against 4.9 [g++-4.9 (Ubuntu 4.9.2-0ubuntu1~12.04) 4.9.2]. g++ -W -Wall -std=c++11
[Bug bootstrap/65865] [6 Regression] Bootstrap failure on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65865 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug target/65456] powerpc64le autovectorized copy loop missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65456 Bill Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #21 from Bill Schmidt wschmidt at gcc dot gnu.org --- Work is complete. Anton, thanks for the report!
[Bug c++/50800] Internal compiler error in finish_member_declarations, possibly related to may_alias attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50800 --- Comment #15 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Fri Apr 24 20:53:28 2015 New Revision: 222426 URL: https://gcc.gnu.org/viewcvs?rev=222426root=gccview=rev Log: PR c++/50800 * g++.dg/ext/alias-canon2.C: Remove clashing fn definitions. Modified: trunk/gcc/testsuite/g++.dg/ext/alias-canon2.C
[Bug rtl-optimization/26190] combine misses some distributivity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26190 Jim Wilson wilson at gcc dot gnu.org changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #2 from Jim Wilson wilson at gcc dot gnu.org --- Created attachment 35398 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35398action=edit prototype patches for ior/shift/xor optimization
[Bug rtl-optimization/26190] combine misses some distributivity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26190 --- Comment #3 from Jim Wilson wilson at gcc dot gnu.org --- This ior/shift/xor optimization be done during combine with a simplify-rtx.c patch. I wrote a prototype and tested it. Combine canonicalizes shift/logical as logical/shift, so we actually have to look for ior/xor/shift. I see that the optimization does not happen on arm and aarch64 because the 0x4002 value does not fit into the immediate range for logical ops, gets loaded into a register, pulled out of the loop, and hence is not available to combine. We would have to perform the optimization earlier for it to work for arm/aarch64. I tried MIPS, and see that because MIPS promotes HImode to SImode we don't have enough info to prove that the opt is safe. We need type info to make this work. This prototype does work for the x86 target which has both 16-bit immediates and HImode instructions. Next I wrote a prototype for match-and-simplify. This one works for all 4 targets. We have to handle ior/shift/xor as match-and-simplify does not canonicalize logical/shift. I noticed that if I change the xor to an ior, then it gets optimized in combine because of the canonicalization for mips and x86, but not for arm/aarch64 again because the constant was pulled out of the loop. So it seems that match-and-simplify should canonicalize shift/logical to logical/shift too. That would also reduce the number of patterns we need to match when performing this ior/shift/xor optimization. These are prototype patches that need a bit more work to handle more cases, and to prove that they test all conditions necessary to make them safe. This is my first attempt to use the wi:: functions, so there might be a better way to do this.
[Bug c++/65869] Incorrect overload resolution in function return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65869 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579
[Bug target/65456] powerpc64le autovectorized copy loop missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65456
--- Comment #20 from Bill Schmidt wschmidt at gcc dot gnu.org ---
Author: wschmidt
Date: Fri Apr 24 20:17:10 2015
New Revision: 222423
URL: https://gcc.gnu.org/viewcvs?rev=222423root=gccview=rev
Log:
[gcc]
2015-04-24 Bill Schmidt wschm...@linux.vnet.ibm.com
Backport from mainline r222349
2015-04-22 Bill Schmidt wschm...@linux.vnet.ibm.com
PR target/65456
* config/rs6000/rs6000.c (rs6000_option_override_internal): For
VSX + POWER8, enable TARGET_ALLOW_MOVMISALIGN and
TARGET_EFFICIENT_UNALIGNED_VSX if not selected by command line
option.
(rs6000_builtin_mask_for_load): Return 0 for targets with
efficient unaligned VSX accesses so that the vectorizer will use
direct unaligned loads.
(rs6000_builtin_support_vector_misalignment): Always return true
for targets with efficient unaligned VSX accesses.
(rs6000_builtin_vectorization_cost): Cost of unaligned loads and
stores on targets with efficient unaligned VSX accesses is almost
always the same as the cost of an aligned load or store, so model
it that way.
* config/rs6000/rs6000.h (SLOW_UNALIGNED_ACCESS): Return 0 for
unaligned vectors if we have efficient unaligned VSX accesses.
* config/rs6000/rs6000.opt (mefficient-unaligned-vector): New
undocumented option.
[gcc/testsuite]
2015-04-24 Bill Schmidt wschm...@linux.vnet.ibm.com
Backport from mainline r222349
2015-04-22 Bill Schmidt wschm...@linux.vnet.ibm.com
PR target/65456
* gcc.dg/vect/bb-slp-24.c: Exclude test for POWER8.
* gcc.dg/vect/bb-slp-25.c: Likewise.
* gcc.dg/vect/bb-slp-29.c: Likewise.
* gcc.dg/vect/bb-slp-9.c: Replace vect_no_align with
vect_no_align { ! vect_hw_misalign }.
* gcc.dg/vect/costmodel/ppc/costmodel-slp-33.c: Exclude test for
vect_hw_misalign.
* gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c: Likewise.
* gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c: Adjust tests to
account for POWER8, where peeling for alignment is not needed.
* gcc.dg/vect/costmodel/ppc/costmodel-vect-outer-fir.c: Replace
vect_no_align with vect_no_align { ! vect_hw_misalign }.
* gcc.dg.vect.if-cvt-stores-vect-ifcvt-18.c: Likewise.
* gcc.dg/vect/no-scevccp-outer-6-global.c: Likewise.
* gcc.dg/vect/no-scevccp-outer-6.c: Likewise.
* gcc.dg/vect/no-vfa-vect-43.c: Likewise.
* gcc.dg/vect/no-vfa-vect-57.c: Likewise.
* gcc.dg/vect/no-vfa-vect-61.c: Likewise.
* gcc.dg/vect/no-vfa-vect-depend-1.c: Likewise.
* gcc.dg/vect/pr16105.c: Likewise.
* gcc.dg/vect/pr20122.c: Likewise.
* gcc.dg/vect/pr33804.c: Likewise.
* gcc.dg/vect/pr33953.c: Likewise.
* gcc.dg/vect/slp-25.c: Likewise.
* gcc.dg/vect/vect-105-bit-array.c: Likewise.
* gcc.dg/vect/vect-105.c: Likewise.
* gcc.dg/vect/vect-27.c: Likewise.
* gcc.dg/vect/vect-29.c: Likewise.
* gcc.dg/vect/vect-33.c: Exclude unaligned access test for
POWER8.
* gcc.dg/vect/vect-42.c: Replace vect_no_align with vect_no_align
{ ! vect_hw_misalign }.
* gcc.dg/vect/vect-44.c: Likewise.
* gcc.dg/vect/vect-48.c: Likewise.
* gcc.dg/vect/vect-50.c: Likewise.
* gcc.dg/vect/vect-52.c: Likewise.
* gcc.dg/vect/vect-56.c: Likewise.
* gcc.dg/vect/vect-60.c: Likewise.
* gcc.dg/vect/vect-72.c: Likewise.
* gcc.dg/vect/vect-75-big-array.c: Likewise.
* gcc.dg/vect/vect-75.c: Likewise.
* gcc.dg/vect/vect-77-alignchecks.c: Likewise.
* gcc.dg/vect/vect-77-global.c: Likewise.
* gcc.dg/vect/vect-78-alignchecks.c: Likewise.
* gcc.dg/vect/vect-78-global.c: Likewise.
* gcc.dg/vect/vect-93.c: Likewise.
* gcc.dg/vect/vect-95.c: Likewise.
* gcc.dg/vect/vect-96.c: Likewise.
* gcc.dg/vect/vect-cond-1.c: Likewise.
* gcc.dg/vect/vect-cond-3.c: Likewise.
* gcc.dg/vect/vect-cond-4.c: Likewise.
* gcc.dg/vect/vect-cselim-1.c: Likewise.
* gcc.dg/vect/vect-multitypes-1.c: Likewise.
* gcc.dg/vect/vect-multitypes-3.c: Likewise.
* gcc.dg/vect/vect-multitypes-4.c: Likewise.
* gcc.dg/vect/vect-multitypes-6.c: Likewise.
* gcc.dg/vect/vect-nest-cycle-1.c: Likewise.
* gcc.dg/vect/vect-nest-cycle-2.c: Likewise.
* gcc.dg/vect/vect-outer-3a-big-array.c: Likewise.
* gcc.dg/vect/vect-outer-3a.c: Likewise.
* gcc.dg/vect/vect-outer-5.c: Likewise.
* gcc.dg/vect/vect-outer-fir-big-array.c: Likewise.
* gcc.dg/vect/vect-outer-fir-lb-big-array.c: Likewise.
* gcc.dg/vect/vect-outer-fir-lb.c: Likewise.
* gcc.dg/vect/vect-outer-fir.c: Likewise.
* gcc.dg/vect/vect-peel-3.c: Likewise.
* gcc.dg/vect/vect-peel-4.c: Likewise.
* gcc.dg/vect/vect-pre-interact.c: Likewise.
* gcc.target/powerpc/pr65456.c: New test.
* gcc.target/powerpc/vsx-vectorize-2.c: Exclude test for POWER8.
* gcc.target/powerpc/vsx-vectorize-4.c: Likewise.
* gcc.target/powerpc/vsx-vectorize-6.c: Likewise.
*
[Bug tree-optimization/65818] [6 Regression] libiberty/vprintf-support.c:41:1: ICE: in expand_i fn_va_arg_1, at tree-stdarg.c:1095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65818 --- Comment #11 from vries at gcc dot gnu.org --- Bootstrap and reg-test on x86_64 also went ok for for the updated patch. I'll submit.
[Bug target/65849] Add missing tuning knobs to #pragma target/attribute target support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65849 --- Comment #2 from Michael Meissner meissner at gcc dot gnu.org --- Author: meissner Date: Fri Apr 24 20:03:13 2015 New Revision: 222421 URL: https://gcc.gnu.org/viewcvs?rev=222421root=gccview=rev Log: [gcc] 2015-04-24 Michael Meissner meiss...@linux.vnet.ibm.com Backport from mainline 2015-04-24 Michael Meissner meiss...@linux.vnet.ibm.com PR target/65849 * config/rs6000/rs6000.opt (-mvsx-align-128): Make options that save to independent variables use the Save attribute. This will allow these options to be modified with the #pragma/attribute target support. (-mallow-movmisalign): Likewise. (-mallow-df-permute): Likewise. (-msched-groups): Likewise. (-malways-hint): Likewise. (-malign-branch-targets): Likewise. (-mvectorize-builtins): Likewise. (-msave-toc-indirect): Likewise. * config/rs6000/rs6000.c (rs6000_opt_masks): Add more options that can be set via the #pragma/attribute target support. (rs6000_opt_vars): Likewise. (rs6000_inner_target_options): If VSX was set, also set -mno-avoid-indexed-addresses. [gcc/testsuite] 2015-04-24 Michael Meissner meiss...@linux.vnet.ibm.com Backport from mainline 2015-04-24 Michael Meissner meiss...@linux.vnet.ibm.com PR target/65849 * gcc.target/powerpc/pr65849-1.c: New test to verify being able to set new options. * gcc.target/powerpc/pr65849-2.c: Likewise. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/pr65849-1.c - copied unchanged from r222417, trunk/gcc/testsuite/gcc.target/powerpc/pr65849-1.c branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/pr65849-2.c - copied unchanged from r222417, trunk/gcc/testsuite/gcc.target/powerpc/pr65849-2.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/rs6000/rs6000.c branches/gcc-5-branch/gcc/config/rs6000/rs6000.opt branches/gcc-5-branch/gcc/testsuite/ChangeLog
