https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65898
stanley <sstsoft at wp dot pl> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|INVALID |---
--- Comment #3 from stanley <sstsoft at wp dot pl> ---
(In reply to Andrew Pinski from comment #2)
> There is no GCC bug here. You change the syntax without notifying GCC. And
> GCC is free to insert instructions between two inline-asms.
No there IS A BUG.
Have you reed it carefully?
I think you haven't (ok maybe i wrote it not so clear)
The problem is that(i will repeat) - GCC put it's auto generated asm line(from
his C compilation process, it's not mine) between two of mine "hand made"
inline volatile asm's. Ok but why it's wrong? GCC uses wrong syntax, blind for
first line where i changed it. Ok maybe it's not a bug because for GCC each of
asm() is one "object". There are locals in each of them. Labels in each of them
etc. So also syntaxes should be threated separatly in each of them.
It's a bug(not my mistake) because if i change .intel_syntax somewhere, this
line switches syntax globally, for all inline asms() puted below elswhere.
Problem is that not only for inline, for whole compilation process..is it a bug
in linker? I dont think so.
Maybe it's about /APP not #APP or something else? Maybe it's problem with
linker? I dont know, but it's far way from OK, and GCC generates it. It's close
to very BIG problem.
One my asm block changes .intel syntax, second does something, third changes
syntax back to default instead of one multiline asm that does it without
problem. The first changes (as you mentioned) syntax without notifying GCC and
that is the problem. So GCC put's it's code in wrong syntax between two of
mine. Is't not a BUG? Really?
I think less code lines would change this bug than i wrote about it..
But need person who well knows it's code.
For now, .s postprocessor - linker(?) rises an error, stupid/blind GCC puted
some stupid code after that line i need omited problem of three asm() with
string #define. Haven't found auto definition such as exists for __SSE__ or
__MMX__ that is "activated" when -mmmx or -msse is passed to gcc command line.
Omitted problem of -masm=intel(witch could be wrong scenario with code ended by
".att_syntax") with -DGCC_SYNTAX=".intel_syntax" + -masm=intel after each mine
init ".intel_syntax" instead of turning it off to att code is passing
GCC_SYNTAX=".intel_syntax" define as string, at end of my inline blocks.
Automation of this proces is guaranted by well formated makefile, use of define
in macro is plausible and everybody happy. I suppose there is such #define
generated by GCC but i cant find it nowhere. Mentioned previous, about it but
it was some man propose for code, not definition from GCC. If You could help me
to figure out name for __INTEL_SYNTAX__(if there is such "#define") i would
appreciate it.
BTW3. I know there is lot of __buildin_mm_nameit functions, so inline asm is
useless..(someone else done hard work). Secondly i have found -save-temps(debug
of asm is working now like charm) i have learned how to write .s assembly and
figured out "offline" GAS is even better, simpler than NASM, YASM, FASM and
SASM. But, why to learn linker nameing conventions _ZN6blablav@i when you
could have C generated names, namespaces, __stdcalls etc. as simple as in MS VS
on inline asm.. that's why i need it.
So i've made past week some cool stuff and named it __stasm :)
New way of using asm made in C preprocessor(learned some cool stuff from GNU
about preprocessor), I will public it very soon.
It's very very qool thing i hope so ;) But i not hope for GNU guys :)
+ There is some other bugs i will report soon. Really BUGS in PTR[] offsets for
intel syntax(that's not working at all, but in att are working well)
I hope __stasm(Stanley asm) would be very cool even with those bugs, almost the
same form as Microsoft asm {} and there is no need to patch gcc, there is only
need for C preprocessor :)
Force with you bro. Sory for spamer mode, sory for my previous bugreport, im
shamed of it but not for this.
Cheers.
