I have implemented this gcc mips16 floating point scheme in llvm/clang
and ran into one interesting issue.
In gcc mips16, for all the hard float routines, i.e. __mips16_xxx, gcc
emits a .globl for them.
It does not do this for other routines like strcmp for example or puts.
If don't remit
I forgot to mention that this only happens with Im linking as C++
On 08/29/2013 02:07 PM, Reed Kotler wrote:
I have implemented this gcc mips16 floating point scheme in llvm/clang
and ran into one interesting issue.
In gcc mips16, for all the hard float routines, i.e. __mips16_xxx, gcc
emits
I would like to move on to figuring out precisely what the issues are .
What rules would make this attribute behave in a proper and
understandable way?
Maybe there are limitations that the user would have to be aware of.
My main interest is in LLVM but there is great interest to keep the
On 05/03/2013 01:06 AM, Chung-Ju Wu wrote:
2013/5/3 Chung-Ju Wu jasonw...@gmail.com:
Or do you think 'naked' is still useful for some other cases in mips porting?
You can implement it and submit the patch to gcc-patc...@gcc.gnu.org
and I believe the mips maintainers are willing to have review
On 05/03/2013 03:29 AM, Richard Sandiford wrote:
Glad to see the push-back on this :-)
reed kotler rkot...@mips.com writes:
On 05/03/2013 01:06 AM, Chung-Ju Wu wrote:
2013/5/3 Chung-Ju Wu jasonw...@gmail.com:
Or do you think 'naked' is still useful for some other cases in mips porting?
You
Microchip which makes the Pic32 embedded processor (Mips32) has the
naked attribute in their C compiler.
http://ww1.microchip.com/downloads/en/DeviceDoc/51686F.pdf
This issue of naked function attribute support for Mips has come up in
the context of LLVM and in regards to maintaining compatibility with gcc.
It's my understanding that the idea of the naked function attribute was
rejected for gcc Mips.
I'm curious as to why.
For LLVM it basically works
Should a return statement be emitted in a function that has the naked
attribute.
There seems to be some confusion here and apparently disagreement
between various
gcc compilers.
On 05/02/2013 03:44 PM, reed kotler wrote:
Should a return statement be emitted in a function that has the naked
attribute.
There seems to be some confusion here and apparently disagreement
between various
gcc compilers.
Sorry. This was meant to be a question.
Should a return statement
On 05/02/2013 04:13 PM, Andrew Pinski wrote:
On Thu, May 2, 2013 at 3:35 PM, reed kotler rkot...@mips.com wrote:
This issue of naked function attribute support for Mips has come up in the
context of LLVM and in regards to maintaining compatibility with gcc.
It's my understanding that the idea
On 05/02/2013 04:16 PM, Andrew Pinski wrote:
On Thu, May 2, 2013 at 3:46 PM, reed kotler rkot...@mips.com wrote:
On 05/02/2013 03:44 PM, reed kotler wrote:
Should a return statement be emitted in a function that has the naked
attribute.
There seems to be some confusion here and apparently
On 05/02/2013 07:54 PM, Ian Lance Taylor wrote:
On Thu, May 2, 2013 at 3:44 PM, reed kotler rkot...@mips.com wrote:
Should a return statement be emitted in a function that has the naked
attribute.
I vote yes.
why would you want that? naked functions are just inline asm.
you can generate your
On 05/02/2013 08:41 PM, Chung-Ju Wu wrote:
2013/5/3 reed kotler rkot...@mips.com:
Should a return statement be emitted in a function that has the naked
attribute.
There seems to be some confusion here and apparently disagreement between
various
gcc compilers.
IMHO, it depends on how you
On 05/02/2013 09:06 PM, Ian Lance Taylor wrote:
On Thu, May 2, 2013 at 8:59 PM, reed kotler rkot...@mips.com wrote:
On 05/02/2013 07:54 PM, Ian Lance Taylor wrote:
On Thu, May 2, 2013 at 3:44 PM, reed kotler rkot...@mips.com wrote:
Should a return statement be emitted in a function that has
Consider the following function:
void floatvf(float x) {
}
The compiled with:
mips-linux-gnu-gcc -mips16 mips16_fpcall.c -S -fPIC -EL
The stub looks like this:
__fn_stub_floatvf:
.setnoreorder
.cpload$25
.setreorder
.reloc0,R_MIPS_NONE,floatvf
la
I tried to report a bug against llvm for not properly handling the
section attribute but they claim that it's not the intention for gcc to
work this way.
I reported it as an X86 problem because it's more generally
understandable to people but actually the problem occurs when mips16
generates
.setnomicromips
.ent__fn_stub_foovf
.type__fn_stub_foovf, @function
__fn_stub_foovf:
la$25,foovf
mfc1$4,$f12
jr$25
.end__fn_stub_foovf
.text
$__fn_local_foovf = foovf
--More--(55%)
On 04/19/2013 08:22 AM, reed kotler wrote:
I tried
CPIC is added to .o files for mips a lot.
Is that needed?
What is it for?
Tia.
Reed
rkotler@ubuntu-rkotler:~/testmips16$ mips-linux-gnu-gcc null.c -c
mipsrkotler@ubuntu-rkotler:~/testmips16$ mips-linux-gnu-objdump -x null.o
null.o: file format elf32-tradbigmips
null.o
architecture:
I'm not understanding why mips16 and nomips16 are not simple inheritable
attributes.
i..e you should be able to say:
void foo();
void __attribute((nomips16)) foo();
or
void goo();
void __attribute((mips16)) goo();
There does not seem to be any other cases in gcc where this would not be
On 01/14/2013 04:50 PM, David Daney wrote:
On 01/14/2013 04:32 PM, reed kotler wrote:
I'm not understanding why mips16 and nomips16 are not simple inheritable
attributes.
The mips16ness of a function must be known by the caller so that the
appropriate version of the JAL/JALX instruction can
For extended inline assembly, there are constraints. Some seem to be
supported by all architectures and some specific to a particular
architecture.
Where are these defined in gcc source?
Some seem to be in constraints.md and some not.
Tia.
Reed
21 matches
Mail list logo
