Heads-Up: early LTO debug to land, breaking Mach-O / [X]COFF
This is a heads-up that I am in the process of implementing the last of Jasons review comments on the dwarf2out parts of early LTO debug support. I hope to post final patches early next week after thoroughly re-testing everything. Note that Mach-O and [X]COFF support in the simple-object machinery is still missing for the early LTO debug feature so I am going to break LTOing with DWARF debuginfo on Darwin and Windows (CCing maintainers). Mach-O support has been worked on a bit by Iain and myself but the simple-object piece is still missing. A workaround is to use stabs on these targets with LTO. DWARF part: https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01023.html simple-object part: https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01733.html both still apply with some fuzz. Richard.
Re: Heads-Up: early LTO debug to land, breaking Mach-O / [X]COFF
On 05/12/2017 09:24 AM, Richard Biener wrote: > > This is a heads-up that I am in the process of implementing the last > of Jasons review comments on the dwarf2out parts of early LTO debug > support. I hope to post final patches early next week after thoroughly > re-testing everything. > > Note that Mach-O and [X]COFF support in the simple-object machinery > is still missing for the early LTO debug feature so I am going to > break LTOing with DWARF debuginfo on Darwin and Windows (CCing > maintainers). Mach-O support has been worked on a bit by Iain > and myself but the simple-object piece is still missing. > A workaround is to use stabs on these targets with LTO. > > DWARF part: https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01023.html > simple-object part: > https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01733.html > > both still apply with some fuzz. > > Richard. > AFAIK, LTO doesn't work well on Windows to begin with, if non-LTO modes are unaffected, I have no issues with this. signature.asc Description: OpenPGP digital signature
Re: Heads-Up: early LTO debug to land, breaking Mach-O / [X]COFF
Hi Richard, > On 12 May 2017, at 10:24, Richard Biener wrote: > > > This is a heads-up that I am in the process of implementing the last > of Jasons review comments on the dwarf2out parts of early LTO debug > support. I hope to post final patches early next week after thoroughly > re-testing everything. > > Note that Mach-O and [X]COFF support in the simple-object machinery > is still missing for the early LTO debug feature so I am going to > break LTOing with DWARF debuginfo on Darwin and Windows (CCing > maintainers). Mach-O support has been worked on a bit by Iain > and myself but the simple-object piece is still missing. Still on my TODO, and intending to do it for Mach-O - but rather short of cycles (if non-LTO is unaffected at least we have some breathing space). > A workaround is to use stabs on these targets with LTO. stabs isn’t going to work (well, if at all) on modern Darwin... > DWARF part: https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01023.html > simple-object part: > https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01733.html > > both still apply with some fuzz. I have a branch somewhere, will rebase - I’ve been getting stuff up to speed this week, Iain
Install GCC guide
Hi, The installing GCC guide contains a paragraph that says 'If you also intend to build binutils (either to upgrade an existing installation or for use in place of the corresponding tools of your OS), unpack the binutils distribution either in the same directory or a separate one.' Bu according to bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80719, unpacking a binutils source release within a GCC source release may not be a good idea. Problem with building GCC is that if you do not, you end up with a missing libiberty. So to summarize, the install guide does not work as-is Joris
Re: Install GCC guide
On 12 May 2017 at 14:03, joris wrote: > Hi, > > The installing GCC guide contains a paragraph that says 'If you also intend > to build binutils (either to upgrade an existing installation or for use in > place of the corresponding tools of your OS), unpack the binutils > distribution either in the same directory or a separate one.' > > Bu according to bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80719, > unpacking a binutils source release within a GCC source release may not be a > good idea. > > Problem with building GCC is that if you do not, you end up with a missing > libiberty. I can't parse this sentence. If you do not what? Build binutils at the same time? It's certainly not true that you get a missing libiberty if you don't build binutils at the same time.
Re: Install GCC guide
On 12 May 2017 at 15:05, Jonathan Wakely wrote: > On 12 May 2017 at 14:03, joris wrote: >> Hi, >> >> The installing GCC guide contains a paragraph that says 'If you also intend >> to build binutils (either to upgrade an existing installation or for use in >> place of the corresponding tools of your OS), unpack the binutils >> distribution either in the same directory or a separate one.' >> >> Bu according to bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80719, >> unpacking a binutils source release within a GCC source release may not be a >> good idea. >> >> Problem with building GCC is that if you do not, you end up with a missing >> libiberty. > > I can't parse this sentence. If you do not what? Build binutils at the > same time? > > It's certainly not true that you get a missing libiberty if you don't > build binutils at the same time. Please reply to the mailing list not just to me, I'm not interested in having a private conversation. What Jakub said is that you need to ensure the common parts of the two trees are the same (sometimes that is true if you use a gcc release and a binutils release that are very similar ages, but more often it doesn't). If you don't want to have to do that, just build them separately. We could update https://gcc.gnu.org/install/download.html to clarify this, as I agree it doesn't mention the caveats.
Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates
On 05/10/2017 04:14 PM, Daniel Santos wrote:
On 05/10/2017 04:24 AM, Jonathan Wakely wrote:
Just because there's already one way to do something doesn't mean
better ways to do it are bad.
I'm only speaking out of jealousy being that most of my recent work has
been in C.
hadn't gone so far as to investigate using this new attribute on
functions
since we already have __attribute__((const)). I haven't used this
before so
maybe I'm not aware of something that makes it unusable for such cases?
Which of course raises the question if __attribute__((const)) would
work out
since it's only currently used on function declarations (and pointers to
function declarations, but I don't fully understand what that is
doing in
handle_const_attribute).
__attribute__((const)) is not a substitute for constexpr, it's not
even in the same ballpark. It says the function doesn't touch global
memory, it doesn't mean its return value is a constant expression, so
you can't do:
int f() __attribute__((const));
int f() { return 1; }
int i[f()];
I don't think __attribute__((const)) is useful for your goal.
Well my primary goal is programming with values that are constant in the
compiler. There is no language in any C specification (that I'm aware
of) for a "compile-time constant", but the concept is very important.
So just because some expression is a compile-time constant doesn't mean
we morph into a "constant expression" (as per the spec), even with
__attribute__((const)).
The C committee has discussed extending the set of expressions
that are considered constant in C2X. A proposal was submitted
last year that, at least in spirit, gained pretty broad support
(the finer details, including the syntax, especially the reuse
of the register keyword, are likely to evolve):
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2067.pdf
The C committee's charter for C2X is to increase compatibility
with C++, so new language features with that effect have a good
chance of being considered.
I don't expect C2X to go as far as to add something as complex
as templates but some on the committee are working on enhancing
support for generic programming (via _Generic). Interestingly,
C11 (by accident) introduced a requirement for implementations
to support true type genericity in the form of the C11 atomic
APIs. It may not be too far out there to propose to generalize
the underlying machinery and make it available to programs (as
opposed to just the standard library alone).
Martin
Duplicating loops and virtual phis
(Short version of this email, is there a way to recalculate/rebuild virtual
phi nodes after modifying the CFG.)
I have a question about duplicating loops and virtual phi nodes.
I am trying to implement the following optimization as a pass:
Transform:
for (i = 0; i < n; i++) {
A[i] = A[i] + B[i];
C[i] = C[i-1] + D[i];
}
Into:
if (noalias between A&B, A&C, A&D)
for (i = 0; i < 100; i++)
A[i] = A[i] + B[i];
for (i = 0; i < 100; i++)
C[i] = C[i-1] + D[i];
else
for (i = 0; i < 100; i++) {
A[i] = A[i] + B[i];
C[i] = C[i-1] + D[i];
}
Right now the vectorizer sees that 'C[i] = C[i-1] + D[i];' cannot be
vectorized so it gives up and does not vectorize the loop. If we split
up the loop into two loops then the vector add with A[i] could be vectorized
even if the one with C[i] could not.
Currently I can introduce the first 'if' that checks for aliasing by
using loop_version() and that seems to work OK. (My actual compare
for aliasing is actually just an approximation for now.)
Where I am running into problems is with splitting up the single loop
under the noalias if condition into two sequential loops (which I then
intend to 'thin out' by removing one or the other set of instructions.
I am using slpeel_tree_duplicate_loop_to_edge_cfg() for that loop duplication
and while I get the CFG I want, the pass ends with verify_ssa failing due
to bad virtual/MEM PHI nodes. Perhaps there is a different function that
I should use duplicate the loop.
a.c: In function âfooâ:
a.c:2:5: error: PHI node with wrong VUSE on edge from BB 13
int foo(int *a, int *b, int *c, int *d, int n)
^~~
.MEM_40 = PHI <.MEM_15(D)(13), .MEM_34(9)>
expected .MEM_58
a.c:2:5: internal compiler error: verify_ssa failed
I have tried to fix up the PHI node by hand using SET_PHI_ARG_DEF but
have not had any luck. I was wondering if there was any kind of
'update all the phi nodes' function or just a 'update the virtual phi
nodes' function. The non-virtual PHI nodes seem to be OK, it is just
the virtual ones that seem wrong after I duplicate the loop into two
consecutive loops.
Steve Ellcey
sell...@cavium.com
Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates
Sorry for my delayed response.
On 05/11/2017 09:35 AM, Joseph Myers wrote:
On Thu, 11 May 2017, Jonathan Wakely wrote:
On 10 May 2017 at 23:14, Daniel Santos wrote:
Well my primary goal is programming with values that are constant in the
compiler. There is no language in any C specification (that I'm aware of)
for a "compile-time constant", but the concept is very important. So just
because some expression is a compile-time constant doesn't mean we morph
into a "constant expression" (as per the spec), even with
__attribute__((const)).
The C standard says "An implementation may accept other forms of
constant expressions." That means rather than inventing some
"constprop" you could just extend GCC to treat more expressions
involving constants as constant-expressions.
I would rather not invent terms either. In regards to the proposed attribute name, I'm leaning towards re-using
"const" instead of adding "constprop" because it seems to fall in line with the original purpose of
the attribute while and there doesn't appear to be any overlap between what it currently applies to and what I would
like to add the attribute to. But from a conceptual standpoint, I believe the term "constant-expression"
would be incorrect because the C standard defines this constraint: (6.6.3 of C11) "Constant expressions shall not
contain assignment, increment, decrement, function-call, or comma operators, except when they are contained within a
subexpression that is not evaluated." I definitely do need to study the C specs more carefully to make sure I
fully understand how this is used and how it's changed over different revisions of the spec.
But from what I've done so far, I can tell that around 80-90% of what I hope to
achieve will be through simply improving GCC's ability to to constant propagate
(I'm focusing on one issue right now where it appears that early SRA might be
throwing off later constant propagation).
Note that while "other forms" might be accepted in initializers, they
would still not be integer constant expressions (see DR#312).
What is DR#312?
I should probably be more careful and explicit in my language. I was
thinking particularly of integer constant expressions that are required
for the size of non-variable length arrays, bitfields, and such.
If only for the sake of entertainment, there *is* actually a legitimate
way to transform an expression into an integer constant expression and
even an integer constant, but is only practical when the range of
possible values is limited.
#define foo (i) /* Do something here. */
#define bar (expr) \
do { \
ASSERT_CONST (expr); \
switch (expr) {\
case 1: foo(1); break; \
case 2: foo(2); break; \
case 4: foo(4); break; \
case 8: foo(8); break; \
case 16: foo(16); break; \
case 32: foo(32); break; \
case 64: foo(64); break; \
case 128: foo(128); break; \
case 256: foo(256); break; \
default: \
ASSERT (0); \
}\
} while (0)
Daniel
Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates
On Fri, 12 May 2017, Daniel Santos wrote: > > Note that while "other forms" might be accepted in initializers, they > > would still not be integer constant expressions (see DR#312). > > What is DR#312? http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_312.htm (but cf the older http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_032.html against C90). -- Joseph S. Myers jos...@codesourcery.com
Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates
On 05/12/2017 10:49 AM, Martin Sebor wrote: On 05/10/2017 04:14 PM, Daniel Santos wrote: Well my primary goal is programming with values that are constant in the compiler. There is no language in any C specification (that I'm aware of) for a "compile-time constant", but the concept is very important. So just because some expression is a compile-time constant doesn't mean we morph into a "constant expression" (as per the spec), even with __attribute__((const)). The C committee has discussed extending the set of expressions that are considered constant in C2X. A proposal was submitted last year that, at least in spirit, gained pretty broad support (the finer details, including the syntax, especially the reuse of the register keyword, are likely to evolve): http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2067.pdf The C committee's charter for C2X is to increase compatibility with C++, so new language features with that effect have a good chance of being considered. I don't expect C2X to go as far as to add something as complex as templates but some on the committee are working on enhancing support for generic programming (via _Generic). Interestingly, C11 (by accident) introduced a requirement for implementations to support true type genericity in the form of the C11 atomic APIs. It may not be too far out there to propose to generalize the underlying machinery and make it available to programs (as opposed to just the standard library alone). Martin Thank you for this! It sounds like I need to read up on what is in the works with the C committee and maybe prepare my own proposal and become involved. I see the monetary cost of not having generic support as very high -- you end up with more boiler-plate code that has to be maintained, thus increasing development time and the chance for bugs. It also takes more time to analyze the code, diagnose problems and get new programmers up to speed. Thanks, Daniel
Re: Install GCC guide
Hi, I redid the build without touching binutils ( is installed on the system), then it works OK. The issue is when you follow the install guide's suggestion to unpack binutils within the source tree. So indeed the issue is with the doc. Once you start moving dirs from binutils to gcc tree and configure, things go wrong, and keep going wrong if you try to undo. Building binutils on its own, separately works ok as well. Joris On 13/05/17 00:05, Jonathan Wakely wrote: On 12 May 2017 at 14:03, joris wrote: Hi, The installing GCC guide contains a paragraph that says 'If you also intend to build binutils (either to upgrade an existing installation or for use in place of the corresponding tools of your OS), unpack the binutils distribution either in the same directory or a separate one.' Bu according to bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80719, unpacking a binutils source release within a GCC source release may not be a good idea. Problem with building GCC is that if you do not, you end up with a missing libiberty. I can't parse this sentence. If you do not what? Build binutils at the same time? It's certainly not true that you get a missing libiberty if you don't build binutils at the same time.
Re: Duplicating loops and virtual phis
On May 12, 2017 10:42:34 PM GMT+02:00, Steve Ellcey wrote:
>(Short version of this email, is there a way to recalculate/rebuild
>virtual
>phi nodes after modifying the CFG.)
>
>I have a question about duplicating loops and virtual phi nodes.
>I am trying to implement the following optimization as a pass:
>
>Transform:
>
> for (i = 0; i < n; i++) {
> A[i] = A[i] + B[i];
> C[i] = C[i-1] + D[i];
> }
>
>Into:
>
> if (noalias between A&B, A&C, A&D)
> for (i = 0; i < 100; i++)
> A[i] = A[i] + B[i];
> for (i = 0; i < 100; i++)
> C[i] = C[i-1] + D[i];
> else
> for (i = 0; i < 100; i++) {
> A[i] = A[i] + B[i];
> C[i] = C[i-1] + D[i];
> }
>
>Right now the vectorizer sees that 'C[i] = C[i-1] + D[i];' cannot be
>vectorized so it gives up and does not vectorize the loop. If we split
>up the loop into two loops then the vector add with A[i] could be
>vectorized
>even if the one with C[i] could not.
Loop distribution does this transform but it doesn't know about versioning for
unknown dependences.
>Currently I can introduce the first 'if' that checks for aliasing by
>using loop_version() and that seems to work OK. (My actual compare
>for aliasing is actually just an approximation for now.)
>
>Where I am running into problems is with splitting up the single loop
>under the noalias if condition into two sequential loops (which I then
>intend to 'thin out' by removing one or the other set of instructions.
>I am using slpeel_tree_duplicate_loop_to_edge_cfg() for that loop
>duplication
>and while I get the CFG I want, the pass ends with verify_ssa failing
>due
>to bad virtual/MEM PHI nodes. Perhaps there is a different function
>that
>I should use duplicate the loop.
>a.c: In function ���foo���:
>a.c:2:5: error: PHI node with wrong VUSE on edge from BB 13
> int foo(int *a, int *b, int *c, int *d, int n)
> ^~~
>.MEM_40 = PHI <.MEM_15(D)(13), .MEM_34(9)>
>expected .MEM_58
>a.c:2:5: internal compiler error: verify_ssa failed
>
>I have tried to fix up the PHI node by hand using SET_PHI_ARG_DEF but
>have not had any luck. I was wondering if there was any kind of
>'update all the phi nodes' function or just a 'update the virtual phi
>nodes' function. The non-virtual PHI nodes seem to be OK, it is just
>the virtual ones that seem wrong after I duplicate the loop into two
>consecutive loops.
>
>Steve Ellcey
>sell...@cavium.com
