On 10/18/2013 12:55 PM, Jeff Law wrote:
On 10/18/13 08:00, Andrew MacLeod wrote:
The question is... Do we allow a .h file like this to be an aggregator,
meaning a file can just include tree-ssa.h and get all this, or do we
push it all down to the .c file, and actually include what each one
nee
On 10/18/13 08:00, Andrew MacLeod wrote:
The tree-flow.h restructuring now brings us to the larger question of
exactly how we want includes organized. All the remaining includes in
tree-ssa.h are required by numerous other .c files. The actual number of
.c files which will need to #include any g
Kenneth Zadeck writes:
> I am a little confused here.what is the reason for doing the the
> is_sign_extended thing?
> is the point of deferring the canonization that we can avoid the use of
> the scratch array until the value is actually used. then we
> canonicalize on demand?
The idea i
Kenneth Zadeck wrote:
>I am a little confused here.what is the reason for doing the the
>is_sign_extended thing?
>is the point of deferring the canonization that we can avoid the use of
>
>the scratch array until the value is actually used. then we
>canonicalize on demand?
Yes.
>That see
I am a little confused here.what is the reason for doing the the
is_sign_extended thing?
is the point of deferring the canonization that we can avoid the use of
the scratch array until the value is actually used. then we
canonicalize on demand?
That seems like it is going to require seve
Hi,
these FAILs:
FAIL: g++.dg/guality/pr55665.C -O2 line 23 p == 40
FAIL: g++.dg/guality/pr55665.C -O3 -fomit-frame-pointer line 23 p == 40
FAIL: g++.dg/guality/pr55665.C -O3 -g line 23 p == 40
apparently are here to stay, at least on x86_64-linux... Seriusly, do we
know what's going on?
The tree-flow.h restructuring now brings us to the larger question of
exactly how we want includes organized. All the remaining includes in
tree-ssa.h are required by numerous other .c files. The actual number of
.c files which will need to #include any given file is:
(roughly calculated by t
On Tue, Oct 15, 2013 at 02:03:48PM +0400, Kirill Yukhin wrote:
> Let me somewhat summarize current understanding of
> host binary linking as well as target binary building/linking.
>
> We put code which supposed to be offloaded to dedicated sections,
> with name starting with gnu.target_lto_
>
>
