I forgot to mention that this only happens with I"m 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
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 th
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
com
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
On 05/03/2013 03:29 AM, Richard Sandiford wrote:
Glad to see the push-back on this :-)
reed kotler writes:
On 05/03/2013 01:06 AM, Chung-Ju Wu wrote:
2013/5/3 Chung-Ju Wu :
Or do you think 'naked' is still useful for some other cases in mips porting?
You can implement it and
My general opinion is that to not allow the naked attribute is to
pontificate over a group of sophisticated gcc users that are fully
capable of understanding what the naked attribute does. They can read
the manual and accept the responsibility for using the feature.
The ramifications of the fu
On 05/03/2013 01:06 AM, Chung-Ju Wu wrote:
2013/5/3 Chung-Ju Wu :
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 with you. :)
Oops~
On 05/02/2013 09:06 PM, Ian Lance Taylor wrote:
On Thu, May 2, 2013 at 8:59 PM, reed kotler wrote:
On 05/02/2013 07:54 PM, Ian Lance Taylor wrote:
On Thu, May 2, 2013 at 3:44 PM, reed kotler wrote:
Should a return statement be emitted in a function that has the naked
attribute.
I vote yes
On 05/02/2013 08:41 PM, Chung-Ju Wu wrote:
2013/5/3 reed kotler :
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 define the word
On 05/02/2013 07:54 PM, Ian Lance Taylor wrote:
On Thu, May 2, 2013 at 3:44 PM, reed kotler 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 own return
On 05/02/2013 04:16 PM, Andrew Pinski wrote:
On Thu, May 2, 2013 at 3:46 PM, reed kotler 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 disagreement
On 05/02/2013 04:13 PM, Andrew Pinski wrote:
On Thu, May 2, 2013 at 3:35 PM, reed kotler 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 of the
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 be
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.
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 j
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$25,__f
nomips16
.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 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
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: mips:
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 instructio
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
all
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
22 matches
Mail list logo
