[adtools] Re: questions about the GCC port
- From: Andrija Antonijevic <antony@xxxxxxxxxxxxxxxxx>
- To: adtools@xxxxxxxxxxxxx
- Date: Tue, 9 Aug 2005 19:51:29 +0200 (CEST)
On 8-Aug-2005, Gunther Nikl wrote:
On Fri, Aug 05, 2005 at 05:07:04PM +0200, Andrija Antonijevic wrote:
On 4-Aug-2005, Gunther Nikl wrote:
I provided a minimal .cpp file which doesn't include anything so it's
equivalent to the .i file when I filed the bug report:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21460 (please let me know if
you think there's something missing).
The testcase is self-contained thus I think thats fine.
Good, thanks for taking a look.
Since there were no reactions, I thought noone has/want's to bother to
build the compiler with which this can be reproduced - that's why I
wrote about the "step by step" part above.
It may take some time for someone to look a such reports. However, I
don't get the crash you are describing:
Using built-in specs.
Target: ppc-powerup
Configured with: ../gcc-4.0.0-gg/configure --prefix=/usr/local --disable-nls
--enable-languages=c,c++ --with-gc=zone --with-headers=yes --target=ppc-powerup
Thread model: single
gcc version 4.0.0
/usr/local/lib/gcc/ppc-powerup/4.0.0/cc1plus -quiet -v bar.cc -quiet
-dumpbase bar.cc -auxbase bar -O2 -version -o /var/tmp//ccvGirpd.s
GNU C++ version 4.0.0 (ppc-powerup)
compiled by GNU C version 2.95.4 20020320 [FreeBSD].
GGC heuristics: --param ggc-min-expand=55 --param ggc-min-heapsize=48644
/usr/local/lib/gcc/ppc-powerup/4.0.0/../../../../ppc-powerup/bin/as -E0 -F1
-R -pc -x -o bar.o /var/tmp//ccvGirpd.s
Maybe your 4.0.0 is miscompiled or some fof you configure options may be
the cause.
I think I used the configure options that were used to compile the Debian
gcc3 and added --enable-haifa and --enable-sjlj-exceptions. I suspected the
latter triggers the problem (I see that you didn't use it, so it's a
possibility). Perhaps building on a "major" platform with this option would
also trigger it. I don't remember that I tried that, I'm sure that I planned
to, though. I *think* that I tried compiling powerpc-linux one without
--enable-sjlj-exceptions and it didn't help (which sends that theory down the
drain), but it was a while ago and I might be wrong.
BTW, I noticed "--enable-haifa" was used but I can't find this flag with
either 3.4.x nor 4.x.
I used that by inertia since it was (and is) in our README files for building
the compiler which were around since gcc 2.95.3 days. I suppose it either
became the default at some point or was removed so, you are right, we should
probably stop using it.
Also, I seem to remember that the linker would report an error about
unrecognized emulation mode or something.
-mcrt= isn't passed to the linker, is it?
Normally, no, this happened when I tried adding %{!mcrt=*: -mcrt=xxx} to
see what happens.
If the linker doesn't know that switch then don't pass it ;)
I can't argue with that ;) This was for that quick test to see if injecting a
-mcrt option when none was specified would do the trick (it also had to be
injected into the link string since it adds -L options based on -mcrt option
but, as we concluded, injecting won't work).
%{mcrt=default|!mcrt=*:%<mcrt=default -mcrt=clib2}
The "%<" removes default if it was given. Something like the above is
needed to avoid passing =default to cc1 since then cc1 would have to
know internally what "default" is.
I see. If it creates too much problems, we might remove -mcrt=default,
it isn't that useful (I think?).
For now it should stay since the above seems to work. If "default" is
becoming a burdon, then it should go if thats the best solution.
Makes sense.
I still find it interesting that in
const char *amigaos_crt_string = CRT_AMIGA_DEFAULT;
{ "crt=", &amigaos_crt_string, N_("Select C runtime library"), 0},
amigaos_crt_string won't be set to 0 when the parser doesn't see -mcrt on
the command line.
I looked at the generic code, but I have no idea when the final "0" would
be used.
Even more interesting since the documentation suggests that it would get
used. Oh, well...
I haven't checked the code, but I have seen several targets do something
similar so it should work. It's a bit unusual since the last member of
the structure above is supposed to be the default value - unless 0 is a
special case.
All I know is that m68k-amigaos used similiar code for -mregparm= and
that worked.
Great, in that case everything's OK :)
mcrt=default|!mcrt=*: %{mcrt=default|!nostdinc: %(cpp_amiga_default)};
^^^^^^^^^^^^^^^^^^^^^^^
What is the purpose of the inner test?
I wanted to achieve this:
if (default_crt_specified || (mcrt_not_specified && nostdinc_not_specified))
use_cpp_amiga_default
Ok, but that doesn't explain why you test "!nostdinc" for "!mcrt" ;-)
Hehe, when you put it like that I don't know either, although the "math" does
make sense ;)
if (default_crt_specified || crt_not_specified)
if (default_crt_specified || nostdinc_not_specified)
use_cpp_amiga_default
There is probably a different/better way to do this.
You could make them separate cases.
That would probably have been a better way. I suppose I looked at the whole
construct as one large if (mcrt_is_clib2) ... else if (mcrt_is_ixemul) etc
construct so I wrote it like that.
I see "default" as a can of worms. If a user wants a specific C lib,
then -mcrt= should be used on the commandline.
I tend to agree with this now.
Fine :) We should revisit this issue after my symbol defintion patch
is commited.
OK.
The usage of multilib in the build process would solve almost all
problems, but we would have to dump the possibility to change the
default CRT.
Maybe.
You think the usage of multilib wouldn't solve the problems with moving
things around after the build process that is currently required? :)
I think this needs more investigations and tests. I am not a multilib
expert.
Sure, I'm just saying that it looks promising at the moment, more tests are
definitely needed.
Andrija
______________________________________________________________________________
Amiga Development tools ML - //www.freelists.org/list/adtools
Homepage...................: http://www.sourceforge.net/projects/adtools
Listserver help............: mailto:adtools-request@xxxxxxxxxxxxx?Subject=HELP
Other related posts:
