James E Wilson wrote:
The testcase is not portable, as I pointed out in the PR. Trying this
on an x86_64-linux system, I get 27 excess errors failures. All of
them are
error: cast from 'int*' to 'int' loses precision
Using long works better than int, but is still not fool proof, as there
are
On Fri, 2005-04-01 at 00:38, Nathan Sidwell wrote:
Here it is, ok?
The patch is OK. The ChangeLog entry should refer to INTEGER_CST
instead of INT_CST.
You are missing a ChangeLog entry for the testcase.
The testcase is not portable, as I pointed out in the PR. Trying this
on an x86_64-linux
James E Wilson wrote:
The testcase is not portable, as I pointed out in the PR. Trying this
on an x86_64-linux system, I get 27 excess errors failures. All of
them are
error: cast from 'int*' to 'int' loses precision
Using long works better than int, but is still not fool proof, as there
are
James E Wilson wrote:
Nathan Sidwell wrote:
My inclination is to simply add an additional check in the dwarf
outputter,
verifying that the initializer is indeed an INT_CST.
That is a simple solution, but it causes us to lose debug info.
correct -- but we also don't output such info for
Nathan Sidwell wrote:
Bug 20505 is an ICE with -ggdb2. We have the following member
definition,
const int b::d = ((int)(((b*)1)-c) - 1);
whose initializer used to be folded during construction to an INT_CST, but
now it doesn't -- fold cannot fold the complete expression. As
My inclination is
Bug 20505 is an ICE with -ggdb2. We have the following member
definition,
const int b::d = ((int)(((b*)1)-c) - 1);
whose initializer used to be folded during construction to an INT_CST, but
now it doesn't -- fold cannot fold the complete expression. As
the PR says, this was changed by,
Nathan Sidwell wrote:
Bug 20505 is an ICE with -ggdb2. We have the following member
definition,
const int b::d = ((int)(((b*)1)-c) - 1);
whose initializer used to be folded during construction to an INT_CST, but
now it doesn't -- fold cannot fold the complete expression. As
the PR says, this
