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
m any of
the myriad other ways a SIGSEGV can be generated.
Ross Ridge
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
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
sync_fetch() and __sync_store() builtins, but doing so would
be more difficult than a simple documentation change.
Ross Ridge
ate that XMM0-XMM5 are volatile
(caller-saved), while XMM6-XXM15 are non-volatile (callee-saved).
Ross Ridge
h. Making any changes to regclass.c
is probably not the right thing to do.
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
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
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
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:
>
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
tches, at least that will have a chance of being seriously
considered.
Ross Ridge
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
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
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
breaking chains with all
three instructions.
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
character. This can easily happen with the ISO 2022-JP encoding.
Ross Ridge
[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
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
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 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
s OpenMP.
Ross Ridge
PUs speculative loads can be used instead of strict alias
analysis to avoid this problem.
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
Imode for 32-bit and 64-bit
operations respectively.
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
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
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
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 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
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:
> 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'
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
g your patch approved.
Ross Ridge
101 - 139 of 139 matches
Mail list logo
