y functions that MinGW doesn't provide, so
other libraries may not link even with a _chkstk alias.
Ross Ridge
Ross Ridge wrote:
>There are other MSC library functions that MinGW doesn't provide, so
>libraries may not link even with a _chkstk alias.
Mark Mitchell wrote:
>Got a list?
Probably the most common missing symbols, using their assembler
names are:
__ftol2
@[E
of a head start. Which isn't to say it wouldn't be a
worthy enough project in it's own right.
Ross Ridge
and bite you once LTO arrives no matter what you
do in your own code. You might want to see if you can't get them to
change undefined code like this:
*(unsigned **)pvalue = &conn->oparams.maxoutbuf;
into code like this:
*pvalue = (void *) &conn->oparams.maxoutbuf;
Ross Ridge
Ross Ridge wrote:
>Umm... those 80 processors that Intel is talking about are more like the
>8 coprocessors in the Cell CPU.
Michael Eager wrote:
>No, the Cell is asymmetrical (vintage 2000) architecture.
The Cell CPU as a whole is asymmetrical, but I'm only comparing the
d
x27; too:
It's a NOP. Probably inserted by the assembler because of an alignment
directive.
Ross Ridge
passed by value using an integer register.
This is how SSE and MMX values should be passed regardless of wether
the function takes a variable number of arguments or not.
Ross Ridge
tion, you always need to
allocate space for 4 arguments.
The only thing different you need to do with functions taking variable
arguments (and unprototyped functions) is to pass floating point values
both in the integer and floating point registers for that argument.
s expored without "@n" suffixes.
Any library that needs to be able to be called from VisualBasic 6 or some
other "stdcall only" environment should explictly declare it's exported
functions with the stdcall calling convention.
Ross Ridge
Ross Ridge wrote:
> Any library that needs to be able to be called from VisualBasic 6 or some
> other "stdcall only" environment should explictly declare it's exported
> functions with the stdcall calling convention.
Tobias Burnus writes:
> Thus, if I understood you co
system I'm using has 32-bit support, but the build
procedure breaks anyways because it assumes 32-bit libraries are in "lib"
and 64-bit libraries are in "lib64". Instead, this Debian-like AMD64
system has 32-bit libraries in "lib32" and 64-bit libraries in "lib".
Ross Ridge
guarantees we can make.
It looks like MSC requires that you link with the static CRT libraries
if you want strict standard conformance.
Ross Ridge
ly defining the macro
regardless of the platform.
Ross Ridge
his check could have
>an impact, like for pool allocators that are otherwise very cheap.
>If so, there could be a flag to suppress the check.
Excessive code size growth could also be problem for some programs.
Ross Ridge
Joe Buck writes:
>If a check were to be implemented, the right thing to do would be to throw
>bad_alloc (for the default new) or return 0 (for the nothrow new).
Ross Ridge writes:
>What do you do if the user has defined his own operator new that does
>something else?
Gabriel Dos
[EMAIL PROTECTED] (Ross Ridge) writes:
> Well, for example, like all other things that a new_handler can do,
> like throwing an exception derived from bad_alloc or calling exit().
> In addition, any number of side effects are possible, like printing
> error messages or setting flags.
t of memory requested is the result
of the unsigned multiplication of "n_elements * sizeof Foo", using your
example above. Since this result of this caclulation isn't undefined,
even if it "overflows", there's no room for the compiler to calculate
a different value to pass to operator new().
Ross Ridge
if (num > ~size_t(0) / size)
return ~size_t(0);
return num * size;
}
Ross Ridge
re. Anything that works
should make the people concerned about security happy. People more
concerned with size or speed aren't going to enable this feature.
Ross Ridge
where
as and ld are. Unfortunately, it seems to get this wrong is some case
or another and thus these rules for "linking" the utilities into the
build directory were added. Maybe it's the gcc front end that needed
to be fixed, not the makefile.
Ross Ridge wrote:
> You already have a not-so-small C program that's supposed to know
> where as and ld are.
DJ Delorie wrote:
> You're forgetting about configure.
I don't see how the existance of configure changes the fact the GCC
compiler driver exists, is capable of ru
Ross Ridge wrote:
> I don't see how the existance of configure changes the fact the GCC
> compiler driver exists,
DJ Delorie wrote:
> At the time you're running configure, the gcc driver does *not* exist,
> but you *do* need to run as and ld to test what features they
Ross Ridge wrote:
>I don't see how the existance of configure changes the fact the GCC
>compiler driver exists,
DJ Delorie wrote:
>At the time you're running configure, the gcc driver does *not* exist,
>but you *do* need to run as and ld to test what features they support,
ther hack.
Ross Ridge
e shell (eg. "/bin/sh") that aren't likely
to be valid to plain Windows.
Ross Ridge
cripts without editing their first line. */
It's likely to work in this case, but it doesn't guarantee that the
shell that gets executed uses the same MSYS/Cygwin enviroment as the
rest of the build process.
Ross Ridge
--
l/ //
ht shell. While in
other contexts finding any shell might be better than nothing, in this
context, fixing the MinGW build failure, the shell needs to be from the
same "Unix emulation" environment that running the build process.
Ros
ny official release.
Ross Ridge
ry. Using binutils as
the assembler and linker is pretty much a given, but they'd need to be
ported to support the Windows x64 PE32+ PECOFF, if they don't already.
Ross Ridge
. GCC doesn't conform to C99 and
any implementation of "c99" that uses GCC would presumably also be
non-conforming.
Ross Ridge
Ross Ridge wrote:
> GCC doesn't use (A), (B) or (C). GCC doesn't conform to C99 and
> any implementation of "c99" that uses GCC would presumably also be
> non-conforming.
Robert Dewar wrote:
> What exactly is the observable non-conformance?
GCC doesn't clai
Ross Ridge wrote:
> GCC doesn't use (A), (B) or (C). GCC doesn't conform to C99 and
> any implementation of "c99" that uses GCC would presumably also be
> non-conforming.
Robert Dewar wrote:
> What exactly is the observable non-conformance?
Ross Ridg
e techinical issue at hand. While that implies GCC doesn't
conform, I said so explictly because Paul Eggert said that c99 is often
implemented using GCC.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] [EMAIL
t's doing (B) if UCNs aren't ever necessary, though it
doesn't seem to support extended characters in indentifiers so it's not
quite using native encodings where possible. Though the intent does
seem to be to go with option (B).
Ross Ridge
erstand that the three options are in fact
> distinct semantically.
The aren't in C99, as Paul Eggert's original message made clear, but
they are in an environment that defines a command like "c99" that makes
preprocessed output visable.
Ross Ridge wrote:
> Thinking semantically is irrelevent because the question isn't whether GCC
> conforms to C99 or POSIX. It clearly doesn't. GCC fails the as-if rule.
> The question is one of implementation burden, which can only be answered
> by examining GCC's imp
this feature.
Ross Ridge
en would be on whomever wants to use GCC to
implement the c99 command.
Ross Ridge
cters only
from C basic character set (which is a subset of the portable character
set), there isn't a problem.
Ross Ridge
he POSIX portable character set on that POSIX system then there isn't
a problem. If it selects a character set that isn't a superset, say
because the POSIX portable character set is encoded using ASCII on that
system, then the effect is undefined, and so there's also isn't a pro
ack pointer points to that is
considered part of the stack and since GCC is using that red zone to
"push' values on the stack, this optimization isn't safe.
Ross Ridge
et, and chksum.
It's not compatible with the Intel CRC32 instruction which uses the
CRC-32C polynomial (0x1EDC6F41).
Ross Ridge
sembler based API.
Ross Ridge
0]) == BP_REG
&& true_regnum(operand[1]) == SP_REG)
return ASM_BYTE "0x8B, 0xEC";
gcc_unreachable();
#endif
}
[(set_attr "length" "2")
(set_attr "length_immediate" "0")
(set_attr "modrm" "0")])
It's not pretty but you won't be dependent on binutils.
Ross Ridge
n't stopped other ports from implementing a naked
attribute or for that matter developers like me creating their own
private implementations.
Ross Ridge
spx
Mind you, last I checked, GCC didn't actually follow the ABI requirements
for prologues and epilogues given in the link above, but that only breaks
ABI unwinding.
Ross Ridge
indows-1252", or some
other non-ASCII single-byte characters when it returned "iso-8859-1".
Ross Ridge
Ross Ridge wrote:
> The correct fix is for GCC not to intentionally choose to rely on
> implementation defined behaviour when using the "C" locale. GCC can't
> portably assume any other locale exists, but can portibly and easily
> choose to get consistant output when us
stack alignment
would disapear as well. The kernel would then be free to choose to use
whatever code generation options it felt was appropriate.
Ross Ridge
nk code quality is a problem with GCC. I hate
the GNU coding style as much as anyone, but it's used consistantly and
that's what matters. Compared other open and closed projects I've seen
it's as easy to understand and maintain as anything. GNU binutils is
a pile of poo, but I don't know of any codebase the size of GCC that's
as nice to work with.
Ross Ridge
ons whether
the macros are used or not.
I think the solution to the specific problem he mentioned, connecting
nested functions to their try blocks, would be to emit address pairs to
a special section.
Ross Ridge
are you testing this? Without SEH support Windows wouldn't
ordinarily ever need to unwind through GCC compiled code. I assumed
that's why it was never implemented.
Ross Ridge
n
>for gcc compiled code quite well
I don't see how it would be possible in the general case. Without the
unwind talbes Windows doesn't have the required information to unwind
through GCC compiled functions.
Ross Ridge
general I agree, that the generation of .pdata/.xdata sections
>would be a good thing for better support of MS abis by gcc.
I'm not advocating that they should be added to GCC now. I'm just
pointing out that without them 64-bit SEH macros will be of limitted use.
Ross Ridge
al
private SEH implementation. I don't think it's a good idea to use or
copy Microsoft's implementation. Create your own handler function and
give it whatever data you need.
Ross Ridge
sn't sound all
that useful to me.
Ross Ridge
omes a lot more practical.
Ross Ridge
Ross Ridge wrote:
> Oh, ok, that makes a world of difference. Even with just AMD GPU
> support a GCC-based OpenCL implementation becomes a lot more practical.
Michael Meissner writes:
>And bear in mind that x86's with GPUs are not the only platform of interest
I never said anythi
's
proposed ARM patch, or full arithmetic support like any other scalar or
vector type?
Ross Ridge
s an intermediate language, so isn't tied to any particular NVIDIA GPU.
I beleive there's something similar for AMD/ATI GPUs.
btw. The computational power of Intel's integrated GPUs is pretty dismal,
so I don't think GCC port targetting them would be very useful.
Ross Ridge
yah, forgot about that one. Political stuff like this another reason
not to get involved with GCC.
Ross Ridge
Ross Ridge writes:
> Years ago, I was asked to sign one of these documents for some public
> domain code I wrote that I never intended to become part of a FSF project.
> Someone wanted to turn it a regular GNU project with a GPL license,
> configure scripts, a cute acronym and all tha
>My confusion is that these functions currently allow arithmetic
>operations of the form "reg = op(mem,immed)" even though this
>shape isn't supported by x86 ISA.
The IMUL instruction can have this form.
Ross Ridge
herit its parent's console window. Either gcc is somehow losing
it's console window or it never had one to begin with. Hmm... if that
"#!" kludge is being used here then it could be the shell that's losing
the console.
Ross Ridge
Ross Ridge wrote:
> I think you're barking up the wrong tree here. Windows only creates
> console windows automagically when a console application starts that
> can't inherit its parent's console window.
Mark Mitchell wrote:
> Exactly -- there is no parent console wi
d.
This is what I got using your code and Cygwin rxvt:
Cygwin rxvt
===
parent spawn: Works.
parent nostd: No output from child.
parent std: Works.
I wasn't able to test it with xterm, I don't have an X server handy,
but it looks your problem is with xterm, not gcc.
Ross Ridge
by you
switching to rxvt? Maybe the only problem is that your xterm is broken.
Ross Ridge
standard win32 assumptions hold.
So, in general you can't expect any Win32 console application to work
correctly in such a enviroment. Why should Mark expect a Win32 console
version gcc to be any different? Hmm... maybe that's best solution,
Mark should be using a "native" Cygwin version of gcc and tools.
Ross Ridge
Ross Ridge wrote:
> Arguably, not having a console window attached a shell window is broken
> in the Cygwin environment.
Paul Brook wrote:
> How exactly do you suggest implementing this?
The same way Cygwin rxvt implements this.
>By implication you're saying that you shouldn&
-picking, but the above notice doesn't put the code
into the public domain. Sun still owns the copyright of the software.
Ross Ridge
Dave Murphy wrote:
> install: e:/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/
Don't use a --prefix with a drive letter. Just use --prefix=/devkitARM,
and then use "make install DESTDIR=e:/devkitPro" to install it where
you actually want it.
Ross Ridge
configured prefix but isn't ideal.
MinGW GCC is a native Win32 application and is unaffected by any mounts
you create with MSYS.
Ross Ridge
Ross Ridge wrote:
>MinGW GCC is a native Win32 application and is unaffected by any mounts
>you create with MSYS.
Dave Murphy wrote:
>It's affected when you run from the msys bash shell, my apologies for
>not being clear.
That makes no difference. MinGW GCC is a native Win3
Ross Ridge wrote:
>That makes no difference. MinGW GCC is a native Win32 application and
>can't see any mounts you create with MSYS.
Dave Murphy wrote:
>sorry but you're most definitely wrong about that
No, I'm not. The example you gave shows how MSYS mounts have an
c-mingw32/bin/
This is the directory ("i686-pc-mingw32/bin") where you should install
the version of as.exe and ld.exe you want that installation of gcc to use.
Ross Ridge
to change other backend code for
handling addresses.
Ross Ridge
recognize such an expression ?
Since this expression is a memory operand, it's recognized by the
GO_IF_LEGITIMATE_ADDRESS() macro. In the i386 port, that's implemented
by legitimate_address_p() in "i386.c".
Ross Ridge
FX Coudert wrote:
> -B/mingw/i386-pc-mingw32/bin/
This looks wrong, it should be "/mingw/mingw32/bin". Putting a copy of
as and ld in "/mingw/i386-pc-mingw32/bin" might work around your problem.
Ross Ridge
slots. See the internals
documentation for more details.
Ross Ridge
us the TLS directory entry) and __tls_index__.
Actually, the last one I haven't done yet. I've just been using a linker
script to do that, but it should be in a library so the TLS directory
entry isn't created if the executable doesn't use TLS.
Ross Ridge
problem. What
exactly is the error you're getting that indicates that your compiled
version of GCC isn't relocatable?
Ross Ridge
Ross Ridge wrote:
>The GCC I get from my native MinGW build of the trunk is relocatable:
Hmm... I should have sent that to gcc-patches, sorry.
Ross Ridge
Ross Ridge wrote:
> Actually, the last one I haven't done yet. I've just been using a linker
> script to do that, but it should be in a library so the TLS directory
> entry isn't created if the executable doesn't use TLS.
Richard Henderson wrote:
> You can also cr
I don't see how the "Lua-style" coroutines you're looking are any
lightweight than what Maurizio Vitale is looking for. They're actually
more heavyweight because you need to implement some method of returning
values to the "coroutine" being yeilded to.
Ross Ridge
Ross Ridge wrote:
>Hmm? I don't see how the "Lua-style" coroutines you're looking are any
>lightweight than what Maurizio Vitale is looking for. They're actually
>more heavyweight because you need to implement some method of returning
>values to the "cor
might point
to. I don't think there are any optimizing opportunities for arguments
declared as const, as opposed to arguments declared as pointing to const.
Ross Ridge
999, so I wouldn't be surprised if Microsoft has
filed a bunch of new C++ ABI patents since then.
Ross Ridge
y,
the fundamental changes the standard made to how templates work...)
Ross Ridge
o do it safely would be to emit some sort
instruction not to merge a function when the compiler sees that its
address is taken.
Ross Ridge
Ross Ridge writes:
>I don't think this is a good idea. With different compiler options the
>same RTL can generate different assembly instructions. Consider the case
>of compiling the same function multiple times with different names and
>different CPU architectures selected
Ross Ridge writes:
>No, and I can't see how how you've came up with such an abusurd
>misintepretation of what I said. As I said clearly and explicity,
>the example I gave was where you'd want to use function merging.
Daniel Berlin writes:
>Whatever. Why would you turn
ted by their
>implementation.
Yes, this issue has already been mentioned in this thread and is a problem
regardless of how you compare functions to find out if they are the same.
The compiler also needs to be able to detect when its safe to merge
functions that are identical.
Ross Ridge writes:
>Microsoft's implementation has proven that "stupid" byte comparions can
>generate significant savings.
Daniel Berlin wrtes:
>No they haven't.
So Microsoft and everyone who says they've got significant savings using
it is lying?
>But ha
safe by communicating to the linker
which functions have had their address taken. Yes, this requires special
support from the linker, but then so has linkonce on some platforms.
If that special support isn't available you're still left with an unsafe
but very useful optimization for applications that don't compare function
pointers.
Ross Ridge
their member function pointers might be compared
in another compilation unit.
Ross Ridge
return 2;
}
If cases like these are rare enough it's probably an acceptable change
if they give an error because the argument types don't match.
Ross Ridge
erating system doesn't need an MMU or virtual memory in order to
free all the memory used by a process when it exits. MS-DOS did this,
and I assume AmigaOS did as well.
Ross Ridge
g pointer arithmetic on.
Ross Ridge
r
cases of missing operating support might make processor specific overlow
support detrimental.
Ross Ridge
f -ftrapv, but not Ada.
Ross Ridge
1 - 100 of 139 matches
Mail list logo
