Hi,
Since recently, I am facing several of the warnings above when building
GCC-trunk cross for RTEMS targets.
So far, not much clues about what is going on, except that I see
-Wno-narrowing were recently added to
gcc/configure.ac and libcpp/configure.ac.
Ralf
Hello Jakub,
I've talked to our engineers, who work on vectorization in ICC
They all said, "yes you can optimize vpxor out both in f1 and f2"
Thanks, K
Snapshot gcc-4.7-2005 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-2005/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Sat, Nov 5, 2011 at 2:30 PM, David Brown
> A C++ template class for "_Fract" support would be straightforward to write,
> and could easily support the formats in N1169. But it would be very hard to
> do so in a way that generates small and fast code without resorting to
> inline assembly for ta
On 05/11/11 18:29, Ed Smith-Rowland wrote:
On 11/05/2011 08:36 AM, David Brown wrote:
On 04/11/11 20:35, 3dw...@verizon.net wrote:
Greetings,
Now that C++11 user-defined literals are in trunk I was thinking
about reclaiming some of the numeric suffixes that are currently
recognized by gcc in t
On 11/05/2011 08:36 AM, David Brown wrote:
On 04/11/11 20:35, 3dw...@verizon.net wrote:
Greetings,
Now that C++11 user-defined literals are in trunk I was thinking
about reclaiming some of the numeric suffixes that are currently
recognized by gcc in the preprocessor. The C++11 spec stipulates
On 04/11/11 20:35, 3dw...@verizon.net wrote:
Greetings,
Now that C++11 user-defined literals are in trunk I was thinking
about reclaiming some of the numeric suffixes that are currently
recognized by gcc in the preprocessor. The C++11 spec stipulates
that any suffix that is recognized by the im
On Sat, Nov 05, 2011 at 08:58:18PM +1030, Alan Modra wrote:
> On Sat, Nov 05, 2011 at 10:50:44AM +0100, Jakub Jelinek wrote:
> > >From quick look, f1 isn't shrink-wrapped probably because of the set
> > of bb's that need prologue/epilogue around it doesn't end in a return,
> > but in a tail call.
On Sat, Nov 05, 2011 at 10:50:44AM +0100, Jakub Jelinek wrote:
> >From quick look, f1 isn't shrink-wrapped probably because of the set
> of bb's that need prologue/epilogue around it doesn't end in a return,
> but in a tail call. Can't we just add a prologue before the bar call
> and throw the epi
Hi!
On the following testcase with -m64 -O3 -mavx2 (but it is just an example,
you can replace the loop there with any code that doesn't touch the
stack or frame pointer at all), only f3 is shrink wrapped and in that case
it on the other side doesn't add vzeroupper before leaving the AVX using
cod
10 matches
Mail list logo
