Re: Anyone/anything still using CVS on gcc.gnu.org?
"Dave Korn" <[EMAIL PROTECTED]> writes: > It's pretty obvious the moment you read the content of any of the posts > that it can't be cvs and has to be svn, even more so if you follow one of > the viewvc links... but it couldn't hurt to make it explicit, I'm sure. FWIW, the links still use the viewcvs URL, btw. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Anyone/anything still using CVS on gcc.gnu.org?
Patches welcome :) On Tue, Jul 22, 2008 at 3:55 AM, Andreas Schwab <[EMAIL PROTECTED]> wrote: > "Dave Korn" <[EMAIL PROTECTED]> writes: > >> It's pretty obvious the moment you read the content of any of the posts >> that it can't be cvs and has to be svn, even more so if you follow one of >> the viewvc links... but it couldn't hurt to make it explicit, I'm sure. > > FWIW, the links still use the viewcvs URL, btw. > > Andreas. > > -- > Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] > SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany > PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 > "And now for something completely different." >
Re: [Ada] multilib patch take two => multilib build working
I had to solve one rts source issue though:
gcc/ada/system-linux-x86_64.ads and x86.ads do hardcode the number of
bits for a word (64 and 32 respectively), I changed them both to be
completely the same and use GNAT defined Standard'Word_Size attribute.
- Word_Size: constant := 64;
- Memory_Size : constant := 2 ** 64;
+ Word_Size: constant := Standard'Word_Size;
+ Memory_Size : constant := 2 ** Word_Size;
The same change will have to be done on other 32/64 bits Ada targets. I
don't know if this change has adverse effect on GNAT build in some
situations.
I think this is worthwhile on its own, before the build patch goes in.
The patch is not complete yet of course but I'd appreciate feedback on
wether or not I'm on the right track for 4.4 inclusion.
It looks good to me, though I'll defer to Arnaud and other adacore people.
One nit:
+GNATLIBMULTI := $(subst /,,$(MULTISUBDIR))
Please substitute / with _ instead, to avoid unlikely but possible clashes.
[EMAIL PROTECTED]:~/tmp$ gnatmake -f -g
-aO/home/guerby/build-mlib7/gcc/ada/rts32 -m32 p
I guess this fixing this requires duplicating in gnatmake and gnatbind
the logic in gcc.c that uses the info produced by genmultilib. Search
gcc.c for
multilib_raw
multilib_matches_raw
multilib_extra
multilib_exclusions_raw
multilib_options
set_multilib_dir
Maybe it makes sense to make a separate .c module for this, so that both
the driver and gnat{make,bind} can use it.
I'm not sure how much churn is there in gcc/ada/Makefile.in. If there
is little, it probably makes more sense to work on a branch. If there
is much, it probably makes more sense to commit the partially working
patch. Again, I'll defer to AdaCore people on this.
Paolo
Re: [Ada] multilib patch take two => multilib build working
Paolo Bonzini <[EMAIL PROTECTED]>: > I'm not sure how much churn is there in gcc/ada/Makefile.in. If there > is little, it probably makes more sense to work on a branch. If there > is much, it probably makes more sense to commit the partially working > patch. Again, I'll defer to AdaCore people on this. I can propose the purely mechanical rts => $(RTSDIR), stamp => stamp-$(RTSDIR) patch separately, it has no visible effect and is much of the otherwise small diff. (It already allows to build multiple rts easily from the command line in the build tree which might be useful on its own.) Arnaud, would that be okay for you? Thanks in advance, Laurent
Re: [Ada] multilib patch take two => multilib build working
>> I had to solve one rts source issue though: >> gcc/ada/system-linux-x86_64.ads and x86.ads do hardcode the number of >> bits for a word (64 and 32 respectively), I changed them both to be >> completely the same and use GNAT defined Standard'Word_Size attribute. >> >> - Word_Size: constant := 64; >> - Memory_Size : constant := 2 ** 64; >> + Word_Size: constant := Standard'Word_Size; >> + Memory_Size : constant := 2 ** Word_Size; >> >> The same change will have to be done on other 32/64 bits Ada targets. I >> don't know if this change has adverse effect on GNAT build in some >> situations. > > I think this is worthwhile on its own, before the build patch goes in. Not clear to me actually. The idea currently is to make these values explicit so that when people read system.ads, they know right away what the right value is. Also, this points to a real flaw in the approach, since e.g. in case of little/big endian multilibs, similar issue would arise. And, system.ads is only the tip of the iceberg: if you do not get system.ads right, it means that potentially a complete wrong set of sources will be used to build the run-time, since there can be an arbitrary number of target dependent units as defined by LIBGNAT_PAIRS, and indeed, looking at the target pairs for x86 and x86-64, these are quite different, so we need to find a mechanism to properly select the right pair when using multilib. > It looks good to me, though I'll defer to Arnaud and other adacore people. It seems that a branch would be more appropriate for this kind of work, since there's a long way to go before getting in reasonable shape. Also, it's not clear how using $(RTS) for building gnattools will work properly. >> [EMAIL PROTECTED]:~/tmp$ gnatmake -f -g >> -aO/home/guerby/build-mlib7/gcc/ada/rts32 -m32 p There's an existing mechanism in gnatmake which is the use of the --RTS switch, so ideally it would be great to match multilib install into --RTS=xxx compatible dirs, and also have -xxx (e.g. -32 or -64) imply --RTS=xxx. Arno
Re: [Ada] multilib patch take two => multilib build working
Arnaud Charlet wrote: I had to solve one rts source issue though: gcc/ada/system-linux-x86_64.ads and x86.ads do hardcode the number of bits for a word (64 and 32 respectively), I changed them both to be completely the same and use GNAT defined Standard'Word_Size attribute. - Word_Size: constant := 64; - Memory_Size : constant := 2 ** 64; + Word_Size: constant := Standard'Word_Size; + Memory_Size : constant := 2 ** Word_Size; The same change will have to be done on other 32/64 bits Ada targets. I don't know if this change has adverse effect on GNAT build in some situations. I think this is worthwhile on its own, before the build patch goes in. Not clear to me actually. The idea currently is to make these values explicit so that when people read system.ads, they know right away what the right value is. Also, this points to a real flaw in the approach, since e.g. in case of little/big endian multilibs, similar issue would arise. Yes, if different multilibs should use different sets of sources, we have a problem. On the other hand, this is also something that can be solved by moving the RTS to libada. The standard approach with C multilibs is to rely on configure tests, or on #define constants, to pick the appropriate choice between multilibs, and I don't see why this shouldn't work with Ada. For example, g-soccon* files are generated automatically -- then, why not go one step further and generate a g-soccon file at configure time? It seems that a branch would be more appropriate for this kind of work, since there's a long way to go before getting in reasonable shape. Given the above, I agree. Also, it's not clear how using $(RTS) for building gnattools will work properly. Only target modules are multilibbed, so only one copy of gnattools is built. I assume that the characteristics of the target do not affect the operation of gnattools -- different multilibs may use different filesystem paths and thus behave differently, but the *code* of gnattools should be the same in all cases. [EMAIL PROTECTED]:~/tmp$ gnatmake -f -g -aO/home/guerby/build-mlib7/gcc/ada/rts32 -m32 p There's an existing mechanism in gnatmake which is the use of the --RTS switch, so ideally it would be great to match multilib install into --RTS=xxx compatible dirs, and also have -xxx (e.g. -32 or -64) imply --RTS=xxx. Yes, you would basically take from gcc.c the code that turns "-m32" into "use multilib 32", and use it to make a --RTS option. Paolo
Re: [Ada] multilib patch take two => multilib build working
Selon Arnaud Charlet <[EMAIL PROTECTED]>: > >> I had to solve one rts source issue though: > >> gcc/ada/system-linux-x86_64.ads and x86.ads do hardcode the number of > >> bits for a word (64 and 32 respectively), I changed them both to be > >> completely the same and use GNAT defined Standard'Word_Size attribute. > >> > >> - Word_Size: constant := 64; > >> - Memory_Size : constant := 2 ** 64; > >> + Word_Size: constant := Standard'Word_Size; > >> + Memory_Size : constant := 2 ** Word_Size; > >> > >> The same change will have to be done on other 32/64 bits Ada targets. I > >> don't know if this change has adverse effect on GNAT build in some > >> situations. > > > > I think this is worthwhile on its own, before the build patch goes in. > > Not clear to me actually. The idea currently is to make these values > explicit so that when people read system.ads, they know right away what > the right value is. They can still read the wrong system.ads in case of multiple rts installed, the only way to be sure is to use gcc -c -gnatdg with your flags on your source :). > Also, this points to a real flaw in the approach, since e.g. in case > of little/big endian multilibs, similar issue would arise. > > And, system.ads is only the tip of the iceberg: if you do not get system.ads > right, it means that potentially a complete wrong set of sources will be > used to build the run-time, since there can be an arbitrary number of > target dependent units as defined by LIBGNAT_PAIRS, and indeed, looking > at the target pairs for x86 and x86-64, these are quite different, so we > need to find a mechanism to properly select the right pair when using > multilib. This will need some additionals tests on MULTILIB in the LIBGNAT_TARGET_PAIRS machinery (3 files for x86 vs x86_64, solaris looks like already done, powerpc seem 32 bits only right now, s390/s390x, others?) but it doesn't seem like a blocking issue with the proposed design since each MULTILIB rts build has completely separate directory and stamp (through RTSDIR) so there is no possibility of conflict through sharing. Do you agree with this assessment? If so I'll propose an update patch. Thanks in advance, Laurent
Re: [Ada] multilib patch take two => multilib build working
> They can still read the wrong system.ads in case of multiple rts installed, > the > only way to be sure is to use gcc -c -gnatdg with your flags on your source > :). Not if they are using a proper IDE :-) > This will need some additionals tests on MULTILIB in the LIBGNAT_TARGET_PAIRS > machinery (3 files for x86 vs x86_64, solaris looks like already done, powerpc > seem 32 bits only right now, s390/s390x, others?) but it doesn't seem like a > blocking issue with the proposed design since each MULTILIB rts build has > completely separate directory and stamp (through RTSDIR) so there is no > possibility of conflict through sharing. Well, also the issue is that currently the Makefile for building the run-time is not prepared to handle all the possible combinations currently supported by GCC on some platforms, so things will also break in various places if you enable multilibs blindly. Arno
Re: [Ada] multilib patch take two => multilib build working
This will need some additionals tests on MULTILIB in the LIBGNAT_TARGET_PAIRS machinery (3 files for x86 vs x86_64, solaris looks like already done, powerpc seem 32 bits only right now, s390/s390x, others?) but it doesn't seem like a blocking issue with the proposed design since each MULTILIB rts build has completely separate directory and stamp (through RTSDIR) so there is no possibility of conflict through sharing. Do you agree with this assessment? Unfortunately not. The solaris bits are just "factoring" a bit the definition of LIBGNAT_TARGET_PAIRS. The actual multilib definition can be arbitrary, for example you can have big-endian/little-endian multilibs. If the design is explicitly to have constants spelled out in system-* files (instead of having them, for example, in Autoconf macros), there is not much that you can do. Paolo
Re: [Ada] multilib patch take two => multilib build working
Selon Arnaud Charlet <[EMAIL PROTECTED]>: > Well, also the issue is that currently the Makefile for building the run-time > is not prepared to handle all the possible combinations currently supported > by GCC on some platforms, so things will also break in various places if > you enable multilibs blindly. Right. Paolo, do you know where to look for the list of multilibs on a given platform in the GCC sources? And if we want to disable some of them for Ada? Thanks in advance, Laurent
Re: [Ada] multilib patch take two => multilib build working
Paolo, do you know where to look for the list of multilibs on a given platform in the GCC sources? And if we want to disable some of them for Ada? In the makefile fragments t-*, in places like config/i386/t-linux64 MULTILIB_OPTIONS = m64/m32 MULTILIB_DIRNAMES = 64 32 MULTILIB_OSDIRNAMES = ../lib64 $(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib) Problematic (from an Ada point of view) configurations are those like config/arm/t-xscale-elf: MULTILIB_OPTIONS = mbig-endian MULTILIB_DIRNAMES= be MULTILIB_EXCEPTIONS = MULTILIB_MATCHES = mbig-endian=mbe mlittle-endian=mle and 32/64-bit configurations like x86_64-pc-linux-gnu. Paolo
Re: [Ada] multilib patch take two => multilib build working
Selon Paolo Bonzini <[EMAIL PROTECTED]>: > > > This will need some additionals tests on MULTILIB in the > LIBGNAT_TARGET_PAIRS > > machinery (3 files for x86 vs x86_64, solaris looks like already done, > powerpc > > seem 32 bits only right now, s390/s390x, others?) but it doesn't seem like > a > > blocking issue with the proposed design since each MULTILIB rts build has > > completely separate directory and stamp (through RTSDIR) so there is no > > possibility of conflict through sharing. > > > > Do you agree with this assessment? > > Unfortunately not. The solaris bits are just "factoring" a bit the > definition of LIBGNAT_TARGET_PAIRS. The actual multilib definition can > be arbitrary, for example you can have big-endian/little-endian > multilibs. If the design is explicitly to have constants spelled out in > system-* files (instead of having them, for example, in Autoconf > macros), there is not much that you can do. There is a Standard'Default_Bit_Order so it's the same as Word_Size: we just loose "source" documentation (and gain less diff between target file). There is some code in the Ada RTS that explicitely check for big endian/little endian (so will work on both, see g-socket.adb Short_To_Network), I doubt that there is RTS code that makes an implicit assumption about this (if there is it's most likely a bug). Laurent
Re: [Ada] multilib patch take two => multilib build working
Paolo Bonzini wrote: Arnaud Charlet wrote: I had to solve one rts source issue though: gcc/ada/system-linux-x86_64.ads and x86.ads do hardcode the number of bits for a word (64 and 32 respectively), I changed them both to be completely the same and use GNAT defined Standard'Word_Size attribute. - Word_Size: constant := 64; - Memory_Size : constant := 2 ** 64; + Word_Size: constant := Standard'Word_Size; + Memory_Size : constant := 2 ** Word_Size; The same change will have to be done on other 32/64 bits Ada targets. I don't know if this change has adverse effect on GNAT build in some situations. I think this is worthwhile on its own, before the build patch goes in. Not clear to me actually. The idea currently is to make these values explicit so that when people read system.ads, they know right away what the right value is. Unless you want to have a combination of switching system* or generating them, I don't know how you will get this. Certainly a general mechanism for inserting a few values like endian, word size, etc would cover many of the variations but you might still have odd variations that require switching the files. When dealing with multilibs, I don't know that it is really possible to assume that you can look at a file and directly know what the "truth" is for a particular set of CPU options. In many cases, you have CPU CFLAGS that use CPU model names and then map onto an arbitrary directory which corresponds to the ISA used. For example, for a SPARC/ERC32 you use -mcpu=cypress and that maps onto a V7 set of libraries. Without knowing the multilib mapping, there is no obvious answer. And in C for multilibs, there is typically only one set of .h files (e.g. specification) and multiple implementations (e.g. objects). From my perspective, being technically correct is more important than giving a user the direct answer in a file. It is hard enough to always have the right multilib. If you want to provide a utility to give a report that answers these questions, that would be useful. In fact, GCC even has something that is similar to this report for C/C++ users. gcc CPU_CFLAGS -dM -E - Also, this points to a real flaw in the approach, since e.g. in case of little/big endian multilibs, similar issue would arise. Yes, if different multilibs should use different sets of sources, we have a problem. I can see major differences when you have 32/64 bit multilibs and those have to have different RTS source. I am sure there are other cases like this. But the majority of multilibs are based upon binary compatibility differences that the compiler handles automatically. If you can handle endianness and don't have RTS source code that is dependent on CPU model differences, then that much should take care of itself once the basic build infrastructure works multilib. I think you will end up having to support generating different source trees for each multilib variant to be safe and correct. Handling some common differences like endianness in a clean way that doesn't involve source variation should reduce the cases though. On the other hand, this is also something that can be solved by moving the RTS to libada. The standard approach with C multilibs is to rely on configure tests, or on #define constants, to pick the appropriate choice between multilibs, and I don't see why this shouldn't work with Ada. For example, g-soccon* files are generated automatically -- then, why not go one step further and generate a g-soccon file at configure time? This will work for native builds but may have problems on cross builds where you can't run a program. I know for the RTEMS g-soccon* file we have to run a program on target hardware and capture the output. It seems that a branch would be more appropriate for this kind of work, since there's a long way to go before getting in reasonable shape. Given the above, I agree. If you move the source to libada and start potentially using different source combinations for different multilib variants, then it does need to be on a branch. But some of the patches so far seem like they would be OK to commit on the mainline and minimize diffs. Also, it's not clear how using $(RTS) for building gnattools will work properly. Only target modules are multilibbed, so only one copy of gnattools is built. I assume that the characteristics of the target do not affect the operation of gnattools -- different multilibs may use different filesystem paths and thus behave differently, but the *code* of gnattools should be the same in all cases. I would think this is the case. The multilib impacts the Ada include path and the library search path just like with C. [EMAIL PROTECTED]:~/tmp$ gnatmake -f -g -aO/home/guerby/build-mlib7/gcc/ada/rts32 -m32 p There's an existing mechanism in gnatmake which is the use of the --RTS switch, so ideally it would be great to match multilib instal
Re: [Ada] multilib patch take two => multilib build working
There is a Standard'Default_Bit_Order so it's the same as Word_Size: we just loose "source" documentation (and gain less diff between target file). Yes, but Arnaud said that system-* constants are written down for a reason. I don't understand *what* is the reason, but that's just because I have no clue (among other things) of what parts of the Ada RTS are installed. For example, are these system-*.ads files installed? If so, is it possible to install different versions for each multilib? If not (question to Arnaud), is this self-documentation meant only for the people reading the source code of GNAT? IOW, is it meant as a quick-and-dirty reference as to what are the characteristics of the target? My impression is that 50% of the constants system-*.ads files are boilerplate (same for every file), 30% is easily derivable from configure.ac tests or from other Standard'xyz constants, and only 20% is actually something that depends on how GNAT works on the target. If it was up to me, I would make the system.ads file automatically generated (except for the latter 20%, which would have to be specified in some way). That would simplify multilibbing, but is moot unless there is a guarantee that this 20% is *totally* derivable from the target triplet, so that no conceivable flag combination can affect it. If this guarantee is not there, any attempt to multilib the Ada RTS is going to be a sore failure. Paolo
Re: [Ada] multilib patch take two => multilib build working
I think you will end up having to support generating different source trees for each multilib variant to be safe and correct. Yes, that comes out naturally if the RTS is built in libada. In fact, Arnaud said: The idea currently is to make these values explicit so that when people read system.ads, they know right away what the right value is. That's "when people read system.ads", not "when people read system-linux-x86.ads". In other words, he's not necessarily against automatically generating system.ads from other means, for example using configure tests. Which, I repeat, comes out naturally if the RTS build is confined in libada. This will work for native builds but may have problems on cross builds where you can't run a program. I know for the RTEMS g-soccon* file we have to run a program on target hardware and capture the output. Do you really need to run programs? Most of gen-soccon can be done by running Ada source code through the C pre-processor and massaging the output. In fact, the code that would be passed through cpp strongly resembles gen-soccon.c itself. If you move the source to libada and start potentially using different source combinations for different multilib variants, then it does need to be on a branch. But some of the patches so far seem like they would be OK to commit on the mainline and minimize diffs. Yes, that's true. Paolo
Re: [Ada] multilib patch take two => multilib build working
Selon Paolo Bonzini <[EMAIL PROTECTED]>: > > > There is a Standard'Default_Bit_Order so it's the same as Word_Size: we > just > > loose "source" documentation (and gain less diff between target file). > > Yes, but Arnaud said that system-* constants are written down for a > reason. I don't understand *what* is the reason, but that's just > because I have no clue (among other things) of what parts of the Ada RTS > are installed. Arnaud was quite clear about the reason: "The idea currently is to make these values explicit so that when people read system.ads, they know right away what the right value is." My take is that it's not a strong blocking point and that integrated multilib build is more useful to Ada users (and GCC developpers) than this limited form of documentation, being able to do -m32 on x86_64 or powerpc/sparc is nice to have after all :). > If it was up to me, I would make the system.ads file automatically > generated (except for the latter 20%, which would have to be specified > in some way). That would simplify multilibbing, but is moot unless > there is a guarantee that this 20% is *totally* derivable from the > target triplet, so that no conceivable flag combination can affect it. > If this guarantee is not there, any attempt to multilib the Ada RTS is > going to be a sore failure. On a given target triplet you can still have multiple Ada RTS for example for different thread libraries or exception models. These choices are expressed in gcc/ada/Makefile.in and as I said it doesn't look very hard to update it to handle multilibs as they currently exist. Laurent
Re: [Ada] multilib patch take two => multilib build working
> The idea currently is to make these values > explicit so that when people read system.ads, they know right away what > the right value is. > > That's "when people read system.ads", not "when people read > system-linux-x86.ads". In other words, he's not necessarily against > automatically generating system.ads from other means, for example using > configure tests. Which, I repeat, comes out naturally if the RTS build is > confined in libada. Right, that's one possibility, although people seem to be focusing in system.ads alot, which is actually only the tip of the iceberg, and not a real issue per se. > Do you really need to run programs? Most of gen-soccon can be done by > running Ada source code through the C pre-processor and massaging the > output. In fact, the code that would be passed through cpp strongly > resembles gen-soccon.c itself. We have actually made such a change recently, still need to contribute it. Arno
Re: [Ada] multilib patch take two => multilib build working
Arnaud Charlet wrote: The idea currently is to make these values explicit so that when people read system.ads, they know right away what the right value is. That's "when people read system.ads", not "when people read system-linux-x86.ads". In other words, he's not necessarily against automatically generating system.ads from other means, for example using configure tests. Which, I repeat, comes out naturally if the RTS build is confined in libada. Right, that's one possibility, although people seem to be focusing in system.ads alot, which is actually only the tip of the iceberg, and not a real issue per se. Still it's the biggest problem so far. For example, g-bytswa-x86.adb vs. g-bytswa.adb is also a problem because a -mcpu=i386 multilib should use the latter; however, that's arguably already a GNAT bug for the i386-pc-linux-gnu configuration, so it can be left for later. Good to hear about soccon, though. Paolo
Re: [Ada] multilib patch take two => multilib build working
>> Right, that's one possibility, although people seem to be focusing >> in system.ads alot, which is actually only the tip of the iceberg, and not >> a real issue per se. > > Still it's the biggest problem so far. No, the issue is setting the proper target when building gnatlib, most things will fall out for free once this is solved. Arno
Re: [Ada] multilib patch take two => multilib build working
Arnaud Charlet wrote: The idea currently is to make these values explicit so that when people read system.ads, they know right away what the right value is. That's "when people read system.ads", not "when people read system-linux-x86.ads". In other words, he's not necessarily against automatically generating system.ads from other means, for example using configure tests. Which, I repeat, comes out naturally if the RTS build is confined in libada. Right, that's one possibility, although people seem to be focusing in system.ads alot, which is actually only the tip of the iceberg, and not a real issue per se. Do you really need to run programs? Most of gen-soccon can be done by running Ada source code through the C pre-processor and massaging the output. In fact, the code that would be passed through cpp strongly resembles gen-soccon.c itself. Agreed. But the current procedure generates a program which generates the output. We have actually made such a change recently, still need to contribute it. For RTEMS, we build everything including the OS itself from source in sequential order. The .h files for the network stack are not available when the tools are built so the file can't be generated automatically during the Ada build. I don't think that's a big deal as long as you are aware that at least one target can't generate the file on the fly. Arno --joel
Re: [Ada] multilib patch / -imultilib and language drivers
On Tue, 2008-07-22 at 13:41 +0200, Paolo Bonzini wrote:
> > [EMAIL PROTECTED]:~/tmp$ gnatmake -f -g
> > -aO/home/guerby/build-mlib7/gcc/ada/rts32 -m32 p
>
> I guess this fixing this requires duplicating in gnatmake and gnatbind
> the logic in gcc.c that uses the info produced by genmultilib. Search
> gcc.c for
>
> multilib_raw
> multilib_matches_raw
> multilib_extra
> multilib_exclusions_raw
> multilib_options
> set_multilib_dir
>
> Maybe it makes sense to make a separate .c module for this, so that both
> the driver and gnat{make,bind} can use it.
When I invoke the gcc driver on a C source file:
$ gcc -c -v -m32 toto.c
...
/home/guerby/install-trunk-mlib7/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/cc1
-quiet -v -imultilib 32 -iprefix
/home/guerby/install-trunk-mlib7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/
toto.c -quiet -dumpbase toto.c -m32 -mtune=generic -auxbase toto -version -o
/tmp/cc6kC8e8.s
...
=> it does add "-imultilib 32" when calling cc1 which if I understand
the logic is the subdirectory matching the multilib flags, it is
computed by set_multilib_dir, and it should match the MULTISUBDIR in
Makefiles when building. Correct me if I'm wrong.
But when I do it on an Ada source file:
$ gcc -c -v -m32 p.adb
...
/home/guerby/install-trunk-mlib7/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/gnat1
-quiet -dumpbase p.adb -m32 -mtune=generic p.adb -o /tmp/ccmqJCN2.s
...
=> this computation and addition of -imultilib is not done and gnat1 is
called without it.
What triggers the passing of -imultilib to a language driver?
Once gcc passes this info to gnat1 it will likely be easy to have
gnatmake/bind/link extract it when needed since those tools
call gcc.
Thanks in advance,
Laurent
Re: [Ada] multilib patch / -imultilib and language drivers
On Tue, 22 Jul 2008, Laurent GUERBY wrote: > What triggers the passing of -imultilib to a language driver? The handling of the %I spec. -imultilib is a preprocessor option used to get the fixed headers corresponding to a particular multilib. -- Joseph S. Myers [EMAIL PROTECTED]
Re: How to determine if a decl is a class member in GCC
Le-Chun Wu wrote:
Hi,
I haven't heard anything back on my questions. Can any of C++ frontend
maintainers please shed some light (or comment on my proposed patch)?
Thanks a lot.
Le-chun
On Fri, Jul 18, 2008 at 10:22 AM, Le-Chun Wu <[EMAIL PROTECTED]> wrote:
Hi,
In my attribute handlers that handle the new thread-safety attributes
(in c-common.c), I need to check if a decl is a class member. How do
people do that? My original code was checking if a decl is a
FIELD_DECL but that doesn't work for static members. I also tried to
use DECL_CONTEXT but it is not set (in the C++ front-end) for data
members. (I was able to use DECL_CONTEXT for member functions,
though.) Is there any other way that I should use?
I created a simple testcase for treehydra and it seems that DECL_CONTEXT was
set and correct for all of the following in 4.3.0:
struct A {
int a;
int f();
static int sa;
static int sf();
};
Are you saying that you don't see a proper DECL_CONTEXT for "a" and "sa"?
--BDS
Re: [Ada] multilib patch / -imultilib and language drivers
What triggers the passing of -imultilib to a language driver? It is passed together with -isystem, -iprefix and friends when %I is in a spec. I'm sure you can define a new spec function and use it to pass the multilib_dir variable down to the Ada driver (see default_compilers, I guess you have to read some gcc.c). Once gcc passes this info to gnat1 it will likely be easy to have gnatmake/bind/link extract it when needed since those tools call gcc. I believe you on this. :-) Paolo
[tuples] New memory/time comparison vs trunk
The branch has regressed in terms of memory and compile time. However, I think the regressions are localized. I compiled tuples and [EMAIL PROTECTED] with --disable-checking --enable-gather-detailed-mem-stats. I ran cc1 and cc1plus over the preprocessed code of cc1-i-files, FF3D, SPEC2000, TRAMP3D, PR 12850, PR 15855 and PR 30089. I had to disable PRE and FRE on both trunk and tuples because trunk wouldn't bootstrap if I only disabled the same bits that are disabled in tuples. The attached is a comparison using the compile and memory figures emitted by -ftime-report. The "Before" column corresponds to [EMAIL PROTECTED], the "After" column corresponds to [EMAIL PROTECTED] The times and memory figures are aggregated over ALL the files in the collection I described above. Some preliminary notes: - The branch is 25secs slower than mainline (2%). Out of those 25 seconds, 15.31 seconds are in tree DSE, which is puzzling. The other 10 seconds seem to be going to RTL DSE1 (3 secs), tree CCP (2 secs) and various others more evenly distributed. In fact, if you take away tree DSE, the tree passes are faster on tuples. - Memory utilization is tricky to check. The difference is almost totally going to the gimplifier and RTL expansion (about 900Kb of the 1.3Mb difference). These two have trees and gimple coexisting for a short period of time, particularly in the gimplifier. However, the trees that are used in RTL expansion are built and destroyed on the spot, so that should not affect peak memory use, but the report doesn't let me distinguish that. - The rest of the memory utilization difference is mostly in inlining (240Kb) and SSA update (50Kb). I think the main focus points should be DSE and trying to get a good way of measuring the memory utilization differences. Jan, any suggestion? Thanks. Diego. TimeMemory Phase Before After % change Before After % change ^ garbage collectio 54.90 56.012.02% 0 0 -100.00% ^ callgraph constru7.047.587.67% 320099 205154 -35.91% ^ callgraph optimiz 12.019.98 -16.90% 274447 269807 -1.69% ^ ipa reference1.461.14 -21.92%11591514 30.63% ^ cfg cleanup 19.91 23.85 19.79% 49290 49184 -0.22% ^ trivially dead co5.534.97 -10.13% 0 0 -100.00% ^ df reaching defs11.13 11.745.48% 0 0 -100.00% ^ df live regs25.94 26.953.89% 0 0 -100.00% ^ df reg dead/unuse9.119.312.20% 152248 1538391.05% ^ alias analysis 9.088.70 -4.19% 229345 229018 -0.14% ^ register scan1.861.870.54%12662053 62.16% ^ preprocessing 37.94 37.10 -2.21% 777544 776711 -0.11% ^ parser 182.56 184.841.25%15463178158077282.23% ^ name lookup 37.38 37.961.55% 1535795 15620591.71% ^ inline heuristics6.434.12 -35.93% 98582 997501.18% ^ integration 31.66 33.255.02% 2585635 28247319.25% ^ tree gimplify 35.01 36.414.00% 1984557 2770492 39.60% ^ tree eh 1.771.896.78% 98729 130155 31.83% ^ tree CFG construc6.574.31 -34.40% 720404 376314 -47.76% ^ tree CFG cleanup17.99 15.96 -11.28% 120599 1269755.29% ^ tree VRP24.91 25.191.12% 830490 808712 -2.62% ^ tree copy propaga7.417.714.05% 72143 724070.37% ^ tree find ref. va1.821.58 -13.19% 72720 86277 18.64% ^ tree PTA 9.569.44 -1.26% 99931 97924 -2.01% ^ tree alias analys4.474.531.34% 68751 710853.39% ^ tree call clobber0.420.59 40.48% 8871084 22.21% ^ tree flow sensiti0.260.34 30.77%411943976.75% ^ tree memory parti1.461.43 -2.05% 612 538 -12.09% ^ tree PHI insertio0.720.87 20.83% 11050 14721 33.22% ^ tree SSA rewrite 8.688.781.15% 512512 5622069.70% ^ tree SSA other 1.862.15 15.59% 01008 100.00% ^ tree SSA incremen 15.31 16.849.99% 241694 295323 22.19% ^ tree operand scan 17.85 17.920.39% 1191734 1181479 -0.86% ^ dominator optimiz 23.55 22.96 -2.51% 640181 539452 -15.73% ^ tree SRA 2.552.570.78% 61375 666728.63% ^ tree STORE-CCP 2.642.32 -12.12% 13339 13020 -2.39% ^ tree CCP 6.608.47 28.33% 65710 667831.63% ^ tree PHI const/co0.570.94 64.91% 3054796 100.00% ^ tree split crit e2.112.00 -5.21% 197589 196116 -0.75% ^ tree reassociatio4.181.98 -52.63% 27810 26479 -4.79% ^ tree code sinking1.401.33 -5.00% 12805 11777 -8.03% ^ tree linearize ph0.590.53 -10.17%11161305 16.94% ^ tree forward prop2.792.945.38%
Re: How to determine if a decl is a class member in GCC
Benjamin,
Thanks for looking into this issue. I see what's going on here. It's
basically a phase ordering problem. I am trying to determine whether a
declaration is a class member when attributes are parsed and handled
(in c-common.c), which happens earlier than where the context of a
data member is set (which takes place either in
finish_static_data_member_decl or finish_member_declaration). Do you
know of any way to determine whether a decl is a class member when we
are parsing the decl attributes?
Thanks,
Le-chun
On Tue, Jul 22, 2008 at 12:34 PM, Benjamin Smedberg
<[EMAIL PROTECTED]> wrote:
> Le-Chun Wu wrote:
>>
>> Hi,
>>
>> I haven't heard anything back on my questions. Can any of C++ frontend
>> maintainers please shed some light (or comment on my proposed patch)?
>> Thanks a lot.
>>
>> Le-chun
>>
>> On Fri, Jul 18, 2008 at 10:22 AM, Le-Chun Wu <[EMAIL PROTECTED]> wrote:
>>>
>>> Hi,
>>>
>>> In my attribute handlers that handle the new thread-safety attributes
>>> (in c-common.c), I need to check if a decl is a class member. How do
>>> people do that? My original code was checking if a decl is a
>>> FIELD_DECL but that doesn't work for static members. I also tried to
>>> use DECL_CONTEXT but it is not set (in the C++ front-end) for data
>>> members. (I was able to use DECL_CONTEXT for member functions,
>>> though.) Is there any other way that I should use?
>
> I created a simple testcase for treehydra and it seems that DECL_CONTEXT was
> set and correct for all of the following in 4.3.0:
>
> struct A {
> int a;
> int f();
> static int sa;
> static int sf();
> };
>
> Are you saying that you don't see a proper DECL_CONTEXT for "a" and "sa"?
>
> --BDS
>
Re: How to determine if a decl is a class member in GCC
Le-Chun Wu wrote: Benjamin, Thanks for looking into this issue. I see what's going on here. It's basically a phase ordering problem. I am trying to determine whether a declaration is a class member when attributes are parsed and handled (in c-common.c), which happens earlier than where the context of a data member is set (which takes place either in finish_static_data_member_decl or finish_member_declaration). Do you know of any way to determine whether a decl is a class member when we are parsing the decl attributes? I don't know for certain, but you could certainly try current_class_type, which is derived from the scope chain. --BDS
RFC: Bug in specs processing
I noticed today that:
gcc -c -o hw.o hw.c
removes hw.o if failure occurs during the compilation, but:
gcc -c -ohw.o hw.c
does not.
The reason turns out to be that, in the latter case, we record the name
"-ohw.o" as a temporary file, rather than "hw.o". Our confusion comes
from the handling of "%W" specs:
/* If any args were output, mark the last one for
deletion
on failure. */
if (argbuf_index != cur_index)
record_temp_file (argbuf[argbuf_index - 1], 0, 1);
in the handling of the spec "%W{o*}", which is supposed to mean that we
generate all of the "-o" options, and then remember that the last one is
a temporary file we should delete. However, the generation of the
output (which is what argbuf contains) is faithful to the input, so if
the user writes "-ofoo.o" instead of "-o foo.o", then the output is
again "-ofoo.o", leading to the bug. I guess this matters if your
assembler, for example, only accepts the "-ofoo.o" form. Are there such
tools? (It looks like the opposite is sometimes true; we have
SWITCHES_NEED_SPACES, which indicates that some options must be split,
no matter how the user writes them, and that is set to indicate that
"-ofoo.o" must be split on IRIX and OSF.)
We can't just check in the code above for the last argument starting
with "-o", since then "-o -ofoo.o" wouldn't work right. And, besides,
although "%W" seems to be used only with "%W{o*}" it could in theory be
used in other ways as well. And we can't blindly try deleting both
"-ofoo.o" and plain "foo.o" because then if the user said "-ofoo.o", and
that was missing, we'd delete "foo.o" which we should not. (There is
already some code involving have_o_argbuf_index which looks like it may
mishandle things like "gcc -c -x c -- -o", but that's another matter.)
This idea of going back and looking at argbuf is, therefore, broken by
design. I don't see a way to really make %W make sense, in this context.
Ideas?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: RFC: Bug in specs processing
On Tue, Jul 22, 2008 at 4:53 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote: > I noticed today that: > > gcc -c -o hw.o hw.c > > removes hw.o if failure occurs during the compilation, but: > > gcc -c -ohw.o hw.c > > does not. > > The reason turns out to be that, in the latter case, we record the name > "-ohw.o" as a temporary file, rather than "hw.o". This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11810 . There was a patch posted here: http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00784.html It was reviewed here: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01432.html Thanks, Andrew Pinski
Re: RFC: Bug in specs processing
On Tue, Jul 22, 2008 at 04:53:19PM -0700, Mark Mitchell wrote: > I noticed today that: > > gcc -c -o hw.o hw.c > > removes hw.o if failure occurs during the compilation, but: > > gcc -c -ohw.o hw.c > > does not. Hmm. About 20 years of gcc use, and this is the first time I learned that the second command line choice was even legal.
Re: Thread safety annotations and analysis in GCC
This looks like interesting work, and I hope something like this gets folded into a release soon. A few things occurred to me when reading the writeup at google (sorry, I haven't started looking through the code much yet): All the examples seem to be C++ oriented; is it, in fact, a goal for the annotations and analysis to be just as useful in C? What are the scoping rules used for finding the mutex referenced in the GUARDED_BY macro within a C++ class definition? Are they the same as for looking up identifiers in other contexts? How is the lookup done for C structures? Will the compiler get built-in knowledge of the OS library routines (e.g., pthread_mutex_lock) on various platforms? You list separate annotations for "trylock" functions. It appears that the difference is that "trylock" functions can fail. However, pthread_mutex_lock can fail, if the mutex isn't properly initialized, if recursive locking of a non-recursive mutex is detected, or other reasons; the difference between pthread_mutex_lock and pthread_mutex_trylock is whether it will wait or immediately return EBUSY for a mutex locked by another thread. So I think pthread_mutex_lock should be described as a "trylock" function too, under your semantics. Conservatively written code will check for errors, and will have a path in which the lock is assumed *not* to have been acquired; if the analysis assumes pthread_mutex_lock always succeeds, that path may be analyzed incorrectly. (I ran into a tool once before that complained about my locking code until I added an unlock call to the error handling path. Since it's actively encouraging writing incorrect code, I'm not using it any more.) Ken
