Re: [RFC] GCC vector extension: binary operators vs. differing signedness
On Wed, Dec 10, 2014 at 10:09 PM, Ulrich Weigand uweig...@de.ibm.com wrote:
Hello,
we've noticed the following behavior of the GCC vector extension, and were
wondering whether this is actually intentional:
When you use binary operators on two vectors, GCC will accept not only
operands
that use the same vector type, but also operands whose types only differ in
signedness of the vector element type. The result type of such an operation
(in C) appears to be the type of the first operand of the binary operator.
For example, the following test case compiles:
typedef signed int vector_signed_int __attribute__ ((vector_size (16)));
typedef unsigned int vector_unsigned_int __attribute__ ((vector_size (16)));
vector_unsigned_int test (vector_unsigned_int x, vector_signed_int y)
{
return x + y;
}
However, this variant
vector_unsigned_int test1 (vector_unsigned_int x, vector_signed_int y)
{
return y + x;
}
fails to build:
xxx.c: In function 'test1':
xxx.c:12:3: note: use -flax-vector-conversions to permit conversions between
vectors with differing element types or numbers of subparts
return y + x;
^
xxx.c:12:10: error: incompatible types when returning type 'vector_signed_int
{aka __vector(4) int}' but 'vector_unsigned_int {aka __vector(4) unsigned
int}' was expected
return y + x;
^
Given a commutative operator, this behavior seems surprising.
Note that for C++, the behavior is apparently different: both test
and test1 above compile as C++ code, but this version:
vector_signed_int test2 (vector_unsigned_int x, vector_signed_int y)
{
return y + x;
}
which builds on C, fails on C++ with:
xxx.C:17:14: note: use -flax-vector-conversions to permit conversions between
vectors with differing element types or numbers of subparts
return y + x;
^
xxx.C:17:14: error: cannot convert 'vector_unsigned_int {aka __vector(4)
unsigned int}' to 'vector_signed_int {aka __vector(4) int}' in return
This C vs. C++ mismatch likewise seems surprising.
I agree that all cases above should be rejected.
Now, the manual page for the GCC vector extension says:
You cannot operate between vectors of different lengths or different
signedness without a cast.
And the change log of GCC 4.3, where the strict vector type checks (and the
above-mentioned -flax-vector-conversions option) were introduced, says:
Implicit conversions between generic vector types are now only permitted
when the two vectors in question have the same number of elements and
compatible element types. (Note that the restriction involves compatible
element types, not implicitly-convertible element types: thus, a vector type
with element type int may not be implicitly converted to a vector type with
element type unsigned int.) This restriction, which is in line with
specifications for SIMD architectures such as AltiVec, may be relaxed using
the flag -flax-vector-conversions. This flag is intended only as a
compatibility measure and should not be used for new code.
Both of these statements appear to imply (as far as I can tell) that all
the functions above ought to be rejected (unless -flax-vector-conversions).
Correct.
So at the very least, we should bring the documentation in line with the
actual behavior. However, as seen above, that actual behavior is probably
not really useful in any case, at least in C.
So I'm wondering whether we should:
A. Bring C in line with C++ by making the result of a vector binary operator
use the unsigned type if the two input types differ in signedness?
and/or
B. Enforce that both operands to a vector binary operator must have the same
type (except for opaque vector types) unless -flax-vector-conversions?
I suppose the current behavior comes from the idea that C would
apply promotion rules to the operands of binary operators. To the extent
we can apply the same rules to vector operands we should probably
support that. This means that for example
1) promotions that only differ in signedness happen (partly the C frontend
behavior)
2) promotions that change the size of the elements and thus the size of
the vector happen (probably not a good idea by default)
3) promotions that change the kind of the elements of the vectors
(float vs. non-float) happen (probably neither a good idea)
I think it's sensible to support 1) by default (also to not regress existing
code) but fix it so it applies to C++ as well and accepts both cases
in C. And of course fix documentation.
Richard.
Thanks,
Ulrich
PS: FYI some prior discussion of related issues that I found:
https://gcc.gnu.org/ml/gcc/2006-10/msg00235.html
https://gcc.gnu.org/ml/gcc/2006-10/msg00682.html
https://gcc.gnu.org/ml/gcc-patches/2006-11/msg00926.html
https://gcc.gnu.org/ml/gcc-patches/2013-08/msg01634.html
https://gcc.gnu.org/ml/gcc-patches/2013-09/msg00450.html
--
Dr. Ulrich Weigand
GNU/Linux compilers and
Vector modes and the corresponding width integer mode
Hi, I'm working on MIPS SIMD support for MSA. Can anyone point me towards information about the need for an integer mode of equal size to any supported vector mode? I.e. if I support V4SImode is there any core GCC requirement that TImode is also supported? Any guidance is appreciated. The MIPS port already has limited support for TImode for 64-bit targets which makes it all the more difficult to figure out if there is a relationship between vector modes and integer modes. Thanks, Matthew
Re: [RFC] GCC vector extension: binary operators vs. differing signedness
Richard Biener wrote:
On Wed, Dec 10, 2014 at 10:09 PM, Ulrich Weigand uweig...@de.ibm.com wrote:
So at the very least, we should bring the documentation in line with the
actual behavior. However, as seen above, that actual behavior is probably
not really useful in any case, at least in C.
So I'm wondering whether we should:
A. Bring C in line with C++ by making the result of a vector binary operator
use the unsigned type if the two input types differ in signedness?
and/or
B. Enforce that both operands to a vector binary operator must have the same
type (except for opaque vector types) unless -flax-vector-conversions?
I suppose the current behavior comes from the idea that C would
apply promotion rules to the operands of binary operators. To the extent
we can apply the same rules to vector operands we should probably
support that. This means that for example
1) promotions that only differ in signedness happen (partly the C frontend
behavior)
2) promotions that change the size of the elements and thus the size of
the vector happen (probably not a good idea by default)
3) promotions that change the kind of the elements of the vectors
(float vs. non-float) happen (probably neither a good idea)
Just to clarify: your 1) is pretty much the same as my A., right?
The difference in behavior between C and C++ seems to originate in different
implementations in c_common_type vs. cp_common_type:
C has:
/* If one type is a vector type, return that type. (How the usual
arithmetic conversions apply to the vector types extension is not
precisely specified.) */
if (code1 == VECTOR_TYPE)
return t1;
if (code2 == VECTOR_TYPE)
return t2;
while C++ has:
if (code1 == VECTOR_TYPE)
{
/* When we get here we should have two vectors of the same size.
Just prefer the unsigned one if present. */
if (TYPE_UNSIGNED (t1))
return build_type_attribute_variant (t1, attributes);
else
return build_type_attribute_variant (t2, attributes);
}
I think it's sensible to support 1) by default (also to not regress existing
code) but fix it so it applies to C++ as well and accepts both cases
in C. And of course fix documentation.
I'm not sure I understand exactly what you mean here. C++ already implements
the sign promotion rule; just C doesn't. So we could do the same for C as is
currently done for C++.
However, if we make that change, there will be some cases that regress: the
problem is that an expression x + y has *one* result type, and some things
you do with the result will require that type to match precisely (including
signedness). So *any* change that affects what that result type is will
regress some code that happened to rely on the precise result type ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Re: Do we create new insn in combine? Or can we rely on INSN_LUID checking the order of instuctions?
On Thu, Dec 11, 2014 at 03:13:50PM +0800, Bin.Cheng wrote: So I am wondering if I can rely on INSN_LUID checking orders of difference instruction. If it can be done, I can easily differentiate live range shrink and extend. Further question is, if we don't insert new insns, can I use INSN_LUID safely for this purpose? I0 is before I1 is before I2 is before I3; one of the first things try_combine does is make sure this is true (by swapping the names around if necessary). The LUIDs are in strictly increasing order, and they stay that way: combine never moves or inserts insns. Segher
gcc-4.8-20141211 is now available
Snapshot gcc-4.8-20141211 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20141211/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch revision 218641 You'll find: gcc-4.8-20141211.tar.bz2 Complete GCC MD5=2534dbcdcfb9cde9a4552d032739b877 SHA1=fc5102e9de8438b5733c9fd0de69744a2fb88244 Diffs from 4.8-20141204 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[Bug tree-optimization/64260] [5 Regression] wrong code at -O1 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64260 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-11 CC||jakub at gcc dot gnu.org Target Milestone|--- |5.0 Summary|wrong code at -O1 on|[5 Regression] wrong code |x86_64-linux-gnu|at -O1 on x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Yes, r217646 again. I think we should gather testcases from all the dup PRs and commit them after the fix is committed.
[Bug tree-optimization/42108] [4.8/4.9/5 Regression] 50% performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108 --- Comment #65 from rguenther at suse dot de rguenther at suse dot de --- On Wed, 10 Dec 2014, burnus at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108 --- Comment #64 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Richard Biener from comment #63) Unfortunately for the testcase this doesn't allow moving the division at all and we are lucky that we have range information at all because of the fortran frontend casting 'n' to unsigned before dividing by it. If it helps and the semantic is preserved, there is no reason not to completely change what tree code the Fortran FE generates for loops. The attached patch helps, but only sofar as enabling moving the division out one loop level - if you add another nest the entry condition on it will prevent moving the division further. [I think one reason for the odd way tree code for loops is generated is: The current code makes it simple to permit loops which are always run once, as some Fortran 66 compilers did. For instance, DO i = 2, 1 would then be executed once. (Such loops are not permitted in F66 - and some compilers executed them once others zero times; since F77, such loops are permitted and executed zero times. Unsurprisingly, some old code from the 60s relies on the execute once feature.) g77 and some commercial compilers have a compile flag like -f66, gfortran hasn't and I don't think it ever will.] I wondered if DO i = 1, 1, 0 is valid (a step of zero). Note that DO i = 2, 1 wouldn't be executed once with the current generated code, only DO i = 1, 1 is, but with step == 0 it would divide by zero.
[Bug middle-end/63608] [4.8/4.9 Regression] error: type mismatch in binary expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63608 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org --- But the testcase looks completely artificial and this ICEs only because the compiler is configured with --enable-checking.
[Bug rtl-optimization/62151] [5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151 --- Comment #16 from amker at gcc dot gnu.org --- For calls of distribute_notes with from_insn != NULL, I kind of understand why it is vulnerable, at least when handling REG_DEAD notes. When we distribute REG_DEAD note of one register from FROM_INSN, generally it means live range shrink of that register. For example: i1: r1 - const_0 i2: r2 - rx const_0 REG_DEAD (rx) i3: r3 - i3src (using r2) In this case, we need to search backward in instruction flow, find previous reference of rx and put a REG_DEAD note there, or delete the definition of rx if there is no other reference. But in combine, thing is complicate when use of rx in r1 is combined into i2. It means live range extend of register rx. In this case, we need to search forward and decide whether we need to put a REG_DEAD for rx at i2. Sometimes we are lucky when i2 is the predecessor of i3, which means we can infer the insert point directly. This is why the code handles this specially (as quoting): /* ... If the register is used as an input in I3, it dies there. Similarly for I2, if it is nonzero and adjacent to I3. ... */ else if (reg_referenced_p (XEXP (note, 0), PATTERN (i3))) place = i3; else if (i2 != 0 next_nonnote_nondebug_insn (i2) == i3 reg_referenced_p (XEXP (note, 0), PATTERN (i2))) place = i2; For other cases, GCC just start from i3 and search backward in flow. This causes this PR. Thing becomes even complicated when we support four insn combination because it's possible that i1dest is re-set in i2, like below example: i0: r0 - const_0 i1: r1 - i1src (using r0) REG_DEAD (r0) i2: r0 - i2src (using r1) i3: r3 - i3src (using r0) Since GCC wrongly handles live range shrink of r0 as live range extend, it searches from r3 backward in flow, resulting in i2 deleted. So distribute_notes is complicated and vulnerable because it tries to understand live range change by guessing based on information like elim_ix/i2/i3, etc., rather than real live range information. From my point of view, all distribute_notes needs to do when FROM_INSN!=NULL are three live range changes: 1) live range shrink, like the first example. 2) live range shrink, but the instruction has already deleted by combine, like the last example. 3) live range extend, like below example: before combine after combine i0: r0 - consti0: INSN_DELETED i1: r1 - rx r0 i1: INSN_DELETED REG_DEAD(rx) i2: r2 - r1 i2: r2 - rx const REG_DEAD(rx) i3: r3 - i3srci3: r3 - i3src' Problem is if we can infer live range change from order of i0/i1/i2/i3, using INSN_LUID maybe?
[Bug ipa/60871] [4.9/5 Regression] internal compiler error: in possible_polymorphic_call_targets, at ipa-devirt.c:1510
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60871 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Honza, any progress on this? People are regularly hitting this ICE in 4.9.x...
[Bug tree-optimization/42108] [4.8/4.9/5 Regression] 50% performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108 --- Comment #66 from Salvatore Filippone sfilippone at uniroma2 dot it --- As far as I remember(In reply to rguent...@suse.de from comment #65) On Wed, 10 Dec 2014, burnus at gcc dot gnu.org wrote: Fortran 66 compilers did. For instance, DO i = 2, 1 would then be executed once. (Such loops are not permitted in F66 - and some compilers executed them once others zero times; since F77, such loops are permitted and executed zero times. Unsurprisingly, some old code from the 60s relies on the execute once feature.) g77 and some commercial compilers have a compile flag like -f66, gfortran hasn't and I don't think it ever will.] I wondered if DO i = 1, 1, 0 is valid (a step of zero). Note that DO i = 2, 1 wouldn't be executed once with the current generated code, only DO i = 1, 1 is, but with step == 0 it would divide by zero. Step 0 is not allowed (see e.g. F2003 Handbook, sect. 8.7.2.1.1). Salvatore
[Bug tree-optimization/57523] ICE in merge_assigned_reloads, at reload1.c:6062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57523 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- GCC 3.4.3 is ancient. Closing.
[Bug tree-optimization/61906] failed to build gcc 4.9.1 on debian wheezy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61906 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-12-11 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- GCC 4.7 is not supported anymore, does this work with 4.8+?
[Bug tree-optimization/58722] c-c++-common/gomp/pr58472.c FAILs: SEGV in tree_class_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58722 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Assuming fixed.
[Bug libgcc/63832] [5.0 Regression] crtstuff.c:400:19: warning: array subscript is above array bounds [-Warray-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63832 --- Comment #3 from Uroš Bizjak ubizjak at gmail dot com --- Created attachment 34246 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34246action=edit Preprocessed source Preprocessed source, compile with -O2 -Wall: ../../../gcc-svn/trunk/libgcc/crtstuff.c: In function ‘__do_global_dtors_aux’: ../../../gcc-svn/trunk/libgcc/crtstuff.c:400:19: warning: array subscript is above array bounds [-Warray-bounds] f = __DTOR_LIST__[++dtor_idx]; ^ frame_dummy
[Bug tree-optimization/64260] [5 Regression] wrong code at -O1 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64260 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 CC||zhenqiang.chen at arm dot com
[Bug libgcc/63832] [5.0 Regression] crtstuff.c:400:19: warning: array subscript is above array bounds [-Warray-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63832 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|RESOLVED|NEW Resolution|WORKSFORME |--- --- Comment #4 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Uroš Bizjak from comment #2) The warning doesn't happen anymore, let's assume this was a transient issue. I was too quick, this still happens on CentOS 5.11 x86_64.
[Bug rtl-optimization/64255] [5 Regression] failures with -O2 optimization on i = 0 ? (unsigned long) i : - (unsigned long) i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64255 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug lto/64262] New: [5 Regression] Several LTO failures after r218609 when compiling with -fpic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64262
Bug ID: 64262
Summary: [5 Regression] Several LTO failures after r218609 when
compiling with -fpic.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: dominiq at lps dot ens.fr
CC: hubicka at gcc dot gnu.org
After r218609 the following tests fail when compiled with -fpic, e.g. darwin:
FAIL: g++.dg/ipa/pr64059.C -std=gnu++11 (internal compiler error)
FAIL: g++.dg/ipa/pr64059.C -std=gnu++11 (test for excess errors)
FAIL: g++.dg/ipa/pr64059.C -std=gnu++14 (internal compiler error)
FAIL: g++.dg/ipa/pr64059.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/ipa/pr64059.C -std=gnu++98 (internal compiler error)
FAIL: g++.dg/ipa/pr64059.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/lto/20081119 cp_lto_20081119_0.o assemble, -O0 -flto
-flto-partition=1to1 -fno-use-linker-plugin (internal compiler error)
FAIL: g++.dg/lto/20081119 cp_lto_20081119_0.o assemble, -O0 -flto
-flto-partition=none -fuse-linker-plugin (internal compiler error)
FAIL: g++.dg/lto/20081119 cp_lto_20081119_0.o assemble, -O0 -flto
-fuse-linker-plugin -fno-fat-lto-objects (internal compiler error)
FAIL: g++.dg/lto/20081119 cp_lto_20081119_1.o assemble, -O0 -flto
-flto-partition=1to1 -fno-use-linker-plugin (internal compiler error)
FAIL: g++.dg/lto/20081119 cp_lto_20081119_1.o assemble, -O0 -flto
-flto-partition=none -fuse-linker-plugin (internal compiler error)
FAIL: g++.dg/lto/20081119 cp_lto_20081119_1.o assemble, -O0 -flto
-fuse-linker-plugin -fno-fat-lto-objects (internal compiler error)
FAIL: g++.dg/lto/20081211-1 cp_lto_20081211-1_0.o assemble, -O0 -flto
-flto-partition=1to1 -fno-use-linker-plugin (internal compiler error)
FAIL: g++.dg/lto/20081211-1 cp_lto_20081211-1_0.o assemble, -O0 -flto
-flto-partition=none -fuse-linker-plugin (internal compiler error)
FAIL: g++.dg/lto/20081211-1 cp_lto_20081211-1_0.o assemble, -O0 -flto
-fuse-linker-plugin -fno-fat-lto-objects (internal compiler error)
FAIL: g++.dg/lto/pr45621 cp_lto_pr45621_1.o assemble, -O0 -flto
-flto-partition=1to1 -fno-use-linker-plugin (internal compiler error)
FAIL: g++.dg/lto/pr45621 cp_lto_pr45621_1.o assemble, -O0 -flto
-flto-partition=none -fuse-linker-plugin (internal compiler error)
FAIL: g++.dg/lto/pr45621 cp_lto_pr45621_1.o assemble, -O0 -flto
-fuse-linker-plugin -fno-fat-lto-objects (internal compiler error)
FAIL: g++.dg/lto/pr52605 cp_lto_pr52605_0.o assemble, -flto -g (internal
compiler error)
FAIL: g++.dg/lto/v1-plugin-api-not-supported
cp_lto_v1-plugin-api-not-supported_0.o assemble, -O0 -flto -flto-partition=1to1
-fno-use-linker-plugin (internal compiler error)
FAIL: g++.dg/lto/v1-plugin-api-not-supported
cp_lto_v1-plugin-api-not-supported_0.o assemble, -O0 -flto -flto-partition=none
-fuse-linker-plugin (internal compiler error)
FAIL: g++.dg/lto/v1-plugin-api-not-supported
cp_lto_v1-plugin-api-not-supported_0.o assemble, -O0 -flto -fuse-linker-plugin
-fno-fat-lto-objects (internal compiler error)
see https://gcc.gnu.org/ml/gcc-regression/2014-12/msg00350.html.
The backtrace is
* thread #1: tid = 0x83eeb52, 0x000100e6d411
cc1plus`get_binfo_at_offset(tree_node*, long long, tree_node*) [inlined]
tree_check(__c=tree_code at scalar(0x), __g=unavailable,
__l=int at scalar(0x), __f=unavailable, __t=unavailable) at
tree.h:2763, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x0)
frame #0: 0x000100e6d411 cc1plus`get_binfo_at_offset(tree_node*, long
long, tree_node*) [inlined] tree_check(__c=tree_code at
scalar(0x), __g=unavailable, __l=int at
scalar(0x), __f=unavailable, __t=unavailable) at
tree.h:2763
2760inline tree
2761tree_check (tree __t, const char *__f, int __l, const char *__g,
tree_code __c)
2762{
- 2763 if (TREE_CODE (__t) != __c)
2764tree_check_failed (__t, __f, __l, __g, __c, 0);
2765 return __t;
2766}
(lldb) bt
* thread #1: tid = 0x83eeb52, 0x000100e6d411
cc1plus`get_binfo_at_offset(tree_node*, long long, tree_node*) [inlined]
tree_check(__c=tree_code at scalar(0x), __g=unavailable,
__l=int at scalar(0x), __f=unavailable, __t=unavailable) at
tree.h:2763, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x0)
* frame #0: 0x000100e6d411 cc1plus`get_binfo_at_offset(tree_node*, long
long, tree_node*) [inlined] tree_check(__c=tree_code at
scalar(0x), __g=unavailable, __l=int at
scalar(0x), __f=unavailable, __t=unavailable) at
tree.h:2763
frame #1: 0x000100e6d411
cc1plus`get_binfo_at_offset(binfo=0x, offset=0,
expected_type=0x000142774348) + 17
frame #2:
[Bug tree-optimization/64258] internal compiler error: Segmentation fault (on loop optimization?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64258 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-11 Component|c++ |tree-optimization Blocks||59859 Ever confirmed|0 |1 Known to fail||4.8.3, 4.9.2 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. crash_compiler.cpp:12:1: internal compiler error: Segmentation fault 0xdaca1e crash_signal /space/rguenther/src/svn/gcc-4_9-branch/gcc/toplev.c:337 0x1489924 subtract_commutative_associative_deps /space/rguenther/src/svn/gcc-4_9-branch/gcc/graphite-dependences.c:430 0x1489d3e compute_deps(scop*, vecpoly_bb*, va_heap, vl_ptr, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**) /space/rguenther/src/svn/gcc-4_9-branch/gcc/graphite-dependences.c:502 0x1489ff2 loop_level_carries_dependences /space/rguenther/src/svn/gcc-4_9-branch/gcc/graphite-dependences.c:566 0x148a15c loop_is_parallel_p(loop*, hash_tablebb_pbb_hasher, xcallocator, int) /space/rguenther/src/svn/gcc-4_9-branch/gcc/graphite-dependences.c:598 0x148687a translate_clast_for_loop /space/rguenther/src/svn/gcc-4_9-branch/gcc/graphite-clast-to-gimple.c:1200
[Bug c++/64259] Erroneous declaration 'struct ...' does not declare anything when using typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64259 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-11 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Confirmed. Every version since 4.7.0 has given the same warning (but not a regression as 4.6 didn't support the syntax at all).
[Bug c++/64000] internal compiler error on lambda that captures 2-dimensional variable size array by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64000 tobias.polzer+gcc at gmail dot com changed: What|Removed |Added Attachment #34053|0 |1 is obsolete|| --- Comment #2 from tobias.polzer+gcc at gmail dot com --- Created attachment 34247 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34247action=edit Reduced testcase
[Bug c++/58969] bogus error: the value of 'kName' is not usable in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58969 --- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org --- (In reply to Richard Smith from comment #2) (In reply to Kai Tietz from comment #1) Hmm, issue seems to be in too restrictive decl_maybe_constant_var_p function. I don't know how the GCC code is structured, but I don't think that's right; that function appears to be checking whether the value of the variable can be used in a constant expression. The relevant condition here is whether the address of the variable can be used. hmm, this function has nothing to do with its value. AFAIU the comment (and its use) it just checks that a VAR-decl might be a constant. In general it checks for const and volatile attributes, and assumes for integral/enumeral typed variables that variable is constant. So a 'const char *' isn't constant - as just the destination the variable is pointing to is constant, but not the variable itself. For a constant array with trivial destructor, and non-vla size this is different. The array's name is indeed a constant address, and its content is constant too. Of course the a variable pointing to into an array isn't constant, but the array itself is. Anyway I might be wrong here
[Bug tree-optimization/59859] [meta-bug] GRAPHITE issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859 Bug 59859 depends on bug 64258, which changed state. Bug 64258 Summary: internal compiler error: Segmentation fault (on loop optimization?) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64258 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/59586] [4.8/4.9 Regression] [graphite] Segmentation fault with -Ofast -floop-parallelize-all -ftree-parallelize-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59586 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||csoeder at akamai dot com --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- *** Bug 64258 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/64258] internal compiler error: Segmentation fault (on loop optimization?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64258 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Duplicate of PR59586 which was fixed for GCC 5 only sofar. *** This bug has been marked as a duplicate of bug 59586 ***
[Bug lto/64262] [5 Regression] Several LTO failures after r218609.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64262 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-11 Summary|[5 Regression] Several LTO |[5 Regression] Several LTO |failures after r218609 when |failures after r218609. |compiling with -fpic. | Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- -fpic is not necessary to reproduce the failures: see https://gcc.gnu.org/ml/gcc-regression/2014-12/msg00354.html or https://gcc.gnu.org/ml/gcc-regression/2014-12/msg00346.html for instance.
[Bug lto/64262] [5 Regression] Several LTO failures after r218609.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64262 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |5.0
[Bug target/64263] New: ICE where adddi3_aarch64 does not satisfy its constraints after r217546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64263
Bug ID: 64263
Summary: ICE where adddi3_aarch64 does not satisfy its
constraints after r217546
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
CC: ramana at gcc dot gnu.org
Host: x86_64-unknown-linux-gnu
Target: aarch64-none-elf
Created attachment 34248
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34248action=edit
Failing testcase
As of r217546, for the attached testcase (compile with -O1), I see the
following ICE on aarch64-none-elf:
---
$ gcc-r217546 bug.c -O1
./bug.c: In function 'foo':
./bug.c:35:10: warning: implicit declaration of function 'vget_lane_s64'
[-Wimplicit-function-declaration]
val14 = vcreate_s8(0xff0080f6807f807fUL);
^
./bug.c:38:1: error: insn does not satisfy its constraints:
val40 = vreinterpretq_u32_u64(
^
(insn 14 13 7 2 (set (reg:DI 32 v0)
(plus:DI (reg:DI 32 v0)
(const_int 255 [0xff]))) ./bug.c:35 80 {*adddi3_aarch64}
(expr_list:REG_EQUAL (const_int 71776119077929215 [0xff00ff00ff])
(nil)))
./bug.c:38:1: internal compiler error: in extract_constrain_insn, at
recog.c:2230
0xa19646 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/work/gcc-clean/src/gcc/gcc/rtl-error.c:110
0xa19677 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/work/gcc-clean/src/gcc/gcc/rtl-error.c:121
0x9f0a40 extract_constrain_insn(rtx_insn*)
/work/gcc-clean/src/gcc/gcc/recog.c:2230
0x9f32bc copyprop_hardreg_forward_1
/work/gcc-clean/src/gcc/gcc/regcprop.c:773
0x9f3fbd execute
/work/gcc-clean/src/gcc/gcc/regcprop.c:1279
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 target/64263] [5.0 Regression] ICE where adddi3_aarch64 does not satisfy its constraints after r217546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64263 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.8.4, 4.9.2 Keywords||ice-on-valid-code Last reconfirmed||2014-12-11 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 Summary|ICE where adddi3_aarch64|[5.0 Regression] ICE where |does not satisfy its|adddi3_aarch64 does not |constraints after r217546 |satisfy its constraints ||after r217546 Known to fail||5.0 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed.
[Bug target/64264] New: [5 Regression] s390 bootstrap fails in ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64264 Bug ID: 64264 Summary: [5 Regression] s390 bootstrap fails in ada Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: build, ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target: s390-linux [ 5208s] +===GNAT BUG DETECTED==+ [ 5208s] | 5.0.0 20141210 (experimental) [trunk revision 218580] (s390-suse-linux) | [ 5208s] | Storage_Error stack overflow or erroneous memory access | [ 5208s] | Error detected at s-stalib.ads:75:42 | [ 5208s] | Please submit a bug report; see http://gcc.gnu.org/bugs.html. | [ 5208s] | Use a subject line meaningful to you and us to track the bug. | [ 5208s] | Include the entire contents of this bug box in the report. | [ 5208s] | Include the exact command that you entered. | [ 5208s] | Also include sources listed below. | [ 5208s] +==+ [ 5208s] [ 5208s] Please include these source files with error report [ 5208s] Note that list may not be accurate in some cases, [ 5208s] so please double check that the problem can still [ 5208s] be reproduced with the set of files listed. [ 5208s] Consider also -gnatd.n switch (see debug.adb). [ 5208s] [ 5208s] ../../gcc/ada/system.ads [ 5208s] ../../gcc/ada/a-ioexce.ads [ 5208s] ../../gcc/ada/ada.ads [ 5208s] ../../gcc/ada/s-exctab.ads [ 5208s] ../../gcc/ada/s-stalib.ads [ 5208s] ../../gcc/ada/a-unccon.ads [ 5208s] [ 5208s] compilation abandoned [ 5208s] ../../gcc/ada/gcc-interface/Make-lang.in:123: recipe for target 'ada/a-ioexce.o' failed [ 5208s] make[3]: *** [ada/a-ioexce.o] Error 1 [ 5208s] make[3]: *** Waiting for unfinished jobs [ 5208s] +===GNAT BUG DETECTED==+ [ 5208s] | 5.0.0 20141210 (experimental) [trunk revision 218580] (s390-suse-linux) | [ 5208s] | Storage_Error stack overflow or erroneous memory access | [ 5208s] | Error detected at s-stalib.ads:75:42 | [ 5208s] | Please submit a bug report; see http://gcc.gnu.org/bugs.html. | [ 5208s] | Use a subject line meaningful to you and us to track the bug. | [ 5208s] | Include the entire contents of this bug box in the report. | [ 5208s] | Include the exact command that you entered. | [ 5208s] | Also include sources listed below. | [ 5208s] +==+ [ 5208s] [ 5208s] Please include these source files with error report [ 5208s] Note that list may not be accurate in some cases, [ 5208s] so please double check that the problem can still [ 5208s] be reproduced with the set of files listed. [ 5208s] Consider also -gnatd.n switch (see debug.adb). [ 5208s] [ 5208s] ../../gcc/ada/system.ads [ 5208s] ../../gcc/ada/a-except.adb [ 5208s] ../../gcc/ada/a-except.ads [ 5208s] ../../gcc/ada/ada.ads [ 5208s] ../../gcc/ada/s-parame.ads [ 5208s] ../../gcc/ada/s-stalib.ads [ 5208s] ../../gcc/ada/a-unccon.ads [ 5208s] ../../gcc/ada/s-traent.ads [ 5208s] ../../gcc/ada/s-excdeb.ads [ 5208s] ../../gcc/ada/s-soflin.ads [ 5208s] ../../gcc/ada/s-stache.ads [ 5208s] ../../gcc/ada/s-stoele.ads [ 5208s] [ 5208s] compilation abandoned [ 5208s] +===GNAT BUG DETECTED==+ [ 5208s] | 5.0.0 20141210 (experimental) [trunk revision 218580] (s390-suse-linux) | [ 5208s] | Storage_Error stack overflow or erroneous memory access | [ 5208s] | Error detected at s-stalib.ads:75:42 | [ 5208s] | Please submit a bug report; see http://gcc.gnu.org/bugs.html. | [ 5208s] | Use a subject line meaningful to you and us to track the bug. | [ 5208s] | Include the entire contents of this bug box in the report. | [ 5208s] | Include the exact command that you entered. | [ 5208s] | Also include sources listed below. | [ 5208s] +==+ [ 5208s] [ 5208s] Please include these source files with error report [ 5208s] Note that list may not be accurate in some cases, [ 5208s] so please double check that the problem can still [ 5208s] be reproduced with the set of files listed. [ 5208s] Consider also -gnatd.n switch (see debug.adb). [ 5208s] [ 5208s] ../../gcc/ada/system.ads [ 5208s] ../../gcc/ada/a-elchha.adb [ 5208s] ../../gcc/ada/a-elchha.ads [
[Bug target/64264] [5 Regression] s390 bootstrap fails in ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64264 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug target/63399] Segmentation Fault on pow() function call when all parameters constant, ARM v61 Processor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63399 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target||arm* Status|UNCONFIRMED |WAITING Last reconfirmed||2014-12-11 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- I can't reproduce this with the options: -march=armv6 -mfloat-abi=hard -mfpu=vfp -mabi=aapcs-linux on current 4.8.4 (or later). Is this still a problem?
[Bug target/64263] [5.0 Regression] ICE where adddi3_aarch64 does not satisfy its constraints after r217546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64263 ktkachov at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- I'll take a look
[Bug rtl-optimization/64110] [5 Regression] ICE: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64110 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ra Target||x86_64-*-* Priority|P3 |P1
[Bug c++/64105] [4.9/5 Regression] ICE: in strip_typedefs, at cp/tree.c:1326
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64105 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- 4.8 rejected this testcase, possibly because a feature is not implemented. So not sure how this can count as a regression (regressions are things that have a known-to-work version)
[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug ipa/64163] [5 Regression] r218024 causes qt5 build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64163 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1
[Bug rtl-optimization/64164] [4.9/5 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug c++/64265] New: r217669 broke tsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265
Bug ID: 64265
Summary: r217669 broke tsan
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Created attachment 34249
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34249action=edit
test case
starting with r217669 tsan instrumentation gets wrong code:
g++ -g -fsanitize=thread test.cpp
./a.out
= soaks all memory up.
reason is this function calls __tsan_func_entry in a loop:
_ZNSt12_Destroy_auxILb0EE9__destroyIN9__gnu_cxx17__normal_iteratorIPSsSt6vectorISsSaISsEEvT_S9_:
.LFB982:
.loc 5 100 0
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
subq$32, %rsp
movq%rdi, -16(%rbp)
movq%rsi, -32(%rbp)
.L153:
movq8(%rbp), %rax
movq%rax, %rdi
call__tsan_func_entry
.loc 5 102 0 discriminator 2
leaq-32(%rbp), %rdx
leaq-16(%rbp), %rax
movq%rdx, %rsi
movq%rax, %rdi
call
_ZN9__gnu_cxxneIPSsSt6vectorISsSaISsbRKNS_17__normal_iteratorIT_T0_EESA_
testb %al, %al
je .L152
.loc 5 103 0 discriminator 1
leaq-16(%rbp), %rax
movq%rax, %rdi
call_ZNK9__gnu_cxx17__normal_iteratorIPSsSt6vectorISsSaISsEEEdeEv
movq%rax, %rdi
call_ZSt11__addressofISsEPT_RS0_
movq%rax, %rdi
call_ZSt8_DestroyISsEvPT_
.loc 5 102 0 discriminator 1
leaq-16(%rbp), %rax
movq%rax, %rdi
call_ZN9__gnu_cxx17__normal_iteratorIPSsSt6vectorISsSaISsEEEppEv
jmp .L153
.L152:
.loc 5 104 0
call__tsan_func_exit
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
it is generated from bits/stl_container.h, line 95-105:
templatebool
struct _Destroy_aux
{
templatetypename _ForwardIterator
static void
__destroy(_ForwardIterator __first, _ForwardIterator __last)
{
for (; __first != __last; ++__first)
std::_Destroy(std::__addressof(*__first));
}
};
[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to jos...@codesourcery.com from comment #9) On Thu, 4 Dec 2014, ktkachov at gcc dot gnu.org wrote: Hmm, is passing vectors around when vector instructions are not present expected to work? All you need to conform to the VFP AAPCS variant is loads/stores. Even single-precision-only VFP has the required loads/stores to support that AAPCS variant. When fixing up various problems in an early version of the VFP ABI support patch some years ago, one of the things I implemented was making sure generic vector types would be passed the same (which would be the same as the corresponding NEON vector types) whether or not NEON instructions were available. In the current version of the code, I think what's relevant is in aapcs_vfp_sub_candidate: case VECTOR_TYPE: /* Use V2SImode and V4SImode as representatives of all 64-bit and 128-bit vector types, whether or not those modes are supported with the present options. */ The test in the present bug doesn't even seem to have vectors as function arguments / returns so the ABI shouldn't even be involved - I'd have expected the generic vector code to be lowered completely to non-vector code before the back end gets involved. That indeed happens if the target doesn't provide optabs with vector modes. See tree-vect-generic.c.
[Bug target/64204] [5 Regression] gcc.dg/c11-atomic-2.c fails on powerpc 64-bit little endian after -mupper-regs patches went in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64204 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Assuming fixed.
[Bug target/64205] [5 Regression] powerpc64-linux --with-cpu=G5 bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64205 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug target/64210] [5 Regression] FAIL: gcc.target/i386/avx512vl-(vmovdqa64|vpbroadcastd)-1.c ... with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64210 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug target/64240] [5.0 Regression][AArch64] SMS-3.c causes runtime exception(segfault).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64240 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-11 CC||fyang at gcc dot gnu.org, ||ramana at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Please assign this to yourself Felix.
[Bug target/64240] [5.0 Regression][AArch64] SMS-3.c causes runtime exception(segfault).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64240 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug target/58623] lack of ldp/stp optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58623 --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to bin.cheng from comment #3) Patch sent at https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02209.html On latest trunk, the patch generates below assembly for the example: .cpu generic+fp+simd .file pr58623.c .text .align 2 .global foo .type foo, %function foo: adrpx0, .LANCHOR0 add x2, x0, :lo12:.LANCHOR0 ldr x1, [x0, #:lo12:.LANCHOR0] ldr x0, [x2, 8] add w0, w1, w0 ret .size foo, .-foo .align 2 .global bar .type bar, %function bar: adrpx1, .LANCHOR0 add x1, x1, :lo12:.LANCHOR0 ldp w2, w0, [x1, 16] add w0, w2, w0 ret .size bar, .-bar .global d .global c .global b .global a .bss .align 3 .LANCHOR0 = . + 0 .type a, %object .size a, 8 a: .zero 8 .type b, %object .size b, 8 b: .zero 8 .type c, %object .size c, 4 c: .zero 4 .type d, %object .size d, 4 d: .zero 4 .ident GCC: (GNU) 5.0.0 20141118 (experimental) ldp opportunity in bar is captured, but not the one in foo. Apparently, fwprop pass propagates the expression into memory reference, corrupting the pair opportunity. This is another known issue for long time. So I think we should take the fwprop issue as a separate bug and close this out for 5.0 as the main work required to generate ldp / stp in the compiler is now done.
[Bug c++/64266] New: Can GCC produce local mergeable symbols for *.__FUNCTION__ and *.__PRETTY_FUNCTION__ function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64266
Bug ID: 64266
Summary: Can GCC produce local mergeable symbols for
*.__FUNCTION__ and *.__PRETTY_FUNCTION__ function.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Created attachment 34250
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34250action=edit
test case
For the following testcase:
extern C {
extern int printf (char *, ...);
}
class a {
public:
void sub (int i)
{
printf (__FUNCTION__ = %s\n, __FUNCTION__);
printf (__PRETTY_FUNCTION__ = %s\n, __PRETTY_FUNCTION__);
}
void sub()
{
printf (__FUNCTION__ = %s\n, __FUNCTION__);
}
};
int
main (void)
{
a ax;
ax.sub (0);
ax.sub ();
return 0;
}
Unlink clang, GCC produces a local symbol residing in .symtab and string values
are not in mergeable section:
$ g++ ~/Programming/testcases/pretty-function.c -o a.o
$ readelf -s a.o --wide | grep PRE
15: 0040071017 OBJECT LOCAL DEFAULT 14
_ZZN1a3subEiE19__PRETTY_FUNCTION__
$ readelf -p '.rodata' a.out
String dump of section '.rodata':
[10] __FUNCTION__ = %s
[23] __PRETTY_FUNCTION__ = %s
[3d] sub
[50] void a::sub(int)
[61] sub
and clang produces:
$ clang++ ~/Programming/testcases/pretty-function.c -o a.o
$ readelf -s a.out --wide | grep PRE
(nothing)
$ readelf -p '.rodata' a.o
String dump of section '.rodata':
[ 4] __FUNCTION__ = %s
[17] sub
[1b] __PRETTY_FUNCTION__ = %s
[35] void a::sub(int)
I'm wondering if we can also process such kind of optimization.
For Inkscape (compiled with -O2), there are following differences:
section portionsizesizecompared
comparison
.rodata 15.69 % 2.41 MB 2523277 2291412 90.81
%
.strtab 13.06 % 2.00 MB 2099988 1933845 92.09
%
Where column 'size' is related to GCC and 'compared' is size generated by
clang.
Thanks,
Martin
[Bug c++/64267] New: [DR 482] Qualified declarators in redeclarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64267
Bug ID: 64267
Summary: [DR 482] Qualified declarators in redeclarations
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
namespace S
{
struct coll;
struct ::S::coll { };
}
qual.cc:4:20: error: global qualification of class name is invalid before ‘{’
token
struct ::S::coll { };
^
Clang 3.4 rejected this but 3.5 accepts it (with a -Wextra-qualification
warning) and EDG accepts it.
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#482 makes this
valid, in at least C++14 (but it's a DR against C++11 so maybe there too).
The example from DR 482 is:
void f();
void ::f();// error: qualified declarator
namespace N {
void f();
void N::f() { } // error: qualified declarator
}
I get the same results for this, Clang 3.4 rejects, 3.5+ accepts, EDG accepts,
and G++ rejects in all modes:
dr482.cc:2:14: error: explicit qualification in declaration of ‘void f()’
void ::f();// error: qualified declarator
^
dr482.cc:6:17: error: explicit qualification in declaration of ‘void N::f()’
void N::f() { } // error: qualified declarator
^
[Bug tree-optimization/63288] [5 Regression] gcc.c-torture/execute/20140326-1.c FAILs with -Og -fgcse -fif-conversion2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63288 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r210492.
[Bug c++/64266] Can GCC produce local mergeable symbols for *.__FUNCTION__ and *.__PRETTY_FUNCTION__ functions?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64266
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
C++11 says that the address of __func__ can be the same as address of other
string literals, so I think that allows putting it into mergeable section.
But what isn't clear to me is if __func__ is used in some inline function,
if the standard allows __func__ to have different addresses between different
compilation units. Say a.h:
extern void bar (const char *);
inline void foo () { bar (__func__); }
a.C:
#include a.h
void bar (const char *x)
{
static const char *p;
if (p p != x) __builtin_abort ();
p = x;
}
extern void baz ();
int
main ()
{
foo ();
baz ();
foo ();
}
b.C:
#include a.h
void baz ()
{
foo ();
}
Now, if you compile b.C into a shared library and a.C into executable linked
with the shared library, this will fail. If instead of bar (__func__) you use
static const char func[] = func; bar (func) it will presumably work fine.
So, the question is if C++ should just say that address comparisons on the
__func__ variables are undefined, or if we really need to make sure we use a
public symbol rather than private in that case.
And, for __func__ occurrences in non-inline functions, supposedly we can keep
them local and could consider using local symbols instead of the mangled names
to decrease .symtab/.strtab size. Though, perhaps that will make it harder for
users to inspect those in gdb.
[Bug tree-optimization/57523] ICE in merge_assigned_reloads, at reload1.c:6062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57523 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- .
[Bug tree-optimization/55405] ICE with optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55405 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- All active branches seem to be fine now.
[Bug tree-optimization/53966] procmail build deadloop on _autotst -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53966 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- No feedback.
[Bug c++/64267] [DR 482] Qualified declarators in redeclarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64267 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- It seems Clang 3.1 used to give a warning, but Clang 3.2 promoted it to an error for GCC and EDG compatibility. They must have changed it again for DR482.
[Bug tree-optimization/55459] Firefox 17: internal compiler error: in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55459 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- Should be fixed now.
[Bug target/64268] New: [5 Regression] bootstrap failure (ICE in wide_int_to_tree, at tree.c:1438) on powerpc in libgcc, stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64268 Bug ID: 64268 Summary: [5 Regression] bootstrap failure (ICE in wide_int_to_tree, at tree.c:1438) on powerpc in libgcc, stage2 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org seen with 20141211, r218620, failing to configure libgcc: configure:3427: /home/doko/gcc/gcc-snapshot-20141211/build/./gcc/xgcc -B/home/doko/gcc/gcc-snapsho t-20141211/build/./gcc/ -B/usr/lib/gcc-snapshot/powerpc-linux-gnu/bin/ -B/usr/lib/gcc-snapshot/pow erpc-linux-gnu/lib/ -isystem /usr/lib/gcc-snapshot/powerpc-linux-gnu/include -isystem /usr/lib/gcc -snapshot/powerpc-linux-gnu/sys-include-o conftest -g -O2 conftest.c 5 built-in: internal compiler error: in wide_int_to_tree, at tree.c:1438 Please submit a full bug report, with preprocessed source if appropriate.
[Bug tree-optimization/61328] valgrind finds problem in find_bswap_or_nop_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61328 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- Assuming fixed.
[Bug tree-optimization/14541] [tree-ssa] built-in math functions are not fully optimized at tree level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14541 --- Comment #22 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to ktkachov from comment #21) Created attachment 34215 [details] Link errors output for aarch64 Which one exactly? That is, what is the failing link output? All of them AFAICS. I'm attaching the link failures log. The test PASSes at -O2 -flto and -O2 -flto -flto-partition=none but FAILs on all other torture options With a cross to aarch64-linux and compiling with -O1+ -ffast-math the result is as expected (optimized to empty functions). How exactly do you configure? I used /space/rguenther/src/svn/trunk2/configure --target=aarch64-suse-linux --enable-languages=c,c++,fortran --enable-checking
[Bug c/64269] New: ICE with -O3 enabled on Ubuntu 14.04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64269
Bug ID: 64269
Summary: ICE with -O3 enabled on Ubuntu 14.04
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tarasevich at cs dot uni-saarland.de
Created attachment 34251
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34251action=edit
preprocessed test case
home/tarasevich/build/bin/gcc492 -v -save-temps -O3 test_case_7213.c
Using built-in specs.
COLLECT_GCC=/home/tarasevich/build/bin/gcc492
COLLECT_LTO_WRAPPER=/home/tarasevich/build/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../../source/gcc_492/configure --enable-coverage
--prefix=/home/tarasevich/build/ --program-suffix=492 --disable-multilib
Thread model: posix
gcc version 4.9.2 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mtune=generic' '-march=x86-64'
/home/tarasevich/build/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/cc1 -E
-quiet -v -imultiarch x86_64-linux-gnu test_case_7213.c -mtune=generic
-march=x86-64 -O3 -fpch-preprocess -o test_case_7213.i
ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu
ignoring nonexistent directory
/home/tarasevich/build/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/home/tarasevich/build/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include
/usr/local/include
/home/tarasevich/build/include
/home/tarasevich/build/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mtune=generic' '-march=x86-64'
/home/tarasevich/build/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/cc1
-fpreprocessed test_case_7213.i -quiet -dumpbase test_case_7213.c
-mtune=generic -march=x86-64 -auxbase test_case_7213 -O3 -version -o
test_case_7213.s
GNU C (GCC) version 4.9.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 4.3.2, MPFR version 2.4.2, MPC
version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (GCC) version 4.9.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 4.3.2, MPFR version 2.4.2, MPC
version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: fc102f9fe8436bee9826789629a3ba6f
test_case_7213.c: In function ‘main’:
test_case_7213.c:1:5: internal compiler error: Segmentation fault
int main() {
^
0xdeed4a crash_signal
../../../source/gcc_492/gcc/toplev.c:337
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 ipa/64190] [4.9 Regression] FAIL: gcc.dg/ipa/pr63551.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64190 --- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to Eric Botcazou from comment #2) Everywhere I guess. I'm not getting this warning neither on x86_64-linux nor on i686-linux, otherwise I would not have committed the patch. Any information about the platform you are getting the warning on would be appreciated. If you can reproduce it, can you check whether providing option -std=c90 or something like it would suppress it?
[Bug c/64269] ICE with -O3 enabled on Ubuntu 14.04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64269 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-11 CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||4.8.3, 4.9.1, 5.0 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Confirmed. ==3714== Invalid write of size 8 ==3714==at 0x402F8B7: memset (vg_replace_strmem.c:1094) ==3714==by 0xBC185D: simplify_builtin_call(gimple_stmt_iterator*, tree_node*) (tree-ssa-forwprop.c:1396) ==3714== Address 0xfff001000 is not stack'd, malloc'd or (recently) free'd ==3714== test_case_7213.c: In function ‘main’: test_case_7213.c:1:5: internal compiler error: Segmentation fault
[Bug c/64269] ICE with -O3 enabled on Ubuntu 14.04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64269 --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- But the testcase is invalid: markus@x4 tmp % frama-c -val -val-signed-overflow-alarms -precise-unions -obviously-terminates -no-val-show-progress -machdep x86_64 test_case_7213.c [kernel] preprocessing with gcc -C -E -I. test_case_7213.c [value] Analyzing a complete application starting at main [value] Computing initial state [value] Initial state computed [value] Values of globals at initialization test_case_7213.c:14:[kernel] warning: out of bounds write. assert \valid(tmp_5);
[Bug tree-optimization/14541] [tree-ssa] built-in math functions are not fully optimized at tree level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14541 --- Comment #23 from ktkachov at gcc dot gnu.org --- (In reply to Richard Biener from comment #22) (In reply to ktkachov from comment #21) Created attachment 34215 [details] Link errors output for aarch64 Which one exactly? That is, what is the failing link output? All of them AFAICS. I'm attaching the link failures log. The test PASSes at -O2 -flto and -O2 -flto -flto-partition=none but FAILs on all other torture options With a cross to aarch64-linux and compiling with -O1+ -ffast-math the result is as expected (optimized to empty functions). How exactly do you configure? I used /space/rguenther/src/svn/trunk2/configure --target=aarch64-suse-linux --enable-languages=c,c++,fortran --enable-checking Hmmm... My compiler is a bare-metal one: aarch64-none-elf (and I still see these failures). With an aarch64-none-linux-gnu compiler the testcase works fine...
[Bug tree-optimization/61917] [4.9/5 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61917
Andrey Tarasevich tarasevich at cs dot uni-saarland.de changed:
What|Removed |Added
CC||tarasevich at cs dot
uni-saarland.
||de
--- Comment #3 from Andrey Tarasevich tarasevich at cs dot uni-saarland.de ---
Is it the same bug? It is triggered only if printf() is called.
→ /home/tarasevich/build/bin/gcc492 -v -save-temps -O3 test_case_3001.c
Using built-in specs.
COLLECT_GCC=/home/tarasevich/build/bin/gcc492
COLLECT_LTO_WRAPPER=/home/tarasevich/build/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../../source/gcc_492/configure --enable-coverage
--prefix=/home/tarasevich/build/ --program-suffix=492 --disable-multilib
Thread model: posix
gcc version 4.9.2 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mtune=generic' '-march=x86-64'
/home/tarasevich/build/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/cc1 -E
-quiet -v -imultiarch x86_64-linux-gnu test_case_3001.c -mtune=generic
-march=x86-64 -O3 -fpch-preprocess -o test_case_3001.i
ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu
ignoring nonexistent directory
/home/tarasevich/build/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/home/tarasevich/build/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include
/usr/local/include
/home/tarasevich/build/include
/home/tarasevich/build/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mtune=generic' '-march=x86-64'
/home/tarasevich/build/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/cc1
-fpreprocessed test_case_3001.i -quiet -dumpbase test_case_3001.c
-mtune=generic -march=x86-64 -auxbase test_case_3001 -O3 -version -o
test_case_3001.s
GNU C (GCC) version 4.9.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 4.3.2, MPFR version 2.4.2, MPC
version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (GCC) version 4.9.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 4.3.2, MPFR version 2.4.2, MPC
version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: fc102f9fe8436bee9826789629a3ba6f
test_case_3001.c: In function ‘main’:
test_case_3001.c:10:5: warning: incompatible implicit declaration of built-in
function ‘printf’
printf(%d, var4);
^
test_case_3001.c:1:5: internal compiler error: in vectorizable_reduction, at
tree-vect-loop.c:4913
int main() {
^
0x118d0c2 vectorizable_reduction(gimple_statement_base*, gimple_stmt_iterator*,
gimple_statement_base**, _slp_tree*)
../../../source/gcc_492/gcc/tree-vect-loop.c:4913
0x116e79d vect_analyze_stmt(gimple_statement_base*, bool*, _slp_tree*)
../../../source/gcc_492/gcc/tree-vect-stmts.c:7106
0x117e50d vect_analyze_loop_operations
../../../source/gcc_492/gcc/tree-vect-loop.c:1505
0x117f5a3 vect_analyze_loop_2
../../../source/gcc_492/gcc/tree-vect-loop.c:1766
0x117fdd3 vect_analyze_loop(loop*)
../../../source/gcc_492/gcc/tree-vect-loop.c:1864
0x11b536c vectorize_loops()
../../../source/gcc_492/gcc/tree-vectorizer.c:430
0x102fb8d tree_loop_vectorize
../../../source/gcc_492/gcc/tree-ssa-loop.c:154
0x102fcc4 execute
../../../source/gcc_492/gcc/tree-ssa-loop.c:189
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
---
int main() {
int var4 = 1;
int var5 = -10;
for (; var5 = 0; ++var5) {
int var6 = -1979310964;
for (; var6 = -1979310946; ++var6) {
var4 = var5 - var4;
}
}
printf(%d, var4);
}
[Bug tree-optimization/61917] [4.9/5 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61917 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Yes, I think that is the same bug.
[Bug tree-optimization/63288] [5 Regression] gcc.c-torture/execute/20140326-1.c FAILs with -Og -fgcse -fif-conversion2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63288 --- Comment #4 from Zdenek Sojka zsojka at seznam dot cz --- (In reply to Marek Polacek from comment #3) Started with r210492. In that case the issue might be latent at least in 4_9.
[Bug middle-end/64099] [5 Regression] ~15% runtime increase for fatigue.f90.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64099 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- I can confirm a regression of ~7% vs. 4.9 with -Ofast -fwhole-program on x86_64-linux (otherwise default -march/tune). perf isn't too useful (everything is inlined into MAIN__ it seems).
[Bug target/64263] [5.0 Regression] ICE where adddi3_aarch64 does not satisfy its constraints after r217546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64263 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug c++/64270] New: packed fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64270 Bug ID: 64270 Summary: packed fields Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: damien.ruscoe at imgtec dot com Testcase attached. Passing an array field from a packed struct into a function as a reference appears to copy the array. If the function accesses the address of the array (or any of its elements) it will get the address of the temporary created in the scope of that function. Using that address after the return of the function leads to bad stuff happening :/ Testing has been done on many versions of gcc $ g++ --version g++ packed_stuct_access.cpp ./a.out g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-46) 0xbfd28c4c 0xbfd28c54 a.out: packed_stuct_access.cpp:8: void ASSERT_EQUALS(const T, const T) [with T = const uint32_t*]: Assertion `expected == value' failed. Aborted $ g++ --version g++ packed_stuct_access.cpp ./a.out g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-54) 0xbfeb608c 0xbfeb6094 a.out: packed_stuct_access.cpp:8: void ASSERT_EQUALS(const T, const T) [with T = const uint32_t*]: Assertion `expected == value' failed. Aborted $ g++ --version g++ packed_stuct_access.cpp ./a.out g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-55) 0xbf93351c 0xbf933524 a.out: packed_stuct_access.cpp:8: void ASSERT_EQUALS(const T, const T) [with T = const uint32_t*]: Assertion `expected == value' failed. Aborted $ g++ --version g++ packed_stuct_access.cpp ./a.out g++ (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3) 0x7fff5992e0d0 0x7fff5992e0e0 a.out: packed_stuct_access.cpp:8: void ASSERT_EQUALS(const T, const T) [with T = const uint32_t*]: Assertion `expected == value' failed. Aborted (core dumped) $ g++ --version g++ packed_stuct_access.cpp ./a.out g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3) 0x7fff31acda70 0x7fff31acda80 a.out: packed_stuct_access.cpp:8: void ASSERT_EQUALS(const T, const T) [with T = const uint32_t*]: Assertion `expected == value' failed. Aborted (core dumped) $ g++ --version g++ packed_stuct_access.cpp ./a.out g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4) 0x7fff3641dee0 0x7fff3641def0 a.out: packed_stuct_access.cpp:8: void ASSERT_EQUALS(const T, const T) [with T = const uint32_t*]: Assertion `expected == value' failed. Aborted (core dumped) $ g++ --version g++ packed_stuct_access.cpp ./a.out g++ (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1 0x7fff3456f260 0x7fff3456f250 a.out: packed_stuct_access.cpp:8: void ASSERT_EQUALS(const T, const T) [with T = const unsigned int*]: Assertion `expected == value' failed. Aborted (core dumped)
[Bug c++/64270] packed fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64270 Damien Ruscoe damien.ruscoe at imgtec dot com changed: What|Removed |Added CC||damien.ruscoe at imgtec dot com --- Comment #1 from Damien Ruscoe damien.ruscoe at imgtec dot com --- Created attachment 34252 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34252action=edit testcase
[Bug middle-end/56212] Does not fold unsigned (b - a) + a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56212 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Trunk optimizes it to return b now, so I guess fixed.
[Bug middle-end/53293] Internal Compiler Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53293 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- So fixed.
[Bug middle-end/52587] using out of bounds of an array with size of one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52587 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- So should be fixed now.
[Bug middle-end/48164] ICE in redirect_jump, at jump.c:1443
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48164 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Should be fixed now.
[Bug c++/64270] packed fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64270 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-11 Version|4.1.2 |4.8.3 Ever confirmed|0 |1 Known to fail||4.1.2, 4.4.7, 4.8.3, 5.0 Severity|major |normal --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Confirmed.
[Bug lto/64262] [5 Regression] Several LTO failures after r218609.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64262 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target||aarch64*, x86* CC||ktkachov at gcc dot gnu.org Known to fail||5.0 --- Comment #2 from ktkachov at gcc dot gnu.org --- Confirming it for me too...
[Bug target/64160] msp430 code generation error adding 32-bit integers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64160 --- Comment #6 from Nick Clifton nickc at redhat dot com --- Hi Ulrich, if (reg_overlap_mentioned_p (operands[3], operands[7]) || reg_overlap_mentioned_p (operands[3], operands[8])) FAIL; Thanks - that is indeed a better solution to the bug. B.t.w. is there a particular reason why the target-specific msp430_subreg is needed instead of the usual operand_subword? I am not sure. According to the comments in msp430.c it is because; Simplify_gen_subreg() doesn't handle memory references the way we need it to below, so we use this function for when we must get a valid subreg in a 'natural' state. I think that this is all connected with the fact that for the MSP430 in large mode, pointers are 20-bits long, and that this tends to confuse gcc. Cheers Nick
[Bug middle-end/64099] [5 Regression] ~15% runtime increase for fatigue.f90.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64099
--- Comment #9 from Richard Biener rguenth at gcc dot gnu.org ---
For r217826 vs. r217827 the assembly differences show a larger stack frame
while the optimized dump differences are net positive (more memory CSE happens
and loads get removed - which might increase register pressure enough).
For r216727 vs. r216728 the order of functions output changes, there are no
real changes in the optimized dumps.
Both rev. changes cause operand order to be swapped for some instructions
which can, given TER, result in significant scheduling differences in
the RTL expansion.
One thing is for example that the reassoc pass produces non-canonical
operand order but its operand order might be more optimal in practice
(the canonical order is just canonicalization for commutative operands).
As we deal with single-use chains there we might consider swapping
SSA names (swap SSA_NAME_VERSION) to preserve its ordering over a
fold_stmt call. No, doing that doesn't make a significant difference :/
For reference:
Index: gcc/tree-ssa-reassoc.c
===
--- gcc/tree-ssa-reassoc.c (revision 217827)
+++ gcc/tree-ssa-reassoc.c (working copy)
@@ -3602,6 +3602,16 @@ rewrite_expr_tree (gimple stmt, unsigned
update_stmt (stmt);
}
+ if (commutative_tree_code (gimple_assign_rhs_code (stmt))
+ tree_swap_operands_p (new_rhs1, oe-op, true))
+ {
+ gcc_assert (TREE_CODE (new_rhs1) == SSA_NAME
+ TREE_CODE (oe-op) == SSA_NAME);
+ std::swap (SSA_NAME_VERSION (new_rhs1), SSA_NAME_VERSION (oe-op));
+ std::swap (ssa_name (SSA_NAME_VERSION (new_rhs1)),
+ssa_name (SSA_NAME_VERSION (oe-op)));
+ }
+
if (dump_file (dump_flags TDF_DETAILS))
{
fprintf (dump_file, into );
[Bug jit/63854] Fix memory leaks seen in JIT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63854
David Binderman dcb314 at hotmail dot com changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment #29 from David Binderman dcb314 at hotmail dot com ---
Similar thing in the same area, caught using static analyser cppcheck:
[gcc/jit/jit-playback.c:1791]: (error) Resource leak: f_in
Source code is
if (!feof (f_in))
{
add_error (NULL, error reading from %s, path);
free (result);
return NULL;
}
fclose (f_in);
It looks to me like a call to fclose needs to happen just before
the return.
[Bug fortran/44054] Handle -Werror, -Werror=, -fdiagnostics-show-option, !GCC$ diagnostic (pragmas) and color
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44054 --- Comment #21 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Author: manu Date: Thu Dec 11 15:13:33 2014 New Revision: 218627 URL: https://gcc.gnu.org/viewcvs?rev=218627root=gccview=rev Log: gcc/ChangeLog: 2014-12-11 Manuel López-Ibáñez m...@gcc.gnu.org PR fortran/44054 * diagnostic.c (diagnostic_action_after_output): Make it extern. Take diagnostic_t argument instead of diagnostic_info. Count also DK_WERROR towards max_errors. (diagnostic_report_diagnostic): Update call according to the above. (error_recursion): Likewise. * diagnostic.h (diagnostic_action_after_output): Declare. * pretty-print.c (pp_formatted_text_data): Delete. (pp_append_r): Call output_buffer_append_r. (pp_formatted_text): Call output_buffer_formatted_text. (pp_last_position_in_text): Call output_buffer_last_position_in_text. * pretty-print.h (output_buffer_formatted_text): New. (output_buffer_append_r): New. (output_buffer_last_position_in_text): New. gcc/testsuite/ChangeLog: 2014-12-11 Manuel López-Ibáñez m...@gcc.gnu.org * gfortran.dg/do_iterator.f90: Remove bogus dg-warning. gcc/fortran/ChangeLog: 2014-12-11 Manuel López-Ibáñez m...@gcc.gnu.org PR fortran/44054 * error.c (pp_error_buffer): New static variable. (pp_warning_buffer): Make it a pointer. (gfc_output_buffer_empty_p): New. (gfc_error_init_1): Call gfc_buffer_error. (gfc_buffer_error): Do not use pp_warning_buffer.flush_p as the buffered_p flag. (gfc_clear_warning): Likewise. (gfc_warning_check): Call gfc_clear_warning. Only check the new pp_warning_buffer if the old warning_buffer was empty. Call diagnostic_action_after_output. (gfc_error_1): Renamed from gfc_error. (gfc_error): New. (gfc_clear_error): Clear also pp_error_buffer. (gfc_error_flag_test): Check also pp_error_buffer. (gfc_error_check): Likewise. Only check the new pp_error_buffer if the old error_buffer was empty. (gfc_move_output_buffer_from_to): New. (gfc_push_error): Use it here. Take also an output_buffer as argument. (gfc_pop_error): Likewise. (gfc_free_error): Likewise. (gfc_diagnostics_init): Use XNEW and placement-new to init pp_error_buffer and pp_warning_buffer. Set flush_p to false for both pp_warning_buffer and pp_error_buffer. * Update gfc_push_error, gfc_pop_error and gfc_free_error calls according to the above changes. * Use gfc_error_1 for all gfc_error calls that use multiple locations. * Use %qs instead of '%s' for many gfc_error calls. Modified: trunk/gcc/ChangeLog trunk/gcc/diagnostic.c trunk/gcc/diagnostic.h trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/array.c trunk/gcc/fortran/check.c trunk/gcc/fortran/class.c trunk/gcc/fortran/data.c trunk/gcc/fortran/decl.c trunk/gcc/fortran/error.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/match.c trunk/gcc/fortran/openmp.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/scanner.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-common.c trunk/gcc/pretty-print.c trunk/gcc/pretty-print.h trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/64269] [4.8/4.9/5 Regression] ICE with -O3 enabled on Ubuntu 14.04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64269 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Known to work||4.7.4 Target Milestone|--- |4.8.4 Summary|ICE with -O3 enabled on |[4.8/4.9/5 Regression] ICE |Ubuntu 14.04|with -O3 enabled on Ubuntu ||14.04 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Works with 4.7.x. 1395 memset (src_buf + tree_to_uhwi (diff), 1396 tree_to_shwi (val2), tree_to_uhwi (len2)); (gdb) p debug_generic_expr (len2) 18446744073709551615 (that's -1) function added by Jakub (simplify_builtin_call).
[Bug target/64268] [5 Regression] bootstrap failure (ICE in wide_int_to_tree, at tree.c:1438) on powerpc in libgcc, stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64268 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug fortran/44054] Handle -Werror, -Werror=, -fdiagnostics-show-option, !GCC$ diagnostic (pragmas) and color
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44054
--- Comment #22 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
I think the two remaining issues are:
1) Multiple locations (%C/%L) in diagnostics
2) Support !GCC$ diagnostic (pragmas)
For (2), I'm not planning to work on it since it seems all the common support
is there, Fortran just needs to parse and handle the pragmas in the same way as
the C/C++ FEs do. There may be some opportunity for code sharing (perhaps the
pragmas are language specific and they should not be), but I haven't looked at
the details.
For (1), my plan is to add location_t location[2] to text_info and make
diagnostic_context directly use those. The common part in diagnostic.c will
need some refactoring to print two caret chars in the same line and to
customize which caret char and which location is printed so that Fortran can
print the second location on a different line with a different caret char when
desired. The most tricky part is how to handle the prefix/locus_prefix
difference when there is zero, one or two caret lines printed, in
gfc_diagnostic_starter(). Handling two locations in gfc_format_decoder is
trivial if one considers that the only way to set text-location[0] in Fortran
is via gfc_format_decoder itself:
--- gcc/fortran/error.c (revision 218628)
+++ gcc/fortran/error.c (working copy)
@@ -1056,25 +1056,26 @@ gfc_format_decoder (pretty_printer *pp,
switch (*spec)
{
case 'C':
case 'L':
{
- static const char *result = (1);
+ static const char *result[2] = { (1), (2) };
locus *loc;
if (*spec == 'C')
loc = gfc_current_locus;
else
loc = va_arg (*text-args_ptr, locus *);
gcc_assert (loc-nextc - loc-lb-line = 0);
unsigned int offset = loc-nextc - loc-lb-line;
- gcc_assert (text-locus);
- *text-locus
+ /* If location[0] != UNKNOWN_LOCATION means that we already
+ processed one of %C/%L. */
+ int loc_num = text-location[0] == UNKNOWN_LOCATION ? 0 : 1;
+ text-location[loc_num]
= linemap_position_for_loc_and_offset (line_table,
loc-lb-location,
offset);
- global_dc-caret_char = '1';
- pp_string (pp, result);
+ pp_string (pp, result[loc_num]);
return true;
}
default:
return false;
}
[Bug bootstrap/64271] New: Minimal patches to bootstrap on NetBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64271 Bug ID: 64271 Summary: Minimal patches to bootstrap on NetBSD Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: kuehro at gmx dot de Created attachment 34253 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34253action=edit libstdc++-patch1 Bootstrap of 5.0 fails on NetBSD, but with the patches in NetBSD's package system pkgsrc it builds a functional gcc. In Bug #48244 I was asked to submit a minimal set of patches to bootstrap with testresults. So I did a stepwise bootstrap until failure and used the relevant patches from pkgsrc, precisely http://pkgsrc-wip.cvs.sourceforge.net/viewvc/pkgsrc-wip/wip/gcc50snapshot/ On NetBSD 7.0 amd64: /home/kue/build/gcc_patched/gcc-5-20141207/configure --disable-nls --with-libiconv-prefix=/usr --enable-__cxa_atexit --with-gxx-include-dir=/home/kue/gcc5install/include/c++/ --enable-languages='c obj-c++ objc fortran c++' --enable-shared --enable-long-long --with-local-prefix=/home/kue/gcc5install --enable-libssp --enable-threads=posix --with-boot-ldflags='-static-libstdc++ -static-libgcc -Wl,-R/home/kue/local/lib ' --with-gnu-ld --with-ld=/usr/bin/ld --with-gnu-as --with-as=/usr/bin/as --with-arch=nocona --with-tune=nocona --with-fpmath=sse --prefix=/home/kue/gcc5install --build=x86_64--netbsd --host=x86_64--netbsd --infodir=/home/kue/gcc5install/info --mandir=/home/kue/gcc5install/man ac_cv_func_clock_gettime=yes ac_cv_func_gethostbyname=yes ac_cv_func_freelocale=no ac_cv_func_newlocale=no ac_cv_func_uselocale=no env ac_cv_func_clock_gettime=yes ac_cv_func_gethostbyname=yes ac_cv_func_freelocale=no ac_cv_func_newlocale=no ac_cv_func_uselocale=no gmake 21|tee builderror.log gmake -k check 21|tee testsuiterun.log the six attached patches are necessary to bootstrap.
[Bug bootstrap/64271] Minimal patches to bootstrap on NetBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64271 --- Comment #1 from Kai-Uwe Eckhardt kuehro at gmx dot de --- Created attachment 34254 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34254action=edit libstdc++-patch2
[Bug bootstrap/64271] Minimal patches to bootstrap on NetBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64271 --- Comment #2 from Kai-Uwe Eckhardt kuehro at gmx dot de --- Created attachment 34255 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34255action=edit libstdc++-patch3
[Bug bootstrap/64271] Minimal patches to bootstrap on NetBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64271 --- Comment #3 from Kai-Uwe Eckhardt kuehro at gmx dot de --- Created attachment 34256 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34256action=edit libcilkrts1
[Bug bootstrap/64271] Minimal patches to bootstrap on NetBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64271 --- Comment #5 from Kai-Uwe Eckhardt kuehro at gmx dot de --- Created attachment 34258 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34258action=edit libgfortran-weak
[Bug bootstrap/64271] Minimal patches to bootstrap on NetBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64271 --- Comment #4 from Kai-Uwe Eckhardt kuehro at gmx dot de --- Created attachment 34257 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34257action=edit libcilkrts-thread cilk uses a non-posix function
[Bug bootstrap/64271] Minimal patches to bootstrap on NetBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64271 --- Comment #6 from Kai-Uwe Eckhardt kuehro at gmx dot de --- Created attachment 34259 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34259action=edit test_summary All gfortran tests fail to run due to bug #39570
[Bug tree-optimization/42108] [4.8/4.9 Regression] 50% performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||5.0 Summary|[4.8/4.9/5 Regression] 50% |[4.8/4.9 Regression] 50% |performance regression |performance regression Known to fail||4.3.6 --- Comment #67 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk (sofar). --- Comment #68 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Dec 11 15:52:47 2014 New Revision: 218630 URL: https://gcc.gnu.org/viewcvs?rev=218630root=gccview=rev Log: 2014-12-11 Richard Biener rguent...@suse.de PR tree-optimization/42108 * trans-stmt.c (gfc_trans_do): Execute the division computing countm1 before the loop entry check. * gfortran.dg/pr42108.f90: Amend. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pr42108.f90
[Bug fortran/48244] iso-c-binding support missing on NetBSD (with patch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48244 --- Comment #9 from Kai-Uwe Eckhardt kuehro at gmx dot de --- I have submitted the necessary patches and test_result.log as #64271
[Bug middle-end/64272] New: useless called from here for inline failed error/warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64272
Bug ID: 64272
Summary: useless called from here for inline failed
error/warning
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
CC: schwab at gcc dot gnu.org
Notice here: https://sourceware.org/ml/libc-alpha/2014-12/msg00300.html
It is useless to print the additional called from here (which should be an
inform note) if there is no location. Also, in the case of warning, there is no
point in giving the additional note if no warning was emitted.
I would argue that it would be better to print first the location of the call
and then give a note saying declared here, like we do for other similar
warnings. However, since there may be no location for the call (???!!!), I
guess we can make do with something like the patch below.
I don't actually have a testcase. Andreas, could you extract one from the glibc
sources? Thanks!
Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c (revision 218628)
+++ gcc/tree-inline.c (working copy)
@@ -4383,13 +4383,15 @@ expand_call_inline (basic_block bb, gimp
|| !optimize
|| cgraph_inline_failed_type (reason) == CIF_FINAL_ERROR)
/* PR 20090218-1_0.c. Body can be provided by another module. */
(reason != CIF_BODY_NOT_AVAILABLE || !flag_generate_lto))
{
+ /* See https://sourceware.org/ml/libc-alpha/2014-12/msg00300.html */
error (inlining failed in call to always_inline %q+F: %s, fn,
cgraph_inline_failed_string (reason));
- error (called from here);
+ if (input_location != UNKNWON_LOCATION)
+ inform (input_location, called from here);
}
else if (warn_inline
DECL_DECLARED_INLINE_P (fn)
!DECL_NO_INLINE_WARNING_P (fn)
!DECL_IN_SYSTEM_HEADER (fn)
@@ -4398,13 +4400,14 @@ expand_call_inline (basic_block bb, gimp
/* Do not warn about not inlined recursive calls. */
!cg_edge-recursive_p ()
/* Avoid warnings during early inline pass. */
symtab-global_info_ready)
{
- warning (OPT_Winline, inlining failed in call to %q+F: %s,
- fn, _(cgraph_inline_failed_string (reason)));
- warning (OPT_Winline, called from here);
+ if (warning (OPT_Winline, inlining failed in call to %q+F: %s,
+ fn, _(cgraph_inline_failed_string (reason)))
+ input_location != UNKNWON_LOCATION)
+ inform (input_location, called from here);
}
goto egress;
}
fn = cg_edge-callee-decl;
cg_edge-callee-get_untransformed_body ();
[Bug bootstrap/64271] Minimal patches to bootstrap on NetBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64271 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Kai-Uwe Eckhardt from comment #0) Created attachment 34253 [details] libstdc++-patch1 Bootstrap of 5.0 fails on NetBSD, but with the patches in NetBSD's package system pkgsrc it builds a functional gcc. In Bug #48244 I was asked to submit a minimal set of patches to bootstrap with testresults. Please submit them by posting them to gcc-patc...@gcc.gnu.org. So I did a stepwise bootstrap until failure and used the relevant patches from pkgsrc, precisely http://pkgsrc-wip.cvs.sourceforge.net/viewvc/pkgsrc-wip/wip/gcc50snapshot/ On NetBSD 7.0 amd64: /home/kue/build/gcc_patched/gcc-5-20141207/configure --disable-nls --with-libiconv-prefix=/usr --enable-__cxa_atexit --with-gxx-include-dir=/home/kue/gcc5install/include/c++/ --enable-languages='c obj-c++ objc fortran c++' --enable-shared --enable-long-long --with-local-prefix=/home/kue/gcc5install --enable-libssp --enable-threads=posix --with-boot-ldflags='-static-libstdc++ -static-libgcc -Wl,-R/home/kue/local/lib ' --with-gnu-ld --with-ld=/usr/bin/ld --with-gnu-as --with-as=/usr/bin/as --with-arch=nocona --with-tune=nocona --with-fpmath=sse --prefix=/home/kue/gcc5install --build=x86_64--netbsd --host=x86_64--netbsd --infodir=/home/kue/gcc5install/info --mandir=/home/kue/gcc5install/man ac_cv_func_clock_gettime=yes ac_cv_func_gethostbyname=yes ac_cv_func_freelocale=no ac_cv_func_newlocale=no ac_cv_func_uselocale=no env ac_cv_func_clock_gettime=yes ac_cv_func_gethostbyname=yes ac_cv_func_freelocale=no ac_cv_func_newlocale=no ac_cv_func_uselocale=no gmake 21|tee builderror.log gmake -k check 21|tee testsuiterun.log the six attached patches are necessary to bootstrap.
[Bug bootstrap/64271] Minimal patches to bootstrap on NetBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64271 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Kai-Uwe Eckhardt from comment #0) Created attachment 34253 [details] libstdc++-patch1 This introduces an ABI change. Also, if _CTYPE_BL represents the blank character class, I would expect it to be used for the ctype_base::blank mask defined at the end of the file. I only defined it as equal to ctype_base::space because as far as I could tell NetBSD didn't support a bitmask element for blank. If that's changed in recent releases we should set ctype_base::blank properly. (In reply to Kai-Uwe Eckhardt from comment #1) Created attachment 34254 [details] libstdc++-patch2 (In reply to Kai-Uwe Eckhardt from comment #2) Created attachment 34255 [details] libstdc++-patch3 These two are OK.
[Bug bootstrap/64271] Minimal patches to bootstrap on NetBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64271 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Richard Biener from comment #7) Please submit them by posting them to gcc-patc...@gcc.gnu.org. And please CC libstd...@gcc.gnu.org for the three libstdc++ patches.
[Bug fortran/28662] fpp call of gfortran: -traditional-cpp versus newer macros like #x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28662 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org --- Related: All source-file reading should go though libcpp, which requires a better white space handling; cf. https://gcc.gnu.org/ml/fortran/2014-12/msg3.html
[Bug ipa/64190] [4.9 Regression] FAIL: gcc.dg/ipa/pr63551.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64190
--- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
I'm not getting this warning neither on x86_64-linux nor on i686-linux,
otherwise I would not have committed the patch. Any information about
the platform you are getting the warning on would be appreciated.
x86-64/Linux -m32 for me:
eric@polaris:~/build/gcc-4_9-branch/native gcc/xgcc -Bgcc pr63551.c -m32
pr63551.c: In function 'fn2':
pr63551.c:24:9: warning: this decimal constant is unsigned only in ISO C90
union U b = { 4294967286 };
If you can reproduce it, can you check whether providing option
-std=c90 or something like it would suppress it?
-std=c99 works.
[Bug fortran/54687] Use gcc option machinery for gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54687 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org --- At least all warnings should be handled now (work done as part of PR44054 and in the separate but related commit r218188). Is there still something missing?
