Re: Warning bug with -fPIC? (was Re: Some testsuite cleanups (mostly for -fPIC))
Is this indeed a bug? Sounds like a bug. I just found something in the bug database relating to this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19232 According to Andrew (#3) it doesnt eject a warning becuase the function isn't inlined. I'm not sure thats a valid reason for not ejecting the warning. Just becuase the function can be over-ridden in another TU doesn't mean that the one that is currently declared, and called with sign differnces, shouldn't eject a warning. Kean
Warning bug with -fPIC? (was Re: Some testsuite cleanups (mostly for -fPIC))
All, This is from an email trail on gcc-patches. I was attempting to clean up differences in the test suite between -fPIC and no -fPIC tests. * gcc.dg/assign-warn-3.c: Ditto. Why in the world do you imagine this should depend on -fpic? Here's the case that passes (no -fPIC): Executing on host: /u2/gcc/head/osr5/gcc/xgcc -B/u2/gcc/head/osr5/gcc/ /u2/gcc/head/gcc/gcc/testsuite/gcc.dg/assign-warn-3.c -O3 -std=c99 -pedantic-errors -fno-show-column -S -o assign-warn-3.s(timeout = 300) /u2/gcc/head/gcc/gcc/testsuite/gcc.dg/assign-warn-3.c: In function 'g1': /u2/gcc/head/gcc/gcc/testsuite/gcc.dg/assign-warn-3.c:13: warning: pointer targets in passing argument 1 of 'f1' differ in signedness /u2/gcc/head/gcc/gcc/testsuite/gcc.dg/assign-warn-3.c: In function 'g0': /u2/gcc/head/gcc/gcc/testsuite/gcc.dg/assign-warn-3.c:9: warning: pointer targets in passing argument 1 of 'f0' differ in signedness output is: /u2/gcc/head/gcc/gcc/testsuite/gcc.dg/assign-warn-3.c: In function 'g1': /u2/gcc/head/gcc/gcc/testsuite/gcc.dg/assign-warn-3.c:13: warning: pointer targets in passing argument 1 of 'f1' differ in signedness /u2/gcc/head/gcc/gcc/testsuite/gcc.dg/assign-warn-3.c: In function 'g0': /u2/gcc/head/gcc/gcc/testsuite/gcc.dg/assign-warn-3.c:9: warning: pointer targets in passing argument 1 of 'f0' differ in signedness PASS: gcc.dg/assign-warn-3.c (test for warnings, line 9) PASS: gcc.dg/assign-warn-3.c (test for warnings, line 13) PASS: gcc.dg/assign-warn-3.c (test for excess errors) And here is the case that fails (-fPIC). I have no idea why those warnings are not being ejected when compiling with -fPIC. Perhaps I discovered a bug here by accident? I guess I should have looked at the test case more carefully instead of just trying to silence the failure. Executing on host: /u2/gcc/head/osr5/gcc/xgcc -B/u2/gcc/head/osr5/gcc/ /u2/gcc/head/gcc/gcc/testsuite/gcc.dg/assign-warn-3.c -O3 -std=c99 -pedantic-errors -fno-show-column -S -fPIC -o assign-warn-3.s (timeout = 300) FAIL: gcc.dg/assign-warn-3.c (test for warnings, line 9) FAIL: gcc.dg/assign-warn-3.c (test for warnings, line 13) PASS: gcc.dg/assign-warn-3.c (test for excess errors) Is this indeed a bug? Kean
Re: Running testsuite with extra --param argument
Not sure if it will work by try
make check RUNBTESTFLAGS="--target_board 'unix{, --param foo=blah}'"
Actuallt that runs the suites twice. Once with no extra args,
once with --param foo=blah. If you only want to run it once
try removing the leading comma. Thus:
make check RUNBTESTFLAGS="--target_board 'unix{--param foo=blah}'"
Again Im not sure if it works (I am busy building a tree ATM so
cant test it for you) but it might.
Kean
Re: Running testsuite with extra --param argument
Richard Guenther wrote:
I wonder what magic is required to run the testsuite with an extra
--param foo=blah argument. Just using
RUNTESTFLAGS="--target-board=unix/--param foo=blah"
fails because of the space, trying to be clever and doing
RUNTESTFLAGS="--target-board=unix/--param/foo=blah"
results in --param -mfoo being passed, the =blah is ignored. Escaping
the space or the = in interesting ways also doesn't seem to work.
Not sure if it will work by try
make check RUNBTESTFLAGS="--target_board 'unix{, --param foo=blah}'"
Re: Link-time optimzation
The document is on the web here: http://gcc.gnu.org/projects/lto/lto.pdf The LaTeX sources are in htdocs/projects/lto/*.tex. Thoughts? It may be worth mentioning that this type of optimization applies mainly to one given type of output: a non-symbolic a.out. When the output it a shared library or an a.out with exposed symbols (-Bexport, -E etc), then the semantics will need to be different. In the simplest case where you are producing a non-symbolic a.out, you can detect that global functions or variables are completely unused, and therefore discard them. However, if the a.out has some of its symbols exposed by linker options, then those symbols, and any other symbols or functions which they reference, must be left intact. Similarly for shared libraries, although that case is slightly worse as *any* global symbol must be left intact, unless a specific export list is being used, in which case only those symbols, and symbols which they in turn reference, need survive. At least thats my understanding. Also, this whole issue of visible symbols and shared libraries may well be covered by requirement 3, and if so, it may be worth mentioning since there was no accompanying rationale for requirement 3. Kean
Big thankyou
I recently had occasion to revisit the nightmare that is the *_SPECS madness for the SCO port. I dont know who all was responsible for it, but I want to say a huge thankyou to whoever it was that updated the compiler driver to allow for the if-then-else spec syntax. It has made my life SO much easier. Kudos. The thanks is most likely a few years late but I havent really needed to change the specs since 2.95 days :) Kean
Re: backslash whitespace newline
So I assume it is possible for an ISO 9000 environment to allow for ad hoc sed scripts to fix trivial problems, and it would be the specific institution, and not ISO 9000, that is broken (IMHO) if anal rule prevented such utilitarian acts? ISO9000 is a pretty broad word these days. As someone amusingly pointed out, you can ride in an ISO9000 taxi. When I raised the point about not using a sed script to change code becuase of implications in an ISO9000 environment, I was talking about a slightly more "normal" usage of the term "ISO9000". It is common, in military and government work, especially when the contracts span multiple governments, that you have to be "ISO9000 compliant". Yes, the standards body in whatever country you work have to verify that you do have coding practices and procedures defined and that you do adhere to them, but thats not the important audit. Certainly in the environment in which I worked, it was the project itself that audited the procedures to make sure they were sane. So the standards body tests your adherance to the procedures, but the client tests the quality of the procedures themselves. I have limited exposure to ISO9000 environments but the one in which I did work, where the software was responsible for maintaining billions and billions of dollars of equipment across multiple government boundaries, those procedures were anal in the extreme. Every single line of code had been audited, both internally and by two independent auditors. The procedures we had to follow to make even a single line change in parts of the system ran into months. In such an environment, "just use a sed script" is a totally unacceptable solution. It was actually *easier* for us to move from Sunpro cc to gcc than it was to make changes to certain parts of the system. Part of the reason is that compilers were frequently "certified" for a much broader range of products, so once it was on the customer's "approved" list, we were free to change compilers. Of course, we didn't have code that had funky newline problems :) Kean
Re: backslash whitespace newline
worrying about other compilers in my opinion. Having gcc compile
non-portable code accepted by other compilers is a useful goal, but
one of low priority compared to maintaining compatibility as far as
possible between gcc versions.
You mean like the change between 2.95 that worked the way Howard
wanted it to, and 3.x (I dont know the value of x where the change
happened) where it doesn't?
This compiles on 2.95.3:
(There is whitespace at the end of the following line)
// comment \\
int x = 0;
int y = 1;
int foo() { return x + y;}
But doesn't on 3.4.4. I dont have earlier versions of 2.x or 3.x
to narrow it down further. Sorry. I beleive Pinski posted the
actual changelog entry where the change occured.
Kean
Re: backslash whitespace newline
You still have not demonstrated that this is a real problem. If someone is having a real problem, then we can offer them a simple sed script to fix it. If I am recalling the original posting correctly, the fact that gcc behaves differently to "most other compilers" is the actual problem. Issues relating to code correctness, user brain-deadednes, or even just sensible practices are rather moot. gcc can be the only Johnny in step, or it can behave, as Mr. Hinnant was suggesting, the way everyone else does and adopt the de-facto standard. Writing sed scripts that change source code is likely to be very unpalletable to some users. If you're working in an ISO9000 environment where every single source line change is tracked by a rather burdensome process, the last thing you want to do is invoke that process for some source base simply because the new compiler you are moving to behaves differently to the last 5 compilers you used. Just my $0.02. Kean
Re: RFC: future gfortran development and subversion
I saw no postings that contained anything like a design for doing this, etc, to the dev list from you. http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=106243 Of course, you seem represent this thread you started as having actually involved any subversion developers, which it didn't, AFAIK, and as something that was potentially productive, which it stood no chance of being, given how you wrote it. I dont know what you are refering to Dan. If there was something wrong with the message quoted above please educate me (off this list), becuase if there was something wrong with what I wrote I just don't see it. Please note the last paragraph. I am *volunteering* to make it happen. I asked for advice or pointers. What replies did I get? "use svn export". Can you please stop fear-mongering? Say what??? Expressing an opinion that something is unlikely to happen, based on lengthy discussions that indicate they wont, is fear mongering? Come onnn. You are being hyper critical, and its not necessary. This thread has contained numerous reponses with concerns about the move to svn, or problems users were having with the prototype etc. I don't see you getting bent at anyone's post other than mine. I'm not being paranoid here either. When you first announced on the list the move to svn, I asked simply: http://gcc.gnu.org/ml/gcc/2005-10/msg00054.html "What is the actual problem you are trying to solve". The mail was polite, respectful, non-inflamatory. I was told to shut the f*** up and read the list archives because I was entering the discussion late. But let someone *else* ask pretty much the same thing: http://gcc.gnu.org/ml/gcc/2005-10/msg00545.html And he gets polite, informative responses. If my FQDN offends you that you (and others) are being so critical and in many cases downright rude, please remember: I am an individual, not a corporation. My personal views are wildly divergant from my employers. This list is starting to feel downright hostile. Its unprofessional and uncalled for. But maybe thats just acceptable behaviour if you're bashing the SCO guy. I may be just an email address you respond to but I assure you I am a real, live human being, with real feelings that are capable of (and recently, rather frequently ARE) being hurt. But that's my problem, not yours. In case it is not clear to you, and other GCC folks, let me assure you that it is no accident that the only two projects I wish to spend my time on are svn and gcc. I have a tremendous amount of respect and admiration for the developers and designers of both tools. I am constantly amazed and impressed at the quality and sometimes just sheer brilliance present in both. And this is not idle flattery, it is very sincerely meant. So please, in future, try not to look on my mails as negative, for I *never* intend them to be so. Sincerely, Kean.
Re: RFC: future gfortran development and subversion
I fear the impending switch to subversion will have a negative impact on the future development of gfortran due the rather limited number of people who actually supply patches and the sudden increase in hardware requirements. For example, I find troutmask:sgk[204] du -sh gcc40 gcc41 trunk 241Mgcc40 <-- CVS 4.0 branch 275Mgcc41 <-- CVS mainline 694Mtrunk <-- svn mainline This is one of the less fortunate aspects of svn. A lot of that increased space is due to the fact that every single file in the repository is duplicated. Once in its normal location, and again in the .svn directory. This "feature" has been much-discussed. Search the svn archives for "textbase penalty". I am glad I am not the only one who feels that duplicating every single file is a problem. If you bring it up on teh svn list though, be prepared to be regailed with the merrits of being able to sit on an aeroplane and do an 'svn diff' with no access to the repository (because we all know that most serious developers spend most of their time in planes, unattached to their repo network). I recently tried to re-open the discussion on the svn list but got nowhere. I would *dearly* love to see an option to svn that uses a simple checksum or something to figure out if a file has changed, or an 'svn edit' that copies the file to the textbase on an as-needed basis. I fear it will never happen though. I too have to purchase a new hdd to do gcc work on, because my 8G drive just isn't enough any more. On the bright side, I will be replacing an old SCSI-II hdd with a 140G U320 drive, so svn can check the files out in triplicate for all I care :) Kean
Re: Updating a subversion directory?
In fact, I believe that using "username@" does not work when using SVN over http://. You have to use --username for that (and yes, it sucks). I long ago wrote a 'gccvs' script that simply reads: #! /bin/ksh export CVS_RSH=ssh cvs -d :ext:[EMAIL PROTECTED]/cvs/gcc $@ and I now reflexivly type 'gccvs update' or whatever. I fully anticiptae creating a similar 'gccsvn' and adding and special args I need to get it working. This way you aren't surprised by accidental environment variable changes etc. Maybe you want to do that if you dont like using --username all the time. Kean
Re: [cft] aligning main's stack frame
This should get more than just bootstrap testing. Anyone care to help out here? I'm bringing my mainline tree up to speed, as all the porting work I recently did was on the 4.0 branch, but once that's done I'll be glad to help out. Aside from the full testsuite, I will compile up Xorg and an internal package I have which is a collection of about 70 different open source libraries (gtk, cairo, libxml2 etc) and perl and apache/php. If that all works, then thats about as well tested as I can think to get. Its a lot of code, some of which really stresses the compiler (Xorg and Perl in particular). Kean
Re: About the alignment of main
Intuitively, it seems like that would work. Comments? Suggestions? Never mind ... forget that last mail. It's %ebp that needs to be aligned not %esp and I really do need to do that in the crt stuff so that the original stack frame pre-main is correct. Kean
About the alignment of main
Ok, with the current patch I have to prevent sibcall optimization in main (the patch isn't final, but thats not important, the problem will be fixed somehow) I am now getting much better results from the testsuite. However, I am still running into problems when a function is inlined into main and it uses alignment sensitive functions. The comment for 'FORCE_PREFERRED_STACK_BOUNDARY_IN_MAIN' clearly states that it will align the stack nicely for all calls from main, but does nothing for the alignment of main itself. I realize that I should probably fix this in the crt code such that main always enters aligned (as discussed previously here). However, I was wondering whether gcc couldn't help with even that, and actually align main itself (given some suitable target macro like TARGET_IS_LAME_AND_DOESNT_ALIGN_MAIN). The way I would see this working is thus. gcc detects that it is dealing with the function "main". If it does and T_I_L_A_D_A_M is set, it emits the code for aligning the stack as it currently does, then makes a call to a local label, and does a normal return from main. So you go from something like this: main: pushl %ebp movl%esp, %ebp pushl %edi push%esi subl$64, %esp andl$-16, %esp / Stack now aligned normal main code here popl%esi popl%edi popl%ebp ret To something like this: main: pushl %ebp movl%esp, %ebp pushl %edi push%esi subl$64, %esp andl$-16, %esp / stack now aligned movl16(%ebp), %eax pushl %eax/ argc movl12(%ebp), %eax pushl %eax/ argv movl8(%ebp), %eax pushl %eax/ envp call.temp_main_label addl$12, %esp popl%esi popl%edi popl%ebp ret .temp_main_label: ... rest of main code here ... Intuitively, it seems like that would work. Comments? Suggestions? Kean
Re: Severe problems with vectorizing stuff in 4.0.3 HEAD
Yes. You can thank Intel for this.
Thank you Intel :)
With the introduction of SSE1, something had to change in order
to satisfy hardware constraints. Intel initially proposed some
scheme that performed dynamic stack alignment in functions that
use SSE1 instructions, and multiple entry points to avoid
redundant realignments.
Ok I am no compiler expert, so this may be totally impossible,
and if so I'd appreciate an education, but this is what I
instinctively thought of when first thinking about this problem.
There are a very limited number of instructions that require
16-byte alignment. The two main places you have to worry about
that alignment are when passing arguments to a function, and
local stack variables. I guess the compiler is safe to assume
that if you are using normal memory, say from a malloc() to
hold the alignment-sensitive data that you have done your
own alignment. So lets take the first case. You have some code
that is going to be passing some vector parameter, something
that is alignment-conscious. I am assuming the compiler knows
that. Before pushing the data onto the stack, the compiler
could arrange things such that those parameters would be
neatly aligned on a 16-byte boundary. The only assumption
that would need to hold true is that the called function was
also compiled with gcc. Using imaginary data types here, where
int128_t is alignment-sensitive, suppose we had:
int func (int128_t x, int y, int128_t z) {
}
int otherfunc (void) {
int128_t foo = 123;
int128_t bar = 234;
return func(foo, 0, bar);
}
When generating teh call to func(), could gcc not align the
stack to 16-bytes, such that the first argument is propperly
aligned. You then push the next argument, a simple 4-byte
, and then re-align to the next 16-byte boundary for the
third argument. the code in func() could take this scheme
into account, and know the exact offsets into the stack that
it needs to get to the args.
The second case is where you have function-local variables
that are alignment-constrained. In this case, wouldn't
simple analysis of the function contents determine whether
or not any alignment-specific insns are being used, and
if so, to automatically align the stack to 16 bytes if
there is. That way, only those functions that actually use
such insns pay the (small) penalty of rounding up the stack.
If cxourse, all of that could be consitional on targets
that don't always align functions on a 16-byte boundary.
This seems far less invasive that redefining an ABI.
GCC code will interoperate with other compilers if you don't use
the 128-bit vector modes, but if you do, then we *require* that
the stack be maintained aligned.
I think, and I may be wrong here, but I think if I simply
make sure that entry to main is correctly aligned, then
the majority of code will just work. Assuming I am compiling
some program with gcc, if main is correctly aligned, and all
gcc code goes to lengths to ensure that alignment, then the
only time it can get *out* of alignment is if gcc code has
made a call to non-aligned libc code, which in turn makes
calls back into gcc code (a la qsort, ftw, etc). Those cases
are relatively rare. The only other time it's likely to be
an issue is with signal delivery, and I am pretty certain I
can persuade the kernel folks to ensure that the stack frame
is always aligned to 16 bytes when that happens.
Kean
Re: Severe problems with vectorizing stuff in 4.0.3 HEAD
Yes, in fact that's *exactly* what GCC is assuming. And it will be true for all code that GCC generates. How can that possibly ever work? Is the assumption then that the only code GCC will ever work with is code that GCC compiled? In effect what this implies is that GCC is re-defining the ABI. It also means it is impossible for GCC to inter-operate with vendor supplied libraries like libc. If I use a libc function that has a callback, like ftw() or bsearch() or qsort(), then I cannot have them call a function that was compiled with gcc, becasue no ABI previously defined has made it a requirement for every stack frame to be 16-byte aligned. Kean
Re: Severe problems with vectorizing stuff in 4.0.3 HEAD
It indicated that sibling calling optimization in main should
be disabled for targets that need to up the stack alignment,
otherwise you get the stack alignment of a lower one than
While that may be true, I think the problem is broader.
I took out the main1() function and put it into a separate
file, and compiled just that. So now there is no carnal
knowledge of main or its stack alignment. The generated
code for this stand-alone main1() makes no attempt to
align the stack or the stack variables it is going to be
passing to the movdqa instruction. Unless thats what you
mean by:
that is required. You have to look to see what changed
between 3.4.0 and 4.0.0 that caused this since it is a
regression. I think the issue is that we are detecting them
at the tree level but not rejecting them when expanding. So you
have to look at the expand functions for that.
You're using internals verbiage thats beyond me :) I'm a
simple porter, I have very little understanding of the actual
internals of GCC.
The reason why nobody notices this before is because most x86 OS's
now a days align their stack going into main as 16byte aligned
which was what my comment about fixing your OS was about, it was
more of a joke rather than anything else.
Ok I appologise Andrew. I took it as a SCO-bash. My bad.
However, I dont think the stack being aligned on a 16-byte
boundary into main will help, unless GCC is assuming (and I
dont see how it possibly could) that every function would
likewise be aligned. The fact that a stand-alone version of
main1() was not correctly aligned leads me to believe that
the real error is that gcc is not making an attempt to
align the stack variables for use by the alignment-sensitive
vector insns.
Also, when you say "stack going into main is 16 byte aligned",
what specifically do you mean? that its 16-byte aligned before
the call to main() itself? That at the first insn in main, most
likely a push %ebp, its 16-byte aligned (i.e does the call
to main from crt1.o have to take the push of the return address
into account)?
Kean
PS, here is the generated assembly for main() as a stand-alone
function, nothing else defined in the .c file:
.file "foo.c"
.version"01.01"
.section.rodata
.align 32
.type C.0.1458, @object
.size C.0.1458, 32
C.0.1458:
.long 0
.long 3
.long 6
.long 9
.long 12
.long 15
.long 18
.long 21
.text
.align 16
.globl main1
.type main1, @function
main1:
pushl %ebp
movl$8, %ecx
movl%esp, %ebp
pushl %edi
cld
pushl %esi
leal-40(%ebp), %edi
subl$64, %esp
movl$C.0.1458, %esi
rep
movsl
xorl%edx, %edx
leal-40(%ebp), %esi
leal-72(%ebp), %ecx
.align 16
.L2:
leal0(,%edx,4), %eax
addl$4, %edx
cmpl$8, %edx
movdqa (%esi,%eax), %xmm0
movdqa %xmm0, (%ecx,%eax)
jne .L2
movb$1, %dl
.align 16
.L4:
movl-4(%ecx,%edx,4), %eax
cmpl-4(%esi,%edx,4), %eax
jne .L14
incl%edx
cmpl$9, %edx
jne .L4
addl$64, %esp
xorl%eax, %eax
popl%esi
popl%edi
popl%ebp
ret
.L14:
callabort
.size main1, .-main1
.ident "GCC: (GNU) 4.0.3 20051013 (prerelease)"
# cat foo.c
#define N 8
int main1 ()
{
int b[N] = {0,3,6,9,12,15,18,21};
int a[N];
int i;
for (i = 0; i < N; i++)
{
a[i] = b[i];
}
/* check results: */
for (i = 0; i < N; i++)
{
if (a[i] != b[i])
abort ();
}
return 0;
}
Re: Severe problems with vectorizing stuff in 4.0.3 HEAD
Can you try -fno-optimize-sibling-calls and see if that works?
Yes, it did, thank you.
If so, then the problem is that we sibling calls should not be
done in main. To fix the testcase anyways to be correct is to
put "return 0;" after the call to main1. Since right now the
return of main could be anything.
I don't think the test case is inocrrect. In a nutshell,
it has:
int main1() {
... stuff ...
return 0;
}
int main(void)
{
return main1();
}
That should be perfectly valid, and return 0 from main1
which subsequently returns 0 from main.
What does the fact that -fno-optimize-sibling-calls worked
indicate really? Without that option something really does
seem to be mis-calculating the stack offsets by 4. What may
be of interest here is that aside from the vect/* tests,
the only other test that is failing is sibcall-6.
Kean
Re: Severe problems with vectorizing stuff in 4.0.3 HEAD
Can you just fix your OS instead? My OS is just fine, thank you very much. You disappoint me. I expected better from you. It is most likely of absolutely no consequence to you, and this has nothing to do with GCC so this is the very last I will say on this subject to you, but you really did hurt me with your comment. Hurt *me*, specifically, the person trying to help out with GCC. If you are upset at what other people in my company are doing, I would humbly request you take it up with them and leave me out of it. Thank you. Kean
Severe problems with vectorizing stuff in 4.0.3 HEAD
All, I am getting a lot of test suite failures with almost all of the vect/* tests. I am using pr18400.c from the test suite as an example here, becuase its about the smallest one I can find. Here is what is generated at -O2: .file "pr18400.c" .version"01.01" .text .align 16 .globl sig_ill_handler .type sig_ill_handler, @function sig_ill_handler: pushl %ebp movl%esp, %ebp subl$20, %esp pushl $0 callexit .size sig_ill_handler, .-sig_ill_handler .align 16 .globl check_vect .type check_vect, @function check_vect: pushl %ebp movl%esp, %ebp subl$16, %esp pushl $sig_ill_handler pushl $4 callsignal /APP .byte 0xf2,0x0f,0x10,0xc0 /NO_APP popl%eax popl%edx pushl $0 pushl $4 callsignal addl$16, %esp leave ret .size check_vect, .-check_vect .section.rodata .align 32 .type C.0.1905, @object .size C.0.1905, 32 C.0.1905: .long 0 .long 3 .long 6 .long 9 .long 12 .long 15 .long 18 .long 21 .text .align 16 .globl main1 .type main1, @function main1: pushl %ebp movl$8, %ecx movl%esp, %ebp pushl %edi cld pushl %esi leal-40(%ebp), %edi subl$64, %esp movl$C.0.1905, %esi rep movsl xorl%edx, %edx leal-40(%ebp), %esi leal-72(%ebp), %ecx .align 16 .L6: leal0(,%edx,4), %eax addl$4, %edx cmpl$8, %edx *** At this point, the registers have the following values: *** %eax = 0, %ecx = 0x8047d84, %edx = 4, %ebx = 0x8047dec *** %esi = 0x8047da4, %edi = 0x8047dc4, %ebp = 0x8047dcc *** This is guaranteed to cause a SIGSEGV, and it does, becuase *** %esi is aligned on a 16-byte boundary. But ... see below ... movdqa (%esi,%eax), %xmm0 movdqa %xmm0, (%ecx,%eax) jne .L6 movb$1, %dl .align 16 .L8: movl-4(%ecx,%edx,4), %eax cmpl-4(%esi,%edx,4), %eax jne .L18 incl%edx cmpl$9, %edx jne .L8 addl$64, %esp xorl%eax, %eax popl%esi popl%edi popl%ebp ret .L18: callabort .size main1, .-main1 .align 16 .globl main .type main, @function main: pushl %ebp movl%esp, %ebp pushl %ecx pushl %ecx andl$-16, %esp subl$16, %esp callcheck_vect leave *** Looks like it was trying to align the stack on a 16-byte *** boundary here. But on entry into main1(), its doing 3 *** push's at the beginning. Thus teh offsets into teh stack *** (like the leal -40(%ebp), %edi close to the top of main1) *** appear to be being incorrectly calculated. jmp main1 .size main, .-main .ident "GCC: (GNU) 4.0.3 20051013 (prerelease)" Thats the first problem. I then compiled with -O6, and got this: .file "pr18400.c" .version"01.01" .text .align 16 .globl sig_ill_handler .type sig_ill_handler, @function sig_ill_handler: pushl %ebp movl%esp, %ebp subl$20, %esp pushl $0 callexit .size sig_ill_handler, .-sig_ill_handler .align 16 .globl check_vect .type check_vect, @function check_vect: pushl %ebp movl%esp, %ebp subl$16, %esp pushl $sig_ill_handler pushl $4 callsignal /APP .byte 0xf2,0x0f,0x10,0xc0 /NO_APP popl%eax popl%edx pushl $0 pushl $4 callsignal addl$16, %esp leave ret .size check_vect, .-check_vect .section.rodata .align 32 .type C.0.1905, @object .size C.0.1905, 32 C.0.1905: .long 0 .long 3 .long 6 .long 9 .long 12 .long 15 .long 18 .long 21 .text .align 16 .globl main1 .type main1, @function main1: pushl %ebp movl$8, %ecx movl%esp, %ebp pushl %edi cld pushl %esi leal-40(%ebp), %edi subl$64, %esp movl$C.0.1905, %esi rep movsl xorl%edx, %edx leal-40(%ebp), %esi leal-72(%ebp), %ecx .align 16 .L6: leal0(,%edx,4), %eax addl$4
Re: Passing va_args...
I'am looking for some way to pass variable arguments to another function that receives variable arguments without using va_list. This is impossible. USL C has a very neat construct called '&...' which was designed for exactly this purpose. One day when I have idle cycles (yeah right) I will look into adding this as an extension. Kean
Re: Whats the real penalty of non-mmap ggc?
Ideally, though, you would find some chunk of address space that is always free on your OS and just use that with mmap; that's pretty much guaranteed to be faster and more reliable. Aha thanks. I looked at host-linux.c and adapted its gt_pch_get_address to taste, added that to host-sco.c and now all the tests pass. Thanks for the pointer (no pun intended). Kean
Whats the real penalty of non-mmap ggc?
Hi all, After days spent trying to get a clean gmake check run, I am down to the last few failures. They are all related to the PCH tests, and they all fail the same way: "largefile.c:1: fatal error: had to relocate PCH". Previously, *all* PCH tests were failing but I crafted a host file that uses MAP_FIXED and now only this one test fails. However, if I pretend that mmap() doesn't exist in ggc-page.c and fall back on valloc, then everything passes. But the comments say that is not the prefered solution. My question is: exactly what kind of penalty would I pay if I forced the use of valloc() versus using mmap? Any advice greatly appreciated. Kean
Re: DejaGNU test case assistance please?
You're in luck! dg-warning and similar directives can be skipped or
xfailed for particular targets, but those don't take options into
account. There is, however, an effective-target keyword for fpic.
Ok I'll give that a whirl. But what if I needed to skip the test
based on some other command line option? Intuitively, I would want
to use dg-skip-if or dg-xfail-if, which provide a more generalized
approach to command line checking and doesnt rely on that special
target.
The directives used in the GCC testsuite, along with effective-target
keywords and target/xfail selectors, are documented at
http://gcc.gnu.org/onlinedocs/gccint/Test-Directives.html.
I read that carefully before asking the question, and it is very
unclear (to me, a non-DG head) what the scope of some of those
directives are. For example, dh-skip-if seems to apply to the
entire test case, whereas things line dg-warning can appear on
a line-by-line basis. Or perhaps I'm just assuming that, and they
can in fact be used on a line-by-line test basis.
For example, in gcc.dg/assign-warn-3.c, how would I
ignore the check for a warning if -fPIC is used?
Any help greatly appreciated.
Something like
{ dg-warning "regexp" { "" { target { ! fpic } } } }
This is purely for my education's sake (the fpic target you
mentioned will suffice for the specific case I care about), but
if I wanted to, say xfail the test if -mfoo was specified on the
command line: Could I have something like:
foo(); /* dg-warning "regexp" { ! dg-skip-if { "" { i?86-*-* } { "-mfoo"
} { "" } } */
The tcl syntax makes my head hurt so if thats wrong and you can
show me a generalized way to do this type of thing I would be
very grateful. Thank you Janis!
Kean
DejaGNU test case assistance please?
Hi, Is there a way to exclude specific line tests based on target switches? Something like dg-skip-if? Or perhaps thats the right think to use (but all the examples I have seen seem to skip the entire test case). For example, in gcc.dg/assign-warn-3.c, how would I ignore the check for a warning if -fPIC is used? Any help greatly appreciated. Kean
Re: target-defs.h / tm.h question
Are the comment /* Note that if one of these macros must be defined in an OS .h file rather than the .c file, then we need to wrap the default definition in a #ifndef, since files include tm.h before this one. */ and the description in tm.texi of these macros as defined in the .c file (not in tm.h) insufficiently clear about the principle? Sarcasm unneccesary. Its a big file, I didnt read every line of it. But thank you for the reply it answered my question. Kean
target-defs.h / tm.h question
Hi, Is there any reason why *all* of the macros in target-defs.h are not conditionalized? target-defs.h is always included after tm.h, so if the target specific include sets any of the macros that are not protected in target-defs.h, they get overwritten. Yes, you are warned, so my question is, is the intent to only conditioalize those macros that have actually been defined ib the target header file and to adjust target-defs.h on a case by case basis, or should I just clean up target-defs.h and protect *all* of the macros from redefining what may have been set in tm.h? Thanks for any input. PS. The specific case I ran into was I needed to define TARGET_PROMOTE_FUNCTION_RETURN but target-defs.h was not protecting its definition thereof with a #ifndef. Kean
Re: Moving to subversion, gonna eat me a lot of peaches
Rather than starting up this discussion on gcc@ again, could you please go read the list archives? I feel like you've missed a couple of years of context here, including the last few times we discussed why a switch was in order. Its not necessary, I wasn't trying to start a debate. I was simply answering Daniel's question. I'm just a lowly consumer, I will use whatever tool is required to access the sources. Kean
Re: Moving to subversion, gonna eat me a lot of peaches
Why doesn't it thrill you? I think svn is a great tool, don't get me wrong. Very well written and got all the features one could want. But I don't know (or see) the actual problem you are trying to solve. cvs seems to be wroking really well for gcc. The weaknesses of cvs, such as the pain of renaming and moving directories, isn't really an issue for that codebase (at least not very often). Maybe I am just being too conservative but for a project as stable and vital to teh community as gcc, changing something as fundamental as its SCM should come with a pretty big long set of justifictions (all coolness factors waived). There's a lot of infrastructure behind the current CVS (all the ssh access control, integration with bugzilla, automated mailings, all manner of things) that would need to be updated. Its not just a matter of changing the repository format and fixing viewcvs. I know you are aware of all of that too, this isn't news. So I guess I'd like to know: what is the actual problem or problems you aim to solve by moving to svn? then I hope that the repo will be an FSFS one and not BerkeleyDB? Yes. I'm a subversion developer. I'm pretty aware of the problems in BDB. :) I knoew your name sounded familiar :) Kean
Re: Moving to subversion, gonna eat me a lot of peaches
Daniel Berlin wrote: So, now that the new machine is working, i'm starting to get a lot of questions about moving to subversion. If you're going to move to svn (which idea doesn't thrill me) then I hope that the repo will be an FSFS one and not BerkeleyDB? I realize that FSFS hasn't has as much airtime as BDB but I think the FSFS model is intrinsically better than the BDB one. A filesystem is a lot more likely to be bug-free than BDB is. There are also a plethora of tools you can fix FS problems with, but almost nothing you can fix BDB databases with. Kean
Re: GCC 4.0.2 Released
I'd appreciate feedback. (I don't promise to be bound by the majority view, though.) I seem to recall in the past that they did patch releases. From both a tagging purity point of view and reproducability point ov view, why not create a branch off 4.0.2, apply the fixes that were missed, tag it as 4.0.2.1 and release that? Kean
Re: Problem building 3.3.6 (with 3.4.4): xgcc: cannot specify -o with -c or -S and multiple compilations
Libtool ... automatically implies Something is very fscked up I have had no end of bad luck, and very little good luck, with libtool. Not to mention that its use (at least in stock 1.4.3) breaks paradigms like 'make install DESTDIR=blah' But this is gcc list, not a libtool list, so I will just wish you good luck and my condolences go out to you. Debugging libtool can be extremely painful. Kean
Re: Problem building 3.3.6 (with 3.4.4): xgcc: cannot specify -o with -c or -S and multiple compilations
Andrew Walrond wrote: Can anybody explain what this error might mean? /tmp/gcc-3-3.heretix/work/gcc/xgcc "" -B/tmp/gcc-3-3.heretix/work/gcc/ ^^^ -c ../../../../gcc-3.3.6/libstdc++-v3/libsupc++/guard.cc -fPIC -DPIC -o guard.o ^^ gcc sees those as two input files (two non-option arguments). I suspect somewhere along the line you have something like CFLAGS='""' by mistake, or somehow the string "" is being passed into CFLAGS. Chekc your environment and whatever args you gave to `make bootstrap' Kean
Re: Uninitialized use warning message
program that is completely unrealistic. However, warning at 2 should be trivial. Unfortunately, it isn't. This warning happens very late in the processing, after a lot of mangling has been done. Take: I really mean't to sat trivial by comparison :) The point you raise about all the mangling and reordering and other things that happen to teh code is what I feared would cause the trouble. I just don't know enough about the data structures involved to know if producing the new warninging message is even possible. I dont know how the current warning message is even calculated, and I need to go stare at some code to find out how before I must either give up on this idea or start asking annoying intenals questions :) But at least I know people aren't opposed to the idea, so I wont be wasting my time trying. Kean
Re: Uninitialized use warning message
A common situation would be:
if (condition) {
flag = 1
msg = "Hello World";
} else
flag = 0; [1]
...
if (flag)
printf ("I say, %s\n", msg); [2]
Point [1] is where I "fail" to init 'msg', point [2] is where I
use it. I know that the program is safe, and if the flow analysis
can relate 'flag' and 'msg' then the warning would go away.
Which one would we want listed in the proposed new warning, 1 or 2?
Definately 2. I wont say it is *impossible*, but I think
it is asking way too much of the compiler to warn about 1.
It implies a level of understanding of the flow of the
program that is completely unrealistic. However, warning at
2 should be trivial. Where this level of detail in the
warning is useful is if you have a particularly large function,
with the variables declared at the top (not at the top of, say,
and enclosing if() block). Its even worse when the code is
full of pre-processor conditionals. By telling me that 2
(or all instances of type 2), it saves me looking at *every*
usage of msg. It's just plain more useful, IMHO :)
Kean
Uninitialized use warning message
Hello everyone, There is a warning message I would dearly love to see improved a little. Its the one where you use a variable without it being initialized first: foo.c:123: warning: `foo' might be used unitialized in this function Obviously, there was some code somewhere that used variable `foo' to trigger the warning. What I would dearly love to see is the warning message be a bit more informative, along the lines of: foo.c:123: warning: `foo' might be used unitialized in this function foo.c:234: warning: possible use of unitialized `foo' foo.c:345: warning: possible use of unitialized `foo' You get the idea. Does anyone else think this would be useful? Do we even have sufficient data available to be able to produce such warnings? I figured I'd ask first before diving into the code. Kean
General problem with x86 and PIC
Hi everyone, I've filed #23224, which outlines some pretty substantial problems with PIC on x86 targets (at least 2). This was all tested on 3.4.4, but very similar, if not exact, failures exist on the head of the 3_4-branch, and on the 4_0-branch too. I havent tried top-of-tree. I doubt this is fixed there either. If I can help at all, please let me know. I can produce any kind of assembly / compiler pass dumps required to help anyone who may understand all of this. TIA. Kean
ICE and reg class problems in 3.4.5-20050801 in g++.dg/eh/simd-2.C
Hi all,
I'm getting the following ICE when testing $subject:
simd-2.C: In function `int __vector__ vecfunc(int __vector__)':
simd-2.C:14: error: insn does not satisfy its constraints:
(insn 41 40 35 0 (set (reg:SI 21 xmm0 [ beachbum+12 ])
(mem:SI (plus:SI (reg/f:SI 6 bp)
(const_int -4 [0xfffc])) [0 S4 A8])) 37
{*movsi_1_nointernunit} (nil)
(nil))
simd-2.C:14: internal compiler error: in reload_cse_simplify_operands,
at postreload.c:391
That's pretty much gobbldygook to me, but I see that other
X86 targets aren't having this problem, so it's something with
my port. And guidance as to what it could be would be greatly
appreciated.
I dont know if its related but I also get other errors
(not ICE) when compiling a few things in PIC mode. For example:
gcc.c-torture/compile/2804-1.c: In function f:
error: can't find a register in class `GENERAL_REGS' while reloading `asm'
If anyone can point me in the right direction I'd be most grateful.
Kean
Re: gcov weirdness: local lable being declared
I don't understand why the .type and .size information is useless. Just some further information ... gas thinks it's useless too. The information is recorded in the object file. I've seen various No, it's not. At least not with gas 2.15.90.0.3. Just is just silent about it. The SCO assembler is producing a warning because if you have .type and .size for a sybol or lable for which those things have no meaning, it warns you in case you meant to do something else with the symbol. I believe the warning message is valid. In my original post, I asked if checking TREE_STATIC would be the right thing. While it does shut the warning up, I don't think it is. What we'd really need is some way to mark a tree as internal. Then in coverage.c, mark the contructed variable that way. For example, TREE_INTERNAL (gcov_info) = 1. The only problem is that in order to do this, we would need to invent a new bit in tree_common. Although there is an unused bit available, I am not sure this has wide enough utility to justify using it. But maybe it does. I leave it up to the experts to decide. An second solution would be to have create_coverage() use a symbol name that isn't an internal lable. For example, prefixing it with __gcov_. That also solves the problem. A third alternatie would be to make A_D_O_N smarter, and check to see if the first character of the name is a period, and not eject the .size and .type if it is. Anyone care to advise what the best course of action would be? I'm leaning towards the second solution. Kean
Re: gcov weirdness: local lable being declared
I don't understand why the .type and .size information is useless. Becuase its for a local lable only, not anything thats intended to wind up in the symbol table? I'm not sure what meaning a type and size has for a local lable like that? Kean
gcov weirdness: local lable being declared
Hi everyone,
I am getting weird warning messages from my assembler when
gcov is being used. I have tracked what I think is the
problem down but I don't really know how to fix it. The
bit of assembler that causes the warning is:
.type .LPBX0, @object
.size .LPBX0, 52
.LPBX0:
... whole bunch of initialization stuff
The assembler warns that the .type/.size directive is useless.
This is causing many testsuite failures. The assembler is
right. Why is a local lable being declared as if it was a
global symbol? .LPBX0 comes from ASM_GENERATE_INTERNAL_LABEL.
The problem seems to start in coverage.c:create_coverage().
Fairly close to the top of that is a call to assemble_variable().
assemble_variable(), ends up calling ASM_DECLARE_OBJECT_NAME.
This is what is emitting the .type and .size directives.
Is there some way that the tree can be marked as an internal
construct, and if that is set, not have the bit of code in
assemble_variable() call ASM_DECLARE_OBJECT_NAME? Or perhaps
I can train A_D_O_N to not emit anything if its a local?
I see that the tree in question is declared static. Would it
be the right thing to have something like this at the end of
assemble_variable:
if (!TREE_STATIC (decl)) {
#ifdef ASM_DECLARE_OBJECT_NAME
last_assemble_variable_decl = decl;
ASM_DECLARE_OBJECT_NAME (asm_out_file, name, decl);
#else
/* Standard thing is just output label for the object. */
ASM_OUTPUT_LABEL (asm_out_file, name);
#endif
}
I am not sure if "if (TREE_STATIC (decl))" is the correct test.
Is there a better test that I can check for an internal lable?
Thanks in advance for any insight.
Kean
Re: Guidance please: static or extern __inline__
That's a pretty neat trick.
I know, we've filed a patent for it, wait for it, no, wait, ok, just
kidding... :-)
Hehehehe :)
I dont suppose I could trouble you to give me the voodoo required for
inserting an extra pushl before the call could I?
Not sure exactly what you want, but with the below I think it will be
obvious how to do it.
void ioctl(int, unsigned long, char *) __attribute__((always_inline));
asm inline void ioctl(int fd, unsigned long m, char *buf) {
movl#42, 12($esp)
movlfd, 8($esp)
movlm, 4($esp)
movlbuf, ($esp)
call_xioctl
xorl$eax, $eax
leave
ret
}
That does help with teh general mechanism. Unfortunately I can't
use inline, becuase ioctl is supposed to be declared as
int ioctl (int, int, ...);. I dont think you can have variadic
inline's can you?
This whole notion of fixing ABI issues in header files makes
my you-know-what's ache. Of course the *rest* of the world
has decent symbol versioning, but some of us are left in the
approximate mid-90's :(
I think I may just cheat and declare ioctl incorrectly, and
put in the 3rd arg. I suspect that is the path of least
resistance, although I have no doubt it will break some
standard. But since I'm shooting for a working, real-world
compiler, I find myself strangely comfortable with the idea
of ignoring a miniscule subclause here and there in a
standard I'm not certifying to :)
Thanks for all your help tho. It's much appreciated.
Kean
Re: Guidance please: static or extern __inline__
[ cough ]
#if _FILE_OFFSET_BITS - 0 == 32
int open (const char *, int, int) asm ("open32");
#elif _FILE_OFFSET_BITS - 0 == 64
int open (const char *, int, int) asm ("open64");
#else
int open (const char *, int, int) asm ("__open");
#endif
That's a pretty neat trick. I dont suppose I could
trouble you to give me the voodoo required for
inserting an extra pushl before the call could I?
PS this trick you described here is great for variadic
functions like open and ioctl. It is the ioctl case
where I need to push an extra arg and then call a
fn called _xioctl. Your assistance would be very
much appreciated. Thanks Mike.
Kean
Re: Guidance please: static or extern __inline__
So, can I summarize your question as a way of trying to make "open" and alias for open32 or open63 and not having to get into the trap of different function address? If yes, does glibc's weak_alias would work for you without creating new problems? Yeah thats pretty much it, but I dont think weak aliasing is the trick (if I understand what you mean by weak aliasing -- if you mean something other than #pragma weak then ignore the next paragraph). The problem with weak symbols is that they are only really useful at link-edit time, and then only if you want to override the symbol with one of your own. Considering that you offered weak_alias as a solution, I am guessing that you are not talking about simple weak symbols. I need this to be resolved at compile time (so that we call the right version of open, stat, whatever) without getting into the CPP namespace quagmire. But you said "glibc's weak_alias" ... I think that puts me out of the running considering this is a SCO platform :( This has to inteface with our libc (this wont be the first or last time I have wished I could use glibc). I think for right now, I am going to go with the extern inline and always_inline approach, and test the hell out of the beast, with as much code as I can (testsuites and stuff like php, apache, postgresql, Xorg, KDE, Xalan, Xerces). If those all work I will consider my work done :) If it doesn't work its trivial to adjust the fixincludes stuff to use static inline, and I will do so before I submit my patches. Kean
Re: Guidance please: static or extern __inline__
[ cough ] "always_inline" [ cough ]
HA!
I *knew* there was a solution. Thank you Mike.
So now I guess the question remains, for the cases where
you want a function to behave differently depending on
pre-processor conditionals, whats the best way of doing
it? The particularly interesting case is with LFS stuff:
extern int open (const char *, int, int); /* Legacy */
extern int __open (const char *, int, int); /* New */
extern int open32 (const char *, int, int); /* New LFS */
extern int open64 (const char *, int, int); /* New LFS */
#if _FILE_OFFSET_BITS - 0 == 32
#define open open32
#elif _FILE_OFFSET_BITS - 0 == 64
#define open open64
#else
#define open __open
#endif
Wreaks havoc with libstdc++ and libjava, where class
members are called 'open'. I would ideally want those calls
defined in terms of inline, and leave the pre-processor
out of it. For argument's sake, lets assume open wasn't
actualy variadic and that it was declared as above. Would
the best thing to have in the header file be:
#if _FILE_OFFSET_BITS - 0 == 32
static __inline__ int open (const char *__1, int __2, int __3)
{
return open32(__1, __2, __3);
}
#endif
-or-
#if _FILE_OFFSET_BITS - 0 == 32
extern __inline__ __attribute__ ((__always_inline__))
int open (const char *__1, int __2, int __3)
{
return open32(__1, __2, __3);
}
#endif
I fully understand Daniel's point about why you *dont* want
&open to really return the address of the old open, but you
may also want &open to be consistent across different
modules. With the static inline case, they won't be. The case
where that sort of shenanigans is refering to old API's is
of course the worst case. However, for other simpler cases,
lets say, min or max, you may well have a version in libc,
for linkage purposes, but under normal circumstances you
would like it to be inlined. &min would be the same always,
but in cases where you are not taking the address of the
function, and are just using it, you want the quicker, inlined
version to save on a call to libc.
I'm trying to solve a problem not create one, and I get the
feeling that using static inline will solve more problems,
but I am at war with the pedant in me that says the extern
inline case may be more "purely correct".
Kean
Re: Guidance please: static or extern __inline__
However, I *think* I like the semantics of 'extern inline'
better: use the inline version for the most part but if,
for example, you take the address of the function, use the
actual symbol stat(). But I see that most other fixincs
use static inline.
Huh? This paragraph conflicts with the previous one I quoted. You
don't want extern inline, because you don't want the symbol stat() to
be called - that's your whole problem.
Maybe I expressed myself unclearly. I also may have read the
docs wrong. But this is how I understand it:
extern void foo (void);
extern __inline__ void foo (void) {
some_other_foo();
}
typedef void (*retfn_t)(void);
retfn_t bar (void)
{
foo(); /* Really calls some_other_foo(); */
return foo;/* Returns extern reference to library func foo() */
}
If you compile the above without -O, you only get an UNDEF
for foo in the object file. If you compile it with -O, you
get the UNDEF for both foo and some_other_foo. If you change
extern __inline__ to static __inline__ and remove the first
decl, you only get an UNDEF for some_other_foo.
I thought that the -O case with extern inline was the most
correct. Say for example I have foo() in a library. It's
declared as a weak symbol for __foo. A very common case
with libc functions. A program can legitimately expect to
call foo(), get whatever the header file gives it (for
example, the header could "#define foo some_other_foo").
The same program may also want to return a function pointer
to foo(), and possibly even over-ride the weak library version
with a foo() of their own. The static inline case foils
all of that. The docs hint that 'extern inline' should behave
similarly to a macro, and it does, but only in the -O case.
Gaby pointed out that static inline is the most porttable
and doesn't depend on optimization, so I will go with that.
However, I think it is a mistake (albeit an intentional
one, the docs say that too) that extern inline behaves
differently with -O. I beleive that Gaby's concerns about
intefacing C++ code with C code should not be affected by
extern inline, but I bow to his superior knowledge.
FWIW, compiling with g++, with or without -O, creates
an UNDEF for some_other_foo, and a WEAK for foo. The
only other compiler I have access to, the USL compiler,
behaves the same way with or without -O, and creates
an UNDEF for some_other_foo, and a GLOB for foo. Go
figure.
For the particular problem I am having, I can live with
using static inline, but I *do* think that extern inline
should behave more like a macro in C mode, even without
-O.
Kean
Re: Guidance please: static or extern __inline__
I've long come to the conclulsion that "static inline" is the most palatable form of the whole thingy -- its semantics does not depend on optimization level. It is also the form that suits needs for people who need to write C++ codes that use or interface with C codes. Thanks for the advice Gaby. I'll switch from extern inline to static inline. Kean
Guidance please: static or extern __inline__
Hi everyone,
I've run into a little SNAFU with my porting work. In my
fixincludes changes I changed all forms in the header files
of (using stat as an example):
static int
stat(const char *__p, stat_t *__s)
{
return _xstat(_STAT_VER, __p, __s);
}
to:
extern int stat (const char *__p, stat_t *__s);
extern __inline__ int
stat(const char *__p, stat_t *__s)
{
return _xstat(_STAT_VER, __p, __s);
}
From reading teh docs it seems like 'extern __inline__' was
the way to go for this type of header file trickery. However,
it caused a problem bootstrapping the compiler, becuase the
first stage doesn't have -O, so any calls to stat() actually
go to the library routine called stat(), which is an old,
deprecated stat that can't deal with, say, 32-bit inodes or
uid_t's etc, and various programs like fixincludes then
fail to stat files.
If things are compiled with -O, everything works fine,
becuase _xstat, which is what I really want, is called. If
I change the extern __inline__ to static __inline__, it
works correctly, even without optimization.
However, I *think* I like the semantics of 'extern inline'
better: use the inline version for the most part but if,
for example, you take the address of the function, use the
actual symbol stat(). But I see that most other fixincs
use static inline.
So my question is in two parts I guess:
a) Which is the better thing to use in a header file for
this type of function mapping? static or extern inline?
b) If its extern inline, is there a way to force the inline
expansion even when not using -O (and without command
line options). I wouldn't want users to get nasty
surprises if they just used 'gcc -o foo foo.c'.
Any advice and guidance greatly appreciated.
Kean
Is there a way to exclude a dir from multilibing?
All, Is there a way to exclude a given directory, for example, libjava, from multilibing? There are certainly cases where it may make sense to have the C/C++ runtime be multilibbed one way, but not have libjava multilibed the same way. I looked for something like this in the docs and didn't find it but perhaps someone knows some voodoo I can use? Any help greatly appreciated. Kean
Re: GCC-3.4.5 status report
Here is how Mark and I have agreed on those sort of things. If such a patch is accepted in 3.4.x but not in 4.0.x, then we've introduced a regression in 4.0.x. So, the way we deal with it is that, the patch is first applied to 4.0.x, then to 3.4.x retrospectively. Is that workable for you? Absolutely. I actually did all the workin in a 4.0.2 cvs tree, and Im backporting it to my 3.4.5 tree. Kean
Re: GCC-3.4.5 status report
Gabriel Dos Reis wrote: Kean Johnston <[EMAIL PROTECTED]> writes: | > The full list of bugs is produced below. Maintainers, please look | > into any of those and see which ones you can fix or give guidance for | > fixes in ways that are suitable for a stable branch. | Do I still have time / opportunity to refresh the SCO ports? This being a stable release branch, I'll consider only regressions fixes. Is that the case? I guess it depends on how pedantic we want to define 'regression'. I did a mostly-working port circa 3.4.1, but it had some problems, but teh last known-to-be-working-well port was 2.95.3. I have people baying for 3.4 all the time. So its technicalyl a regression from 2.95.3, and almost one from 3.4.1 :) Kean
Re: GCC-3.4.5 status report
The full list of bugs is produced below. Maintainers, please look into any of those and see which ones you can fix or give guidance for fixes in ways that are suitable for a stable branch. Do I still have time / opportunity to refresh the SCO ports? If Sept 30 is the deadline I will definately be able to make it. I have the thing bootstrapping, and I am working my way through the regression suites to understand and either fix, or at least understand why I am ignoring, any failures. Kean
Re: Problem compiling libstdc++ is current 4.0.2 cvs (volatile strikes again)
The GCC team has been urged to drop support for SCO Unix from GCC, as a protest against SCO's irresponsible > aggression against free software and GNU/Linux. > We have decided to take no action at this time, as we no longer believe that SCO is a serious threat. What part of *NO ACTION* was unclear to you? For more on the FSF's position regarding SCO's attacks on free software, please read: http://www.fsf.org/licensing/sco/ Where in any of those pages does it state that GCC is not supported on SCO? Or that *any other GNU project* is not supported on SCO? I was taught never to enter a battle of wits with an unarmed opponent, so I shall simply exercise my right to ignore any future drivel from you. # find . -name ChangeLog\* | xargs grep -iE 'Haren|themis' | wc -l 0 # find . -name ChangeLog\* | xargs grep -iE 'kean|jkj' | wc -l 21 I rest my case. Kean
Re: Problem compiling libstdc++ is current 4.0.2 cvs (volatile strikes again)
Your system is NOT supported by GCC, please read http://www.fsf.org/licensing/sco/ Perhaps you should read README.SCO at the top of the GCC tree? And for your information, SCO is supported by GCC. I am the maintainer, and a few malcontents like yourself aside, I have had little trouble doing so. Please do not confuse my personal contribution to open source with my employers position based on a legal matter that they are using the courts to address. I wish you much success and happiness. Kean
Re: Problem compiling libstdc++ is current 4.0.2 cvs (volatile strikes again)
The error makes perfect sense. __pthread_mutex has only one
assignment operator for it (implicitly generated by the compiler):
__pthread_mutex & operator=(const __pthread_mutex&).
When you try to pass a volatile __pthread_mutex (named as
pthread_mutex_t), the compiler can't pass it to the assignment
operator - because then `volatile' would be stripped off the
reference.
I have created a small test case to demonstrate this:
typedef volatile struct A{} Av;
void foo()
{
Av x;
x = Av();
}
This test gives an error with any compiler I could tested it with:
gcc-2.96, gcc-3.2.1, gcc-4.0.0, xlC-6.0.0
Interestingly enough, it gives an error with the native
compiler too (based on teh EDG front-end).
To fix this for GCC, I will fixincludes the volatile away.
Do you know why the type itself is defined as volatile, as opposed to
I don't, but I shall ask the person who wrote the header file.
declaring only relevant variables as volatile? What system is it anyway?
System V Release 5 (UnixWare / OpenServer 6).
Kean
Problem compiling libstdc++ is current 4.0.2 cvs (volatile strikes again)
Hi all,
I hope someone can help me. I am C++ impaired, and I am getting
the following error when trying to bootstrap the current 4.0.2
CVS. The error is coming from include/ext/bitmap_allocator.h
line 111. The relevant code snippet is:
class _Mutex {
__gthread_mutex_t _M_mut;
// Prevent Copying and assignment.
_Mutex(_Mutex const&);
_Mutex& operator=(_Mutex const&);
public:
_Mutex()
{
if (__threads_enabled)
{
#if !defined __GTHREAD_MUTEX_INIT
_GTHREAD_MUTEX_INIT_FUNCTION(&_M_mut);
#else
__gthread_mutex_t __mtemp = __GTHREAD_MUTEX_INIT;
_M_mut = __mtemp; THIS CAUSES THE ERROR
#endif
}
}
I get the following error message from the compiler:
error: no match for 'operator=' in
'((__gnu_cxx::_Mutex)this)->__gnu_cxx::_Mutex::_M_Mut = __mtemp'
*/gcc/include/sys/types.h:678: note: candidates are: __pthread_mutex&
__pthread_mutex::operator=(const __pthread_mutex&)
The contents of sys/types.h at that location are:
typedef volatile struct __pthread_mutex {
mutex_t __pt_mutex_mutex;
pid_t__pt_mutex_pid;
thread_t __pt_mutex_owner;
int __pt_mutex_depth;
pthread_mutexattr_t __pt_mutex_attr;
} pthread_mutex_t;
If I remove the 'volatile' keyword, then everything just works.
So, do I adjust fixincludes to remove the 'volatile' keyword,
or is this some weird side effect of the recent discussions on
volatile (which I didn't read).
Any help / advice appreciated.
Oh PS ... if I change that from a simple assignment to:
__builtin_memcpy((void *)&_M_mut, (const void *)&__mtemp,
sizeof(__gthread_mutex_t));
Then it also just works. I could of course adjust the header file
to do that for the platform.
Kean
Re: Multilibbing threaded supports
David Edelsohn wrote: The AIX configuration of GCC multilibs thread support. Thank you David, I will go look there. I also noticed that the threads support calls what are really the UI (UNIX International) threads "Solaris" threads. UnixWare supports the same threading API, and I'd like to enable support for it. Would anyone object to renaming it from "Solaris" to "UI"? Kean
Multilibbing threaded supports
All, Is it possible (or if not, desirable) to be able to multilib around the top level --enable-threads option? On systems where the threads library is separate from libc, being able to do so makes sense, as you would only want a threaded version of (say) libstdc++ if your app is threaded. Otherwise, every application may potentially have to link against the threads library, and that can cause a considerable overhead. Advice / opinions welcome. Kean
What's the best way of including extra files for gcc lib dir?
Hi All, What is the best way of including target-specific files in the version-specific gcc library directory? I need to include a file that will be referenced from LINK_SPEC as "gcc.map%s". IE, in the same place the startup files are located. So really I need to know two things: 1) How to I persuade the GCC makefile to install it, and 2) Whats the best place to put it in the source tree? Bear inmind this must be available during bootstrapping too. I suspect it may require additions to "extra_parts" in config.gcc, and then suitable rules for creating it in the t-* fragment. Is this correct? Is it acceptable for that t-* fragment to do something like: gcc.map: $(srcdir)/config/i386/gcc.map -rm -f gcc.map -cp -f $(srcdir)/config/i386/gcc.map $@ Any help / advice would be greatly appreciated. Kean
