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
yah, forgot about that one. Political stuff like this another reason
not to get involved with GCC.
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
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
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
indows-1252", or some
other non-ASCII single-byte characters when it returned "iso-8859-1".
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
n't stopped other ports from implementing a naked
attribute or for that matter developers like me creating their own
private implementations.
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
sembler based API.
Ross Ridge
et, and chksum.
It's not compatible with the Intel CRC32 instruction which uses the
CRC-32C polynomial (0x1EDC6F41).
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
's
proposed ARM patch, or full arithmetic support like any other scalar or
vector type?
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
omes a lot more practical.
Ross Ridge
sn't sound all
that useful to me.
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
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
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
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
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
h. Making any changes to regclass.c
is probably not the right thing to do.
Ross Ridge
ate that XMM0-XMM5 are volatile
(caller-saved), while XMM6-XXM15 are non-volatile (callee-saved).
Ross Ridge
sync_fetch() and __sync_store() builtins, but doing so would
be more difficult than a simple documentation change.
Ross Ridge
Ross Ridge:
>With INTO I don't see any way distignuish the SIGSEGV it generates on
>Linux from any of the myriad other ways a SIGSEGV can be generated.
Paolo Bonzini writes:
>sc.eip == 0xCE (if I remember x86 opcodes well :-) as I'm going by heart...)
The INTO instructi
Ross Ridge writes:
> On Unix-like systems you can catch SIGABRT, but even there how do you
> tell that it didn't come from CTRL-\...
Oops, I forgot that CTRL-\ had it own signal SIGQUIT.
Ross Ridge
m any of
the myriad other ways a SIGSEGV can be generated.
Ross Ridge
Robert Dewar write:
>Usually there are ways of telling what is going on at a sufficiently
>low level, but in any case, code using the conditional jump instruction
>(jo/jno) is hugely better than what we do now (and it is often faster
>to usea jo than into).
Ross Ridge wrote:
>M
f -ftrapv, but not Ada.
Ross Ridge
r
cases of missing operating support might make processor specific overlow
support detrimental.
Ross Ridge
g pointer arithmetic on.
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
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
g your patch approved.
Ross Ridge
oing stack to the
highest value that the flag can have.
Ross Ridge
Ross Ridge writes:
> As I mentioned later in my message STACK_BOUNDARY shouldn't be defined in
> terms of hardware, but in terms of the ABI. While the i386 allows the
> stack pointer to bet set to any value, by convention the stack pointer
> is always kept 4-byte aligned at all t
Ross Ridge wrote:
> I'm currently using -fpreferred-stack-boundary without any trouble.
> Your proposal would in fact generate code to align stack when it's
> not necessary. This would change the behaviour of
> -fpreferred-stack-boundary, hurting performance and that'
Robert Dewar writes:
>Well if we have local variables of type float (and we have specified
>use of SSE), we are in trouble, no?
Non-vector SSE instructions, like the ones that operate on scalar floats,
don't require memory operands to be aligned.
Ross Ridge wrote:
> The -fpreferrred-stack-boundary flag currently generates code that
> assumes the stack aligned to the preferred alignment on function entry.
> If you assume a worse incoming alignment you'll be aligning the stack
> unnecessarily and generating code that
Ye, Joey writes:
>i. STACK_BOUNDARY in bits, which is enforced by hardware, 32 for i386
>and 64 for x86_64. It is the minimum stack boundary. It is fixed.
Ross Ridge wrote:
>Strictly speaking by the above definition it would be 8 for i386.
>The hardware doesn't force the s
Ross Ridge writes:
> This section doesn't make sense to me. The force_align_arg_pointer
> attribute and -mstackrealign assume that the ABI is being
> followed, while the -fpreferred-stack-boundary option effectively
"H.J. Lu" writes
> According to Apple e
ointing new ebp to them, we build a pseudo
>// stack for unwinding
Hmmm... I don't know much about the DWARF unwind information, but
couldn't it handle this case without creating the "pseudo frame"?
Or at least be extended so it could?
Ross Ridge
8 bits and is the same
in frontend and backend.
Ross Ridge
ution would be to call fork() instead of vfork() when changing
the environment.
Ross Ridge
Imode for 32-bit and 64-bit
operations respectively.
Ross Ridge
e, "p" has its address taken and
passed to another function so this rule doesn't apply.)
Note the use of the word "reference" in the above paragraph means
any operation that causes memory to be accessed whether by reading or
writing it. It doesn't mean only the use of C++ reference type.
Ross Ridge
PUs speculative loads can be used instead of strict alias
analysis to avoid this problem.
Ross Ridge
s OpenMP.
Ross Ridge
Ross Ridge writes:
The entire parsing of the format string is affected by the multi-byte
> character encoding. I don't know how GCC would be able tell that a byte
> with the same value as '%' in the middle of string would actually be
> interpreted as '%'
[EMAIL PROTECTED] (Ross Ridge) writes:
> I don't think that's true, but regardless many systems have runtime
> character sets that are dependent on locale. If GCC doesn't support this,
> then GCC is broken.
Geoffrey Keating writes:
> I don't think it's unr
Ross Ridge wrote:
>The compiler can't in general know what encoding that printf, fprintf,
>and sprintf will use to parse the string. It's locale dependent.
Bernd Schmidt writes:
>Does this mean it can vary from one run of the program to another?
Yes, that's the whole p
Ross Ridge writes:
>The compiler can't in general know what encoding that printf, fprintf,
>and sprintf will use to parse the string. It's locale dependent.
Paolo Bonzini writes:
>It is undefined what happens if you run a program in a different charset
>than in the one yo
[EMAIL PROTECTED] (Ross Ridge) writes:
> The entire parsing of the format string is affected by the multi-byte
> character encoding. I don't know how GCC would be able tell that a byte
> with the same value as '%' in the middle of string would actually be
> interpre
character. This can easily happen with the ISO 2022-JP encoding.
Ross Ridge
more concise way to eliminate the need for the bitwise operations on
vector floats would be to implement either the "swizzles" used in 3D
shaders or array indexing on vectors. It would require a lot of work
to implement properly, so I don't see it happening.)
Ross Ridge
breaking chains with all
three instructions.
Ross Ridge
Ross Ridge <[EMAIL PROTECTED]> wrote:
> GCC makes the problem is even worse if only SSE and not SSE 2 instructions
> are enabled. Since the integer bitwise instructions are only available
> with SSE 2, using casts instead of intrinsics causes GCC to expand the
> operation int
Ross Ridge writes:
>tbp is correct. Using casts gets you the integer bitwise instrucitons,
>not the single-precision bitwise instructions that are more optimal for
>flipping bits in single-precision vectors. If you want GCC to generate
>better code using single-precision bitwise
instrucitons,
not the single-precision bitwise instructions that are more optimal for
flipping bits in single-precision vectors. If you want GCC to generate
better code using single-precision bitwise instructions you're now forced
to use the intrinsics.
Ross Ridge
tches, at least that will have a chance of being seriously
considered.
Ross Ridge
s an ELF-only thing, while DLLs are a PE-COFF-only
thing. Is there some platform that supports both sets of attributes?
Ross Ridge
Ross Ridge wrote:
>I completely disagree. Standards should primarily standardize existing
>practice, not inventing new features. New features should be created
>by people who actually want and will use the features, not by some
>disinterested committee.
Robert Dewar write:
>
ew features in C99 had already been implemented GCC. Even in the
cases where C99 standardized features differently, I think both GCC and
Standard C benefited from the work done in GCC.
Ross Ridge
compatible with Visual
C++ 6.0 (and I think 5.0). Newer versions of Visual C++ use different
runtime libraries, so that interoperability is becoming less relevent
over time.
Ross Ridge
That was a probably a mistake, but in order for the MinGW runtime to
be compatibile with both previous implementations and Windows Vista I
think this change makes sense.
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
if (num > ~size_t(0) / size)
return ~size_t(0);
return num * size;
}
Ross Ridge
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
[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.
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
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
ly defining the macro
regardless of the platform.
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
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
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
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
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.
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
x27; too:
It's a NOP. Probably inserted by the assembler because of an alignment
directive.
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
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
of a head start. Which isn't to say it wouldn't be a
worthy enough project in it's own right.
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
y functions that MinGW doesn't provide, so
other libraries may not link even with a _chkstk alias.
Ross Ridge
their member function pointers might be compared
in another compilation unit.
Ross Ridge
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
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
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:
>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
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
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
y,
the fundamental changes the standard made to how templates work...)
Ross Ridge
999, so I wouldn't be surprised if Microsoft has
filed a bunch of new C++ ABI patents since then.
Ross Ridge
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
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
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:
> 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
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
problem. What
exactly is the error you're getting that indicates that your compiled
version of GCC isn't relocatable?
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
1 - 100 of 139 matches
Mail list logo
