On Thu, 2014-10-09 at 19:50 +, Joseph S. Myers wrote:
> On Thu, 9 Oct 2014, Steve Ellcey wrote:
>
> > Do you know which pass does the simple
> > '(float)function((double)float_val)' demotion? Maybe that would be a
> > good place to extend things.
>
> convert.c does such transformations. May
Snapshot gcc-4.8-20141009 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20141009/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Oct 7, 2014, at 2:07 PM, Marek Polacek wrote:
> I'd like to kick off a discussion about moving the default standard
> for C from gnu89 to gnu11.
I endorse the change of default.
> The things I had to fix in the testsuite nicely reflect what we can expect
> in the real life:
A wiki page that
On Thu, 9 Oct 2014, Steve Ellcey wrote:
> Do you know which pass does the simple
> '(float)function((double)float_val)' demotion? Maybe that would be a
> good place to extend things.
convert.c does such transformations. Maybe the transformations in there
could move to the match-and-simplify in
On October 9, 2014 8:40:49 PM CEST, Andrew Pinski wrote:
>On Thu, Oct 9, 2014 at 11:32 AM, Steve Ellcey wrote:
>> On Thu, 2014-10-09 at 11:27 -0700, Andrew Pinski wrote:
>>
>>> > Is there a reason why GCC couldn't (under -ffast-math) call the
>single
>>> > precision routines for the first case?
>
Hi all,
I just noticed that 4.9 generates some code overhead for 386 machines
respect to 4.8.
In my test case I used 4.8.1 and 4.9.1 and realized that when compiling
with "-Os -fno-exceptions -fno-align-functions -fomit-frame-pointer"
certain things change:
On 4.9 the backend adds some "nop"
On Thu, Oct 9, 2014 at 11:32 AM, Steve Ellcey wrote:
> On Thu, 2014-10-09 at 11:27 -0700, Andrew Pinski wrote:
>
>> > Is there a reason why GCC couldn't (under -ffast-math) call the single
>> > precision routines for the first case?
>>
>> There is no reason why it could not. The reason why it doe
On Thu, 2014-10-09 at 11:27 -0700, Andrew Pinski wrote:
> > Is there a reason why GCC couldn't (under -ffast-math) call the single
> > precision routines for the first case?
>
> There is no reason why it could not. The reason why it does not
> currently is because there is no pass which does the
On Thu, Oct 9, 2014 at 11:23 AM, Steve Ellcey wrote:
> I have a -ffast-math (missing?) optimization question. I noticed on MIPS
> that if I compiled:
>
> #include
> extern x;
> void foo() { x = sin(log(x)); }
>
> GCC will extend 'x' to double precision, call the double pr
I have a -ffast-math (missing?) optimization question. I noticed on MIPS
that if I compiled:
#include
extern x;
void foo() { x = sin(log(x)); }
GCC will extend 'x' to double precision, call the double precision log and sin
functions and then truncate the result to single
On Thu, 9 Oct 2014, Marek Polacek wrote:
> On Wed, Oct 08, 2014 at 08:39:40PM -0600, Jeff Law wrote:
> > I like it. And one could reasonably argue that now is the time to change
> > since that maximizes the time for folks to find broken code.
>
> Yep, this is definitely stage1 stuff. We still h
On 10/09/2014 08:45 AM, Matthias Klose wrote:
What happened to the plans to stabilize the libstdc++ c++11 ABI? Is this still
a target for GCC 5?
Yes.
Jason
Am 08.10.2014 um 09:16 schrieb Richard Biener:
> On Tue, 7 Oct 2014, Marek Polacek wrote:
> I think it makes sense to do this (and I expect C++ will follow
> with defaulting to -std=c++11 once the ABI stuff has settled).
>
> Of course it would be nice to look at the actual fallout in
> a whole-dis
Hello!
I'd like to bring PR 63475 to the attention of RTL maintainers. The
problem in the referred PR exposed the RTL infrastructure problem,
where VALUE expressions are leaked instead of MEM expresions into
various parts of aliasing-detecting support functions.
As an example, please consider fol
On Wed, Oct 08, 2014 at 08:39:40PM -0600, Jeff Law wrote:
> I like it. And one could reasonably argue that now is the time to change
> since that maximizes the time for folks to find broken code.
Yep, this is definitely stage1 stuff. We still have a few weeks, but
I wouldn't want to rush such a
15 matches
Mail list logo
