(会社に)残ると決めて(新事業部に)行くのだから、二倍危ういってことだな。
Snapshot gcc-5-20150929 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/5-20150929/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5
On September 29, 2015 9:27:13 PM GMT+02:00, fxcoud...@gmail.com wrote:
>It cannot be done in the front-end, but has to happen during value
>propagation in the middle-end. But the middle-end only handles known
>*_EXPR and built-ins. So this would require adding either a POWINT_EXPR
>or a type-generi
It cannot be done in the front-end, but has to happen during value propagation
in the middle-end. But the middle-end only handles known *_EXPR and built-ins.
So this would require adding either a POWINT_EXPR or a type-generic
__builtin_powint. No small task.
I think there is already a PR for th
Hi Steve,
subroutine foo(n)
integer n
integer i, j
i = 2
j = 4
n = i**j ! <-- This should evaluate to 16 without a function call.
end subroutine foo
To do this in the Fortran front end would require constant propagation,
which we currently do not do.
We do not
There appears to be a missed opportunity to optimize
away exponential operators. I suspect that this
falls under gfortrani's frontend-optimize option, but
it may also be a middle-end issue.
Consider,
subroutine foo(n)
integer n
integer i, j
i = 2
j = 4
n = i**j ! <-- Th
On 25/09/15 21:16, Eric Botcazou wrote:
First, a belated follow-up to https://gcc.gnu.org/PR66512 . The bug is
asking why attribute-const appears to have a weaker effect in C++, compared
to C. The answer in that bug is that GCC assumes that attribute-const
function can terminate by throwing an ex
