On Linux/x86, revision 175427: http://gcc.gnu.org/ml/gcc-cvs/2011-06/msg00918.html caused: FAIL: g++.dg/cpp0x/constexpr-ptrmem.C (test for excess errors) FAIL: g++.dg/tree-ssa/fwprop-align.C scan-tree-dump-times forwprop2 "& 1" 0
Ugh, I think at least g++.dg/tree-ssa/fwprop-align.C is bogus when it tries to use alignment to compute whether a indicator bit is set ... Anyway, confirmed.
An anyway useful transform would be to hoist the call in iftmp.0_15 = *D.2099_14; <bb 4>: # iftmp.0_1 = PHI <foo(2), iftmp.0_15(3)> iftmp.0_1 (&a); based on the fact that on the edge 2->4 it will be a direct call.
constexpr-ptrmem.C is now failing because the C++ ABI uses the low bit of the function pointer field in a pointer-to-member function to indicate whether that field is actually a function pointer or a vtable index, and constexpr-ptrmem.C relies on being able to fold (&fn) & 1 to 0. I assume that the ARM C++ ABI variant uses a different representation.
Sorry for the breakage. I should obviously have tested on x86_64-linux-gnu as well.
yup, cris-elf (non-strict-alignment) too...
Author: rsandifo Date: Wed Jun 29 09:42:42 2011 New Revision: 175627 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175627 Log: gcc/ PR tree-optimization/49545 * builtins.c (get_object_alignment_1): Update function comment. Do not use DECL_ALIGN for functions, but test TARGET_PTRMEMFUNC_VBIT_LOCATION instead. * fold-const.c (get_pointer_modulus_and_residue): Don't check for functions here. * tree-ssa-ccp.c (get_value_from_alignment): Likewise. gcc/testsuite/ * gcc.dg/torture/pr49169.c: Restrict to ARM and MIPS targets. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/pr49169.c trunk/gcc/tree-ssa-ccp.c
I'm now seeing FAIL: g++.dg/tree-ssa/fwprop-align.C scan-tree-dump-times forwprop2 "& 1" 0 on the 4.6 branch for spu-elf ... Could this be the same problem?
I'm also seeing it on hppa64-hp-hpux11.11.
Can you check what patch caused it on the 4.6 branch? I suppose "fixed" on the trunk.
(In reply to comment #9) > Can you check what patch caused it on the 4.6 branch? It is this one: http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg00431.html 2011-07-11 Martin Jambor <mjambor@suse.cz> PR tree-optimization/49094 * tree-sra.c (tree_non_mode_aligned_mem_p): New function. (build_accesses_from_assign): Use it. > I suppose "fixed" on the trunk. Yes, that's correct.
Looks like this got "unfixed" on trunk? It worked on r176507, had reappeared on r176524.
After this commit: http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg01132.html the regression is now gone again on the 4.6 branch. On spu-elf, this bug is now fixed both on mainline and the 4.6.
(In reply to comment #12) > After this commit: > http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg01132.html I.e. r176864, applied to the 4.6 branch. Still, at r176866, g++.dg/tree-ssa/fwprop-align.C fails on trunk for cris-elf. (For which the test never failed on the 4.6 branch.) For cris-elf, code has to be 16-bit-aligned but otherwise there are no alignment restrictions. Perhaps that's related to the failure.
Fixed. The cris issue seems to be sth else.
(In reply to comment #14) > Fixed. The cris issue seems to be sth else. Whatever, as long as it helps fixing the bug. Cloning this PR then.