This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RS6000] Don't pass -many to the assembler


On Nov 12, 2018, at 3:13 PM, Alan Modra <amodra@gmail.com> wrote:
> 
> For people developing new code, it's the right way to go, and
> especially so for people working on gcc itself.  For people just
> wanting stuff to compile, not so much.  I fully expect a chorus of
> *MORON* or worse to come from the likes of the linux kernel rabble.

So, if you just want to hear people whine...

On darwin, we (darwin, as a platform decision) like all instructions available from the assembler.  The assembler and the linker have specialized code to track all instructions used (from which CPU types those instructions come from), and mark the object file according to what is actually used.  We also have FAT binaries as a standard feature and other things to make everything play nicely.  People that use inline assembly are expected to know how to code, because it is an advanced feature, and not need hand holding on how to write the condition that guards the code.  I don't recall seeing any reports of anyone needing any extra help in this matter.  On darwin, there wasn't a .machine for a while, it came later.

Anyway, I thought about saying that it would be nice if all platforms behaved the same, and ask, what do people thing the recommended behavior of all platforms should be?

Personally I don't have a dog in this, as darwin cannot be changed, it's a platform feature, and personally, I don't write a ton of this type of code.  I just provide an alternate POV.  Darwin has api's to query the architecture and code in the assembler/linker to help manage it's decision.  Normal ELF systems, I want to say, usually lack such things.  So, choices it makes aren't necessarily right for others.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]