[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Compilation issues with GCC 4.7
On 15/01/2013 21:57, Miro Kropáček wrote:
if I understand you correctly, you're saying that before gas /ignored/ the
-m flag and now it /transforms/ it into -mcpu= (what leads to "hidden" .cpu) ?
Previously, gcc passed the -m option straight to gas.
Now it transforms it into -mcpu=
Are you sure there's a difference?
I think so.
If you do "m68k-atari-mint-as --target-help", you will see different lists
for "Architecture variants" and "Processor variants". It seems that
architectures are more general concepts.
Can you show us a problematic use case here? It's specifically about the
-m68020-60 parameter?
I don't remember precisely.
But for example, if I pass -m68020-60 to gcc, it translates to -m68040 for
gas. This is totally bogus (should be -m68020). BTW, I see that GCC 4.6 does
the same !!
Other example, similar to the original one.
gcc-4.7 -m68000 translates to gas -mcpu=68000. This is a problem, because it
seems that -m68000 sets both arch/cpu while -mcpu=68000 sets only the cpu.
Then afterwards, if some source uses the .cpu or .arch directives, this can
result in invalid combinations. However, changing both .cpu/.arch seemed to
do the right thing in every case.
Ideally, the whole source tree should be compiled with the same cpu option.
Very special sources such as context.S, detect.S use special assembler
instructions so they override the default cpu at the top. Actually, only
parts of those files should be compiled for a different CPU, but changing
the cpu in the middle of a file does not seem to be supported. Except when
using the obsolete .chip instruction. Another alternative would be to use
those ugly .dc.w.
As I see it, we only need to change all .arch's into .cpu's and problem is
solved.
I did that in my local tree, and it worked fine in some cases (maybe not all
of them). IIRC, setting both .cpu and .arch solved the problem in all cases.
--
Vincent Rivière