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 pers
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. Otherw
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
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 Cop
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 assig
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.
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 unc
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 b
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
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?
Ab
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
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 *__
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
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 previ
[ 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
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
[ 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
tr
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
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
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
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
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)
(
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
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
`f
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 in
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 a
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
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 j
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
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
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 rena
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
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
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
(n
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
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 li
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 u
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
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 l
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"
.t
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
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
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
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
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 poin
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 a
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
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 int
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 'g
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 241
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
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
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
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
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 eas
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 libr
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"
r
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
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):
Execut
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 th
60 matches
Mail list logo
