This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc 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]

HPUX long long issue - question


i read a post, an HPUX user purportedly trying to compile binutils
using HPUX compiler (why sounds bogus, since these tools accompany gcc compiler, but maybe for gas(1) let's assume but not clap for)

his compiler fails on "long long"

i recently wrote (%99 of) a working parser for K&R's CPL (it outputs xml, the bnf for CPL a test of it)

WHY WOULD anyone inject "long long" as a syntax in C/C++ it makes no sense. it's obviously not just a type issue. one coudl use "long2" and that would fail. typdef. #define. they all expect a single string (not identifier, but keyword) while parsing.

the ISSUE i see is requiring a compiler to be forced to understand repeated type specifiers - and that this would slow down compilation while just needing to haphasardously checking for. the issue is why one would do it when it's completely incompatible, un-necessary, but also unclear. but when typdef comes into the issue a whole another batch of problems arise of how a parser must operate and be prepared to operate.

and i wonder: how is this person who did this getting keys to GNU to just alter anything they wish on servers in the USA ? that would break all current compilers ?

------------------------
an answer to the HPUX user's question would be to supply an input filter, such as m4(1), so that all "long long" -> "long2", and to in top level headers map it if need be (or let it fail if needs be). he would use a gcc option to specify, and that would do one first then the next as a script.

i'm accustomed to microsoft promoting the use of non-standard filters to prefilter C code before (cc1, cpp) get the C code, but i'm sure it had been frowned up for GNU

for GNU, failing to use indent(1) or using strange indent(1) options is frowned upon, i had thought

"There may be pitfalls when you use long long types for function arguments without function prototypes. If a function expects type int for its argument, and you pass a value of type long long int, confusion results because the caller and the subroutine disagree about the number of bytes for the argument."

well then ISO C99 is bogus. C is supposed to convert if the program indicated conversion - and a major feature of gcc (i've read an earlier version) is to know the type size and emit this need to as(1). adding a feature that can add but not divide right and doesn't convert: sounds very hackish, like if you need instructions to use it - it shouldn't be in there.

--------------------
i have another concern (other than deletion of ASM code from gcc (all accel for old processors, well i guess), addition of google? Cloog and google ld and microsoft stack fix hacks for taking gnu into their product line) and lack of clear direction on headers to use and when

BIT HACKS being inserted into gcc causing "package dependancy issues" in the host's whole unix distribution

bit hacks can be in separate distribution they do NOT have a need to be integrated inside gcc

FOR EXAMPLE. i'm making X11R7. i find this in france's radeon code they've been helping texas AMD with the linux release of i understand.

return 1 << __builtin_ctz(~n)

WHICH ONLY COUNTS BITS TO FIRST 0 BIT, IMHO

for this alone i was told i need "a new compiler".  for a bit hack.

gcc binary distribution is not the place to tuck away your favorit bit hacks. headers might be i invite that

what it does is cause false dependancy issues and forced upgrades, ie, to a gcc which has deleted ASM for i386

what it does is cause X11R7 to fail to build for no good reason at all

i edite the code and kept compiling: i'm SURE it was the only hold-back of upgrading from XFree86 4.8 (good, easy to compile) to X11R7 (nice fonts, fast web browser, i will see, was hard to compile many issues)

so DELETE already working i386 strcpy, but add bithack ? but forget better float support or bit string support?

and for that matter: gcc is not a dumping ground for "extra libs" one may not want to use, nor should it pre-require parts of X windows to compile (glibc does, maybe your libc doesn't)

i then also find _ctz bit hack not just used within gcc but gcc inserting _ctz in libs, libs that are then unusuable if _ctz is not found - while _ctz is small inline who'd know why it wasn't inline

this is akin to why linux torvals (in my own opinion) asked others not to take and use function symbols out of "unclean" kernel headers and use them in distro software. and i'd expect gcc develops to know why. dependancy issues, forced upgrades, incompatibility, stopped builds, GLIBC can't load errors, misfunctioning software and etc.

well look who's the biggest user of _ctz in gcc internal code:

gcc/longlong.h

back to header. why isn't _ctz in any head i can find in my newer debian OS distro ? all the .o in gcc have the string a if it's a symbol not an include. in debian no .h has a definition, and c++/4.4/bitset is in my include/ but does not have the .h extension but uses .h terms

i'm thinking my worry is right ... that it's a very small patch of ASM that was made a function instead of an (volatile) inline ... which is the worst of the ways bit hacks internal to gcc could be made public for use

---------------------------
thank you all for any problem i find 1000 were taken care of

John


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