a chance of being seriously
considered.
Ross Ridge
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 instructions you're
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 into a long series
.
Ross Ridge
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
.
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
interpreted as '%' character rather than
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 you specified for -fexec
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 point having locales. So
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 '%' character rather than a part of an extended
[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 unreasonable to insist that you tell
.
Ross Ridge
analysis to avoid this problem.
Ross Ridge
.
Ross Ridge
.
Ross Ridge
() instead of vfork() when changing
the environment.
Ross Ridge
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 hjl at lucon dot org writes
According to Apple engineer who implemented
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 stack to be 32-bit 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 this flag doesn't require
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
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's unacceptable
to me.
Ye, Joey
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 times. GCC should
.
Ross Ridge
;
}
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
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
on.
Ross Ridge
.
Ross Ridge
.
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:
My point is that using
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 instruction generates a trap exception
so would
be more difficult than a simple documentation change.
Ross Ridge
are volatile
(caller-saved), while XMM6-XXM15 are non-volatile (callee-saved).
Ross Ridge
changes to regclass.c
is probably not the right thing to do.
Ross Ridge
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
support Windows wouldn't
ordinarily ever need to unwind through GCC compiled code. I assumed
that's why it was never implemented.
Ross Ridge
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
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
function and
give it whatever data you need.
Ross Ridge
... 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 window here.
Why isn't
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
is that your xterm is broken.
Ross Ridge
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't able to use gcc
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
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:
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 effect on
the MSYS shell
-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
.
Ross Ridge
() 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
expression which use reg: force gcc to use a
particular pseudo register ?
Pseudo registers aren't real registers. They either get changed to real
hard registers, or memory references to stack slots. See the internals
documentation for more details.
Ross
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
?
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 create this in the linker, without
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 coroutine being yeilded to.
Dustin Laurence wrote
for arguments
declared as const, as opposed to arguments declared as pointing to const.
Ross Ridge
then.
Ross Ridge
templates work...)
Ross Ridge
to 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. You'd actually want
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 on function merging if you
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
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 have fun implementing it in your linker
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
be compared
in another compilation unit.
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
@[EMAIL PROTECTED
.
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 using the C locale.
Joseph S
disapear as well. The kernel would then be free to choose to use
whatever code generation options it felt was appropriate.
Ross Ridge
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
likely to contribute to GCC.
Please refer to GCC as a free software project, it was written by the
GNU project and the free software community.
Oh, 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 that stuff. I said
enough project in it's own right.
Ross Ridge
= 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
design to the 8 identical
.
Ross Ridge
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.
Ross
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 correctly, you recommend that we add
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
.
It looks like MSC requires that you link with the static CRT libraries
if you want strict standard conformance.
Ross Ridge
.
Ross Ridge
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 Reis writes:
More
[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.
Gabriel Dos Reis
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
)
return ~size_t(0);
return num * size;
}
Ross Ridge
concerned about security happy. People more
concerned with size or speed aren't going to enable this feature.
Ross Ridge
for the MinGW runtime to
be compatibile with both previous implementations and Windows Vista I
think this change makes sense.
Ross Ridge
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:
First of all, I think you
1 - 100 of 129 matches
Mail list logo
