A question about redundant PHI expression stmt
Hi,
For the small case below, there are some redundant PHI expression stmt
generated, and finally cause back-end generates redundant copy instructions
due to some reasons around IRA.
int *l, *r, *g;
void test_func(int n)
{
int i;
static int j;
static int pos, direction, direction_pre;
pos = 0;
direction = 1;
for ( i = 0; i n; i++ )
{
direction_pre = direction;
for ( j = 0; j = 400; j++ )
{
if ( g[pos] == 200 )
break;
if ( direction == 0 )
pos = l[pos];
else
pos = r[pos];
if ( pos == -1 )
{
if ( direction_pre != direction )
break;
pos = 0;
direction = !direction;
}
}
f(g[pos]);
}
}
I know PR39976 has something to do with this case, and check-in r182140
caused big degradation on the real benchmark, but I'm still confusing around
this issue.
The procedure is like this,
Loop store motion generates code below,
bb 6:
D.4084_17 = l.4_13 + D.4077_70;
pos.5_18 = *D.4084_17;
pos_lsm.34_103 = pos.5_18;
goto bb 8;
bb 7:
D.4088_23 = r.6_19 + D.4077_70;
pos.7_24 = *D.4088_23;
pos_lsm.34_104 = pos.7_24;
bb 8:
# prephitmp.29_89 = PHI pos.5_18(6), pos.7_24(7)
# pos_lsm.34_53 = PHI pos_lsm.34_103(6), pos_lsm.34_104(7)
pos.2_25 = prephitmp.29_89;
if (pos.2_25 == -1)
goto bb 9;
else
goto bb 20;
And then, copy propagation transforms block 8 it into
bb 8:
# prephitmp.29_89 = PHI pos.5_18(11), pos.7_24(12)
# pos_lsm.34_53 = PHI pos.5_18(11), pos.7_24(12)
...
And then, these two duplicated PHI stmts have been kept until expand pass.
In dom2, a stmt like below
# pos_lsm.34_54 = PHI pos_lsm.34_53(13), 0(16)
is transformed into
# pos_lsm.34_54 = PHI prephitmp.29_89(13), 0(16)
just because they are equal.
Unfortunately, this transformation changed back-end behavior to generate
redundant copy instructions and hurt performance. This case is from a real
benchmark and hurt performance a lot.
Does the fix in r182140 intend to totally clean up this kind of redundancy?
Where should we get it fixed?
Thanks,
-Jiangning
Is it a bug when use “”if the operator is out of the size 0~63
Case:
#include stdio.h
#include stdlib.h
long long abc = 0x01234567891abcde;
long long xyz;
int main ()
{
xyz = abc 65;
printf(%llx\n, xyz);
return 0;
}
The result of xyz should be 0，but it is 2468acf123579bc ,same as xyz = abc
1,Why?
So as for int a35and etc..
YangYueming
Re: Is it a bug when use “”if the operator is out of the size 0~63
Yang Yueming yueming.y...@huawei.com writes: long long abc = 0x01234567891abcde; long long xyz; ... xyz = abc 65; ... The result of xyz should be 0，but it is 2468acf123579bc ,same as xyz = abc 1,Why? Because the shift operators in C have an undefined result when the shift-count is larger than the size of the type. As the compiler generally just generates the underlying CPU's shift instruction, then what happens in practice depends on the CPU. Different CPUs do different things in such a case, and one popular alternative is to simply interpret the shift-count modulo the word-size. So as for int a35and etc.. Same thing. -miles -- Electricity, n. The cause of all natural phenomena not known to be caused by something else.
Re: A question about redundant PHI expression stmt
On Fri, Feb 24, 2012 at 9:07 AM, Jiangning Liu jiangning@arm.com wrote:
Hi,
For the small case below, there are some redundant PHI expression stmt
generated, and finally cause back-end generates redundant copy instructions
due to some reasons around IRA.
int *l, *r, *g;
void test_func(int n)
{
int i;
static int j;
static int pos, direction, direction_pre;
pos = 0;
direction = 1;
for ( i = 0; i n; i++ )
{
direction_pre = direction;
for ( j = 0; j = 400; j++ )
{
if ( g[pos] == 200 )
break;
if ( direction == 0 )
pos = l[pos];
else
pos = r[pos];
if ( pos == -1 )
{
if ( direction_pre != direction )
break;
pos = 0;
direction = !direction;
}
}
f(g[pos]);
}
}
I know PR39976 has something to do with this case, and check-in r182140
caused big degradation on the real benchmark, but I'm still confusing around
this issue.
The procedure is like this,
Loop store motion generates code below,
bb 6:
D.4084_17 = l.4_13 + D.4077_70;
pos.5_18 = *D.4084_17;
pos_lsm.34_103 = pos.5_18;
goto bb 8;
bb 7:
D.4088_23 = r.6_19 + D.4077_70;
pos.7_24 = *D.4088_23;
pos_lsm.34_104 = pos.7_24;
bb 8:
# prephitmp.29_89 = PHI pos.5_18(6), pos.7_24(7)
# pos_lsm.34_53 = PHI pos_lsm.34_103(6), pos_lsm.34_104(7)
pos.2_25 = prephitmp.29_89;
if (pos.2_25 == -1)
goto bb 9;
else
goto bb 20;
And then, copy propagation transforms block 8 it into
bb 8:
# prephitmp.29_89 = PHI pos.5_18(11), pos.7_24(12)
# pos_lsm.34_53 = PHI pos.5_18(11), pos.7_24(12)
...
And then, these two duplicated PHI stmts have been kept until expand pass.
In dom2, a stmt like below
# pos_lsm.34_54 = PHI pos_lsm.34_53(13), 0(16)
is transformed into
# pos_lsm.34_54 = PHI prephitmp.29_89(13), 0(16)
just because they are equal.
Unfortunately, this transformation changed back-end behavior to generate
redundant copy instructions and hurt performance. This case is from a real
benchmark and hurt performance a lot.
Does the fix in r182140 intend to totally clean up this kind of redundancy?
Where should we get it fixed?
FRE/PRE are currently the only passes that remove redundant PHI nodes.
DOM can be trivially extended to do the same (I _think_ I had a patch for
this somewhere ... but in the end I think DOM should go, one VN is enough).
Richard.
Thanks,
-Jiangning
Re: Is it a bug when use “”if the operator is out of the size 0~63
This question is not appropriate for this mailing list, questions about using GCC should be sent to the gcc-h...@gcc.gnu.org list, please take any follow up there, thanks. On 24 February 2012 08:34, Yang Yueming wrote: The result of xyz should be 0，but it is 2468acf123579bc ,same as xyz = abc 1,Why? The C standard says it's undefined behaviour: If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined.
Proposal: Make TYPE_HASH != TYPE_UID
Over in the pph branch we are having several failures due to TYPE_CANONICAL and the canonical types table. Entries of the canonical types table corresponding to user-generated types get saved on each pre-parsed header. We then read the table back in and register the hash codes corresponding to each type. However, we later run into an ICE in comptypes() because the compiler gets different hash values from structurally identical types. The problem here is that the computation of type hash codes use a non-stable seed (TYPE_UID). When a header file is compiled independently to generate a corresponding pre-parsed header, types will receive different UIDs than when the file is compiled within a translation unit. Initially, I was toying with the idea of not saving the hash code but the steps needed to re-compute the hash code. This is not trivial, since all the hash code computations are open coded and do not always depend on the type itself (e.g., build_type_attribute_qual_variant). So, what I think will be more feasible to do is to make sure that types get stable hash codes that only depend on structural attributes of the type. So far, the only unstable element I've seen is the use of TYPE_UID in the hash computations. My proposal is to: 1- Separate TYPE_HASH from TYPE_UID. 2- Once a type T is entered in the canonical table, make TYPE_HASH(T) be the hash code that was used to enter the type. Another thing I noticed is that type_hash_canon insists that we only enter main variants of types. However, after being entered, some types get their TYPE_MAIN_VARIANT changed (this produces failures when we try to re-enter the types out of a PPH header, but this is simpler to resolve). Do you see any big problems with my plan? Thanks. Diego.
Re: Simulator testing for sh and sh64
Hi! On Thu, 23 Feb 2012 08:42:53 +0900, Kaz Kojima kkoj...@rr.iij4u.or.jp wrote: Thomas Schwinge tho...@codesourcery.com wrote: Kaz, is my understanding correct, that I simply use sh64-elf as target, and again the sh-sim board? Should I be setting a specific CPU when configuring GCC, or any other customization? I used sh64-sim board for sh64-elf. sh64-sim.exp baseboard can be seen in http://lists.gnu.org/archive/html/dejagnu/2008-02/msg00056.html I gave both sh-sim and sh64-sim a try, and -- if I'm reading correctly between all the noise -- there isn't really much difference in the testresults depending on which of the two is being used. This means, for sh-elf sim testing, we have a bit too many failures in GCC and GDB, and some ld test harness issue. For sh64-elf we have a GCC trunk ICE, some section overlap issue, and even more GDB issues. Yep. About sh64, I had used sh64-linux as my testing target, but unfortunately that real sh64 system stopped working after the earthquake. Ouch. :-/ Grüße, Thomas pgpkq7GpdnHMY.pgp Description: PGP signature
inline assembly
For extended inline assembly, there are constraints. Some seem to be supported by all architectures and some specific to a particular architecture. Where are these defined in gcc source? Some seem to be in constraints.md and some not. Tia. Reed
gcc-4.6-20120224 is now available
Snapshot gcc-4.6-20120224 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120224/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 184564 You'll find: gcc-4.6-20120224.tar.bz2 Complete GCC MD5=ac06030bbc4a01b21c8769583c1a2571 SHA1=e123ddfae6cc586e9aef619e24dc70a50f2f7242 Diffs from 4.6-20120217 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 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.
Re: inline assembly
reed kotler rkot...@mips.com writes: For extended inline assembly, there are constraints. Some seem to be supported by all architectures and some specific to a particular architecture. Where are these defined in gcc source? Some seem to be in constraints.md and some not. Machine-specific constraints are normally defined in, as you say, config/CPU/constraints.md. The generic constraints are handled in a few different places, notably ira-*.c, reload.c and recog.c. Probably the easiest way to find them is to grep for REG_CLASS_FROM_CONSTRAINT and check the code around the places where that is used. Ian
[Bug middle-end/39976] [4.5/4.6/4.7 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976 --- Comment #44 from Jiangning Liu jiangning.liu at arm dot com 2012-02-24 08:09:25 UTC --- I'm not sure if this kind of bug has been completely fixed, and posted a qeustion in mail list at http://gcc.gnu.org/ml/gcc/2012-02/msg00415.html .
[Bug rtl-optimization/37516] ~(-2 - a) is not being optimized into a + 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37516
--- Comment #5 from rguenther at suse dot de rguenther at suse dot de
2012-02-24 08:38:19 UTC ---
On Thu, 23 Feb 2012, pinskia at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37516
--- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-23
22:15:05 UTC ---
Maybe get away with these old-stylish names ('tree' and 'fold') and
make it match reality, gimple-ssa-combine.c ;)
That sounds like a good idea. I have done that.
Still have to have a look at your branch - do you have a brief
overview documentation, for example on the wiki? What I'd like
to do is have an interface that I can re-use for VN combining,
basically replace its simplify_*_expression functions.
I don't have one yet. But I hope to create one this weekend.
Right now replacing the VN combining with this new functionality will not work
as it scans the defs itself. Though I am moving all the def scanning to its
own function which should allow for the code to be more modular and allow for
the VN combining to work with it.
I think def scanning is ok, but all SSA names should be valueized via
a hook first.
Richard.
[Bug rtl-optimization/52060] [4.6 Regression] Invalid constant simplification in combine with parallel result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52060 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.6.4 |4.6.3
[Bug tree-optimization/52361] gcc.dg/pr48141.c times out with checking enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52361 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-24 09:16:43 UTC --- Well, that's sort-of expected ...
[Bug middle-end/52355] [4.7 regression] address difference between array elements is not considered to be a compile time constant anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52355 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-24 09:47:33 UTC --- We fold end up trying to fold (long int) (*(a + 256))[0][0] - (long int) (*a)[0][0] because a is of type char[16][16] *. I have a patch.
[Bug tree-optimization/52361] gcc.dg/pr48141.c times out with checking enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52361 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-24 10:35:32 UTC --- Actually I have a simple patch that speeds things up a bit, but not significantly so.
[Bug tree-optimization/52361] gcc.dg/pr48141.c times out with checking enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52361 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-02-24 10:43:02 UTC --- --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-24 10:35:32 UTC --- Actually I have a simple patch that speeds things up a bit, but not significantly so. I wonder if the testcase couldn't be reduced a bit, or instead marked with dg-require-effective-target run_expensive_tests I doubt there is much point routinely running such a compile time hog. Rainer
[Bug middle-end/52355] [4.7 regression] address difference between array elements is not considered to be a compile time constant anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52355 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-24 11:14:24 UTC --- Author: rguenth Date: Fri Feb 24 11:14:17 2012 New Revision: 184548 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184548 Log: 2012-02-24 Richard Guenther rguent...@suse.de PR middle-end/52355 * fold-const.c (fold_addr_of_array_ref_difference): New function. (fold_binary_loc): Use it to extend the existing a[i] - a[j] folding. * gcc.dg/pr52355.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr52355.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/52365] Procedure interface wrongly imported into interface without IMPORT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52365 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-24 11:16:09 UTC --- Note: I think the following variant is valid, where the symbol is in the same interface block. (Correctly accepted.) interface subroutine foo() end subroutine foo subroutine bar(x) procedure(foo) :: x end subroutine bar end interface end While the following variant is also invalid (but accepted): module m interface subroutine bar(x) procedure(foo) :: x end subroutine bar end interface contains subroutine foo() end subroutine foo end Hence, a simple check in decl.c is not possible as it will come too early for the second example. Still, some check should probably added to decl.c's match_procedure_interface - similarly to the gfc_current_ns-proc_name-attr.if_source == IFSRC_IFBODY check in variable_decl. Another check should be done at resolve_procedure_interface - or possibly the only check, if one modifies the way where the decl is declared for IFSRC_IFBODY.
[Bug c++/52369] New: Const-qualified non-class base member and defaulted default constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52369
Bug #: 52369
Summary: Const-qualified non-class base member and defaulted
default constructor
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ai.az...@gmail.com
Created attachment 26740
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26740
Output of -v option and preprocessed file
The following ill-formed code is wrongly accepted by GCC 4.7.0 20120218
(experimental).
class B
{
private:
int const v_;
};
class D
: public B
{};
int main()
{
D d;
}
B's default constructor is implicitly-declared and has no ctor-initializer. So,
B::v_ is not designated by any mem-initializer-id and subject to
default-initialization. However, default-initialization of a const-qualified
non-class type is ill-formed. Therefore, the use of B's constructor is
ill-formed (and it should be defined as deleted in -std=c++11 mode), and the
use of D's is also ill-formed.
N.B. A similar (but a bit different) problem seems to have been resolved in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29043 .
[Bug target/52367] Many incorrect thumb insn lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52367 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-24 Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-02-24 11:35:23 UTC --- Over estimating is safe, though potentially sub-optimal. The concern is mainly around under-estimating, which can lead to broken code. Beware, however that if an insn pattern generates more than one assembly language instruction then all the length costs will be associated with one instruction (normally the last). R.
[Bug tree-optimization/52361] gcc.dg/pr48141.c times out with checking enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52361 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-24 11:38:43 UTC --- Author: rguenth Date: Fri Feb 24 11:38:39 2012 New Revision: 184549 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184549 Log: 2012-02-24 Richard Guenther rguent...@suse.de PR middle-end/52361 * passes.c (execute_function_todo): When verifying SSA form verify gimple form first. * tree-ssa.c (verify_ssa): Do not verify gimple form here. Modified: trunk/gcc/ChangeLog trunk/gcc/passes.c trunk/gcc/tree-ssa.c
[Bug tree-optimization/52361] gcc.dg/pr48141.c times out with checking enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52361 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-24 11:45:37 UTC --- Test taking 17s on x86_64 isn't that unreasonable, nothing close to being a compile time hog, if it is slow even when cross-compiling to sparc, I guess it should be investigated why so much more time is spent there.
[Bug middle-end/52355] [4.7 regression] address difference between array elements is not considered to be a compile time constant anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52355 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-24 11:56:07 UTC --- Fixed.
[Bug target/46092] Improve constant handling of thumb2 instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46092 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||ramana at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.7.0 Severity|normal |enhancement --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-02-24 12:24:04 UTC --- Trunk generates this today. Thus fixed. Ramana tv: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. movwr3, #65520 cmpr0, r3 itthi subhir0, r0, #65280 subhir0, r0, #241 bxlr .sizetv, .-tv .identGCC: (GNU) 4.7.0 20120116 (experimental)
[Bug tree-optimization/52361] gcc.dg/pr48141.c times out with checking enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52361 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-24 12:48:00 UTC --- Author: rguenth Date: Fri Feb 24 12:47:56 2012 New Revision: 184552 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184552 Log: 2012-02-24 Richard Guenther rguent...@suse.de PR middle-end/52361 * gimple.c (walk_gimple_op): Use predicates with less redundant tests. (is_gimple_reg_type): Move inline ... * gimple.h (is_gimple_reg_type): ... here. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple.c trunk/gcc/gimple.h
[Bug c++/52371] New: [C++11] ICE in noexcept with constexpr conversion function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52371
Bug #: 52371
Summary: [C++11] ICE in noexcept with constexpr conversion
function
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ai.az...@gmail.com
The following well-formed code causes ICE on GCC 4.7.0 20120218 (experimental).
//
templatetypename T, T v
struct integral_constant
{
typedef T value_type;
static constexpr value_type value = v;
constexpr operator value_type() { return value; }
};
templatetypename T
struct B
{
B()
noexcept(integral_constantbool, noexcept(T())()) // - ICE
: v_()
{}
T v_;
};
int main()
{
Bint b;
}
//
If I use the static constexpr `value' instread of the constexpr conversion
function, the ICE disappears.
[Bug c++/52371] [C++11] ICE in noexcept with constexpr conversion function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52371 --- Comment #1 from Ai Azuma ai.azuma at gmail dot com 2012-02-24 13:54:18 UTC --- Created attachment 26741 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26741 Output of -v option and preprocessed file
[Bug c++/52371] [C++11] ICE in noexcept with constexpr conversion function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52371 --- Comment #2 from Ai Azuma ai.azuma at gmail dot com 2012-02-24 14:01:41 UTC --- I'm sorry. I forgot to write that this ICE appears with -std=c++11 option.
[Bug c++/52369] Const-qualified non-class base member and defaulted default constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52369 fabien at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-02-24 CC||fabien at gcc dot gnu.org AssignedTo|unassigned at gcc dot |fabien at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 Known to fail||4.1.2, 4.2.4, 4.3.6, 4.5.3, ||4.7.0 --- Comment #1 from fabien at gcc dot gnu.org 2012-02-24 14:05:19 UTC --- Confirmed. Can someone please test it on 4.6.0 and 4.6.2 ? Thanks.
[Bug fortran/52370] Spurious may be used uninitialized warning for check of optional argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52370 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-24 14:05:32 UTC --- (In reply to comment #1) The warning is not printed for the last line where one dereferences a pointer (line 8), but for the b.0 = assignment. I have the impression that problem is rather line 8 - i.e. related to the pointer dereference. The warning vanishes if one comments/moves the a = line - unless b is volatile - or if one makes a a VALUE or a function result. I assume that's because it is then simpler to merge the implicitly and the explicitly created if (present(b)) lines.
[Bug c++/52369] Const-qualified non-class base member and defaulted default constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52369 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-24 14:17:17 UTC --- With 4.6.2 and -Wall gives the same as 4.7.0: l.cc:4:13: warning: non-static const member 'const int B::v_' in class without a constructor [-Wuninitialized] l.cc: In function 'int main()': l.cc:13:5: warning: unused variable 'd' [-Wunused-variable] 4.5.2 gives the same (except doesn't print the [-W...] info after the warnings)
[Bug target/49461] boehm-gc and gcj incompatible with pie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49461 --- Comment #13 from pmarlier at gcc dot gnu.org 2012-02-24 15:21:20 UTC --- Author: pmarlier Date: Fri Feb 24 15:21:12 2012 New Revision: 184555 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184555 Log: 2012-02-23 Patrick Marlier patrick.marl...@gmail.com Jack Howarth howa...@bromo.med.uc.edu boehm-gc/ PR boehm-gc/52179 * include/gc_config.h.in: Undefine HAVE_PTHREAD_GET_STACKADDR_NP. * include/private/gcconfig.h (DARWIN): Define STACKBOTTOM with pthread_get_stackaddr_np when available. * configure.ac (THREADS): Check availability of pthread_get_stackaddr_np. * configure: Regenerate. libjava/ PR target/49461 * configure.ac (SYSTEMSPEC): No longer pass -no_pie for darwin11. * configure: Regenerate. Modified: trunk/boehm-gc/ChangeLog trunk/boehm-gc/configure trunk/boehm-gc/configure.ac trunk/boehm-gc/include/gc_config.h.in trunk/boehm-gc/include/private/gcconfig.h trunk/libjava/ChangeLog trunk/libjava/configure trunk/libjava/configure.ac
[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 --- Comment #27 from pmarlier at gcc dot gnu.org 2012-02-24 15:21:20 UTC --- Author: pmarlier Date: Fri Feb 24 15:21:12 2012 New Revision: 184555 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184555 Log: 2012-02-23 Patrick Marlier patrick.marl...@gmail.com Jack Howarth howa...@bromo.med.uc.edu boehm-gc/ PR boehm-gc/52179 * include/gc_config.h.in: Undefine HAVE_PTHREAD_GET_STACKADDR_NP. * include/private/gcconfig.h (DARWIN): Define STACKBOTTOM with pthread_get_stackaddr_np when available. * configure.ac (THREADS): Check availability of pthread_get_stackaddr_np. * configure: Regenerate. libjava/ PR target/49461 * configure.ac (SYSTEMSPEC): No longer pass -no_pie for darwin11. * configure: Regenerate. Modified: trunk/boehm-gc/ChangeLog trunk/boehm-gc/configure trunk/boehm-gc/configure.ac trunk/boehm-gc/include/gc_config.h.in trunk/boehm-gc/include/private/gcconfig.h trunk/libjava/ChangeLog trunk/libjava/configure trunk/libjava/configure.ac
[Bug target/50580] gcc.target/mips/interrupt_handler-[23].c FAIL on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50580 --- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2012-02-24 15:52:09 UTC --- Author: ro Date: Fri Feb 24 15:52:01 2012 New Revision: 184557 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184557 Log: [testsuite] Skip gcc.target/mips/interrupt_handler-[23].c on IRIX (PR target/50580) PR target/50580 * gcc.target/mips/interrupt_handler-2.c: Skip on mips-sgi-irix6*. * gcc.target/mips/interrupt_handler-3.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/mips/interrupt_handler-2.c trunk/gcc/testsuite/gcc.target/mips/interrupt_handler-3.c
[Bug target/50580] gcc.target/mips/interrupt_handler-[23].c FAIL on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50580 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-02/msg01243.htm ||l Last reconfirmed||2012-02-24 Ever Confirmed|0 |1 --- Comment #2 from Rainer Orth ro at gcc dot gnu.org 2012-02-24 15:59:01 UTC --- Analysis in workaround patch.
[Bug target/52261] [avr] Add support for AVR Xmega cores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52261 --- Comment #7 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-02-24 16:26:46 UTC --- Author: gjl Date: Fri Feb 24 16:26:35 2012 New Revision: 184559 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184559 Log: PR target/52261 * config/avr/avr.c (avr_out_movhi_mr_r_xmega): Use base to test for unusedness in st X addressing. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c
[Bug target/52372] New: gcc.target/mips/mips16-attributes{,-4}.c SEGV in dwf_regno
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52372
Bug #: 52372
Summary: gcc.target/mips/mips16-attributes{,-4}.c SEGV in
dwf_regno
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: rsand...@gcc.gnu.org
Host: mips-sgi-irix6.5
Target: mips-sgi-irix6.5
Build: mips-sgi-irix6.5
The mips16-attributes{, -4}.c tests ICE on IRIX 6:
FAIL: gcc.target/mips/mips16-attributes-4.c (internal compiler error)
FAIL: gcc.target/mips/mips16-attributes-4.c (test for excess errors)
FAIL: gcc.target/mips/mips16-attributes.c (internal compiler error)
FAIL: gcc.target/mips/mips16-attributes.c (test for excess errors)
In the first case, I find:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/mips/mips16-attributes-4.c:
In function 'bar':
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/mips/mips16-attributes-4.c:9:1:
internal compiler error: Segmentation fault
The failure boils down to
$ cc1 -fpreprocessed mips16-attributes-4.i -quiet -mabi=o64 -mlong32 -mno-synci
-o mips16-attributes-4.s
In gdb,I see
Program received signal SIGSEGV, Segmentation fault.
0x104b4048 in dwf_regno (reg=0x40280b8) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:912
(gdb) p reg
$1 = (const_rtx) 0x40280b8
(gdb) pr
(pc)
(gdb) where
#0 0x104b4048 in dwf_regno (reg=0x40280b8) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:912
#1 dwarf2out_flush_queued_reg_saves () at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:994
#2 0x104b56d4 in dwarf2out_frame_debug (insn=0x40f05e0) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:2038
#3 scan_insn_after (insn=insn@entry=0x4033048) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:2361
#4 0x104b6b74 in scan_trace (trace=optimized out) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:2505
#5 0x104b7e0c in create_cfi_notes () at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:2549
#6 execute_dwarf2_frame () at /vol/gcc/src/hg/trunk/local/gcc/dwarf2cfi.c:2907
#7 0x104f5bec in execute_one_pass (pass=pass@entry=0x10dc3708) at
/vol/gcc/src/hg/trunk/local/gcc/passes.c:2081
#8 0x104f6088 in execute_pass_list (pass=0x10dc3708) at
/vol/gcc/src/hg/trunk/local/gcc/passes.c:2136
#9 0x104f60a4 in execute_pass_list (pass=0x10dc3970) at
/vol/gcc/src/hg/trunk/local/gcc/passes.c:2137
#10 0x104f60a4 in execute_pass_list (pass=0x10dc39a8) at
/vol/gcc/src/hg/trunk/local/gcc/passes.c:2137
#11 0x1078c50c in tree_rest_of_compilation (fndecl=0x40b9100) at
/vol/gcc/src/hg/trunk/local/gcc/tree-optimize.c:422
#12 0x105d533c in cgraph_expand_function (node=0x40d80a8) at
/vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1837
#13 0x105d7564 in cgraph_output_in_order () at
/vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2002
#14 cgraph_optimize () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2213
#15 0x105d792c in cgraph_finalize_compilation_unit () at
/vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1344
#16 0x10187cf4 in c_write_global_declarations () at
/vol/gcc/src/hg/trunk/local/gcc/c-decl.c:10031
#17 0x10277148 in compile_file () at
/vol/gcc/src/hg/trunk/local/gcc/toplev.c:573
#18 do_compile () at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:1938
#19 toplev_main (argc=9, argv=0x7ffb7f04) at
/vol/gcc/src/hg/trunk/local/gcc/toplev.c:2014
#20 0x101723f0 in __start ()
I didn't easily see how to find the equivalent of REGNO(reg) in dwf_regno.
Rainer
[Bug target/52372] [4.7 regression] gcc.target/mips/mips16-attributes{,-4}.c SEGV in dwf_regno
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52372
Rainer Orth ro at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.7.0
Summary|gcc.target/mips/mips16-attr |[4.7 regression]
|ibutes{,-4}.c SEGV in |gcc.target/mips/mips16-attr
|dwf_regno |ibutes{,-4}.c SEGV in
||dwf_regno
--- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2012-02-24 16:29:38 UTC
---
I just see that this is a regression from the 4.6 branch.
[Bug c++/52373] New: template usage drops some checks on the accessibility of a member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52373
Bug #: 52373
Summary: template usage drops some checks on the accessibility
of a member
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sylves...@debian.org
Considering this code:
class A
{
struct st
{
static void f();
};
};
template typename t void foo()
{
A::st::f();
}
---
g++ accepts it.
If I remove template typename t, an error is triggered (which is the
expected behavior):
plop.cpp: In function ‘void foo()’:
plop.cpp:4:12: error: ‘struct A::st’ is private
plop.cpp:12:5: error: within this context
[Bug rtl-optimization/37272] [4.5 Regression] IRA has caused ppc64-double-1.c to fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37272 --- Comment #7 from Peter Bergner bergner at gcc dot gnu.org 2012-02-24 16:42:37 UTC --- This looks to be fixed, probably by Mike's fp convert changes from a while back. I'm now seeing the following src code being generated: fctidz 1,1 fcfid 1,1 blr Can we close this now?
[Bug c++/52374] New: [C++11] Fails to transform id-expression into dependent base member access in lambda expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52374
Bug #: 52374
Summary: [C++11] Fails to transform id-expression into
dependent base member access in lambda expression
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ai.az...@gmail.com
Created attachment 26742
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26742
Output of -v option and preprocessed file
In the lambda expression's compound statement, id-expressions referring to
non-static members should be transformed into class member access expressions
by prefixing `(*this).'. However, GCC fails the transformation when
id-expressions involved are qualified-ids and refer to dependent base members.
A test case is as follows;
struct B
{
int get() const { return 42; }
};
templatetypename X
struct D
: public X
{
int get() const { return [this]() - int { return X::get(); }(); }
};
int main()
{
DB d;
d.get();
}
For the above mentioned well-formed code, 4.7.0 20120218 (experimental) with
-std=c++11 complains as follows;
main.cpp: In instantiation of 'DX::get() const [with X = B]::lambda()':
main.cpp:10:29: required from 'struct DX::get() const [with X =
B]::lambda()'
main.cpp:10:65: required from 'int DX::get() const [with X = B]'
main.cpp:16:9: required from here
main.cpp:10:60: error: cannot call member function 'int B::get() const' without
object
`X::get' in the lambda expression should be implicitly transformed into
`(*this).X::get', and the test case should compile successfully.
[Bug c++/52373] template usage drops some checks on the accessibility of a member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52373 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-24 16:50:25 UTC --- dup *** This bug has been marked as a duplicate of bug 41437 ***
[Bug c++/41437] No access control for classes in template functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||sylvestre at debian dot org --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-24 16:50:25 UTC --- *** Bug 52373 has been marked as a duplicate of this bug. ***
[Bug c++/52374] [C++11] Fails to transform id-expression into dependent base member access in lambda expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52374 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-24 Ever Confirmed|0 |1
[Bug target/16458] PowerPC - redundant compare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16458 Peter Bergner bergner at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0 --- Comment #7 from Peter Bergner bergner at gcc dot gnu.org 2012-02-24 17:20:18 UTC --- Richi mentioned this isn't suitable for 4.7 stage4, so re-targeting this for 4.8.
[Bug c++/52282] [C++0x] ICE / confused by earlier errors with decltype/constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282 --- Comment #2 from andyg1001 at hotmail dot co.uk 2012-02-24 17:42:59 UTC --- Created attachment 26743 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26743 test-case for decltype ICE / incorrect evaluation of constexpr The attached test-case source expands on my previous bug report and shows where the ICE occurs with decltype but also where the compiler fails to detect that a value is actually constexpr (lines marked incorrect evaluation). What is interesting is that the incorrect evaluation does not occur for comparable use inside main(). GCC version: g++ (GCC) 4.7.0 20120224 (experimental)
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352
--- Comment #10 from Uros Bizjak ubizjak at gmail dot com 2012-02-24 18:32:56
UTC ---
(In reply to comment #9)
It is fixed on hjl/x32/addr32, hjl/x32/gcc-4_6-branch and
hjl/x32/gcc-4_6-branch+mx32 branches.
The problem is
;; Stores and loads of ax to arbitrary constant address.
;; We fake an second form of instruction to force reload to load address
;; into register when rax is not available
(define_insn *movabsmode_1
[(set (mem:SWI1248x (match_operand:DI 0 x86_64_movabs_operand i,r))
(match_operand:SWI1248x 1 nonmemory_operand a,er))]
TARGET_64BIT ix86_check_movabs (insn, 0)
@
movabs{imodesuffix}\t{%1, %P0|%P0, %1}
mov{imodesuffix}\t{%1, %a0|%a0, %1}
DImode is incorrect for x32, especially for register operand.
That is where
movq$-18874360, %rax
movl(%rax), %edx
comes from. It should be in Pmode. However, the immediate operand
must be in DImode for x86_64_movabs_operand.
But this is the _address_ that we are talking, see the MEM RTX. So, following
(untested) patch can help - access is in PTR mode, and a modifier should
handle this without problems.
--cut here--
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 184560)
+++ config/i386/i386.md (working copy)
@@ -2360,7 +2360,7 @@
;; We fake an second form of instruction to force reload to load address
;; into register when rax is not available
(define_insn *movabsmode_1
- [(set (mem:SWI1248x (match_operand:DI 0 x86_64_movabs_operand i,r))
+ [(set (mem:SWI1248x (match_operand:PTR 0 x86_64_movabs_operand i,r))
(match_operand:SWI1248x 1 nonmemory_operand a,er))]
TARGET_64BIT ix86_check_movabs (insn, 0)
@
@@ -2375,7 +2375,7 @@
(define_insn *movabsmode_2
[(set (match_operand:SWI1248x 0 register_operand =a,r)
-(mem:SWI1248x (match_operand:DI 1 x86_64_movabs_operand i,r)))]
+(mem:SWI1248x (match_operand:PTR 1 x86_64_movabs_operand i,r)))]
TARGET_64BIT ix86_check_movabs (insn, 1)
@
movabs{imodesuffix}\t{%P1, %0|%0, %P1}
--cut here--
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352
--- Comment #11 from H.J. Lu hjl.tools at gmail dot com 2012-02-24 19:14:19
UTC ---
(In reply to comment #10)
But this is the _address_ that we are talking, see the MEM RTX. So,
following
(untested) patch can help - access is in PTR mode, and a modifier should
handle this without problems.
--cut here--
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 184560)
+++ config/i386/i386.md (working copy)
@@ -2360,7 +2360,7 @@
;; We fake an second form of instruction to force reload to load address
;; into register when rax is not available
(define_insn *movabsmode_1
- [(set (mem:SWI1248x (match_operand:DI 0 x86_64_movabs_operand i,r))
+ [(set (mem:SWI1248x (match_operand:PTR 0 x86_64_movabs_operand i,r))
(match_operand:SWI1248x 1 nonmemory_operand a,er))]
TARGET_64BIT ix86_check_movabs (insn, 0)
@
@@ -2375,7 +2375,7 @@
(define_insn *movabsmode_2
[(set (match_operand:SWI1248x 0 register_operand =a,r)
-(mem:SWI1248x (match_operand:DI 1 x86_64_movabs_operand i,r)))]
+(mem:SWI1248x (match_operand:PTR 1 x86_64_movabs_operand i,r)))]
TARGET_64BIT ix86_check_movabs (insn, 1)
@
movabs{imodesuffix}\t{%P1, %0|%0, %P1}
--cut here--
I checked a similar fix into hjl/x32/addr32, hjl/x32/gcc-4_6-branch and
hjl/x32/gcc-4_6-branch+mx32 branches. I also added I code to print
constant address as positive 32bit integer for x32:
http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=c6d9aee05cb3bfbe3c2a1b63f3f842e8d3fcb8e0
I used :P instead of :PTR which will be removed when I submit patches
to use SImode for Pmode with x32.
[Bug target/52364] The unnecessary second form in *movabsmode_[12]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52364 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2012-02-24 19:15:08 UTC --- The second form is needed for -ffixed-rax.
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 --- Comment #12 from Uros Bizjak ubizjak at gmail dot com 2012-02-24 19:29:20 UTC --- (In reply to comment #11) I checked a similar fix into hjl/x32/addr32, hjl/x32/gcc-4_6-branch and hjl/x32/gcc-4_6-branch+mx32 branches. I also added I code to print constant address as positive 32bit integer for x32: I think we can simply disable these two patterns on x32. This is with disabled patterns: x32_O3_main: 0: b8 00 00 e0 fe mov$0xfee0,%eax 5: 8b 00 mov(%rax),%eax 7: a8 01 test $0x1,%al 9: 74 01 je c x32_O3_main+0xc b: 90 nop c: b8 00 00 e0 fe mov$0xfee0,%eax 11: 8b 50 08mov0x8(%rax),%edx 14: 89 50 04mov%edx,0x4(%rax) 17: c3 retq and with enabled patterns: x32_O3_main: 0: a1 00 00 e0 fe 00 00movabs 0xfee0,%eax 7: 00 00 9: a8 01 test $0x1,%al b: 74 01 je e x32_O3_main+0xe d: 90 nop e: a1 08 00 e0 fe 00 00movabs 0xfee8,%eax 15: 00 00 17: a3 04 00 e0 fe 00 00movabs %eax,0xfee4 1e: 00 00 20: c3 retq There is simply no need for movabs from/to mem, since there is no 64bit addresses. And code size is horrible (and I bet that the former code runs faster).
[Bug middle-end/52375] New: [4.7 Regression] internal compiler error: in extract_insn, at recog.c:2123 at -O3 -mfpu=neon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52375 Bug #: 52375 Summary: [4.7 Regression] internal compiler error: in extract_insn, at recog.c:2123 at -O3 -mfpu=neon Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: bernhard.rosenkran...@linaro.org Created attachment 26744 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26744 Preprocessed source (not yet reduced) $ /opt/android-toolchain-4.7/bin/arm-linux-androideabi-g++ -march=armv7-a -mfloat-abi=softfp -mfpu=neon -O3 -o Input.o -c Input.i frameworks/base/libs/ui/Input.cpp: In member function 'void android::VelocityTracker::addMovement(const android::MotionEvent*)': frameworks/base/libs/ui/Input.cpp:866:1: error: unrecognizable insn: (insn 71 70 72 9 (set (reg:V4SI 271) (lshiftrt:V4SI (reg:V4SI 272) (subreg:V4SI (reg:OI 250 [ vect_array.1112 ]) 0))) frameworks/base/include/utils/BitSet.h:36 -1 (nil)) frameworks/base/libs/ui/Input.cpp:866:1: internal compiler error: in extract_insn, at recog.c:2123 Reducing the optimization level to -O2 or omitting -mfpu=neon allows the compile to proceed.
[Bug gcov-profile/52376] New: [4.7 regression] ICE in lto_input_tree_ref, at lto-streamer-in.c:266 while linking LTO-PGO libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52376 Bug #: 52376 Summary: [4.7 regression] ICE in lto_input_tree_ref, at lto-streamer-in.c:266 while linking LTO-PGO libxul Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile AssignedTo: unassig...@gcc.gnu.org ReportedBy: mar...@trippelsdorf.de While linking libxul of a LTO-PGO Firefox build, I get this ICE: ... In member function ‘HandleComment’: lto1: internal compiler error: in lto_input_tree_ref, at lto-streamer-in.c:266 Please submit a full bug report, with preprocessed source if appropriate. Delta reduction points to a single input object file: /var/tmp/mozilla-central/moz-build-dir/content/xml/document/src/nsXMLContentSink.o % c++ -fprofile-use -flto -fno-fat-lto-objects -c -o nsXMLContentSink.o -I../../../../dist/stl_wrappers -I../../../../dist/system_wrappers -include /var/tmp/mozilla-central/config/gcc_hidden.h -DMOZ_GLUE_IN_PROGRAM -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES -DSTATIC_EXPORTABLE_JS_API -DOSTYPE=\Linux3.3\ -DOSARCH=Linux -D_IMPL_NS_LAYOUT -I/var/tmp/mozilla-central/content/xml/document/src -I/var/tmp/mozilla-central/content/xml/document/src/../../../xsl/document/src -I/var/tmp/mozilla-central/content/xml/document/src/../../../html/document/src -I/var/tmp/mozilla-central/content/xml/document/src/../../../../layout/style -I/var/tmp/mozilla-central/content/xml/document/src/../../../base/src -I/var/tmp/mozilla-central/content/xml/document/src/../../../xul/content/src -I/var/tmp/mozilla-central/content/xml/document/src/../../../events/src -I/var/tmp/mozilla-central/content/xml/document/src/../../../../dom/base -I/var/tmp/mozilla-central/content/xml/document/src/../../../../caps/include -I/var/tmp/mozilla-central/xpcom/ds -I/var/tmp/mozilla-central/content/xml/document/src -I. -I../../../../dist/include -I../../../../dist/include/nsprpub -I/var/tmp/mozilla-central/moz-build-dir/dist/include/nspr -I/var/tmp/mozilla-central/moz-build-dir/dist/include/nss -fPIC -fno-rtti -pedantic -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -Wno-long-long -march=native -Wno-delete-non-virtual-dtor -fpermissive -fno-exceptions -fno-strict-aliasing -std=gnu++0x -pthread -ffunction-sections -fdata-sections -pipe -DNDEBUG -DTRIMMED -O3 -fomit-frame-pointer -DMOZILLA_CLIENT -include ../../../../mozilla-config.h -MD -MF .deps/nsXMLContentSink.pp /var/tmp/mozilla-central/content/xml/document/src/nsXMLContentSink.cpp % c++ -flto nsXMLContentSink.o In member function ‘HandleComment’: lto1: internal compiler error: in lto_input_tree_ref, at lto-streamer-in.c:266 Please submit a full bug report, The error above only happens with -fprofile-use and -fno-fat-lto-objects. With -fprofile-use -flto I get: ... /var/tmp/mozilla-central/content/xml/document/src/nsXMLContentSink.cpp: In member function ‘nsXMLContentSink::HandleComment(unsigned short const*)’: /var/tmp/mozilla-central/content/xml/document/src/nsXMLContentSink.cpp:1195:54: internal compiler error: in emit_move_insn, at expr.c:3435 But I don't know how to reduce the testcase further, because it depends on nsXMLContentSink.gcda data.
[Bug gcov-profile/52376] [4.7 regression] ICE in lto_input_tree_ref, at lto-streamer-in.c:266 while linking LTO-PGO libxul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52376 --- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-02-24 19:42:43 UTC --- Created attachment 26745 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26745 nsXMLContentSink.o
[Bug middle-end/52201] FAIL: 29_atomics/atomic/operators/51811.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52201
--- Comment #4 from Andrew Macleod amacleod at redhat dot com 2012-02-24
19:47:18 UTC ---
Created attachment 26746
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26746
disable tests if no atomic support present
That test case really shouldn't be running. To make sure we're on the right
track, add the line
// { dg-require-atomic-builtins }
at the top of the test case (patch attached for the 2 you mention)
Presumably it won't execute the test case anymore, thus avoiding the failure...
Can you give it a try?
Are those the only 2 failing? interesting.
[Bug middle-end/52375] [4.7 Regression] internal compiler error: in extract_insn, at recog.c:2123 at -O3 -mfpu=neon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52375 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2012-02-24 19:52:14 UTC --- On arm-linux-gnueabi this ICEs gcc 4.7 and 4.6, but not 4.5 or 4.4.
[Bug target/52352] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52352 --- Comment #13 from H.J. Lu hjl.tools at gmail dot com 2012-02-24 20:03:59 UTC --- (In reply to comment #12) (In reply to comment #11) I checked a similar fix into hjl/x32/addr32, hjl/x32/gcc-4_6-branch and hjl/x32/gcc-4_6-branch+mx32 branches. I also added I code to print constant address as positive 32bit integer for x32: I think we can simply disable these two patterns on x32. This is with disabled patterns: x32_O3_main: 0: b8 00 00 e0 fe mov$0xfee0,%eax 5: 8b 00 mov(%rax),%eax 7: a8 01 test $0x1,%al 9: 74 01 je c x32_O3_main+0xc b: 90 nop c: b8 00 00 e0 fe mov$0xfee0,%eax 11: 8b 50 08mov0x8(%rax),%edx 14: 89 50 04mov%edx,0x4(%rax) 17: c3 retq and with enabled patterns: x32_O3_main: 0: a1 00 00 e0 fe 00 00movabs 0xfee0,%eax 7: 00 00 9: a8 01 test $0x1,%al b: 74 01 je e x32_O3_main+0xe d: 90 nop e: a1 08 00 e0 fe 00 00movabs 0xfee8,%eax 15: 00 00 17: a3 04 00 e0 fe 00 00movabs %eax,0xfee4 1e: 00 00 20: c3 retq There is simply no need for movabs from/to mem, since there is no 64bit addresses. And code size is horrible (and I bet that the former code runs faster). I think it is a good idea.
[Bug libstdc++/50349] /usr/bin/ld: warning: wildcard match appears in both version 'GLIBCXX_3.4' and 'CXXABI_1.3' in script
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50349 Benjamin Kosnik bkoz at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug middle-end/52375] [4.7 Regression] internal compiler error: in extract_insn, at recog.c:2123 at -O3 -mfpu=neon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52375 Bernhard Rosenkränzer Bernhard.Rosenkranzer at linaro dot org changed: What|Removed |Added Attachment #26744|0 |1 is obsolete|| --- Comment #2 from Bernhard Rosenkränzer Bernhard.Rosenkranzer at linaro dot org 2012-02-24 20:35:08 UTC --- Created attachment 26747 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26747 Reduced test case Reduced test case
[Bug middle-end/52375] [4.7 Regression] internal compiler error: in extract_insn, at recog.c:2123 at -O3 -mfpu=neon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52375 Bernhard Rosenkränzer Bernhard.Rosenkranzer at linaro dot org changed: What|Removed |Added Known to fail||4.7.0 --- Comment #3 from Bernhard Rosenkränzer Bernhard.Rosenkranzer at linaro dot org 2012-02-24 20:37:45 UTC --- Works here with the Linaro version of 4.6.3 (didn't try stock 4.6.3 yet), ICEs with stock 4.7 from a couple of days ago
[Bug middle-end/52375] [4.7 Regression] internal compiler error: in extract_insn, at recog.c:2123 at -O3 -mfpu=neon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52375 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-24 Ever Confirmed|0 |1
[Bug c++/52377] New: C++11 non-static initializers in unions are not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52377
Bug #: 52377
Summary: C++11 non-static initializers in unions are not used
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kenwayne...@hotmail.com
Created attachment 26748
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26748
command-line output and preprocessed file
Given the following code
#include cstdio
union Test
{
int a{4};
};
int main()
{
Test t;
printf(%d, t.a);
return 0;
}
the output is all junk data, unless I specify a -O option, in which case it
prints 0. Either way, t.a is not being properly initialized to 4.
[Bug boehm-gc/48299] [4.7 Regression] FAIL: boehm-gc.c/thread_leak_test.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48299 --- Comment #16 from Jack Howarth howarth at nitro dot med.uc.edu 2012-02-25 02:23:06 UTC --- Created attachment 26749 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26749 back port of thread_leak_test.c from ivmai-bdwgc-8b168d0 The random failures in testsuite/boehm-gc.c/thread_leak_test.c on darwin are eliminated if the current structure of tests/thread_leak_test.c in ivmai-bdwgc-8b168d0 is back ported to gcc's boehm-gc. Note that the MS windows specific changes were left out. In particular... #ifdef GC_PTHREADS # include pthread.h #else # include windows.h #endif and #ifdef GC_PTHREADS void * test(void * arg) #else DWORD WINAPI test(LPVOID arg) #endif
[Bug boehm-gc/48299] [4.7 Regression] FAIL: boehm-gc.c/thread_leak_test.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48299 --- Comment #17 from Jack Howarth howarth at nitro dot med.uc.edu 2012-02-25 02:27:14 UTC --- (In reply to comment #16) Note that at r184560 with the back ported thread_leak_test.c changes applied, I am able to run the 64-bit thread_leak_test test repeatedly without failures.
[Bug target/52378] New: Can't build most recent svn version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52378 Bug #: 52378 Summary: Can't build most recent svn version Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: l...@qtrac.plus.com I did the svn read-only checkout for trunk: : svn info Path: . URL: svn://gcc.gnu.org/svn/gcc/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 184569 Node Kind: directory Schedule: normal Last Changed Author: ian Last Changed Rev: 184569 Last Changed Date: 2012-02-25 02:11:29 + (Sat, 25 Feb 2012) This is into /home/mark/opt/gcc-svn-src I then configured with ./configure --prefix=/home/mark/opt/gcc I then did make: ... make[3]: Entering directory `/home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc' gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/gengtype \ build/gengtype.o build/errors.o build/gengtype-lex.o build/gengtype-parse.o build/gengtype-state.o build/version.o ../../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a gcc -g -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/gencheck \ build/gencheck.o ../../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a build/gengtype.o: In function `create_optional_field_': /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype.c:854: undefined reference to `lexer_line' build/gengtype.o: In function `adjust_field_rtx_def': /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype.c:989: undefined reference to `lexer_line' /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype.c:1045: undefined reference to `lexer_line' /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype.c:1055: undefined reference to `lexer_line' /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype.c:1120: undefined reference to `lexer_line' build/gengtype.o:/home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype.c:1159: more undefined references to `lexer_line' follow build/gengtype-parse.o: In function `token': /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:53: undefined reference to `yylex' build/gengtype-parse.o: In function `parse_error': /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:142: undefined reference to `lexer_line' /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:142: undefined reference to `lexer_line' build/gengtype-parse.o: In function `struct_field_seq': /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:692: undefined reference to `lexer_line' build/gengtype-parse.o: In function `type': /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:726: undefined reference to `lexer_line' /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:758: undefined reference to `lexer_line' build/gengtype-parse.o:/home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:758: more undefined references to `lexer_line' follow build/gengtype-parse.o: In function `parse_file': /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:951: undefined reference to `yybegin' /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:986: undefined reference to `lexer_toplevel_done' /home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype-parse.c:991: undefined reference to `yyend' collect2: ld returned 1 exit status make[3]: *** [build/gengtype] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory `/home/mark/opt/gcc-svn-src/host-x86_64-unknown-linux-gnu/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/mark/opt/gcc-svn-src' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/mark/opt/gcc-svn-src' make: *** [all] Error 2 I would be happy to try to build a slightly earlier and more stable version but don't know how. (With mercurial I'd do 'hg update _an_earlier_tag' but don't know the svn equivalent if there is one.)
[Bug target/52378] Can't build most recent svn version, i.e., trunk 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52378 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-02-25 Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-25 07:46:51 UTC --- ./configure I bet this is just a problem with you building in the src directory. This is not always supported and not always 100% working. Can you try building in an object directory? Also do you have flex since that is required while building from subversion (but not from the release tarballs)?
Re: [PATCH] Fix PR52298
On Thu, 23 Feb 2012, Ulrich Weigand wrote:
Richard Guenther wrote:
PR tree-optimization/52298
* tree-vect-stmts.c (vectorizable_store): Properly use
STMT_VINFO_DR_STEP instead of DR_STEP when vectorizing
outer loops.
(vectorizable_load): Likewise.
* tree-vect-data-refs.c (vect_analyze_data_ref_access):
Access DR_STEP after ensuring it is not NULL.
This causes a bunch of regressions on SPU:
FAIL: gcc.dg/vect/vect-outer-fir-big-array.c (internal compiler error)
FAIL: gcc.dg/vect/vect-outer-fir-big-array.c (test for excess errors)
WARNING: gcc.dg/vect/vect-outer-fir-big-array.c compilation failed to produce
executable
FAIL: gcc.dg/vect/vect-outer-fir-big-array.c scan-tree-dump-times vect OUTER
LOOP VECTORIZED 2
FAIL: gcc.dg/vect/vect-outer-fir-lb-big-array.c (internal compiler error)
FAIL: gcc.dg/vect/vect-outer-fir-lb-big-array.c (test for excess errors)
WARNING: gcc.dg/vect/vect-outer-fir-lb-big-array.c compilation failed to
produce executable
FAIL: gcc.dg/vect/vect-outer-fir-lb-big-array.c scan-tree-dump-times vect
OUTER LOOP VECTORIZED 2
FAIL: gcc.dg/vect/vect-outer-fir-lb.c (internal compiler error)
FAIL: gcc.dg/vect/vect-outer-fir-lb.c (test for excess errors)
WARNING: gcc.dg/vect/vect-outer-fir-lb.c compilation failed to produce
executable
FAIL: gcc.dg/vect/vect-outer-fir-lb.c scan-tree-dump-times vect OUTER LOOP
VECTORIZED 2
FAIL: gcc.dg/vect/vect-outer-fir.c (internal compiler error)
FAIL: gcc.dg/vect/vect-outer-fir.c (test for excess errors)
WARNING: gcc.dg/vect/vect-outer-fir.c compilation failed to produce executable
FAIL: gcc.dg/vect/vect-outer-fir.c scan-tree-dump-times vect OUTER LOOP
VECTORIZED 2
all due to ICEs of the same type:
internal compiler error: in vectorizable_load, at tree-vect-stmts.c:4665
The assert in question looks like:
if (nested_in_vect_loop
(TREE_INT_CST_LOW (STMT_VINFO_DR_STEP (stmt_info))
% GET_MODE_SIZE (TYPE_MODE (vectype)) != 0))
{
gcc_assert (alignment_support_scheme != dr_explicit_realign_optimized);
compute_in_loop = true;
}
where your patch changed DR_STEP to STMT_VINFO_DR_STEP (reverting just this
one change makes the ICEs go away).
However, at the place where the decision to use the
dr_explicit_realign_optimized
strategy is made (tree-vect-data-refs.c:vect_supportable_dr_alignment), we
still
have:
if ((nested_in_vect_loop
(TREE_INT_CST_LOW (DR_STEP (dr))
!= GET_MODE_SIZE (TYPE_MODE (vectype
|| !loop_vinfo)
return dr_explicit_realign;
else
return dr_explicit_realign_optimized;
Should this now also use STMT_VINFO_DR_STEP?
Yes, I think so.
Richard.
Bye,
Ulrich
--
Richard Guenther rguent...@suse.de
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
Re: [PATCH 5/5] dump_file whitespace nitpicks
On Thu, Feb 23, 2012 at 7:21 PM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
gcc/ChangeLog:
2012-02-23 Bernhard Reutner-Fischer al...@gcc.gnu.org
* tree-into-ssa (update_ssa): Avoid trailing whitespace in
dump_file.
* tree-ssa-sccvn.c (print_scc): Ditto.
Ok.
Thanks,
Richard.
Signed-off-by: Bernhard Reutner-Fischer rep.dot@gmail.com
---
gcc/tree-into-ssa.c | 4 ++--
gcc/tree-ssa-sccvn.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/tree-into-ssa.c b/gcc/tree-into-ssa.c
index 7eaed2a..6ca52c1 100644
--- a/gcc/tree-into-ssa.c
+++ b/gcc/tree-into-ssa.c
@@ -3519,9 +3519,9 @@ update_ssa (unsigned update_flags)
if (dump_flags TDF_DETAILS)
{
- fprintf (dump_file, Affected blocks: );
+ fprintf (dump_file, Affected blocks:);
EXECUTE_IF_SET_IN_BITMAP (blocks_to_update, 0, i, bi)
- fprintf (dump_file, %u , i);
+ fprintf (dump_file, %u, i);
fprintf (dump_file, \n);
}
diff --git a/gcc/tree-ssa-sccvn.c b/gcc/tree-ssa-sccvn.c
index fdebe47..ddb1ba6 100644
--- a/gcc/tree-ssa-sccvn.c
+++ b/gcc/tree-ssa-sccvn.c
@@ -2462,11 +2462,11 @@ print_scc (FILE *out, VEC (tree, heap) *scc)
tree var;
unsigned int i;
- fprintf (out, SCC consists of: );
+ fprintf (out, SCC consists of:);
FOR_EACH_VEC_ELT (tree, scc, i, var)
{
- print_generic_expr (out, var, 0);
fprintf (out, );
+ print_generic_expr (out, var, 0);
}
fprintf (out, \n);
}
--
1.7.9
Re: [PATCH 4/5] make_phi_node can be static
On Thu, Feb 23, 2012 at 7:21 PM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
gcc/ChangeLog:
2012-02-23 Bernhard Reutner-Fischer al...@gcc.gnu.org
* tree-phinodes.c (make_phi_node): Mark static.
* tree-flow.h (make_phi_node): Remove extern decl.
* doc/gimple.texi (make_phi_node): Remove documentation.
Ok.
Thanks,
Richard.
Signed-off-by: Bernhard Reutner-Fischer rep.dot@gmail.com
---
gcc/doc/gimple.texi | 4
gcc/tree-flow.h | 1 -
gcc/tree-phinodes.c | 2 +-
3 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/gcc/doc/gimple.texi b/gcc/doc/gimple.texi
index b75dc72..fa31eb0 100644
--- a/gcc/doc/gimple.texi
+++ b/gcc/doc/gimple.texi
@@ -1963,10 +1963,6 @@ Set @code{CLAUSES} to be the clauses associated with
@code{OMP_SINGLE} @code{G}.
@subsection @code{GIMPLE_PHI}
@cindex @code{GIMPLE_PHI}
-@deftypefn {GIMPLE function} gimple make_phi_node (tree var, int len)
-Build a @code{PHI} node with len argument slots for variable var.
-@end deftypefn
-
@deftypefn {GIMPLE function} unsigned gimple_phi_capacity (gimple g)
Return the maximum number of arguments supported by @code{GIMPLE_PHI}
@code{G}.
@end deftypefn
diff --git a/gcc/tree-flow.h b/gcc/tree-flow.h
index f4c4d5c..319be2b 100644
--- a/gcc/tree-flow.h
+++ b/gcc/tree-flow.h
@@ -504,7 +504,6 @@ extern void find_referenced_vars_in (gimple);
/* In tree-phinodes.c */
extern void reserve_phi_args_for_new_edge (basic_block);
extern void add_phi_node_to_bb (gimple phi, basic_block bb);
-extern gimple make_phi_node (tree var, int len);
extern gimple create_phi_node (tree, basic_block);
extern void add_phi_arg (gimple, tree, edge, source_location);
extern void remove_phi_args (edge);
diff --git a/gcc/tree-phinodes.c b/gcc/tree-phinodes.c
index 1d7e5c2..218a551 100644
--- a/gcc/tree-phinodes.c
+++ b/gcc/tree-phinodes.c
@@ -204,7 +204,7 @@ ideal_phi_node_len (int len)
/* Return a PHI node with LEN argument slots for variable VAR. */
-gimple
+static gimple
make_phi_node (tree var, int len)
{
gimple phi;
--
1.7.9
Re: [PR51752] publication safety violations in loop invariant motion pass
On Thu, Feb 23, 2012 at 10:11 PM, Aldy Hernandez al...@redhat.com wrote:
On 02/23/12 12:19, Aldy Hernandez wrote:
about hit me. Instead now I save all loads in a function and iterate
through them in a brute force way. I'd like to rewrite this into a hash
of some sort, but before I go any further I'm interested to know if the
main idea is ok.
For the record, it may be ideal to reuse some of the iterations we already
do over the function's basic blocks, so we don't have to iterate yet again
over the IL stream. Though it may complicate the pass unnecessarily.
It's definitely ugly that you need to do this. And yes, you have to look at
very many passes I guess, PRE comes to my mind at least.
I still do not understand the situation very well, at least why for
transaction { for () if (b) load; } load;
it should be safe to hoist load out of the transaction while for
load; transaction { for () if (b) load; }
it is not. Neither do I understand why it's not ok for
transaction { for () if (b) load; }
to hoist the load out of the transaction.
I assume all the issue is about hoisting things over the trasaction start.
So - why does the transaction start not simply clobber all global memory?
That would avoid the hoisting. I assume that transforming the above to
transaction { tem = load; for () if (b) = tem; }
is ok?
Thanks,
Richard.
RE: spill failure after IF-CASE-2 transformation
I think this is a fairly reasonable minimal fix. For 4.8 we could
experiment whether to always do this, regardless of s_r_c_f_m_p.
Ok if bootstrapped and tested on a primary target (i.e. linux) and
tested on Blackfin.
Bernd
Thanks again, Bernd.
Forwarding to gcc-patches to give people a couple of days to object.
Tested on linux and bfin.
Stu
diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
index 8d81c89..e4e13ab 100644
--- a/gcc/ifcvt.c
+++ b/gcc/ifcvt.c
@@ -2295,7 +2295,9 @@ noce_get_condition (rtx jump, rtx *earliest, bool
then_else_reversed)
cond = XEXP (SET_SRC (set), 0);
tmp = XEXP (cond, 0);
- if (REG_P (tmp) GET_MODE_CLASS (GET_MODE (tmp)) == MODE_INT)
+ if (REG_P (tmp) GET_MODE_CLASS (GET_MODE (tmp)) == MODE_INT
+ (GET_MODE (tmp) != BImode
+ || !targetm.small_register_classes_for_mode_p (BImode)))
{
*earliest = jump;
upstream2.patch
Description: upstream2.patch
Re: [PATCH 3/5] tree-if-conv: Commentary typo fix
On Thu, Feb 23, 2012 at 07:21:29PM +0100, Bernhard Reutner-Fischer wrote: gcc/ChangeLog: 2012-02-23 Bernhard Reutner-Fischer al...@gcc.gnu.org * tree-if-conv (predicate_scalar_phi): Commentary typo fix. Applied to trunk as obvious as r184546. Signed-off-by: Bernhard Reutner-Fischer rep.dot@gmail.com --- gcc/tree-if-conv.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/gcc/tree-if-conv.c b/gcc/tree-if-conv.c index cdbbe5b..ca9503f 100644 --- a/gcc/tree-if-conv.c +++ b/gcc/tree-if-conv.c @@ -1262,7 +1262,7 @@ find_phi_replacement_condition (struct loop *loop, arguments. For example, - S1: A = PHI x1(1), x2(5) + S1: A = PHI x1(1), x2(5) is converted into, S2: A = cond ? x1 : x2; -- 1.7.9
Re: [PATCH, i386, Android] Enable __ANDROID__ macro for Android i386 target
On Wed, Feb 22, 2012 at 6:59 AM, Ilya Enkovich enkovich@gmail.com wrote:
Hello,
Here is a one-line fix to enable __ANDROID__ macro on i386 Android
target. OK for trunk?
Thanks,
Ilya
--
2012-02-22 Enkovich Ilya ilya.enkov...@intel.com
* gcc/config/i386/gnu-user.h (TARGET_OS_CPP_BUILTINS): Add
ANDROID_TARGET_OS_CPP_BUILTINS.
diff --git a/gcc/config/i386/gnu-user.h b/gcc/config/i386/gnu-user.h
index 98d0a25..d317229 100644
--- a/gcc/config/i386/gnu-user.h
+++ b/gcc/config/i386/gnu-user.h
@@ -71,6 +71,7 @@ along with GCC; see the file COPYING3. If not see
do \
{ \
GNU_USER_TARGET_OS_CPP_BUILTINS(); \
+ ANDROID_TARGET_OS_CPP_BUILTINS(); \
} \
while (0)
I think this should be done in linux.h, not gnu-user.h.
I fix macro which is defined in gnu-user.h. How do you suppose me to
do it in linux.h?
Ilya
--
H.J.
Re: [PATCH, i386, Android] Enable exceptions and RTTI by default for Android
On Wed, Feb 22, 2012 at 3:57 PM, Ilya Enkovich enkovich@gmail.com wrote:
Hello,
Here is a simple patch which enables exceptions and RTTI by default
for Android target. OK for trunk?
Err - isn't that the default? Thus, simply delete the bogus spec?
Richard.
Hi,
Is following patch OK or it's better to remove whole macro and its usages?
Thanks,
Ilya
--
2012-02-22 Enkovich Ilya ilya.enkov...@intel.com
* gcc/config/linux-android.h (ANDROID_CC1PLUS_SPEC): Enable
exceptions and rtti by default.
diff --git a/gcc/config/linux-android.h b/gcc/config/linux-android.h
index 94c5274..180b62b 100644
--- a/gcc/config/linux-android.h
+++ b/gcc/config/linux-android.h
@@ -45,9 +45,7 @@
%{!mglibc:%{!muclibc:%{!mbionic: -mbionic}}} \
%{!fno-pic:%{!fno-PIC:%{!fpic:%{!fPIC: -fPIC
-#define ANDROID_CC1PLUS_SPEC \
- %{!fexceptions:%{!fno-exceptions: -fno-exceptions}}\
- %{!frtti:%{!fno-rtti: -fno-rtti}}
+#define ANDROID_CC1PLUS_SPEC
#define ANDROID_LIB_SPEC \
%{!static: -ldl}
[PATCH] Fix PR52361 (a bit)
This avoids redundant verify_gimple_in_cfg calls (the original idea
was to always verify gimple when we verify SSA form).
Scheduled for a bootstrap/regtest.
Richard.
2012-02-24 Richard Guenther rguent...@suse.de
PR middle-end/52361
* passes.c (execute_function_todo): When verifying SSA form
verify gimple form first.
* tree-ssa.c (verify_ssa): Do not verify gimple form here.
Index: gcc/passes.c
===
--- gcc/passes.c(revision 184541)
+++ gcc/passes.c(working copy)
@@ -1724,11 +1724,14 @@ execute_function_todo (void *data)
#if defined ENABLE_CHECKING
if (flags TODO_verify_ssa
|| (current_loops loops_state_satisfies_p (LOOP_CLOSED_SSA)))
-verify_ssa (true);
+{
+ verify_gimple_in_cfg (cfun);
+ verify_ssa (true);
+}
+ else if (flags TODO_verify_stmts)
+verify_gimple_in_cfg (cfun);
if (flags TODO_verify_flow)
verify_flow_info ();
- if (flags TODO_verify_stmts)
-verify_gimple_in_cfg (cfun);
if (current_loops loops_state_satisfies_p (LOOP_CLOSED_SSA))
verify_loop_closed_ssa (false);
if (flags TODO_verify_rtl_sharing)
Index: gcc/tree-ssa.c
===
--- gcc/tree-ssa.c (revision 184541)
+++ gcc/tree-ssa.c (working copy)
@@ -925,8 +925,6 @@ verify_ssa (bool check_modified_stmt)
gcc_assert (!need_ssa_update_p (cfun));
- verify_gimple_in_cfg (cfun);
-
timevar_push (TV_TREE_SSA_VERIFY);
/* Keep track of SSA names present in the IL. */
Re: [PATCH, i386, Android] Enable exceptions and RTTI by default for Android
On Fri, Feb 24, 2012 at 11:22 AM, Ilya Enkovich enkovich@gmail.com wrote:
On Wed, Feb 22, 2012 at 3:57 PM, Ilya Enkovich enkovich@gmail.com
wrote:
Hello,
Here is a simple patch which enables exceptions and RTTI by default
for Android target. OK for trunk?
Err - isn't that the default? Thus, simply delete the bogus spec?
Richard.
Hi,
Is following patch OK or it's better to remove whole macro and its usages?
The latter.
Richard.
Thanks,
Ilya
--
2012-02-22 Enkovich Ilya ilya.enkov...@intel.com
* gcc/config/linux-android.h (ANDROID_CC1PLUS_SPEC): Enable
exceptions and rtti by default.
diff --git a/gcc/config/linux-android.h b/gcc/config/linux-android.h
index 94c5274..180b62b 100644
--- a/gcc/config/linux-android.h
+++ b/gcc/config/linux-android.h
@@ -45,9 +45,7 @@
%{!mglibc:%{!muclibc:%{!mbionic: -mbionic}}} \
%{!fno-pic:%{!fno-PIC:%{!fpic:%{!fPIC: -fPIC
-#define ANDROID_CC1PLUS_SPEC \
- %{!fexceptions:%{!fno-exceptions: -fno-exceptions}} \
- %{!frtti:%{!fno-rtti: -fno-rtti}}
+#define ANDROID_CC1PLUS_SPEC
#define ANDROID_LIB_SPEC \
%{!static: -ldl}
[PATCH] Fix PR52355
This fixes PR52355 by extending the existing folding of a[i] - a[j]
to cover multi-dimensional array access and non-equal base.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2012-02-24 Richard Guenther rguent...@suse.de
PR middle-end/52355
* fold-const.c (fold_addr_of_array_ref_difference): New function.
(fold_binary_loc): Use it to extend the existing a[i] - a[j]
folding.
* gcc.dg/pr52355.c: New testcase.
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 184541)
+++ gcc/fold-const.c(working copy)
@@ -9671,6 +9674,44 @@ fold_vec_perm (tree type, tree arg0, tre
}
}
+/* Try to fold a pointer difference of type TYPE two address expressions of
+ array references AREF0 and AREF1 using location LOC. Return a
+ simplified expression for the difference or NULL_TREE. */
+
+static tree
+fold_addr_of_array_ref_difference (location_t loc, tree type,
+ tree aref0, tree aref1)
+{
+ tree base0 = TREE_OPERAND (aref0, 0);
+ tree base1 = TREE_OPERAND (aref1, 0);
+ tree base_offset = build_int_cst (type, 0);
+
+ /* If the bases are array references as well, recurse. If the bases
+ are pointer indirections compute the difference of the pointers.
+ If the bases are equal, we are set. */
+ if ((TREE_CODE (base0) == ARRAY_REF
+TREE_CODE (base1) == ARRAY_REF
+(base_offset
+ = fold_addr_of_array_ref_difference (loc, type, base0, base1)))
+ || (INDIRECT_REF_P (base0)
+ INDIRECT_REF_P (base1)
+ (base_offset = fold_binary_loc (loc, MINUS_EXPR, type,
+TREE_OPERAND (base0, 0),
+TREE_OPERAND (base1, 0
+ || operand_equal_p (base0, base1, 0))
+{
+ tree op0 = fold_convert_loc (loc, type, TREE_OPERAND (aref0, 1));
+ tree op1 = fold_convert_loc (loc, type, TREE_OPERAND (aref1, 1));
+ tree esz = fold_convert_loc (loc, type, array_ref_element_size (aref0));
+ tree diff = build2 (MINUS_EXPR, type, op0, op1);
+ return fold_build2_loc (loc, PLUS_EXPR, type,
+ base_offset,
+ fold_build2_loc (loc, MULT_EXPR, type,
+ diff, esz));
+}
+ return NULL_TREE;
+}
+
/* Fold a binary expression of code CODE and type TYPE with operands
OP0 and OP1. LOC is the location of the resulting expression.
Return the folded expression if folding is successful. Otherwise,
@@ -10582,19 +10623,11 @@ fold_binary_loc (location_t loc,
TREE_CODE (arg1) == ADDR_EXPR
TREE_CODE (TREE_OPERAND (arg1, 0)) == ARRAY_REF)
{
- tree aref0 = TREE_OPERAND (arg0, 0);
- tree aref1 = TREE_OPERAND (arg1, 0);
- if (operand_equal_p (TREE_OPERAND (aref0, 0),
- TREE_OPERAND (aref1, 0), 0))
- {
- tree op0 = fold_convert_loc (loc, type, TREE_OPERAND (aref0, 1));
- tree op1 = fold_convert_loc (loc, type, TREE_OPERAND (aref1, 1));
- tree esz = array_ref_element_size (aref0);
- tree diff = build2 (MINUS_EXPR, type, op0, op1);
- return fold_build2_loc (loc, MULT_EXPR, type, diff,
- fold_convert_loc (loc, type, esz));
-
- }
+ tree tem = fold_addr_of_array_ref_difference (loc, type,
+ TREE_OPERAND (arg0, 0),
+ TREE_OPERAND (arg1, 0));
+ if (tem)
+ return tem;
}
if (FLOAT_TYPE_P (type)
Index: gcc/testsuite/gcc.dg/pr52355.c
===
--- gcc/testsuite/gcc.dg/pr52355.c (revision 0)
+++ gcc/testsuite/gcc.dg/pr52355.c (revision 0)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+
+void f(char a[16][16][16])
+{
+ asm volatile ( : : i (a[1][0][0] - a[0][0][0]));
+}
+
+int main(void)
+{
+ char a[16][16][16];
+ f(a);
+ return 0;
+}
[PATCH] Some more speedups for PR52361
I noticed that checking time is dominated by walk_gimple_op and
walk_tree, not so much by the core worker. walk_gimple_op can
be micro-optimized a bit and the simple predicate is_gimple_reg_type
can be trivially inlined.
Bootstrap testing in progress.
That was what is low-hanging.
Richard.
2012-02-24 Richard Guenther rguent...@suse.de
PR middle-end/52361
* gimple.c (walk_gimple_op): Use predicates with less redundant
tests.
(is_gimple_reg_type): Move inline ...
* gimple.h (is_gimple_reg_type): ... here.
Index: gcc/gimple.c
===
*** gcc/gimple.c(revision 184551)
--- gcc/gimple.c(working copy)
*** walk_gimple_op (gimple stmt, walk_tree_f
*** 1481,1487
tree lhs = gimple_assign_lhs (stmt);
wi-val_only
= (is_gimple_reg_type (TREE_TYPE (lhs)) !is_gimple_reg (lhs))
! || !gimple_assign_single_p (stmt);
}
for (i = 1; i gimple_num_ops (stmt); i++)
--- 1481,1487
tree lhs = gimple_assign_lhs (stmt);
wi-val_only
= (is_gimple_reg_type (TREE_TYPE (lhs)) !is_gimple_reg (lhs))
! || gimple_assign_rhs_class (stmt) != GIMPLE_SINGLE_RHS;
}
for (i = 1; i gimple_num_ops (stmt); i++)
*** walk_gimple_op (gimple stmt, walk_tree_f
*** 1497,1507
if (wi)
{
/* If the RHS has more than 1 operand, it is not appropriate
! for the memory. */
! wi-val_only = !(is_gimple_mem_rhs (gimple_assign_rhs1 (stmt))
! || TREE_CODE (gimple_assign_rhs1 (stmt))
! == CONSTRUCTOR)
! || !gimple_assign_single_p (stmt);
wi-is_lhs = true;
}
--- 1497,1510
if (wi)
{
/* If the RHS has more than 1 operand, it is not appropriate
! for the memory.
!??? A lhs always requires an lvalue, checking the val_only flag
!does not make any sense, so we should be able to avoid computing
!it here. */
! tree rhs1 = gimple_assign_rhs1 (stmt);
! wi-val_only = !(is_gimple_mem_rhs (rhs1)
! || TREE_CODE (rhs1) == CONSTRUCTOR)
! || gimple_assign_rhs_class (stmt) !=
GIMPLE_SINGLE_RHS;
wi-is_lhs = true;
}
*** is_gimple_id (tree t)
*** 2908,2921
|| TREE_CODE (t) == STRING_CST);
}
- /* Return true if TYPE is a suitable type for a scalar register variable. */
-
- bool
- is_gimple_reg_type (tree type)
- {
- return !AGGREGATE_TYPE_P (type);
- }
-
/* Return true if T is a non-aggregate register variable. */
bool
--- 2911,2916
Index: gcc/gimple.h
===
*** gcc/gimple.h(revision 184551)
--- gcc/gimple.h(working copy)
*** tree gimple_extract_devirt_binfo_from_cs
*** 963,970
/* Returns true iff T is a valid GIMPLE statement. */
extern bool is_gimple_stmt (tree);
- /* Returns true iff TYPE is a valid type for a scalar register variable. */
- extern bool is_gimple_reg_type (tree);
/* Returns true iff T is a scalar register variable. */
extern bool is_gimple_reg (tree);
/* Returns true iff T is any sort of variable. */
--- 963,968
*** gimple_expr_type (const_gimple stmt)
*** 4838,4843
--- 4836,4848
return void_type_node;
}
+ /* Return true if TYPE is a suitable type for a scalar register variable. */
+
+ static inline bool
+ is_gimple_reg_type (tree type)
+ {
+ return !AGGREGATE_TYPE_P (type);
+ }
/* Return a new iterator pointing to GIMPLE_SEQ's first statement. */
Re: [PATCH] Adjust 'malloc' attribute documentation to match implementation
On Tue, Feb 21, 2012 at 4:02 PM, Tijl Coosemans t...@coosemans.org wrote:
On Tuesday 21 February 2012 10:19:15 Richard Guenther wrote:
On Mon, Feb 20, 2012 at 8:55 PM, Tijl Coosemans t...@coosemans.org wrote:
On Monday 9 January 2012 10:05:08 Richard Guenther wrote:
Since GCC 4.4 applying the malloc attribute to realloc-like
functions does not work under the documented constraints because
the contents of the memory pointed to are not properly transfered
from the realloc argument (or treated as pointing to anything,
like 4.3 behaved).
The following adjusts documentation to reflect implementation
reality (we do have an implementation detail that treats the
memory blob returned for non-builtins as pointing to any global
variable, but that is neither documented nor do I plan to do
so - I presume it is to allow allocation + initialization
routines to be marked with malloc, but even that area looks
susceptible to misinterpretation to me).
Any comments?
The new text says the memory must be undefined, but gives calloc as an
example for which the memory is defined to be zero. Also, GCC has
built-ins for strdup and strndup with the malloc attribute and GLIBC
further adds it to wcsdup (wchar_t version of strdup) and tempnam. In
all of these cases the memory is defined.
Isn't the reason the attribute doesn't apply to realloc simply because
the returned pointer may alias the one given as argument, rather than
having defined memory content?
The question is really what the alias-analysis code can derive from a
function that is declared with the malloc attribute. The most useful
property for alias analysis would be that te non-aliasing holds
transitively, thus reading (with any level of indirection) from the returned
pointer does not produce memory that is aliased by any other pointer.
That's what happens for 'malloc' (also for 'calloc' - you can't do any
further indirections through the NULL pointers the memory holds). It
does not happen for realloc. Currently the alias-analysis code does
assume exactly this properly (only very slightly weakened, possibly
because we broke some code I guess).
Internally, all builtins with interesting allocation properties are handled
explicitely, so we probably should not rely on the malloc attribute present
on those (and maybe simply drop it there).
The question is really what is useful for users, and what's the most natural
behavior? For example
int **my_initialized_malloc (int *p)
{
int **q = malloc (sizeof (int *));
*q = p;
return q;
}
would not qualify for the 'malloc' attribute (but we've taken measures to not
miscompile this kind of code, it seems to be a very common misconception
to place annotate these with 'malloc').
I'm not sure how to exactly constrain the documentation for 'malloc' better.
Maybe
The @code{malloc} attribute is used to tell the compiler that a function
may be treated as if any non-@code{NULL} pointer it returns cannot
alias any other pointer valid when the function returns and that the memory
does not contain any pointer value.
? Because that is what is relevant. That you can in no way extract
a pointer value from the memory pointed to by the return value. Because
alias analysis will assume any such extracted pointer value points
nowhere (so, extracting a NULL pointer is ok).
The reasoning why the string functions have the malloc attribute was
probably that strings do not contain pointer values. Of course they
can, you can store a character encoding of a pointer, copy the
string and decode it from the copy again. We'd miscompile then
int i = 1;
int *p = i;
char ptr[16];
... inline encode p into ptr ...
char *x = strdup (ptr);
int *q = ... inline decode x to q
*q = 2;
return i;
to return 1 because we do not see that q may point to i. Of course
we properly handle the transfer of pointers for str[n]dup, so the
'malloc' attribute on it is a lie...
Thanks, that was very informative.
Is it correct to say that the attribute applies to deep copies, but not to
shallow ones?
No, see below
How about the following text:
@item malloc
@cindex @code{malloc} attribute
The @code{malloc} attribute is used to tell the compiler that a pointer
returned by a function is either @code{NULL} or points to a newly
allocated object and that any pointer within that object is either
uninitialised, @code{NULL} or pointing to a newly allocated object for
which the same conditions hold recursively.
The '.. or pointing to a newly allocated object for which the same
conditions hold recursively' is not what is implemented. What is
implemented is '.. or pointing to global memory', but I don't really
want to document this as this implementation detail may change
(and what is considered 'global memory' would deserve its own
complicated description).
The compiler assumes that
existing variables and memory cannot be accessed through the returned
pointer which will
Re: [PR51752] publication safety violations in loop invariant motion pass
On Fri, 2012-02-24 at 09:58 +0100, Richard Guenther wrote:
On Thu, Feb 23, 2012 at 10:11 PM, Aldy Hernandez al...@redhat.com wrote:
On 02/23/12 12:19, Aldy Hernandez wrote:
about hit me. Instead now I save all loads in a function and iterate
through them in a brute force way. I'd like to rewrite this into a hash
of some sort, but before I go any further I'm interested to know if the
main idea is ok.
For the record, it may be ideal to reuse some of the iterations we already
do over the function's basic blocks, so we don't have to iterate yet again
over the IL stream. Though it may complicate the pass unnecessarily.
It's definitely ugly that you need to do this.
Indeed. But that's simply the price we have to pay for making
publication with transactions easier for the programmer yet still at
acceptable performance.
Also note that what we primarily have to care about for this PR is to
not hoist loads _within_ transactions if they would violate publication
safety. I didn't have time to look at Aldy's patch yet, but a first
safe and conservative way would be to treat transactions as full
transformation barriers, and prevent publication-safety-violating
transformations _within_ transactions. Which I would prefer until we're
confident that we understood all of it.
For hoisting out of or across transactions, we have to reason about more
than just publication safety.
And yes, you have to look at
very many passes I guess, PRE comes to my mind at least.
I still do not understand the situation very well, at least why for
transaction { for () if (b) load; } load;
it should be safe to hoist load out of the transaction
This one is funny. *Iff* this is an atomic txn, we can assume that the
transaction does not wait for a concurrent event. If it is a relaxed
txn, then we must not have a loop which terminates depending on an
atomic load (which we don't in that example); otherwise, we cannot hoist
load to before the txn (same reason as why we must not hoist to before
an atomic load with memory_order_acquire).
Now, if these things hold, then the load will always be executed after
the txn. Thus, we can assume that it will happen anyway and nothing can
stop it (irrespective of which position the txn gets in the
Transactional Synchronization Order (see the C++ TM spec)). It is a
nonatomic load, and we can rely on the program being data-race-free, so
we cannot have other threads storing to the same location, so we can
hoist it across because in that part of the program, the location is
guaranteed to be thread-local data (or immutable).
As I said, this isn't related to just pub safety anymore. And this is
tricky enough that I'd rather not try to optimize this currently but
instead wait until we have more confidence in our understanding of the
matter.
while for
load; transaction { for () if (b) load; }
it is not.
If the same assumptions as above hold, I think you can hoist it out,
because again you can assume that it targets thread-local/immutable
data: the nontransactional (+nonatomic!) load can happen at any time,
essentially, irrespective of b's value or how/when other threads modify
it. Thus, it cannot have been changed between the two loads in a
data-race-free program.
Neither do I understand why it's not ok for
transaction { for () if (b) load; }
to hoist the load out of the transaction.
You would violate publication safety.
Also, you don't have any reason to believe that load targets
thread-local/immutable data, so you must not make it nontransactional
(otherwise, you could introduce a race condition).
I assume all the issue is about hoisting things over the trasaction start.
So - why does the transaction start not simply clobber all global memory?
That would avoid the hoisting. I assume that transforming the above to
transaction { tem = load; for () if (b) = tem; }
is ok?
No, it is not. Actually, this is precisely the transformation that we
need to prevent from happening.
As Aldy said, please see the explanations in the PR, or have a look at
the C++ TM specification and the C++11 memory model alternatively. We
could also discuss this on IRC, if this would be easier.
Torvald
Re: [PATCH] Fix PR52298
Richard Guenther wrote:
On Thu, 23 Feb 2012, Ulrich Weigand wrote:
The assert in question looks like:
if (nested_in_vect_loop
(TREE_INT_CST_LOW (STMT_VINFO_DR_STEP (stmt_info))
% GET_MODE_SIZE (TYPE_MODE (vectype)) != 0))
{
gcc_assert (alignment_support_scheme !=
dr_explicit_realign_optimized);
compute_in_loop = true;
}
where your patch changed DR_STEP to STMT_VINFO_DR_STEP (reverting just this
one change makes the ICEs go away).
However, at the place where the decision to use the
dr_explicit_realign_optimized
strategy is made (tree-vect-data-refs.c:vect_supportable_dr_alignment), we
still
have:
if ((nested_in_vect_loop
(TREE_INT_CST_LOW (DR_STEP (dr))
!= GET_MODE_SIZE (TYPE_MODE (vectype
|| !loop_vinfo)
return dr_explicit_realign;
else
return dr_explicit_realign_optimized;
Should this now also use STMT_VINFO_DR_STEP?
Yes, I think so.
Hmmm. Reading the comment in vect_supportable_dr_alignment:
However, in the case of outer-loop vectorization, when vectorizing a
memory access in the inner-loop nested within the LOOP that is now being
vectorized, while it is guaranteed that the misalignment of the
vectorized memory access will remain the same in different outer-loop
iterations, it is *not* guaranteed that is will remain the same throughout
the execution of the inner-loop. This is because the inner-loop advances
with the original scalar step (and not in steps of VS). If the inner-loop
step happens to be a multiple of VS, then the misalignment remains fixed
and we can use the optimized realignment scheme.
it would appear that in this case, checking the inner-loop step is deliberate.
Given the comment in vectorizable_load:
/* If the misalignment remains the same throughout the execution of the
loop, we can create the init_addr and permutation mask at the loop
preheader. Otherwise, it needs to be created inside the loop.
This can only occur when vectorizing memory accesses in the inner-loop
nested within an outer-loop that is being vectorized. */
this looks to me that, since the check is intended to verify that
misalignment remains the same throughout the execuction of the loop,
we actually want to check the inner-loop step here as well, i.e. revert
this chunk of your patch ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Re: [PATCH, i386, Android] -mandroid support for i386 target
On Wed, Feb 22, 2012 at 6:54 AM, Ilya Enkovich enkovich@gmail.com wrote:
Hello,
This patch adds -mandroid support to i386 target. OK for trunk?
Thanks,
Ilya
--
2012-02-22 Enkovich Ilya ilya.enkov...@intel.com
* config/i386/gnu-user.h (LINUX_TARGET_CC1_SPEC): New.
I don't think you should define LINUX_* in gnu-user.h.
(CC1_SPEC): Use LINUX_OR_ANDROID_CC.
(CC1PLUS_SPEC): Likewise.
(LINUX_TARGET_LINK_SPEC): New.
(LINK_SPEC): Support LINUX_OR_ANDROID_LD.
(LIB_SPEC): New.
(STARTFILE_SPEC): New.
(LINUX_TARGET_ENDFILE_SPEC): New.
(ENDFILE_SPEC): Support LINUX_OR_ANDROID_LD.
There is a feedback at
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01283.html
to my earlier patch to define GNU_USER_TARGET_* in gnu-user.h
and use them in linux.h.
Thanks for the link. I fixed patch according to this feedback.
* config/linux-android.h (ANDROID_STARTFILE_SPEC): Use
crtbegin_so%O%s for -shared.
(ANDROID_ENDFILE_SPEC): Use crtend_so%O%s for -shared.
I think you should separate this part similar to
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01109.html
I removed this part from the patch.
--
H.J.
Here is a new patch version. Does it look better?
Thanks,
Ilya
--
2012-02-24 Enkovich Ilya ilya.enkov...@intel.com
* gcc/config/i386/gnu-user.h (CC1_SPEC): Rename to ...
(GNU_USER_TARGET_CC1_SPEC): ... this.
(LINK_SPEC): Rename to ...
(GNU_USER_TARGET_LINK_SPEC): ... this.
(ENDFILE_SPEC): Delete.
(GNU_USER_TARGET_MATHFILE_SPEC): New.
* gcc/config/i386/linux.h (CC1_SPEC): New.
(LINK_SPEC): New.
(LIB_SPEC): New.
(STARTFILE_SPEC): New.
(ENDFILE_SPEC): New.
diff --git a/gcc/config/i386/gnu-user.h b/gcc/config/i386/gnu-user.h
index 98d0a25..59d7062 100644
--- a/gcc/config/i386/gnu-user.h
+++ b/gcc/config/i386/gnu-user.h
@@ -77,8 +77,8 @@ along with GCC; see the file COPYING3. If not see
#undef CPP_SPEC
#define CPP_SPEC %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}
-#undef CC1_SPEC
-#define CC1_SPEC %(cc1_cpu) %{profile:-p}
+#undef GNU_USER_TARGET_CC1_SPEC
+#define GNU_USER_TARGET_CC1_SPEC %(cc1_cpu) %{profile:-p}
/* Provide a LINK_SPEC appropriate for GNU userspace. Here we provide support
for the special GCC options -static and -shared, which allow us to
@@ -97,8 +97,8 @@ along with GCC; see the file COPYING3. If not see
{ link_emulation, GNU_USER_LINK_EMULATION },\
{ dynamic_linker, GNU_USER_DYNAMIC_LINKER }
-#undef LINK_SPEC
-#define LINK_SPEC -m %(link_emulation) %{shared:-shared} \
+#define GNU_USER_TARGET_LINK_SPEC \
+ -m %(link_emulation) %{shared:-shared} \
%{!shared: \
%{!static: \
%{rdynamic:-export-dynamic} \
@@ -106,13 +106,11 @@ along with GCC; see the file COPYING3. If not see
%{static:-static}}
/* Similar to standard GNU userspace, but adding -ffast-math support. */
-#undef ENDFILE_SPEC
-#define ENDFILE_SPEC \
+#define GNU_USER_TARGET_MATHFILE_SPEC \
%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \
%{mpc32:crtprec32.o%s} \
%{mpc64:crtprec64.o%s} \
- %{mpc80:crtprec80.o%s} \
- %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s
+ %{mpc80:crtprec80.o%s}
/* A C statement (sans semicolon) to output to the stdio stream
FILE the assembler definition of uninitialized global DECL named
diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h
index 73681fe..a832ddc 100644
--- a/gcc/config/i386/linux.h
+++ b/gcc/config/i386/linux.h
@@ -22,3 +22,30 @@ along with GCC; see the file COPYING3. If not see
#define GNU_USER_LINK_EMULATION elf_i386
#define GLIBC_DYNAMIC_LINKER /lib/ld-linux.so.2
+
+#undef CC1_SPEC
+#define CC1_SPEC \
+ LINUX_OR_ANDROID_CC (GNU_USER_TARGET_CC1_SPEC, \
+ GNU_USER_TARGET_CC1_SPEC ANDROID_CC1_SPEC)
+
+#undef LINK_SPEC
+#define LINK_SPEC \
+ LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LINK_SPEC, \
+ GNU_USER_TARGET_LINK_SPEC ANDROID_LINK_SPEC)
+
+#undef LIB_SPEC
+#define LIB_SPEC \
+ LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LIB_SPEC, \
+ GNU_USER_TARGET_LIB_SPEC ANDROID_LIB_SPEC)
+
+#undef STARTFILE_SPEC
+#define STARTFILE_SPEC \
+ LINUX_OR_ANDROID_LD (GNU_USER_TARGET_STARTFILE_SPEC, \
+ ANDROID_STARTFILE_SPEC)
+
+#undef ENDFILE_SPEC
+#define ENDFILE_SPEC \
+ LINUX_OR_ANDROID_LD (GNU_USER_TARGET_MATHFILE_SPEC \
+ GNU_USER_TARGET_ENDFILE_SPEC, \
+ GNU_USER_TARGET_MATHFILE_SPEC \
+ ANDROID_ENDFILE_SPEC)
Re: [PATCH, i386, Android] Enable __ANDROID__ macro for Android i386 target
On Fri, Feb 24, 2012 at 1:51 AM, Ilya Enkovich enkovich@gmail.com wrote:
On Wed, Feb 22, 2012 at 6:59 AM, Ilya Enkovich enkovich@gmail.com
wrote:
Hello,
Here is a one-line fix to enable __ANDROID__ macro on i386 Android
target. OK for trunk?
Thanks,
Ilya
--
2012-02-22 Enkovich Ilya ilya.enkov...@intel.com
* gcc/config/i386/gnu-user.h (TARGET_OS_CPP_BUILTINS): Add
ANDROID_TARGET_OS_CPP_BUILTINS.
diff --git a/gcc/config/i386/gnu-user.h b/gcc/config/i386/gnu-user.h
index 98d0a25..d317229 100644
--- a/gcc/config/i386/gnu-user.h
+++ b/gcc/config/i386/gnu-user.h
@@ -71,6 +71,7 @@ along with GCC; see the file COPYING3. If not see
do \
{ \
GNU_USER_TARGET_OS_CPP_BUILTINS(); \
+ ANDROID_TARGET_OS_CPP_BUILTINS(); \
} \
while (0)
I think this should be done in linux.h, not gnu-user.h.
I fix macro which is defined in gnu-user.h. How do you suppose me to
do it in linux.h?
Undef TARGET_OS_CPP_BUILTINS and define TARGET_OS_CPP_BUILTINS
in linux.h with GNU_USER_TARGET_OS_CPP_BUILTINS and
ANDROID_TARGET_OS_CPP_BUILTINS.
--
H.J.
Re: [PATCH, i386, Android] -mandroid support for i386 target
On Fri, Feb 24, 2012 at 7:17 AM, Ilya Enkovich enkovich@gmail.com wrote: On Wed, Feb 22, 2012 at 6:54 AM, Ilya Enkovich enkovich@gmail.com wrote: Hello, This patch adds -mandroid support to i386 target. OK for trunk? Thanks, Ilya -- 2012-02-22 Enkovich Ilya ilya.enkov...@intel.com * config/i386/gnu-user.h (LINUX_TARGET_CC1_SPEC): New. I don't think you should define LINUX_* in gnu-user.h. (CC1_SPEC): Use LINUX_OR_ANDROID_CC. (CC1PLUS_SPEC): Likewise. (LINUX_TARGET_LINK_SPEC): New. (LINK_SPEC): Support LINUX_OR_ANDROID_LD. (LIB_SPEC): New. (STARTFILE_SPEC): New. (LINUX_TARGET_ENDFILE_SPEC): New. (ENDFILE_SPEC): Support LINUX_OR_ANDROID_LD. There is a feedback at http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01283.html to my earlier patch to define GNU_USER_TARGET_* in gnu-user.h and use them in linux.h. Thanks for the link. I fixed patch according to this feedback. * config/linux-android.h (ANDROID_STARTFILE_SPEC): Use crtbegin_so%O%s for -shared. (ANDROID_ENDFILE_SPEC): Use crtend_so%O%s for -shared. I think you should separate this part similar to http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01109.html I removed this part from the patch. -- H.J. Here is a new patch version. Does it look better? Thanks, Ilya -- 2012-02-24 Enkovich Ilya ilya.enkov...@intel.com * gcc/config/i386/gnu-user.h (CC1_SPEC): Rename to ... (GNU_USER_TARGET_CC1_SPEC): ... this. (LINK_SPEC): Rename to ... (GNU_USER_TARGET_LINK_SPEC): ... this. (ENDFILE_SPEC): Delete. (GNU_USER_TARGET_MATHFILE_SPEC): New. You should keep those *_SPEC and define them with new GNU_*_SPEC in gnu-user.h since gnu-user.h is also used by other non-linux targets. In linux.h, you undef *_SPEC before defining them. -- H.J.
[testsuite] Skip gcc.target/mips/interrupt_handler-[23].c on IRIX (PR target/50580)
Looking closer into the gcc.target/mips/interrupt_handler-[23].c
failures
FAIL: gcc.target/mips/interrupt_handler-2.c scan-assembler \\t.cfi_restore
64\\n
FAIL: gcc.target/mips/interrupt_handler-2.c scan-assembler \\t.cfi_restore
65\\n
and many more for interrupt_handler-3.c, I now understand what's going
on: .cfi* directives are only emitted if dwarf2cfi.c
(dwarf2out_do_cfi_asm) returns true, but if MIPS_DEBUGGING_INFO is
defined (as is the case in iris6.h), it returns false. Thus, the tests
are meaningless since even the scan-assembler-not tests only succeed
because no .cfi* directives whatsoever are present in the assembler
output. XFAILing them with dg-xfail-if doesn't work:
XPASS: gcc.target/mips/interrupt_handler-2.c (test for excess errors)
FAIL: gcc.target/mips/interrupt_handler-2.c scan-assembler \t\\.cfi_restore 64\n
FAIL: gcc.target/mips/interrupt_handler-2.c scan-assembler \t\\.cfi_restore 65\n
and adding xfail's to each and every dg-final seems pointless,
especially given that the scan-assembler-not tests only pass by
accident. I therefore just skip the tests on IRIX.
Tested with the appropriate runtest invocation on mips-sgi-irix6.5,
installed on mainline.
Rainer
2012-02-24 Rainer Orth r...@cebitec.uni-bielefeld.de
PR target/50580
* gcc.target/mips/interrupt_handler-2.c: Skip on mips-sgi-irix6*.
* gcc.target/mips/interrupt_handler-3.c: Likewise.
# HG changeset patch
# Parent 5002952adc32431a8c1084a301aa929640d70870
[testsuite] Skip gcc.target/mips/interrupt_handler-[23].c on IRIX (PR target/50580)
diff --git a/gcc/testsuite/gcc.target/mips/interrupt_handler-2.c b/gcc/testsuite/gcc.target/mips/interrupt_handler-2.c
--- a/gcc/testsuite/gcc.target/mips/interrupt_handler-2.c
+++ b/gcc/testsuite/gcc.target/mips/interrupt_handler-2.c
@@ -4,6 +4,7 @@
/* { dg-final { scan-assembler \t\\\.cfi_restore 65\n } } */
/* { dg-final { scan-assembler-not \\\.cfi_def_cfa( |\t) } } */
/* { dg-final { scan-assembler-not \\\.cfi_def_cfa_register( |\t) } } */
+/* { dg-skip-if PR target/50580 { mips-sgi-irix6* } } */
extern void f (void);
diff --git a/gcc/testsuite/gcc.target/mips/interrupt_handler-3.c b/gcc/testsuite/gcc.target/mips/interrupt_handler-3.c
--- a/gcc/testsuite/gcc.target/mips/interrupt_handler-3.c
+++ b/gcc/testsuite/gcc.target/mips/interrupt_handler-3.c
@@ -23,6 +23,7 @@
/* { dg-final { scan-assembler \t\\\.cfi_def_cfa_offset 0\n } } */
/* { dg-final { scan-assembler-not \\\.cfi_def_cfa( |\t) } } */
/* { dg-final { scan-assembler-not \\\.cfi_def_cfa_register( |\t) } } */
+/* { dg-skip-if PR target/50580 { mips-sgi-irix6* } } */
extern void f (void);
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: PATCH: PR target/52364: The unnecessary second form in *movabsmode_[12]
On Fri, Feb 24, 2012 at 5:58 AM, H.J. Lu hongjiu...@intel.com wrote:
The second form is redundant in
;; Stores and loads of ax to arbitrary constant address.
;; We fake an second form of instruction to force reload to load address
;; into register when rax is not available
(define_insn *movabsmode_1
[(set (mem:SWI1248x (match_operand:DI 0 x86_64_movabs_operand i,r))
(match_operand:SWI1248x 1 nonmemory_operand a,er))]
TARGET_64BIT ix86_check_movabs (insn, 0)
@
movabs{imodesuffix}\t{%1, %P0|%P0, %1}
mov{imodesuffix}\t{%1, %a0|%a0, %1}
[(set_attr type imov)
(set_attr modrm 0,*)
(set_attr length_address 8,0)
(set_attr length_immediate 0,*)
(set_attr memory store)
(set_attr mode MODE)])
since it is just normal movmode. Tested on Linux/x86-64. OK for stage1?
I am a bit scarred by ... well ... scary comment that mentions reload.
This second form predates IRA - are we sure that IRA is clever enough
not to break due to this change?
Jan, Vladimir, do you have any comments?
Uros.
Re: [patch] Fix cygwin ada install [was Re: Yet another issue with gcc current trunk with ada on cygwin]
On 22/02/2012 16:25, Pascal Obry wrote: Dave, Pascal, ping? Sorry for the delay, these message has fallen into the crack! No problem, I had plenty to be getting on with in the meantime :) Anyway, with these explanations I'm ok with the patch. Thanks. Committed revision 184558. cheers, DaveK
Re: [patch i386]: Add support of delegitimize of UNSPEC_PCREL plus displacement
On 02/23/12 09:12, Kai Tietz wrote: 2012-02-23 Kai Tietz kti...@redhat.com * config/i386/i386.c (ix86_delegitimize_address): Handle UNSPEC_PCREL plus displacement. Ok. r~
[PATCH] genattrtab: avoid NULL-deref on error
This fixes a coverity-spotted issue. A NULL et could be dereferenced after the diagnostic is issued. 2012-02-24 Jim Meyering meyer...@redhat.com genattrtab: avoid NULL-deref on error * genattrtab.c (gen_attr): Avoid NULL-deref after diagnosing absence of an defin_enum call. diff --git a/gcc/genattrtab.c b/gcc/genattrtab.c index 4a4c2a2..bfbe3e8 100644 --- a/gcc/genattrtab.c +++ b/gcc/genattrtab.c @@ -1,6 +1,6 @@ /* Generate code from machine description to compute values of attributes. Copyright (C) 1991, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, - 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 + 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2012 Free Software Foundation, Inc. Contributed by Richard Kenner (ken...@vlsi1.ultra.nyu.edu) @@ -2993,8 +2993,9 @@ gen_attr (rtx exp, int lineno) if (!et || !et-md_p) error_with_line (lineno, No define_enum called `%s' defined, attr-name); - for (ev = et-values; ev; ev = ev-next) - add_attr_value (attr, ev-name); + if (et) + for (ev = et-values; ev; ev = ev-next) + add_attr_value (attr, ev-name); } else if (*XSTR (exp, 1) == '\0') attr-is_numeric = 1; -- 1.7.9.2.263.g9be8b7
Re: [PR51752] publication safety violations in loop invariant motion pass
On 02/24/12 07:10, Torvald Riegel wrote: On Fri, 2012-02-24 at 09:58 +0100, Richard Guenther wrote: On Thu, Feb 23, 2012 at 10:11 PM, Aldy Hernandezal...@redhat.com wrote: On 02/23/12 12:19, Aldy Hernandez wrote: about hit me. Instead now I save all loads in a function and iterate through them in a brute force way. I'd like to rewrite this into a hash of some sort, but before I go any further I'm interested to know if the main idea is ok. For the record, it may be ideal to reuse some of the iterations we already do over the function's basic blocks, so we don't have to iterate yet again over the IL stream. Though it may complicate the pass unnecessarily. It's definitely ugly that you need to do this. Indeed. But that's simply the price we have to pay for making publication with transactions easier for the programmer yet still at acceptable performance. Also note that what we primarily have to care about for this PR is to not hoist loads _within_ transactions if they would violate publication For that matter, didn't rth add a memory barrier at the beginning of transactions last week? That would mean that we can't hoist anything outside of a transaction anyhow. Or was it not a full memory barrier? safety. I didn't have time to look at Aldy's patch yet, but a first safe and conservative way would be to treat transactions as full transformation barriers, and prevent publication-safety-violating transformations _within_ transactions. Which I would prefer until we're confident that we understood all of it. Do you mean disallow hoisting of *any* loads that happen inside of a transaction (regardless of whether a subsequent load happens on every path out of the loop)? This would definitely be safe and quite easily doable, simply by checking if loads to be hoisted are within a transaction. For hoisting out of or across transactions, we have to reason about more than just publication safety. Again, __transactions being barriers and all, I don't think we should complicate things unnecessarily at this point, since it doesn't happen. Aldy
Re: PATCH: PR target/52364: The unnecessary second form in *movabsmode_[12]
On Fri, Feb 24, 2012 at 8:11 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Fri, Feb 24, 2012 at 5:58 AM, H.J. Lu hongjiu...@intel.com wrote:
The second form is redundant in
;; Stores and loads of ax to arbitrary constant address.
;; We fake an second form of instruction to force reload to load address
;; into register when rax is not available
(define_insn *movabsmode_1
[(set (mem:SWI1248x (match_operand:DI 0 x86_64_movabs_operand i,r))
(match_operand:SWI1248x 1 nonmemory_operand a,er))]
TARGET_64BIT ix86_check_movabs (insn, 0)
@
movabs{imodesuffix}\t{%1, %P0|%P0, %1}
mov{imodesuffix}\t{%1, %a0|%a0, %1}
[(set_attr type imov)
(set_attr modrm 0,*)
(set_attr length_address 8,0)
(set_attr length_immediate 0,*)
(set_attr memory store)
(set_attr mode MODE)])
since it is just normal movmode. Tested on Linux/x86-64. OK for stage1?
I am a bit scarred by ... well ... scary comment that mentions reload.
This second form predates IRA - are we sure that IRA is clever enough
not to break due to this change?
I am afraid reload can't deal with it. I withdrew this patch.
--
H.J.
[lra] patch for S390 bootstrap.
The following patch fixes some bugs preventing S390x bootstrap. The
patch is still not fixing the S390 bootstrap yet but I am working on it.
The patch was successfully bootstrapped on x86/x86-64.
Committed as rev. 184561.
2012-02-24 Vladimir Makarov vmaka...@redhat.com
* lra-assigns.c (improve_inheritance): Add an argument. Set it
up. Don't change allocation of a reload pseudo.
(assign_by_spills): Pass parameter to improve_inheritance.
* lra-constraints.c (extract_loc_address_regs): Process memory as
a register.
(process_addr_reg): Reload memory.
(process_alt_operands): Use get_op_mode instead of GET_MODE.
(process_address): Use find_reg_note instead of find_regno_note.
Index: lra-assigns.c
===
--- lra-assigns.c (revision 184177)
+++ lra-assigns.c (working copy)
@@ -935,10 +935,10 @@ setup_live_pseudos_and_spill_after_risky
pseudos to the connected pseudos. We need this because inheritance
pseudos are allocated after reload pseudos in the thread and when
we assign a hard register to a reload pseudo we don't know yet that
- the connected inheritance pseudos can get the same hard
- register. */
+ the connected inheritance pseudos can get the same hard register.
+ Add pseudos with changed allocation to bitmap CHANGED_PSEUDOS. */
static void
-improve_inheritance (void)
+improve_inheritance (bitmap changed_pseudos)
{
unsigned int k;
int regno, another_regno, hard_regno, another_hard_regno, cost, i, n;
@@ -983,6 +983,7 @@ improve_inheritance (void)
assign_hard_regno (hard_regno, another_regno);
else
assign_hard_regno (another_hard_regno, another_regno);
+ bitmap_set_bit (changed_pseudos, another_regno);
}
}
}
@@ -1104,7 +1105,7 @@ assign_by_spills (void)
}
n = nfails;
}
- improve_inheritance ();
+ improve_inheritance (changed_pseudo_bitmap);
bitmap_clear (changed_insns);
/* We can not assign to inherited pseudos if any its inheritance
pseudo did not get hard register because undo inheritance pass
Index: lra-constraints.c
===
--- lra-constraints.c (revision 184524)
+++ lra-constraints.c (working copy)
@@ -295,7 +295,9 @@ get_reload_reg (enum op_type type, enum
/* The page contains code to extract memory address parts. */
-/* Info about base and index regs of an address. */
+/* Info about base and index regs of an address. In some rare cases,
+ base/index register can be actually memory. In this case we will
+ reload it. */
struct address
{
rtx *base_reg_loc; /* NULL if there is no a base register. */
@@ -519,6 +521,13 @@ extract_loc_address_regs (bool top_p, en
SCRATCH, true, ad);
break;
+ /* We process memory as a register. That means we flatten
+ addresses. In other words, the final code will never
+ contains memory in an address even if the target supports
+ such addresses (it is too rare these days). Memory also can
+ occur in address as a result some previous transformations
+ like equivalence substitution. */
+case MEM:
case REG:
if (context_p)
ad-index_reg_loc = loc;
@@ -1228,6 +1237,26 @@ process_addr_reg (rtx *loc, rtx *before,
enum machine_mode mode;
bool change_p = false;
+ mode = GET_MODE (reg);
+ if (MEM_P (reg))
+{
+ /* Always reload memory in an address even if the target
+ supports such addresses. */
+ new_reg = lra_create_new_reg_with_unique_value (mode, reg, cl, address);
+ push_to_sequence (*before);
+ lra_emit_move (new_reg, reg);
+ *before = get_insns ();
+ end_sequence ();
+ *loc = new_reg;
+ if (after != NULL)
+ {
+ push_to_sequence (*after);
+ lra_emit_move (reg, new_reg);
+ *after = get_insns ();
+ end_sequence ();
+ }
+ return true;
+}
gcc_assert (REG_P (reg));
final_regno = regno = REGNO (reg);
if (regno FIRST_PSEUDO_REGISTER)
@@ -1257,7 +1286,6 @@ process_addr_reg (rtx *loc, rtx *before,
}
if (*loc != reg || ! in_class_p (final_regno, cl, new_class))
{
- mode = GET_MODE (reg);
reg = *loc;
if (get_reload_reg (OP_IN, mode, reg, cl, address, new_reg))
{
@@ -1564,7 +1592,7 @@ process_alt_operands (int only_alternati
}
op = no_subreg_operand[nop];
- mode = GET_MODE (*curr_id-operand_loc[nop]);
+ mode = get_op_mode (nop);
win = did_match = winreg = offmemok = constmemok = false;
badop = true;
@@ -2474,8 +2502,8 @@ process_address (int nop, rtx *before, r
{
if (process_addr_reg (ad.base_reg_loc, before,
(ad.base_modify_p
- find_regno_note (curr_insn, REG_DEAD,
- REGNO (*ad.base_reg_loc)) == NULL
+ find_reg_note (curr_insn, REG_DEAD,
+ *ad.base_reg_loc) == NULL
? after : NULL),
base_reg_class (mode, as,
[PATCH] simulate-thread tweaks and fixes
I've been toying with the simulate-thread framework a bit. With the
timeout threshold is back to where it originally was, the spectre of
huge log files when an infinite loop happens is back.
This patch has the following modifications:
1) An instruction count threshold has been added.
This will truly prevent infinite loops which were the original
issue. If the count reaches the threshold value, the test case fails.
I've set the current limit to 10,000, which I would expect to be
sufficient. The highest Ive seen so far is 877, but I'm sure someone
will find something higher :-). A testcase can override this value if
it wishes. If we encounter targets where this is not high enough, we
can raise it further. The main point is to avoid generating 10's of
gigabytes of log files when a fast machine hits an infinite loop and the
time based timeout doesnt kick in quickly enough.
If a test does fail for this reason, the log file will issue a FAIL
message indicating the instruction count threshold was exceeded.
2) I tweaked the atomic-load-int128.c testcase to avoid an inadvertent
hostile thread situation that was not intended.
3) The speculative-store.c testcase had a bug in it where the verify
function was not returning a value when successful. ThIs resulted in an
UNSUPPORTED result occasionally because the testcase didn't run far
enough to indicate GDB had successfully run, yet no FAIL was issued.
4) I lowered the hostile thread threshold by an order of magnitude so
that if a hostile thread is encountered frequently, it wont rapidly
approach the new instruction count threshold. This could happen on
compare_and_swap loop targets.
I've tried this on x86_64-unknown-linux-gnu and everything seems good.
If anyone wants to try it on their more stressed arch, all you need to
do is apply the patch to the testsuite and run 'make check-gcc
RUNTESTFLAGS=simulate-thread.exp' to see if the results are as expected.
OK for mainline?
Andrew
* gcc.dg/simulate-thread/simulate-thread.gdb: Use return value from
simulate_thread_wrapper_other_threads
* gcc.dg/simulate-thread/atomic-load-int128.c (simulate_thread_main):
Move initialization of 'value' to main().
(main): Initialize 'value';
* gcc.dg/simulate-thread/speculative-store.c
(simulate_thread_step_verify): Return 0 when successful.
* gcc.dg/simulate-thread/simulate-thread.h (HOSTILE_THREAD_THRESHOLD):
Reduce threshold.
(INSN_COUNT_THRESHOLD): New. Instruction limit to terminate test.
(simulate_thread_wrapper_other_threads): Return a success/fail value
and issue an error if the instruction count threshold is exceeded.
Index: testsuite/gcc.dg/simulate-thread/simulate-thread.gdb
===
*** testsuite/gcc.dg/simulate-thread/simulate-thread.gdb (revision 184447)
--- testsuite/gcc.dg/simulate-thread/simulate-thread.gdb (working copy)
*** run
*** 5,11
set $ret = 0
while (simulate_thread_fini != 1) (! $ret)
! call simulate_thread_wrapper_other_threads()
stepi
set $ret |= simulate_thread_step_verify()
end
--- 5,11
set $ret = 0
while (simulate_thread_fini != 1) (! $ret)
! set $ret |= simulate_thread_wrapper_other_threads()
stepi
set $ret |= simulate_thread_step_verify()
end
Index: testsuite/gcc.dg/simulate-thread/atomic-load-int128.c
===
*** testsuite/gcc.dg/simulate-thread/atomic-load-int128.c (revision 184447)
--- testsuite/gcc.dg/simulate-thread/atomic-load-int128.c (working copy)
*** void simulate_thread_main()
*** 105,113
{
int x;
- /* Make sure value starts with an atomic value now. */
- __atomic_store_n (value, ret, __ATOMIC_SEQ_CST);
-
/* Execute loads with value changing at various cyclic values. */
for (table_cycle_size = 16; table_cycle_size 4 ; table_cycle_size--)
{
--- 105,110
*** void simulate_thread_main()
*** 126,131
--- 123,132
main()
{
fill_table ();
+
+ /* Make sure value starts with an atomic value from the table. */
+ __atomic_store_n (value, table[0], __ATOMIC_SEQ_CST);
+
simulate_thread_main ();
simulate_thread_done ();
return 0;
Index: testsuite/gcc.dg/simulate-thread/speculative-store.c
===
*** testsuite/gcc.dg/simulate-thread/speculative-store.c (revision 184447)
--- testsuite/gcc.dg/simulate-thread/speculative-store.c (working copy)
*** int simulate_thread_step_verify()
*** 24,29
--- 24,30
printf(FAIL: global variable was assigned to. \n);
return 1;
}
+ return 0;
}
int simulate_thread_final_verify()
Index: testsuite/gcc.dg/simulate-thread/simulate-thread.h
===
*** testsuite/gcc.dg/simulate-thread/simulate-thread.h (revision
[libgo] Fix typo in libgo/runtime/go-nosys.c
Mainline bootstrap on x86_64-unknown-linux-gnu (CentOS 5.6) was failing
due to a trivial typo. Fixed as follows.
Rainer
diff --git a/libgo/runtime/go-nosys.c b/libgo/runtime/go-nosys.c
--- a/libgo/runtime/go-nosys.c
+++ b/libgo/runtime/go-nosys.c
@@ -52,7 +52,7 @@ faccessat (int fd __attribute__ ((unused
int
fallocate (int fd __attribute__ ((unused)),
int mode __attribute__ ((unused)),
- off_t offset __attribute __ ((unused)),
+ off_t offset __attribute__ ((unused)),
off_t len __attribute__ ((unused)))
{
errno = ENOSYS;
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] simulate-thread tweaks and fixes
On Fri, Feb 24, 2012 at 12:38:56PM -0500, Andrew MacLeod wrote: I've been toying with the simulate-thread framework a bit. With the timeout threshold is back to where it originally was, the spectre of huge log files when an infinite loop happens is back. This patch has the following modifications: 1) An instruction count threshold has been added. This will truly prevent infinite loops which were the original issue. If the count reaches the threshold value, the test case fails. I've set the current limit to 10,000, which I would expect to be sufficient. The highest Ive seen so far is 877, but I'm sure someone will find something higher :-). A testcase can override this value if it wishes. If we encounter targets where this is not high enough, we can raise it further. The main point is to avoid generating 10's of gigabytes of log files when a fast machine hits an infinite loop and the time based timeout doesnt kick in quickly enough. If a test does fail for this reason, the log file will issue a FAIL message indicating the instruction count threshold was exceeded. 2) I tweaked the atomic-load-int128.c testcase to avoid an inadvertent hostile thread situation that was not intended. 3) The speculative-store.c testcase had a bug in it where the verify function was not returning a value when successful. ThIs resulted in an UNSUPPORTED result occasionally because the testcase didn't run far enough to indicate GDB had successfully run, yet no FAIL was issued. 4) I lowered the hostile thread threshold by an order of magnitude so that if a hostile thread is encountered frequently, it wont rapidly approach the new instruction count threshold. This could happen on compare_and_swap loop targets. I've tried this on x86_64-unknown-linux-gnu and everything seems good. If anyone wants to try it on their more stressed arch, all you need to do is apply the patch to the testsuite and run 'make check-gcc RUNTESTFLAGS=simulate-thread.exp' to see if the results are as expected. Andrew, Works fine on x86_64 darwin when applied to curren gcc trunk... Native configuration is x86_64-apple-darwin11.3.0 === gcc tests === Schedule of variations: unix/-m32 unix/-m64 Running target unix/-m32 Using /sw/share/dejagnu/baseboards/unix.exp as board description file for target. Using /sw/share/dejagnu/config/unix.exp as generic interface file for target. Using /sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120224/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120224/gcc/testsuite/gcc.dg/simulate-thread/simulate-thread.exp ... === gcc Summary for unix/-m32 === # of expected passes76 # of unsupported tests 8 Running target unix/-m64 Using /sw/share/dejagnu/baseboards/unix.exp as board description file for target. Using /sw/share/dejagnu/config/unix.exp as generic interface file for target. Using /sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120224/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120224/gcc/testsuite/gcc.dg/simulate-thread/simulate-thread.exp ... === gcc Summary for unix/-m64 === # of expected passes88 # of unsupported tests 2 === gcc Summary === # of expected passes164 # of unsupported tests 10 /sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/xgcc version 4.7.0 20120224 (experimental) (GCC OK for mainline? Andrew * gcc.dg/simulate-thread/simulate-thread.gdb: Use return value from simulate_thread_wrapper_other_threads * gcc.dg/simulate-thread/atomic-load-int128.c (simulate_thread_main): Move initialization of 'value' to main(). (main): Initialize 'value'; * gcc.dg/simulate-thread/speculative-store.c (simulate_thread_step_verify): Return 0 when successful. * gcc.dg/simulate-thread/simulate-thread.h (HOSTILE_THREAD_THRESHOLD): Reduce threshold. (INSN_COUNT_THRESHOLD): New. Instruction limit to terminate test. (simulate_thread_wrapper_other_threads): Return a success/fail value and issue an error if the instruction count threshold is exceeded. Index: testsuite/gcc.dg/simulate-thread/simulate-thread.gdb === *** testsuite/gcc.dg/simulate-thread/simulate-thread.gdb (revision 184447) --- testsuite/gcc.dg/simulate-thread/simulate-thread.gdb (working copy) *** run *** 5,11 set $ret = 0 while (simulate_thread_fini != 1) (! $ret) ! call simulate_thread_wrapper_other_threads() stepi set $ret |= simulate_thread_step_verify() end --- 5,11 set $ret = 0 while (simulate_thread_fini != 1) (! $ret
Ping #1: [Patch,AVR] Fix/hack around spill fail ICE PR52148
http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00956.html Georg-Johann Lay wrote: Spill failure PR52148 occurs for movmem insn that allocates 2 of AVR's 3 pointer registers. Register allocator is at it's limits and the patch tries to cure the situation by replacing (match_operand:HI 0 register_operand x) with explicit (reg:HI REG_X) and similar for Z Register classes x and z contain only one HI register. This PR and PR50925 show that register allocator has some problems. Even though this patch is not a fix of the root cause, it allows the PR's test case to compile. Anyways, the patch simplifies the backend and replaces an insn with 11(!) operands with an insn with only 2 operands so that the patch is improvement of the backend. The hard registers are already known at expand time so there is no need for match_operands. Passes without regression. Ok for trunk? Johann PR target/52148 * config/avr/avr.md (movmem_mode): Replace match_operand that match only one single hard register with respective hard reg rtx. (movmemx_mode): Ditto. * config/avr/avr.c (avr_emit_movmemhi): Adapt expanding to new insn anatomy of movmem[x]_mode. (avr_out_movmem): Same for printing assembler and operand usage.
Ping #1: [Patch,AVR]: Add builtins.def and fix some ICE, add tests
http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00843.html Georg-Johann Lay wrote: This patch introduces a new file builtins.def that is used as central registry to hold built-ins' information. The file is used by defining DEF_BUILTIN macre and then including the file as described in the head comment of builtins.def. Up to here it's all code clean-up and no functional change. Moreover there are some minor changes and ICE fixes: * Fold __builtin_avr_swap to rotate 4 * Don't fold __builtin_avr_insert_bits if first arg is non-const (was ICE) * Don't expand __builtin_avr_delay_cycles if arg is not-const (was ICE) Ok for trunk? Johann gcc/testsuite/ * gcc.target/avr/torture/builtins-1.c: New test. * gcc.target/avr/torture/builtins-error.c: New test. gcc/ * config/avr/builtins.def: New file. * config/avr/t-avr (avr.o, avr-c.o): Depend on it. * config/avr/avr.c (enum avr_builtin_id): Use it. (avr_init_builtins): Use it. And use avr_bdesc. (bdesc_1arg): Remove. (bdesc_2arg): Remove. (bdesc_3arg): Remove. (struct avr_builtin_description): Add field n_args. (avr_bdesc): New static variable using builtins.def. (avr_expand_builtin): Use it. Don't call avr_expand_delay_cycles if op0 is not CONST_INT. (avr_fold_builtin): Fold AVR_BUILTIN_SWAP. Don't fold AVR_BUILTIN_INSERT_BITS if arg0 is not INTEGER_CST.
Re: [PATCH] simulate-thread tweaks and fixes
On Feb 24, 2012, at 9:38 AM, Andrew MacLeod wrote: I've been toying with the simulate-thread framework a bit. OK for mainline? Ok. Don't know why you ask... I'd ask you if I wanted to make a change to the file... Anyway, I reviewed it, and didn't spot anything bad.
Re: [PATCH] simulate-thread tweaks and fixes
On 02/24/2012 02:10 PM, Mike Stump wrote: On Feb 24, 2012, at 9:38 AM, Andrew MacLeod wrote: I've been toying with the simulate-thread framework a bit. OK for mainline? Ok. Don't know why you ask... I'd ask you if I wanted to make a change to the file... Anyway, I reviewed it, and didn't spot anything bad. Just dotting my i's :-) I figured I'd give anyone who had issues earlier with these tests a bit of a chance to make sure it works if they wanted :-) Thanks. Andrew
PATCH: PR target/52352: [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF using registers
Hi,
This patches enables *movabsmode_1 and *movabsmode_2 only for
TARGET_LP64 since x32 doesn't need 64bit address. OK for trunk?
Thanks.
H.J.
---
2012-02-24 H.J. Lu hongjiu...@intel.com
PR target/52352
* config/i386/i386.md (*movabsmode_1): Enable only for
TARGET_LP64.
(*movabsmode_2): Likewise.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 6e2c123..0291e60 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -2362,7 +2362,7 @@
(define_insn *movabsmode_1
[(set (mem:SWI1248x (match_operand:DI 0 x86_64_movabs_operand i,r))
(match_operand:SWI1248x 1 nonmemory_operand a,er))]
- TARGET_64BIT ix86_check_movabs (insn, 0)
+ TARGET_LP64 ix86_check_movabs (insn, 0)
@
movabs{imodesuffix}\t{%1, %P0|%P0, %1}
mov{imodesuffix}\t{%1, %a0|%a0, %1}
@@ -2376,7 +2376,7 @@
(define_insn *movabsmode_2
[(set (match_operand:SWI1248x 0 register_operand =a,r)
(mem:SWI1248x (match_operand:DI 1 x86_64_movabs_operand i,r)))]
- TARGET_64BIT ix86_check_movabs (insn, 1)
+ TARGET_LP64 ix86_check_movabs (insn, 1)
@
movabs{imodesuffix}\t{%P1, %0|%0, %P1}
mov{imodesuffix}\t{%a1, %0|%0, %a1}
