Re: build error in libgcc

[Andreas Schwab]

Mike Stump  writes:

> A make clean followed by a make in the libgcc directory results in:
>
> ../../../../gcc/libgcc/config/i386/cpuinfo.c:23:25: fatal error: 
> auto-target.h: No such file or directory
>  #include "auto-target.h"
>
> Oh, the the old days, we'd just add a dependancy… If someone knows where to 
> add just the right one…  I ask, because there doesn't seem to be a single .h 
> dependency anywhere…

The right way is to let the compiler do it.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Compiling GCC under Cygwin

[Arjen Markus]

Hi Angelo,

well, after a somewhat bumpy start on the Cygwin list, I did get the
information I needed.
It turned out that the directories and files I had created under
Windows had the permission 000 according to Cygwin, but I could still
read the files and enter the
directories, because the Windows permissions allowed it.

However, if the build process _copied_ a file to the work directory,
it inherited the 000
permission and this time it was properly translated to the equivalent
Windows permissions.

(At least, that is my interpretation of what was going on)

I repaired the parent directory's permissions and now the build is continuing.

Regards,

Arjen


2013/6/20 Angelo Graziosi :
> Hi Arjen,
>
> Il 20/06/2013 21.41, Arjen Markus ha scritto:
>
>> I found a reference to this sort of problems in the Cygwin FAQs, but
>> this turned out to be a dead-end too.
>> So I thought, I'd try MinGW/MSYS instead.
>>
>> It started off fairly well, however:
>>
>> - For some reason the gcc compiler did not like the /d/gcc-src/...
>> path (from $srcdir) - it could not find the
>>include file gmp-h.in. So I changed that to d:/gcc-src/... And that
>> worked, until ...
>>
>> - the source file gen-fac.c was missing from the build directory for
>> gmp. So I copied the various source files
>>manually. And that worked, until ...
>>
>> - the assert.lo file was missing, which is necessary for libgmp. That
>> file is nowhere in the build directory.
>>
>> So now I am definitely stuck. I can try to contact the Gygwin people
>> and hope for the best. Or any of
>> you might know the solution wrt MinGW.
>
>
> I don't use MinGW.. so I can't help much.. I would suggest to contact
> Cygwin/MinGW people explaining your problem/system.
>
>
> Ciao,
>  Angelo.
>

Re: Compiling GCC under Cygwin

[Angelo Graziosi]

Il 21/06/2013 16.06, Arjen Markus ha scritto:

Hi Angelo,

well, after a somewhat bumpy start on the Cygwin list, I did get the
information I needed.
It turned out that the directories and files I had created under
Windows had the permission 000 according to Cygwin, but I could still
read the files and enter the
directories, because the Windows permissions allowed it.

However, if the build process _copied_ a file to the work directory,
it inherited the 000
permission and this time it was properly translated to the equivalent
Windows permissions.

(At least, that is my interpretation of what was going on)

I repaired the parent directory's permissions and now the build is continuing.



WoW! Happy build then... :-)


Ciao,
 Angelo.

GCC internal re-architecture proposal

[Andrew MacLeod]

[ I foolishly sent this with the document as an attachment... hopefully 
it gets rejected and anyone interested can simply download the document 
from the wiki..]


Over the past couple of months, I've slowly been putting together an 
action plan to help modernize GCC's source base.  We've had various 
ideas put forth over the years, and a few of the more meritorious ones 
have been incorporated.  My primary goal is to disentangle the front end 
from the middle/back ends, giving us better control over their data 
structures.


The biggest challenge is having an executable plan which allows the 
source to be updated incrementally.   Ie, we need a way to get from 
'Here' to 'There' that does not impact ongoing normal activities, nor 
noticeably affect the performance of the compiler.  This is a huge 
effort and it will require a large time commitment on my part to see it 
through.


I've attached a link to a document which outlines my proposal. Since 
putting it together, I've performed a couple of actual file conversions 
(albeit minor ones) beyond the simple examples I used in the document 
from the original proof of concept.  I've been refining some of the 
actual implementation details and logged the various design decisions 
that I encounter for later discussions  This document is a work in 
progress, and should be considered a strategic guide rather than an 
implementation bible.


There will be a BOF at Cauldron for anyone interested in discussing 
aspects of this.  I should also have a list of the interesting issues 
I've encountered for discussion there.


Im on vacation for about half the time between now and Cauldron, so I 
wanted to get this out now.  As for a time line, I wont be able to get 
seriously started on it for a couple of months since I have the C11 
_Atomic and gimple-atomic implementations to get delivered. That gives 
us a reasonable amount of time to address concerns and sort out the 
overall approach as well other nitty gritty before any serious work 
commences.Once underway, I expect there would be plenty to do for 
anyone else interesting in volunteering some time.


Here's the proposal document... happy reading! Feedback is welcome.

I hope this link will work  :-)...
http://gcc.gnu.org/wiki/AndrewMacLeod?action=AttachFile&do=view&target=gccrestructureplan2.1.odt

Highlander

Re: GCC internal re-architecture proposal

[Andrew MacLeod]

On 06/21/2013 11:27 AM, Andrew MacLeod wrote:


I hope this link will work  :-)...
http://gcc.gnu.org/wiki/AndrewMacLeod?action=AttachFile&do=view&target=gccrestructureplan2.1.odt 



Highlander

or you can use this PDF file...
http://gcc.gnu.org/wiki/AndrewMacLeod?action=AttachFile&do=view&target=gccrestructureplan2.1.pdf

Re: GCC internal re-architecture proposal

[Joseph S. Myers]

A few observations:

* You don't mention anything about separating host-side and target-side 
configuration, which are also entangled.  A slightly out-of-date list of 
target macros used in target-side code is at 
 and a clean back-end 
class would involve eliminating those (so libgcc only includes libgcc_tm.h 
and not the host-side tm.h at all).  (Various of the other things listed 
on that page were finished by Rainer, but not the target macros.)

* I don't see the advantages of separating out the host information into a 
different API.  Any particular compiler binary can only meaningfully run 
on one host, whereas in principle it should be possible to have multiple 
instances of a target class in one process so separating out the target 
interface does make sense.

* It's not clear to me what's supposed to be different about the 
target_info class compared to the existing target structure.  We "just" 
need to convert several hundred more target macros into hooks; that's the 
major work rather than any change from a global object to C++ classes or 
similar.  (The transitional conversion whereby targhooks.c contains a hook 
definition that uses a target macro is, to my mind, of very limited value 
as an end-point; such conversions need finishing by eliminating all direct 
users of the macro, then converting all back ends to define the hook 
directly, then poisoning the macro and allowing and documenting only the 
hook.)

Target macros used in front ends are indeed a good priority for converting 
to hooks.  See previous discussions (and in some cases old patches by 
Joern) of how to convert some particular cases, e.g. INT_TYPE_SIZE or 
SIZE_TYPE (roughly, it seems to make sense to have hooks covering groups 
of related macros rather than one hook per macro in all cases).

(Yes, a clean separation needs some new hook structures as well, e.g. in 
the driver, where the approach for defining the hooks would probably be 
different from the present one given how they tend to depend on the target 
OS as much as the target architecture.)

* Quite a lot of target interfaces would be used by the front ends 
specifically for defining macros for building target libraries only; see 
the "probably predefine macros if -fbuilding-libgcc in most cases" list on 
that wiki page.  (Thus, given a clean separation of target-side and 
host-side configuration, c-cppbuiltin.c is inevitably going to use a lot 
of target macros / hooks.)

* Various cases of front-end folding are to get better warnings, e.g. to 
detect that in a signed-to-unsigned conversion the converted value is in 
fact never negative.  I don't see this issue mentioned in the document.  
But maybe the GIMPLE generated by the front end should contain some form 
of note "give this warning if that condition is satisfied" and then the 
warnings would get given after some GIMPLE optimizations.

* Option handling uses a single OPT_* enumeration with options from all 
parts of the compiler; for a full clean separation, you can no longer just 
have one array of all the options generated when GCC is built, and each 
bit of the compiler would need to see just a subset of the options.

-- 
Joseph S. Myers
jos...@codesourcery.com

Register allocator question

[Hendrik Greving]

A question regarding regalloc (probably greg?)

I understand that matching constraints can constrain allocation to
re-use registers, e.g. for an 'add' actually has 2 instruction
operands (instead of 3). This is documented well. But what about if I
do not necessarily constrain the output template, e.g. zero extend
output template  %1, %0. Does the register allocator by
default assume  the machine can have %1==%0 (e.g. use edge of %0
interferes with define edge %1)? Anything else would surprise me, just
making sure?

Thanks,
Hendrik

Re: GCC internal re-architecture proposal

[Andrew MacLeod]

On 06/21/2013 12:16 PM, Joseph S. Myers wrote:

A few observations:

* You don't mention anything about separating host-side and target-side
configuration, which are also entangled.  A slightly out-of-date list of
target macros used in target-side code is at
 and a clean back-end
class would involve eliminating those (so libgcc only includes libgcc_tm.h
and not the host-side tm.h at all).  (Various of the other things listed
on that page were finished by Rainer, but not the target macros.)
yeah, I didn't go into any configuration stuff... I don't understand it 
well enough (and avoid it like the plague :-)  so that will require some 
outside assistance :-)


Thats something that can be flushed out better in the future for sure.




* I don't see the advantages of separating out the host information into a
different API.  Any particular compiler binary can only meaningfully run
on one host, whereas in principle it should be possible to have multiple
instances of a target class in one process so separating out the target
interface does make sense.
That has been brought up, and It may not be worth any effort at all.   I 
added it more for completeness and consideration for getting that 
information "all in one place".  It may well come to nothing.


* It's not clear to me what's supposed to be different about the
target_info class compared to the existing target structure.  We "just"


There may not be any difference.  The term target_info was just taken 
out of my hat. It may well be that we just extend the existing 
structure.   It just need to be flushed out fully and completed. Im not 
terribly familiar with those bits, so i didn't give it much detail :-)

need to convert several hundred more target macros into hooks; that's the
major work rather than any change from a global object to C++ classes or
similar.  (The transitional conversion whereby targhooks.c contains a hook
definition that uses a target macro is, to my mind, of very limited value
as an end-point; such conversions need finishing by eliminating all direct
users of the macro, then converting all back ends to define the hook
directly, then poisoning the macro and allowing and documenting only the
hook.)

I think that sounds like a most reasonable way to proceed.


Target macros used in front ends are indeed a good priority for converting
to hooks.  See previous discussions (and in some cases old patches by
Joern) of how to convert some particular cases, e.g. INT_TYPE_SIZE or
SIZE_TYPE (roughly, it seems to make sense to have hooks covering groups
of related macros rather than one hook per macro in all cases).
indeed, thats exactly the sort of low-hanging simplifications I was 
thinking about, and I'm sure there will be others




* Quite a lot of target interfaces would be used by the front ends
specifically for defining macros for building target libraries only; see
the "probably predefine macros if -fbuilding-libgcc in most cases" list on
that wiki page.  (Thus, given a clean separation of target-side and
host-side configuration, c-cppbuiltin.c is inevitably going to use a lot
of target macros / hooks.)
If thats where most of it lies, maybe there is some way to "push" some 
of that activity into the backend?...   I'll investigate c-cppbuiltin.c 
at some point when I get some time.   "Heavy" consumers like that would 
show up after the initial conversion stages and we can consider how to 
improve it.




* Various cases of front-end folding are to get better warnings, e.g. to
detect that in a signed-to-unsigned conversion the converted value is in
fact never negative.  I don't see this issue mentioned in the document.
But maybe the GIMPLE generated by the front end should contain some form
of note "give this warning if that condition is satisfied" and then the
warnings would get given after some GIMPLE optimizations.


Indeed, a previous incarnation of the document took that idea to further 
extremes, but that also sounds highly reasonable.   The gimple fodler 
may be able to issue those sorts of warnings as it "optimizes" by 
folding.   I'll add something back in about that.


* Option handling uses a single OPT_* enumeration with options from all
parts of the compiler; for a full clean separation, you can no longer just
have one array of all the options generated when GCC is built, and each
bit of the compiler would need to see just a subset of the options.


Good observation, I'll add something about that too.

Thanks!

Andrew

Re: GCC internal re-architecture proposal

[Eric Botcazou]

> * Various cases of front-end folding are to get better warnings, e.g. to
> detect that in a signed-to-unsigned conversion the converted value is in
> fact never negative.  I don't see this issue mentioned in the document.

Tree front-end folding, or more precisely folding of expressions generated for 
types, is required when types with variable size are first-class citizens like 
in Ada.  In practice, something even more powerful is required, i.e. outlining 
(called from stor-layout.c:variable_size) and back-inlining of the expressions 
(tree-inline.c:maybe_inline_call_in_expr), if you want to be able to compile 
big codebases with a reasonable amount of resources.

-- 
Eric Botcazou

Re: Register allocator question

[Ian Lance Taylor]

On Fri, Jun 21, 2013 at 9:22 AM, Hendrik Greving
 wrote:
> A question regarding regalloc (probably greg?)
>
> I understand that matching constraints can constrain allocation to
> re-use registers, e.g. for an 'add' actually has 2 instruction
> operands (instead of 3). This is documented well. But what about if I
> do not necessarily constrain the output template, e.g. zero extend
> output template  %1, %0. Does the register allocator by
> default assume  the machine can have %1==%0 (e.g. use edge of %0
> interferes with define edge %1)? Anything else would surprise me, just
> making sure?

If you don't use constraints such as & to say that %1 and %0 can not
be in the same register, then they can be.

By the way, you do know that this has all changed in current mainline, right?

Ian

Re: build error in libgcc

[Ian Lance Taylor]

On Thu, Jun 20, 2013 at 6:25 PM, Mike Stump  wrote:
> A make clean followed by a make in the libgcc directory results in:
>
> ../../../../gcc/libgcc/config/i386/cpuinfo.c:23:25: fatal error: 
> auto-target.h: No such file or directory
>  #include "auto-target.h"
>
> Oh, the the old days, we'd just add a dependancy… If someone knows where to 
> add just the right one…  I ask, because there doesn't seem to be a single .h 
> dependency anywhere…

auto-target.h is created by the configure script.

It's a bug that it is removed by "make clean".  It should only be
removed by "make distclean".

Ian

Re: build error in libgcc

[Chung-Ju Wu]

2013/6/22 Ian Lance Taylor :
> On Thu, Jun 20, 2013 at 6:25 PM, Mike Stump  wrote:
>> A make clean followed by a make in the libgcc directory results in:
>>
>> ../../../../gcc/libgcc/config/i386/cpuinfo.c:23:25: fatal error: 
>> auto-target.h: No such file or directory
>>  #include "auto-target.h"
>>
>> Oh, the the old days, we'd just add a dependancy… If someone knows where to 
>> add just the right one…  I ask, because there doesn't seem to be a single .h 
>> dependency anywhere…
>
> auto-target.h is created by the configure script.
>
> It's a bug that it is removed by "make clean".  It should only be
> removed by "make distclean".
>
> Ian

Well... in that case, how about this patch??

Index: libgcc/Makefile.in
===
--- libgcc/Makefile.in  (revision 200306)
+++ libgcc/Makefile.in  (working copy)
@@ -121,7 +121,7 @@
 .PHONY: all clean

 clean:
-   -rm -f auto-target.h libgcc_tm.h libgcc.map
+   -rm -f libgcc_tm.h libgcc.map
-rm -f libgcc_tm.stamp stamp-h stmp-ldirs
-rm -f *$(objext)
-rm -f *.dep
@@ -131,6 +131,7 @@
@$(MULTICLEAN) multi-clean DO=clean
 distclean: clean
@$(MULTICLEAN) multi-clean DO=distclean
+   -rm -f auto-target.h
-rm -f *~ Makefile config.cache config.status multilib.out
-rm -f config.log
 maintainer-clean realclean: distclean


Hi, Mike, would you try it to see if it fixes the problem?
If it does, I will post the patch on gcc-patc...@gcc.gnu.org
to acquire Ian's approval. :)


Best regards,
jasonwucj

Re: build error in libgcc

[Andreas Schwab]

Chung-Ju Wu  writes:

>  clean:
> -   -rm -f auto-target.h libgcc_tm.h libgcc.map
> +   -rm -f libgcc_tm.h libgcc.map
> -rm -f libgcc_tm.stamp stamp-h stmp-ldirs

Same for stamp-h.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."