[adtools] Re: questions about the GCC port
- From: Gunther Nikl <gni@xxxxxxxx>
- To: adtools@xxxxxxxxxxxxx
- Date: Mon, 8 Aug 2005 11:09:26 +0200
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.
> 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.
BTW, I noticed "--enable-haifa" was used but I can't find this flag with
either 3.4.x nor 4.x.
> >>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 ;)
> > %{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.
> > I am attaching my current diffs for moving the symbol defintions into
> > cc1. If you think this is fine I can check it in.
>
> Please do, they look fine to me.
Will do.
> 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.
> 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.
> > 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" ;-)
> 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.
> > 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.
> >>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.
Gunther
--
Linux is only free if your time has no value
- Jamie Zawinski
______________________________________________________________________________
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:
