[Bug tree-optimization/40049] New: Incorrect tree made for vector shifted by constant on powerpc, spu
On machines with only a vector/vector shift like the powerpc and spu, the wrong type is generated for the tree vector that is created with the constant splat'ed to fill the vector. The problem is the code uses get_vectype_for_scalar_type, and integer constants don't have a type. So get_vectype_for_scalar_type returns V4SI, even if the vector in question is V8HI or V16QI. Before the added type validation was added on April 27th, this appeared to work because nothing looked at the type field. With the current code, this can lead to incorrect code being generated, and for larger programs the compiler will die due to garbage collection failure. -- Summary: Incorrect tree made for vector shifted by constant on powerpc, spu Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: meissner at linux dot vnet dot ibm dot com GCC build triplet: powerpc64-unknown-linux-gnu GCC host triplet: powerpc64-unknown-linux-gnu GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40049
[Bug tree-optimization/40049] Incorrect tree made for vector shifted by constant on powerpc, spu
--- Comment #1 from meissner at linux dot vnet dot ibm dot com 2009-05-06 19:08 --- Created an attachment (id=17811) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17811&action=view) Patch to fix vector shift by constant on machines with vector/vector shift This patch fixes the problem in the small case. While there, I fixed the FIXME in the next section to use build_constructor instead of build_constructor_from_list. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40049
[Bug tree-optimization/40049] Incorrect tree made for vector shifted by constant on powerpc, spu
--- Comment #2 from meissner at linux dot vnet dot ibm dot com 2009-05-06 19:19 --- Created an attachment (id=17812) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17812&action=view) Simplified test case This testcase shows the problem. Without the patch, it generates a vspltiw (vector splat immediate word) when it should generate vspltish. Using vsplitw means that every other vector element will be shifted by 0 instead of 2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40049
[Bug tree-optimization/40049] Incorrect tree made for vector shifted by constant on powerpc, spu
--- Comment #5 from meissner at linux dot vnet dot ibm dot com 2009-05-06 19:35 --- Subject: Re: Incorrect tree made for vector shifted by constant on powerpc, spu On Wed, May 06, 2009 at 07:22:25PM -, rguenth at gcc dot gnu dot org wrote: > > > --- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-06 19:22 > --- > See http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01532.html > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40049 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. The integer constants might have the correct types elsewhere, but in the specific case of vector shifts, the type is SImode and not HImode. Perphaps, I need to make the patch more specific for just shifts. Powerpc and spu would be the only machines that this shows up on. X86_64 has vector/vector shifts for SSE5 mode, but it is unlikely many people would notice at this stage (also, the x86 has vector shift by constant, in addition to the vector/vector shift of SSE5). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40049
[Bug tree-optimization/40049] Incorrect tree made for vector shifted by constant on powerpc, spu
--- Comment #6 from meissner at linux dot vnet dot ibm dot com 2009-05-06 20:00 --- Created an attachment (id=17813) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17813&action=view) More targetted patch to fix the problem This patch is much more targeted to just make sure vector shifts by constant or loop invarients have the correct type on machines with vector/vector shifts, and not vector/scalar shifts. -- meissner at linux dot vnet dot ibm dot com changed: What|Removed |Added Attachment #17811|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40049
[Bug tree-optimization/40049] Incorrect tree made for vector shifted by constant on powerpc, spu
--- Comment #9 from meissner at linux dot vnet dot ibm dot com 2009-05-07 21:33 --- Created an attachment (id=17824) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17824&action=view) Updated patch that fixes some internal compiler errors I discovered in further testing, that vect_get_vec_def_for_operand didn't like when a scalar had been converted, so I built a constructor for the op in the non-scalar case. -- meissner at linux dot vnet dot ibm dot com changed: What|Removed |Added Attachment #17813|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40049
[Bug tree-optimization/40073] New: Vector short/char shifts generate sub-optimal code
On machines like the x86_64/i386 with -msse2 option or powerpc with the -maltivec option that support vector 8-bit/16-bit shift instructions, GCC generates suboptimal code for variable shifts. Rather than generate the native instruction, the compiler converts the vector to V4SI vector, does the shift, and then converts the vector back to V16QI/V8HI mode. I speculate that this is due to the normal binary operator rules being done to bring both sides to the same type. Shifts and rotates are different in that the right hand side is an int type. -- Summary: Vector short/char shifts generate sub-optimal code Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: meissner at linux dot vnet dot ibm dot com GCC build triplet: x86_64-unknown-linux-gnu, powerpc64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu, powerpc64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu, powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40073
[Bug tree-optimization/40073] Vector short/char shifts generate sub-optimal code
--- Comment #2 from meissner at linux dot vnet dot ibm dot com 2009-05-08 17:02 --- Created an attachment (id=17828) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17828&action=view) Replacement test case that doesn't need -DTYPE to show the bug Replacement test case. -- meissner at linux dot vnet dot ibm dot com changed: What|Removed |Added Attachment #17827|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40073
[Bug tree-optimization/40073] Vector short/char shifts generate sub-optimal code
--- Comment #3 from meissner at linux dot vnet dot ibm dot com 2009-05-08 17:03 --- Created an attachment (id=17829) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17829&action=view) Powerpc example code This code was compiled with -O3 -maltivec. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40073
[Bug tree-optimization/40073] Vector short/char shifts generate sub-optimal code
--- Comment #4 from meissner at linux dot vnet dot ibm dot com 2009-05-08 17:04 --- Created an attachment (id=17830) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17830&action=view) X86_64 example code This code was compiled with an x86_64 compiler with the -O3 -msse3 options. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40073
[Bug tree-optimization/40073] Vector short/char shifts generate sub-optimal code
--- Comment #5 from meissner at linux dot vnet dot ibm dot com 2009-05-08 17:06 --- Created an attachment (id=17831) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17831&action=view) Vectorizer verbose output This is the output from the Powerpc compiler with -fdump-tree-vect -ftree-vectorizer-verbose=10 -fdump-tree-vect -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40073
[Bug tree-optimization/40073] Vector short/char shifts generate sub-optimal code
--- Comment #1 from meissner at linux dot vnet dot ibm dot com 2009-05-08 16:59 --- Created an attachment (id=17827) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17827&action=view) test case This code is an example of the code that generates sub-optimal code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40073
[Bug bootstrap/40082] New: Power bootstrap is broken in building libstdc++
I synced up to the current tree, and did a bootstrap build, and it fails in
building libstdc++:
/home/meissner/fsf-src/trunk/libstdc++-v3/src/compatibility-ldbl.cc:77: error:
inlined_to pointer is wrong
void std::basic_string<_CharT, _Traits, _Alloc>::_M_leak() [with _CharT =
wchar_t, _Traits = std::char_traits, _Alloc =
std::allocator]/608(-1) [0x4000183b500]: (inline copy in _OutIter
std::money_put<_CharT, _OutIter>::_M_insert(iter_type, std::ios_base&,
char_type, const std::money_put<_CharT, _OutIter>::string_type&) const [with
bool _Intl = true, _CharT = wchar_t, _OutIter =
std::ostreambuf_iterator, iter_type =
std::ostreambuf_iterator, char_type = wchar_t, std::money_put<_CharT,
_OutIter>::string_type = std::basic_string]/568) (clone of void
std::basic_string<_CharT, _Traits, _Alloc>::_M_leak() [with _CharT = wchar_t,
_Traits = std::char_traits, _Alloc = std::allocator]/648)
availability:available 16 insns body finalized inlinable
called by: std::basic_string<_CharT, _Traits, _Alloc>::reference
std::basic_string<_CharT, _Traits,
_Alloc>::operator[](std::basic_string<_CharT, _Traits, _Alloc>::size_type)
[with _CharT = wchar_t, _Traits = std::char_traits, _Alloc =
std::allocator, std::basic_string<_CharT, _Traits, _Alloc>::reference
= wchar_t&, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long
unsigned int]/246 (1.00 per call) (inlined) (can throw external)
calls: void std::basic_string<_CharT, _Traits, _Alloc>::_M_leak_hard() [with
_CharT = wchar_t, _Traits = std::char_traits, _Alloc =
std::allocator]/858 (0.63 per call) (can throw external)
/home/meissner/fsf-src/trunk/libstdc++-v3/src/compatibility-ldbl.cc:77:
internal compiler error: verify_cgraph_node failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions
--
Summary: Power bootstrap is broken in building libstdc++
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: meissner at linux dot vnet dot ibm dot com
GCC build triplet: powerpc64-unknown-linux-gnu
GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40082
[Bug bootstrap/40082] Power bootstrap is broken in building libstdc++
--- Comment #1 from meissner at linux dot vnet dot ibm dot com 2009-05-09 12:36 --- Created an attachment (id=17836) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17836&action=view) .ii file of file in libstdc++ that causes the failure The options needed to show this bug are: -O2 -mlong-double-64 -fno-implicit-templates -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40082
[Bug bootstrap/40082] [4.5 Regression] Power bootstrap is broken in building libstdc++
--- Comment #4 from meissner at linux dot vnet dot ibm dot com 2009-05-09 15:56 --- Subject: Re: [4.5 Regression] Power bootstrap is broken in building libstdc++ On Sat, May 09, 2009 at 02:44:29PM -, hubicka at ucw dot cz wrote: > > > --- Comment #3 from hubicka at ucw dot cz 2009-05-09 14:44 --- > Subject: Re: [4.5 Regression] Power bootstrap is broken in building libstdc++ > > Hi, > I am testing the attached patch. It makes testcase to compile, does it > solve bootstrap issues too? I just fired off a bootstrap, and will let you know when I get back to the computer in a few hours. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40082
[Bug bootstrap/40082] [4.5 Regression] Power bootstrap is broken in building libstdc++
--- Comment #6 from meissner at linux dot vnet dot ibm dot com 2009-05-10 01:05 --- Subject: Re: [4.5 Regression] Power bootstrap is broken in building libstdc++ On Sat, May 09, 2009 at 02:44:29PM -, hubicka at ucw dot cz wrote: > > > --- Comment #3 from hubicka at ucw dot cz 2009-05-09 14:44 --- > Subject: Re: [4.5 Regression] Power bootstrap is broken in building libstdc++ > > Hi, > I am testing the attached patch. It makes testcase to compile, does it > solve bootstrap issues too? It does solve the bootstrap issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40082
[Bug bootstrap/40118] New: cond-optab breaks powerpc bootstrap
The powerpc bootstrap fails due to an inner block that has: rtx op1 = XVECEXP (op1, 0, 0); and this triggers the error: error: op1 may be used uninitialized in this function -- Summary: cond-optab breaks powerpc bootstrap Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: meissner at linux dot vnet dot ibm dot com GCC build triplet: powerpc64-unknown-linux-gnu GCC host triplet: powerpc64-unknown-linux-gnu GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40118
[Bug bootstrap/40118] cond-optab breaks powerpc bootstrap
--- Comment #2 from meissner at linux dot vnet dot ibm dot com 2009-05-12 12:54 --- Created an attachment (id=17854) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17854&action=view) Patch to fix bootstrap error message. Patch applied to the tree as obvious. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40118
[Bug c/40172] [4.5 Regression] Revision 147596 breaks bootstrap
--- Comment #16 from meissner at linux dot vnet dot ibm dot com 2009-05-18 22:56 --- Just to chime in, the warning is a useful warning, but the way rs6000 and mips define FRAME_GROWS_DOWNWARD, the test in toplev.c will never succeed. I can see a couple of ways to fix this: 1) Revert the patch that moves this warning to -Wextra. I think this is a bad idea, since the warning does seem to be useful. 2) Disable the check in toplev.c. Again, I think this is useful in general, but as an immediate palative, it can be useful. 3) Add a new macro to say not to do the test in #2, and define it in mips and rs6000. This is doable, but in general it is not a good idea to add new global macros like this. 4) Change mips and rs6000 to have a global variable that is what FRAME_GROWS_DOWNWARD should be. This is certainly doable. The test will be tested at runtime, but never invoke the error message. 5) Move FRAME_GROWS_DOWNWARD (and STACK_GROWS_DOWNWARD, etc.) into the target structure, and set the field in the target structure from the macro. I tend to like this (and eventually move backends to set the field directly and get rid of the macros). I tend to like this idea best. -- meissner at linux dot vnet dot ibm dot com changed: What|Removed |Added CC||meissner at linux dot vnet ||dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40172
[Bug c/40172] [4.5 Regression] Revision 147596 breaks bootstrap
--- Comment #20 from meissner at linux dot vnet dot ibm dot com 2009-05-18 23:48 --- David, as I said in my message, this patch is just papering over the problem. While we might want to install this patch temporarily, to get the mips and rs6000 building again, I think a better solution is to change the circular dependency between FRAME_GROWS_DOWNWARD and flag_stack_protect, so at the point of the test in toplev.c the compiler won't give this warning. H. J. the problem with your patch is it that the compiler is likely to still issue the warning, since it will be discovered by the dataflow or SSA parts of the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40172
[Bug c/40172] [4.5 Regression] Revision 147596 breaks bootstrap
--- Comment #23 from meissner at linux dot vnet dot ibm dot com 2009-05-19
02:33 ---
Subject: Re: [4.5 Regression] Revision 147596 breaks bootstrap
On Tue, May 19, 2009 at 12:38:08AM -, hjl dot tools at gmail dot com wrote:
>
>
> --- Comment #22 from hjl dot tools at gmail dot com 2009-05-19 00:38
> ---
> Another patch is posted at
>
> http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01187.html
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40172
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
I still feel that if this patch is put in, we eventually will have the same
discussion, as the compiler gets smarter about flow control and propigation,
since semantically:
if (test1)
{
if (test2)
{
/* ... */
}
}
is the same as:
if (test1 && test2)
{
/* ... */
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40172
[Bug target/40197] New: Spu fortran does not build
Spu.h needs to define PTRDIFF_TYPE, since fortran now uses this in compiling trans-types. SIZE_TYPE probably should also be defined. gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -Ifortran -I/home/meissner/fsf-src/trunk/gcc -I/home/meissner/fsf-src/trunk/gcc/fortran -I/home/meissner/fsf-src/trunk/gcc/../include -I/home/meissner/fsf-src/trunk/gcc/../libcpp/include -I/home/meissner/fsf-install-ppc64/gmp-4.2.2/include -I/home/meissner/fsf-install-ppc64/mpfr-2.4.0/include -I/home/meissner/fsf-src/trunk/gcc/../libdecnumber -I/home/meissner/fsf-src/trunk/gcc/../libdecnumber/dpd -I../libdecnumber /home/meissner/fsf-src/trunk/gcc/fortran/trans-types.c -o fortran/trans-types.o In file included from /home/meissner/fsf-src/trunk/gcc/fortran/trans-types.c:335: /home/meissner/fsf-src/trunk/gcc/fortran/iso-c-binding.def: In function init_c_interop_kinds: /home/meissner/fsf-src/trunk/gcc/fortran/iso-c-binding.def:58: error: PTRDIFF_TYPE undeclared (first use in this function) /home/meissner/fsf-src/trunk/gcc/fortran/iso-c-binding.def:58: error: (Each undeclared identifier is reported only once /home/meissner/fsf-src/trunk/gcc/fortran/iso-c-binding.def:58: error: for each function it appears in.) make[2]: *** [fortran/trans-types.o] Error 1 -- Summary: Spu fortran does not build Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: meissner at linux dot vnet dot ibm dot com GCC build triplet: powerpc64-unknown-linux-gnu GCC host triplet: powerpc64-unknown-linux-gnu GCC target triplet: spu-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40197
[Bug target/40197] Spu fortran does not build
--- Comment #1 from meissner at linux dot vnet dot ibm dot com 2009-05-19 12:35 --- Created an attachment (id=17892) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17892&action=view) Define PTRDIFF_TYPE, SIZE_TYPE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40197
[Bug tree-optimization/40219] New: iterative_hash_expr in tree.c has an out of bound reference for machine specific builtins
The function iterative_hash_expr uses built_in_decls to a map a builtin function to the __builtin_ form. It uses DECL_FUNCTION_CODE as the index. For machine specific builtins, the DECL_FUNCTION_CODE is defined by the backend, instead of being the builtin number. This means that the builtin_in_decls reference can point to random memory. In the power7 branch, I added quite a few more builtins, and this code causes crashes when it looks at memory beyond the bound of builtin_in_decls. Even if it doesn't overflow the bounds of the array, the builtin hash might pick up the wrong declaration. -- Summary: iterative_hash_expr in tree.c has an out of bound reference for machine specific builtins Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: meissner at linux dot vnet dot ibm dot com GCC build triplet: powerpc64-unknown-linux-gnu GCC host triplet: powerpc64-unknown-linux-gnu GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40219
[Bug tree-optimization/40219] iterative_hash_expr in tree.c has an out of bound reference for machine specific builtins
--- Comment #1 from meissner at linux dot vnet dot ibm dot com 2009-05-21 13:14 --- Created an attachment (id=17898) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17898&action=view) Patch to avoid de-referencing outside array bounds This patch fixes the particular problem I saw on the power7-branch for the testsuite and building the SPEC2006 gobmk and wrf benchmarks. I will do the usual bootstrap shortly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40219
[Bug bootstrap/40221] New: Powerpc bootstrap is broken in building libstdc++
I was testing my patch for 40219, and I rebuilt today's build on the Powerpc,
and had the build fail in building libstdc++-v3. I backed out my change, and
redid the build, and I get exactly the same failure:
/bin/sh ../libtool --tag CXX --mode=compile
/home/meissner/fsf-build-ppc64/trunk/./gcc/xgcc -shared-libgcc
-B/home/meissner/fsf-build-ppc64/trunk/./gcc -nostdinc++
-L/home/meissner/fsf-build-ppc64/trunk/powerpc64-unknown-linux-gnu/32/libstdc++-v3/src
-L/home/meissner/fsf-build-ppc64/trunk/powerpc64-unknown-linux-gnu/32/libstdc++-v3/src/.libs
-B/home/meissner/fsf-install-ppc64/trunk/powerpc64-unknown-linux-gnu/bin/
-B/home/meissner/fsf-install-ppc64/trunk/powerpc64-unknown-linux-gnu/lib/
-isystem
/home/meissner/fsf-install-ppc64/trunk/powerpc64-unknown-linux-gnu/include
-isystem
/home/meissner/fsf-install-ppc64/trunk/powerpc64-unknown-linux-gnu/sys-include
-m32 -fPIC -mstrict-align
-I/home/meissner/fsf-build-ppc64/trunk/powerpc64-unknown-linux-gnu/32/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/meissner/fsf-build-ppc64/trunk/powerpc64-unknown-linux-gnu/32/libstdc++-v3/include
-I/home/meissner/fsf-src/trunk/libstdc++-v3/libsupc++ -fno-implicit-templates
-Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -std=gnu++0x -c
/home/meissner/fsf-src/trunk/libstdc++-v3/src/mutex.cc
libtool: compile: /home/meissner/fsf-build-ppc64/trunk/./gcc/xgcc
-shared-libgcc -B/home/meissner/fsf-build-ppc64/trunk/./gcc -nostdinc++
-L/home/meissner/fsf-build-ppc64/trunk/powerpc64-unknown-linux-gnu/32/libstdc++-v3/src
-L/home/meissner/fsf-build-ppc64/trunk/powerpc64-unknown-linux-gnu/32/libstdc++-v3/src/.libs
-B/home/meissner/fsf-install-ppc64/trunk/powerpc64-unknown-linux-gnu/bin/
-B/home/meissner/fsf-install-ppc64/trunk/powerpc64-unknown-linux-gnu/lib/
-isystem
/home/meissner/fsf-install-ppc64/trunk/powerpc64-unknown-linux-gnu/include
-isystem
/home/meissner/fsf-install-ppc64/trunk/powerpc64-unknown-linux-gnu/sys-include
-m32 -fPIC -mstrict-align
-I/home/meissner/fsf-build-ppc64/trunk/powerpc64-unknown-linux-gnu/32/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/meissner/fsf-build-ppc64/trunk/powerpc64-unknown-linux-gnu/32/libstdc++-v3/include
-I/home/meissner/fsf-src/trunk/libstdc++-v3/libsupc++ -fno-implicit-templates
-Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -std=gnu++0x -c
/home/meissner/fsf-src/trunk/libstdc++-v3/src/mutex.cc -fPIC -DPIC -o
.libs/mutex.o
In file included from
/home/meissner/fsf-build-ppc64/trunk/powerpc64-unknown-linux-gnu/32/libstdc++-v3/include/functional:70,
from
/home/meissner/fsf-build-ppc64/trunk/powerpc64-unknown-linux-gnu/32/libstdc++-v3/include/mutex:44,
from
/home/meissner/fsf-src/trunk/libstdc++-v3/src/mutex.cc:25:
/home/meissner/fsf-build-ppc64/trunk/powerpc64-unknown-linux-gnu/32/libstdc++-v3/include/tr1_impl/functional:
In copy constructor std::function<_Res(_ArgTypes ...)>::function(const
std::function<_Res(_ArgTypes ...)>&) [with _Res = void, _ArgTypes = ]:
/home/meissner/fsf-src/trunk/libstdc++-v3/src/mutex.cc:51: instantiated from
here
/home/meissner/fsf-build-ppc64/trunk/powerpc64-unknown-linux-gnu/32/libstdc++-v3/include/tr1_impl/functional:1992:
error: could not convert __x to bool
make: *** [mutex.lo] Error 1
Given where it occurs, I suspect it is due to this change:
2009-05-20 Benjamin Kosnik
* include/tr1_impl/functional (function): Use explicit operator bool.
--
Summary: Powerpc bootstrap is broken in building libstdc++
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: meissner at linux dot vnet dot ibm dot com
GCC build triplet: powerpc64-unknown-linux-gnu
GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40221
[Bug bootstrap/40597] Powerpc bootstrap is broken due to changes in expmed.c
--- Comment #4 from meissner at linux dot vnet dot ibm dot com 2009-06-29 21:46 --- Subject: Re: Powerpc bootstrap is broken due to changes in expmed.c On Mon, Jun 29, 2009 at 09:34:02PM -, bonzini at gnu dot org wrote: > > > --- Comment #2 from bonzini at gnu dot org 2009-06-29 21:34 --- > Created an attachment (id=18096) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18096&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18096&action=view) > patch currently in stage2 > > Here it is. A bit early for posting to gcc-patches, but if you want to > approve > it I'll commit it tomorrow morning, after making sure the bootstrap/regtest > passes. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. Approved assuming it passes bootstrap/regtest. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597
[Bug bootstrap/40597] Powerpc bootstrap is broken due to changes in expmed.c
--- Comment #5 from meissner at linux dot vnet dot ibm dot com 2009-06-30 04:20 --- Subject: Re: Powerpc bootstrap is broken due to changes in expmed.c On Mon, Jun 29, 2009 at 09:32:47PM -, bonzini at gnu dot org wrote: > > > --- Comment #1 from bonzini at gnu dot org 2009-06-29 21:32 --- > Mine of course. I was going to post the patch to the mailing list after it > was > well into my x86_64-linux bootstrap, I'll add it here. > > Thanks for the testcase BTW. > > > -- > > bonzini at gnu dot org changed: > >What|Removed |Added > > AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org >|dot org | > Status|UNCONFIRMED |ASSIGNED > Ever Confirmed|0 |1 >Last reconfirmed|-00-00 00:00:00 |2009-06-29 21:32:47 >date|| > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. With my patch, I get 4 regressions compared to the sources I snapped on Friday (subversion #148954): gcc.c-torture/execute/20071030-1.c gcc.c-torture/compile/pr37258.c gfortran.dg/negative_unit_int8.f gfortran.fortran-torture/execute/inquire_5.f90 On the other hand, I get one pass that used to fail: gfortran.dg/proc_ptr_result_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597
[Bug target/30210] [4.5 Regression] Altivec builtins have inaccurate return types
--- Comment #17 from meissner at linux dot vnet dot ibm dot com 2009-07-08 23:42 --- Subject: Re: [4.5 Regression] Altivec builtins have inaccurate return types On Wed, Jul 08, 2009 at 09:04:03PM -, rguenth at gcc dot gnu dot org wrote: > > > --- Comment #16 from rguenth at gcc dot gnu dot org 2009-07-08 21:04 > --- > Mike - you said you have patches for this? > > > -- > > rguenth at gcc dot gnu dot org changed: > >What|Removed |Added > > CC||meissner at gcc dot gnu dot >||org > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. Yes, it should be in the next power7 patch. I hope to send out the patch for review shortly, but I have a few regressions in my code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
[Bug bootstrap/40597] Powerpc bootstrap is broken due to changes in expmed.c
--- Comment #35 from meissner at linux dot vnet dot ibm dot com 2009-07-23 23:00 --- Subject: Re: Powerpc bootstrap is broken due to changes in expmed.c On Thu, Jul 23, 2009 at 10:52:01PM -, paolo dot bonzini at gmail dot com wrote: > > > --- Comment #34 from paolo dot bonzini at gmail dot com 2009-07-23 22:52 > --- > Subject: Re: Powerpc bootstrap is broken due to changes > in expmed.c > > On 07/23/2009 02:37 PM, krebbel at gcc dot gnu dot org wrote: > > In emit_store_flag the following code now invokes emit_store_flag_1 instead > > of > > emit_store_flag: > > This one in particular should be a recursive call indeed. Can you > prepare a patch? > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. Just to be sure we are on the same page, is the trunk up to date, or are there patches to the trunk that haven't been committed yet. It looks like the patch was committed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597
[Bug driver/39293] New: -save-temps does not follow the -o option and instead puts the temp file in the current directory
I was building Spec 2006 with a powerpc64-linux cross compiler using the -save-temps option so that I could do some analysis on the generated code. Unfortunately, if I use -j4 in the make for the spec build, the test cactusADM does not build. I traced this down to there were several Startup.c files in different directories, and the spec make uses -o to put the resulting objects in different directories: /gcc -o PUGH/Startup.o PUGH/Startup.c /gcc -o IOUtil/Startup.o IOUtil/Startup.c /gcc -o BenchADMsrc/Startup.o BenchADMsrc/Startup.c /gcc -o CartGrid3D/Startup.o CartGrid3D/Startup.c ... As luck would have it, make decided to compile several of of the Startup.c's at the same time, and since they wrote the files in the current directory, they overwrote each other, and the assembler complained about illegal input. -- Summary: -save-temps does not follow the -o option and instead puts the temp file in the current directory Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: meissner at linux dot vnet dot ibm dot com GCC build triplet: x86_64-gnu-linux GCC host triplet: x86_64-gnu-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39293
[Bug driver/39293] -save-temps does not follow the -o option and instead puts the temp file in the current directory
--- Comment #3 from meissner at linux dot vnet dot ibm dot com 2009-02-28 01:01 --- Created an attachment (id=17374) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17374&action=view) This patch fixes -save-temps so that it puts the temp file in the output directory rather than the current directory -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39293
[Bug target/39558] New: Fortran iresolve.c cannot be built with -maltivec used in bootstrap
Adding -maltivec to the PowerPC compiler turns on the altivec vector support.
Part of the vector support is to add conditional expansion of the vector
keyword if it looks like vector is part of a type declaration (i.e. vector
float would declare a single precision floating point 4 element vector, or
V4SF). If the next thing after vector is a macro that expands to
__attribute__((__unused__)), the compiler will realize that it should expand
vector to vector, and then glue it with the __attribute__. I discovered this
when doing a bootstrap of the compiler with the power7 VSX instructions enabled
(VSX includes Altivec).
This is the declaration in fortran/iresolve.c that shows the problem:
void
gfc_resolve_pack (gfc_expr *f, gfc_expr *array, gfc_expr *mask,
gfc_expr *vector ATTRIBUTE_UNUSED)
{
/* ... */
}
If we change the argument to something other than vector, it will allow the
code to be compiled with -maltivec, but the underlying problem should be fixed.
--
Summary: Fortran iresolve.c cannot be built with -maltivec used
in bootstrap
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: meissner at linux dot vnet dot ibm dot com
GCC build triplet: powerpc64-unknown-linux-gnu
GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
[Bug target/39558] Fortran iresolve.c cannot be built with -maltivec used in bootstrap
--- Comment #1 from meissner at linux dot vnet dot ibm dot com 2009-03-25 23:24 --- Created an attachment (id=17543) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17543&action=view) Simplified test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support
--- Comment #3 from meissner at linux dot vnet dot ibm dot com 2009-03-26
15:24 ---
Subject: Re: Bad interaction of decls named 'vector' and -maltivec vector
support
On Thu, Mar 26, 2009 at 02:00:49PM -, jakub at gcc dot gnu dot org wrote:
>
>
> --- Comment #2 from jakub at gcc dot gnu dot org 2009-03-26 14:00 ---
> What exact problem do you see?
> #define ATTRIBUTE_UNUSED __attribute__((unused))
>
> vector int i;
>
> int *foo (int *vector)
> {
> return vector;
> }
>
> int *bar (int *vector ATTRIBUTE_UNUSED)
> {
> return vector;
> }
>
> int *baz (int *vector __attribute__((unused)))
> {
> return vector;
> }
>
> compiles just fine for me with -maltivec -Wall (and correctly complains only
> in
> foo about the unused argument).
I just looked at it, and the problem is if you use the -save-temps options
along with -maltivec. Because -save-temps invokes the preprocessor as a
separate stage, when it expands vector (to be vector) and ATTRIBUTE_UNUSED (to
be __attribute__((unused))), it glues the two tokens together. Since I'm
looking at power7 code generation right now, I was doing a full bootstrap with
-save-temps to see where the power7 instructions were being generated.
I suspect if we change the default definition of 'vector' to "vector " instead
of "vector" if vector isn't follwed by a type keyword, it will fix the problem
(ditto for bool, etc.).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support
--- Comment #4 from meissner at linux dot vnet dot ibm dot com 2009-03-26 15:43 --- Further testing shows that this only happens if you use the -save-temps option. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support
--- Comment #6 from meissner at linux dot vnet dot ibm dot com 2009-03-27
15:19 ---
Subject: Re: Bad interaction of decls named 'vector' and -maltivec vector
support
On Fri, Mar 27, 2009 at 11:09:57AM -, jakub at gcc dot gnu dot org wrote:
>
>
> --- Comment #5 from jakub at gcc dot gnu dot org 2009-03-27 11:09 ---
> Ah, I see. The problem is that rs6000_macro_to_expand sometimes calls
> cpp_get_token (when seeing a macro after vector token), and removes optionally
> some CPP_PADDING tokens and a NT_MACRO token (with PREV_WHITE set on it).
> This only affects vector, not pixel nor bool. Unfortunately, we can't
> expand vector to a macro defined as 'vector ' (without quotes), because that
> would mean infinite recursion. We could perhaps if macro_to_expand hook
> returns NULL set PREV_WHITE on the next token (on the libcpp side, as
> rs6000_macro_to_expand sees tokens as const cpp_token), or insert a
> CPP_PADDING
> token.
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
Note, there is problem with infinite recursion, since a macro is temporarily
undefined when it is being expanded, as per the ISO C rules. I tried the
following patch:
2009-03-26 Michael Meissner
PR target/39558
* rs6000-c.c (rs6000_macro_to_expand): If the conditional macro is
not to be expanded, return the default definition which is the
macro defined as itself. This insures that the proper spacing is
put out if -save-temps or -E is used and the next token is an
identifier or macro.
Index: gcc/config/rs6000/rs6000-c.c
===
--- gcc/config/rs6000/rs6000-c.c(revision 145074)
+++ gcc/config/rs6000/rs6000-c.c(working copy)
@@ -155,9 +155,6 @@ rs6000_macro_to_expand (cpp_reader *pfil
ident = altivec_categorize_keyword (tok);
- if (ident != expand_this)
-expand_this = NULL;
-
if (ident == C_CPP_HASHNODE (__vector_keyword))
{
int idx = 0;
And it works for the compiler, but then gcc.target/powerpc/altivec-27.c fails,
which is crafted to test various cpp pasting, etc. I like your idea about
inserting a CPP_PADDING token.
The other way to do it is to add support for conditional keywords, like I did
for the named address space stuff for the cell, and not abuse the preprocessor.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support
--- Comment #7 from meissner at linux dot vnet dot ibm dot com 2009-03-27 15:59 --- Subject: Re: Bad interaction of decls named 'vector' and -maltivec vector support On Fri, Mar 27, 2009 at 11:18:52AM -0400, Michael Meissner wrote: > Note, there is problem with infinite recursion, since a macro is temporarily > undefined when it is being expanded, as per the ISO C rules. I tried the > following patch: Just to be clear, I meant to say "there is no problem with infinite recursion". Whoops. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support
--- Comment #9 from meissner at linux dot vnet dot ibm dot com 2009-03-27 21:20 --- Subject: Re: Bad interaction of decls named 'vector' and -maltivec vector support On Fri, Mar 27, 2009 at 05:55:05PM -, jakub at gcc dot gnu dot org wrote: > > > --- Comment #8 from jakub at gcc dot gnu dot org 2009-03-27 17:55 --- > Created an attachment (id=17546) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17546&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17546&action=view) > gcc44-pr39558.patch > > Untested patch to fix this. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. This does fix the problem and has no extra testsuite failures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
[Bug testsuite/39769] New: vmx tests fail due to reliance on floating point equality
3 of the vmx tests (3a-04.c, 3a-04m.c, and 3a-05.c) fail on different powerpc machines because the test relies on the Vector 2 Raised to the Exponent Estimate and Vector Reciprocal Estimate instructions producing the exact same bit value for each machine. Since these instructions are estitmate functions, different implementations of the powerpc architecture produce different results. Floating point equality should never have been used for these tests. I have patches to change the test to see whether the value produces is accurate to 4 decimal digits using greater than and less than tests, which I will attach shortly. -- Summary: vmx tests fail due to reliance on floating point equality Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: meissner at linux dot vnet dot ibm dot com GCC build triplet: powerpc64-unknown-linux-gnu GCC host triplet: powerpc64-unknown-linux-gnu GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39769
[Bug testsuite/39769] vmx tests fail due to reliance on floating point equality
--- Comment #1 from meissner at linux dot vnet dot ibm dot com 2009-04-14 17:48 --- Created an attachment (id=17637) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17637&action=view) Patch to fix the tests not to use floating point equality. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39769
[Bug middle-end/42431] [4.5 Regression] wrong code for 200.sixtrack with vectorization and -fdata-sections
--- Comment #10 from meissner at linux dot vnet dot ibm dot com 2010-02-24
21:01 ---
Subject: Re: [4.5 Regression] wrong code for
200.sixtrack with vectorization and -fdata-sections
On Tue, Feb 23, 2010 at 09:57:17PM -, bergner at gcc dot gnu dot org wrote:
>
>
> --- Comment #9 from bergner at gcc dot gnu dot org 2010-02-23 21:57
> ---
> This is a generic reload bug. With this test case and options, we have the
> following instructions just before IRA:
>
> (insn 203 2 213 2 (set (reg/f:DI 256 [ vect_pk.44 ])
> (plus:DI (reg/f:DI 255)
> (const_int 16 [0x10]))) 83 {*adddi3_internal1}
> (expr_list:REG_EQUAL
> (const:DI (plus:DI (symbol_ref:DI ("*.LANCHOR2") [flags 0x182])
> (const_int 16 [0x10])))
> (nil)))
> ...
> (insn 21 214 25 2 pr42431.f:27 (set (reg:DI 270)
> (const_int 16 [0x10])) 371 {*movdi_internal64} (nil))
> ...
> (insn 20 17 23 3 pr42431.f:27 (set (mem:V4SI (reg/f:DI 256 [ vect_pk.44 ]) [4
> S16 A128])
> (reg:V4SI 269)) 926 {*altivec_movv4si} (expr_list:REG_EQUAL
> (const_vector:V4SI [
> (const_int 0 [0x0])
> (const_int 0 [0x0])
> (const_int 0 [0x0])
> (const_int 0 [0x0])
> ])
> (nil)))
>
> (insn 23 20 232 3 pr42431.f:27 (set (mem:V4SI (plus:DI (reg/f:DI 256 [
> vect_pk.44 ])
> (reg:DI 270)) [4 S16 A128])
> (reg:V4SI 269)) 926 {*altivec_movv4si} (expr_list:REG_EQUAL
> (const_vector:V4SI [
> (const_int 0 [0x0])
> (const_int 0 [0x0])
> (const_int 0 [0x0])
> (const_int 0 [0x0])
> ])
> (nil)))
>
> Both r256 and r270 are marked for spilling. This leads to two chained
> reloads:
>
> (const:DI (plus:DI (symbol_ref:DI ("*.LANCHOR2") [flags 0x182]) (const_int
> 16
> [0x10])))
> and
> (const_int 16 [0x10])
>
> With these chained reloads, we eventually drop into
> gen_reload_chain_without_interm_reg_p(). This function does a copy_rtx() to
> create a scratch rtx it can modify to run some tests on and then throw away.
> The bug is that copy_rtx() simply returns the passed in rtx pointer for CONST
> rtxs, so we end up modifying the program's real rtl rather than some scratch
> rtl. Since we cannot execute the copy_rtx/substitue statements without
> causing
> problems, I'm testing the patch below to see if it fixes the
> problem...although, if there are CONSTs buried deep within the reload rtx, we
> probably could still end up with a similar problem on a different test case.
> Comments anyone?
I suspect this may have been the culprit for the bandaid that I put in
rs6000_emit_move (around line 6339 of rs6000.c) to handle const addresses that
were overwritten with a register. Here is the comment that starts the block:
/* Fix up invalid (const (plus (symbol_ref) (reg))) that seems to be created
in the secondary_reload phase, which evidently overwrites the CONST_INT
with a register. */
> Index: reload1.c
> ===
> --- reload1.c (revision 156816)
> +++ reload1.c (working copy)
> @@ -5221,6 +5221,10 @@
>r1 = r2;
>r2 = n;
> }
> +
> + if (GET_CODE (rld[r1].in) == CONST)
> +return true;
> +
>gcc_assert (reg_mentioned_p (rld[r2].in, rld[r1].in));
>regno = rld[r1].regno >= 0 ? rld[r1].regno : rld[r2].regno;
>gcc_assert (regno >= 0);
>
>
I dunno, would it be better if we cloned copy_rtx to have a varient that
doesn't call shared_const_p in rtl.c and made a full copy? I would think this
would be better than returning true if it is a constant.
If we decide to keep the current code, please put a comment in re-iterating the
reasons mentioned above (and maybe a call to shared_const_p to see if copy_rtx
would copy it).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42431
[Bug rtl-optimization/43413] Powerpc generates worse code for -mvsx on gromacs even though there are no VSX instructions used
--- Comment #7 from meissner at linux dot vnet dot ibm dot com 2010-03-22 22:24 --- Subject: Re: Powerpc generates worse code for -mvsx on gromacs even though there are no VSX instructions used On Mon, Mar 22, 2010 at 10:20:21PM -, vmakarov at redhat dot com wrote: > > > --- Comment #6 from vmakarov at redhat dot com 2010-03-22 22:20 --- > (In reply to comment #4) > > FWIW, I seem to get considerably worse code from mainline than you -- for > > -O3 > > -ffast-math -mcpu=power7 -mvsx -maltivec I get 140 stfs and 192 lfs insns > > (compared to 117 & 139 respectively that you reported). > > > > I suspect the differnce is because Mike calculated only stfs/lfs and you > stfs(x)/lfs(x). But may be I am wrong. I only calculated the stores and loads to the stack, i.e. egrep (stfs|lfs).*\(1\) since I was just looking for the spills. > > Just for fun, I ran the same code through the a ppc compiler with the LRS > > code > > from reload-v2 and get 133:178 stfs/lsf insns, so that code clearly is > > helping, > > but it's not enough to offset the badness shown by IRA. > > > > > > I couldn't reconcile how -fno-ira-share-spill-slots would be changing the > > number of load/store insns, so I poked at that a bit. > > Yes, I cannot understand that too. Note, while -fno-ira-share-spill-slots as fewer spills, I just measured the results on the machine, and the time spent is pretty much the same. > > -fno-ira-share-spill-slots twiddles whether or not a pseudo which gets > > assigned > > a hard reg is put into live_throughout or dead_or_set_p in the reload chain > > structures, which in turn changes what pseudos get reassigned hard regs > > during > > reload. This is a somewhat odd effect and should be investigated further. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43413
[Bug rtl-optimization/43413] Powerpc generates worse code for -mvsx on gromacs even though there are no VSX instructions used
--- Comment #8 from meissner at linux dot vnet dot ibm dot com 2010-03-22 22:29 --- Subject: Re: Powerpc generates worse code for -mvsx on gromacs even though there are no VSX instructions used On Mon, Mar 22, 2010 at 10:16:56PM -, vmakarov at redhat dot com wrote: > > > --- Comment #5 from vmakarov at redhat dot com 2010-03-22 22:16 --- > (In reply to comment #0) > > > > In the enclosed test case, it generates the following spills for the > > options: > > -O3 -ffast-math -mcpu=power7 -mvsx -maltivec: 117 stfs, 139 lfs > > -O3 -ffast-math -mcpu=power5 -maltivec: 80 stfs, 100 lfs > > -O3 -ffast-math -mcpu=power5: 80 stfs, 100 lfs > > Hi, Mike. I think the comparison should be done with the same -mcpu because > there is 1st insn scheduling which increases register pressure differently for > different architectures. But that is not so important. I see a lot of spills > during assigning because memory is more profitable. Graph coloring pushes > them > on the stack suggesting that they get registers (and that is not happened > during the assignment). I just tried it for -mcpu=power5 -mtune=power7 -maltivec: with -mvsx: 117 stfs to stack, 139 lfs from stack without -mvsx: 74 stfs to stack, 90 lfs from stack If I disable setting the cover class to VSX_REGS, I get 74/90 spills. > On one my branch, I got > -O3 -ffast-math -mcpu=power7 -mno-vsx -maltivec: 248 of stfs and lfs > -O3 -ffast-math -mcpu=power7 -mvsx -maltivec: 331 of stfs and lfs > -O3 -ffast-math -mcpu=power7 -mvsx -maltivec -fsched-pressure: 310 > -O3 -ffast-math -mcpu=power7 -mvsx -maltivec -fsched-pressure -fexper: 179 > > Where -fexper switches on a new graph coloring code without cover classes > which > I am working on. > > So I think that this new code and register pressure sensitive insn scheduling > will help. > > Still I'll investigate a bit more why there are a lot of unexpected spills > during assignment with -mvsx for the current code. Ok, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43413
[Bug tree-optimization/42286] October 23rd change to tree-ssa-pre.c breaks calculix on powerpc with -ffast-math
--- Comment #2 from meissner at linux dot vnet dot ibm dot com 2009-12-04 21:28 --- Subject: Re: October 23rd change to tree-ssa-pre.c breaks calculix on powerpc with -ffast-math On Fri, Dec 04, 2009 at 09:18:45PM -, rguenth at gcc dot gnu dot org wrote: > > > --- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-04 21:18 > --- > This change merely turns off PRE in cold code regions. So if -fno-tree-pre > breaks calculix for you I'd guess some later optimization manages to > miscompile it (my guess: the vectorizer). > > What options do you build calculix with? -m32 -O3 -mcpu=power5 -ffast-math -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42286
[Bug tree-optimization/42286] October 23rd change to tree-ssa-pre.c breaks calculix on powerpc with -ffast-math
--- Comment #4 from meissner at linux dot vnet dot ibm dot com 2009-12-07 18:37 --- Subject: Re: October 23rd change to tree-ssa-pre.c breaks calculix on powerpc with -ffast-math On Sun, Dec 06, 2009 at 01:25:15PM -, irar at il dot ibm dot com wrote: > > > --- Comment #3 from irar at il dot ibm dot com 2009-12-06 13:25 --- > On powerpc64-suse-linux with current trunk calculix failed after a couple of > minutes with > -O3 -maltivec -ffast-math > -O3 -maltivec -ffast-math -fno-tree-vectorize > -O2 -maltivec -ffast-math > -O1 -maltivec -ffast-math > > It is currently running for about an hour with > -O0 -maltivec -ffast-math I suspect you need some amount of optimization to form the negate multiply and subtract/add instruction and -O0 doesn't do the combine step. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42286
[Bug tree-optimization/42286] October 23rd change to tree-ssa-pre.c breaks calculix on powerpc with -ffast-math
--- Comment #11 from meissner at linux dot vnet dot ibm dot com 2010-01-05
18:40 ---
Subject: Re: October 23rd change to tree-ssa-pre.c breaks calculix on powerpc
with -ffast-math
On Tue, Jan 05, 2010 at 04:03:17PM -, rguenther at suse dot de wrote:
>
>
> --- Comment #9 from rguenther at suse dot de 2010-01-05 16:03 ---
> Subject: Re: October 23rd change to tree-ssa-pre.c
> breaks calculix on powerpc with -ffast-math
>
> On Tue, 5 Jan 2010, segher at kernel dot crashing dot org wrote:
>
> > --- Comment #7 from segher at kernel dot crashing dot org 2010-01-05
> > 15:57 ---
> > With -fno-signed-zeroes, a-b*c is transformed to -(b*c-a), which is a
> > machine
> > instruction. If the result would have been +0 before, it now is -0.
> > The code then takes the sqrt() of that; sqrt(-0) is -0. This then is
> > passed to atan2(), which has a discontinuity at 0, and we get wildly
> > diverging results.
> >
> > The compiler does nothing wrong here; the transformation is perfectly
> > valid.
> >
> > A solution might be to transform e.g. atan2(x,y) into atan2(+0.+x,+0.+y)
> > when -fno-signed-zeroes is in effect (and of course somehow make sure
> > those additions aren't optimised away). Similar for other math library
> > functions with discontinuities at +/- 0.
>
> Right. Just it might be simpler with -fno-signed-zeros to
> transform a-b*c to 0 + -(b*c-a). Of course if the result was -0
> before then it will be +0 after either variant (and the atan2
> discontinuity would still happen even with your fix).
>
> Thus whatever "fix" the underlying problem is surely that calculix
> is not really -fno-signed-zeros safe. Can't we get lucky again
> as before by trying to recover the PRE code change?
I've come to the conclusion that the compiler is doing the correct action in
terms fo the FMA, and that we should not remove the current optimizations.
I suspect the AMD/Intel folks will see this also when the AVX/FMA4 hardware
shows up since they also have FMA instructions that generate -0.0 in this
case. I don't recall when I was doing the old SSE5 support whether we had run
the tests through the simulator with -ffast-math or not.
However, I dunno whether there should be a -fno-signed-zeroes version of atan2
that does not give a different result for the function atan2 (-0.0, 1.0) than
for atan2 (0.0, 1.0). I know in the past, we've floated ideas about having a
fast math library that doesn't worry about Nans/negative 0/etc. Or whether
Fortran needs such a wrapper since I don't believe signed zeroes are a Fortran
concept.
For my SPEC runs, I now use the GNU ld --wrap function for atan2, and 'fix' the
negative zeroes by adding 0.0:
static double zero = 0.0;
extern double __real_atan2 (double, double);
double
__wrap_atan2 (double x, double y)
{
return __real_atan2 (x + zero, y + zero);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42286
[Bug debug/43478] Missing DW_AT_location for a variable
--- Comment #13 from meissner at linux dot vnet dot ibm dot com 2010-05-05 23:30 --- Subject: Re: Missing DW_AT_location for a variable On Wed, May 05, 2010 at 09:40:00PM -, jakub at gcc dot gnu dot org wrote: > > > --- Comment #12 from jakub at gcc dot gnu dot org 2010-05-05 21:39 > --- > Please try the PR43994 patch. I have bootstraped the powerpc64-linux compiler with this patch (c, c++, fortran languages). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43478
[Bug target/44877] C++ compiler can no longer compile dealII for VSX/Altivec vectorization
--- Comment #5 from meissner at linux dot vnet dot ibm dot com 2010-07-08 20:11 --- Subject: Re: C++ compiler can no longer compile dealII for VSX/Altivec vectorization On Thu, Jul 08, 2010 at 08:02:00PM -, jakub at gcc dot gnu dot org wrote: > > > --- Comment #3 from jakub at gcc dot gnu dot org 2010-07-08 20:01 --- > Then you should probably just > gcc_assert (POINTER_TYPE_P (TREE_TYPE (arg)); Thanks. I will update the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44877
