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]

msp430 port


Might as well clarify copyright status on *all* the msp430 files in libgcc. While one might claim some are so trivially small and thus not suitable for copyright protection, I'd rather not rely on that for anything in libgcc since those bits get included into user code and lawyers look at them very carefully. Others are (C) Red Hat with nonstandard language -- I don't see the value in doing something nonstandard here.

GPL + exception seems like the way to go, except in those cases where the code is coming from a 3rd party.


I'm assuming you documented all the MSP430 options. I didn't check them closely. I'm also assuming the libgcc functions are reasonably correct.


For popm, why not define a new output modifier instead of using %I, per the comments. That seems cleaner to me.

movqihi seems wrong. You really should determine why the standard methods for handling automatic elimination of extensions when loading from memory isn't working. I believe most RISC port in GCC uses those mechanisms successfully.

Every pattern that is using (subreg:SI (thing:PSI)) needs to be explained on this list and given an explicit clearance. It really looks like you're just papering over problems elsewhere.

As the comment in addhi_cy mentions, that is truly dangerous and wrong. You can't let that stay in the port without proving GCC won't do a code motion that causes problems. Just because sub, cmp, shift, etc haven't shown up in your tests doesn't mean they can't happen, they just didn't show up in your tests.

I don't see any atomics?  Not supported on this target?

Jeff


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