Re: [ros-dev] [ros-diffs] [dgorbachev] 26483: Undo r26482 change, waste more stack space.
Perhaps you could try convincing the GCC folks to actually properly support declspec_align like MSVC does, instead of claiming to support it, but actually ignoring it. Then you could also convince them to support SEH, PDBs, STDCALL-default calling convention, etc ;)
-----Original Message----- From: ros-diffs-bounces@reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of dgorbachev@svn.reactos.org Sent: April-24-07 1:06 AM To: ros-diffs@reactos.org Subject: [ros-diffs] [dgorbachev] 26483: Undo r26482 change, waste more stack space.
Author: dgorbachev Date: Tue Apr 24 09:05:49 2007 New Revision: 26483
URL: http://svn.reactos.org/svn/reactos?rev=26483&view=rev Log: Undo r26482 change, waste more stack space.
Modified: trunk/reactos/ntoskrnl/include/internal/ex.h
Modified: trunk/reactos/ntoskrnl/include/internal/ex.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/e... ============================================================================== --- trunk/reactos/ntoskrnl/include/internal/ex.h (original) +++ trunk/reactos/ntoskrnl/include/internal/ex.h Tue Apr 24 09:05:49 2007 @@ -106,9 +106,15 @@ // #ifdef __GNUC__
-#define DEFINE_WAIT_BLOCK(x) \ - PEX_PUSH_LOCK_WAIT_BLOCK x = __builtin_alloca(sizeof(EX_PUSH_LOCK_WAIT_BLOCK)); - +#define DEFINE_WAIT_BLOCK(x) \ + struct _AlignHack \ + { \ + UCHAR Hack[15]; \ + EX_PUSH_LOCK_WAIT_BLOCK UnalignedBlock; \ + } WaitBlockBuffer; \ + PEX_PUSH_LOCK_WAIT_BLOCK x = (PEX_PUSH_LOCK_WAIT_BLOCK) \ + ((ULONG_PTR)&WaitBlockBuffer.UnalignedBlock &~ 0xF); + #else
// @@ -116,8 +122,8 @@ // local variable (the actual pointer) away, so we don't take any perf hit // by doing this. // -#define DEFINE_WAIT_BLOCK(x) \ - EX_PUSH_LOCK_WAIT_BLOCK WaitBlockBuffer; \ +#define DEFINE_WAIT_BLOCK(x) \ + EX_PUSH_LOCK_WAIT_BLOCK WaitBlockBuffer; \ PEX_PUSH_LOCK_WAIT_BLOCK x = &WaitBlockBuffer;
#endif
Alex Ionescu wrote:
Perhaps you could try convincing the GCC folks to actually properly support declspec_align like MSVC does, instead of claiming to support it, but actually ignoring it. Then you could also convince them to support SEH, PDBs, STDCALL-default calling convention, etc ;)
stdcall default can be by altering spec file. If mingw/cygwin don't update there spec file in gcc that is there problem. As well there is a flag to make stdcall default |-mrtd. Little bit of a confusing name. Yes its provided for some strange reason mingw and cygwin don't use it. Windows is not the only OS with stdcall default. Some unix's its also default nothing that strange other than mingw/cygwin not using it. If in time rosbe becomes its own complier in gcc with its own spec file there is not reason why reactos cannot have it. Its the maintainers of mingw/cygwin that have set the defaults without it. So over the stdcall one either get up mingw/cygwin ribs or request rosbe gets a spec file of its own in gcc with reactos preferred settings.|
SEH this years summer of code. Yes they are listerning.
declspec_align is known to be borked it even causes problems in embeded development. It was ment to be fixed in 4.1.2. If not 4.2.0 and 4.1.3 should have it fixed. They have been working on it. Not exactly simple to fix correctly without over using memory.
PDB feel like writing a internal spec on it? http://en.wikipedia.org/wiki/Program_database Microsoft has not given anyone the spec on it.
Please point blame at right locations.
Peter Dolding
---------------------------------------------------------------------- Find out how you can get spam free email. http://www.bluebottle.com
stdcall default can be by altering spec file. If mingw/cygwin don't update there spec file in gcc that is there problem. As well there is a flag to make stdcall default |-mrtd. Little bit of a confusing name. Yes its provided for some strange reason mingw and cygwin don't use it. Windows is not the only OS with stdcall default. Some unix's its also default nothing that strange other than mingw/cygwin not using it. If in time rosbe becomes its own complier in gcc with its own spec file there is not reason why reactos cannot have it. Its the maintainers of mingw/cygwin that have set the defaults without it. So over the stdcall one either get up mingw/cygwin ribs or request rosbe gets a spec file of its own in gcc with reactos preferred settings.|
That is not strange. GCC's aim to provide uniform environment on different machines.
That's all great except that every other compiler on the planet lets you specify the default convention PER PROJECT. Are you saying that with GCC, I need to recompile the compiler for every single application I want to ship? Maybe I have a fastcall stub DLL, a stdcall program and a cdecl C compatible DLL. I need three compilers for that? That's rubbish.
Fortunately, gcc does support a flag, -mrtd. Oh, but guess what, it's been broken since 2.95.
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of hto@mail.cnt.ru Sent: April-24-07 9:09 PM To: ReactOS Development List Subject: Re: [ros-dev] [ros-diffs] [dgorbachev] 26483: Undo r26482 change, waste more stack space.
stdcall default can be by altering spec file. If mingw/cygwin don't update there spec file in gcc that is there problem. As well there is a flag to make stdcall default |-mrtd. Little bit of a confusing name. Yes its provided for some strange reason mingw and cygwin don't use it. Windows is not the only OS with stdcall default. Some unix's its also default nothing that strange other than mingw/cygwin not using it. If in time rosbe becomes its own complier in gcc with its own spec file there is not reason why reactos cannot have it. Its the maintainers of mingw/cygwin that have set the defaults without it. So over the stdcall one either get up mingw/cygwin ribs or request rosbe gets a spec file of its own in gcc with reactos preferred settings.|
That is not strange. GCC's aim to provide uniform environment on different machines. _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi! Alex Ionescu wrote:
That's all great except that every other compiler on the planet lets you specify the default convention PER PROJECT. Are you saying that with GCC, I need to recompile the compiler for every single application I want to ship? Maybe I have a fastcall stub DLL, a stdcall program and a cdecl C compatible DLL. I need three compilers for that? That's rubbish.
Fortunately, gcc does support a flag, -mrtd. Oh, but guess what, it's been broken since 2.95.
LOL! EGCS! OMG dont get me started!
James
You don't need to exactly rebuild. There is a reason why gcc supports spec override..
Its not exactly broken. -fomit-frame-pointer -mrtd combination has problems. Note -mrtd is not the only flag that does bad things with -fomit-frame-pointer. That fault only appeared gcc 4.x.x. Note mingw alterations to gcc also breaks -fomit-frame-pointer in versions of gcc before it. In gcc release's 2.95. broken. 3.0.0 was fixed. Mingw patchs have been breaking it. Reason why I am trying to get where able standard release gcc used. At least known problems and fixed problems not being kept alive.
Other problem is mingw itself. __attribute__((cdecl)) is missing off a lot of functions. So it stuffs up really bad ways when the functions missing the flag are used as stdcall. instead of cdecl.
Not all the problem is Gcc. Even if gcc fully fixed the faults with -mrtd its still not going to work with mingw. Reason why with this problem part if it getting up mingw ribs not to break things.
Reason to rebuild gcc with stdcall, the internal functions can be built using stdcall only. No need for cdecl at all. cdecl has nothing to do with c or c++. It was just a microsoft/borland warped idea that two different systems had to be used. So if you are going after speed you might exactly want this. Just using flags you still endup with cdecl used with internal gcc functions. Same kinda things happen with the Microsoft complier too. Gcc does give the option of using stdcall completely.
Please note I do use the -mrtd and stdcall default gcc compliers. Alex Ionescu wrote:
That's all great except that every other compiler on the planet lets you specify the default convention PER PROJECT. Are you saying that with GCC, I need to recompile the compiler for every single application I want to ship? Maybe I have a fastcall stub DLL, a stdcall program and a cdecl C compatible DLL. I need three compilers for that? That's rubbish.
Fortunately, gcc does support a flag, -mrtd. Oh, but guess what, it's been broken since 2.95.
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of hto@mail.cnt.ru Sent: April-24-07 9:09 PM To: ReactOS Development List Subject: Re: [ros-dev] [ros-diffs] [dgorbachev] 26483: Undo r26482 change, waste more stack space.
stdcall default can be by altering spec file. If mingw/cygwin don't update there spec file in gcc that is there problem. As well there is a flag to make stdcall default |-mrtd. Little bit of a confusing name. Yes its provided for some strange reason mingw and cygwin don't use it. Windows is not the only OS with stdcall default. Some unix's its also default nothing that strange other than mingw/cygwin not using it. If in time rosbe becomes its own complier in gcc with its own spec file there is not reason why reactos cannot have it. Its the maintainers of mingw/cygwin that have set the defaults without it. So over the stdcall one either get up mingw/cygwin ribs or request rosbe gets a spec file of its own in gcc with reactos preferred settings.|
That is not strange. GCC's aim to provide uniform environment on different machines.
Yes but select partial platforms stdcall is default. It is up to the platform to set is default calling method. For some strange reason mingw and cygwin is choosing cdecl. I find it strange since MSVC was different.
Gcc is a uniform build environment. Not a uniform calling convention..
Peter Dolding
---------------------------------------------------------------------- Get a free email account with anti spam protection. http://www.bluebottle.com
On 4/24/07, Peter Dolding oiaohm@bluebottle.com wrote:
<snip>
Yes but select partial platforms stdcall is default. It is up to the
platform to set is default calling method. For some strange reason mingw and cygwin is choosing cdecl. I find it strange since MSVC was different.
Gcc is a uniform build environment. Not a uniform calling convention..
Peter Dolding
stdcall is not the default on any version of MSVC I have ever seen, cdecl is; so mingw using cdecl by default mimicks the behavior of MSVC. BTW, the versions I'm referring to are 6, 2003 (7.1), and 2005 (8). The fact that Windows uses stdcall for most API functions does not mean that it is the default calling convention.
-ShadowFlare
While you love to bash gcc just because it has it's flaws there's many reasons so many projects use it, even commercial ones. MSVC/Intel/Whatever isn't really free. The number of systems they target is comperatively low and most importantly you rely on the vendor as no sources are available. They may be better in certain areas but not in all, and in some they're worse. All of them have bugs, not just gcc... And the most important thing: There's no other compiler that allows you to target that many different architectures as gcc.
Besides, adding a standard calling convention feature to gcc shouldn't be that big of a deal... These things are done with symbol attributes, maybe I'm going to work on something like that in the summer.
- Thomas
Alex Ionescu wrote:
That's all great except that every other compiler on the planet lets you specify the default convention PER PROJECT. Are you saying that with GCC, I need to recompile the compiler for every single application I want to ship? Maybe I have a fastcall stub DLL, a stdcall program and a cdecl C compatible DLL. I need three compilers for that? That's rubbish.
Fortunately, gcc does support a flag, -mrtd. Oh, but guess what, it's been broken since 2.95.
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of hto@mail.cnt.ru Sent: April-24-07 9:09 PM To: ReactOS Development List Subject: Re: [ros-dev] [ros-diffs] [dgorbachev] 26483: Undo r26482 change, waste more stack space.
stdcall default can be by altering spec file. If mingw/cygwin don't update there spec file in gcc that is there problem. As well there is a flag to make stdcall default |-mrtd. Little bit of a confusing name. Yes its provided for some strange reason mingw and cygwin don't use it. Windows is not the only OS with stdcall default. Some unix's its also default nothing that strange other than mingw/cygwin not using it. If in time rosbe becomes its own complier in gcc with its own spec file there is not reason why reactos cannot have it. Its the maintainers of mingw/cygwin that have set the defaults without it. So over the stdcall one either get up mingw/cygwin ribs or request rosbe gets a spec file of its own in gcc with reactos preferred settings.|
That is not strange. GCC's aim to provide uniform environment on different machines. _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Is there any better, truer reason to bash something other than the fact it has flaws? I don't bash it because it's made by black or Chinese people, I don't bash it because it's FOSS, I don't bash it because of its name... I bash it because it's broken.
Of course there's many projects that use it. There's also many countries that were communist only 20 years ago. As you've implied, most projects use gcc because they don't have a choice, not because it's a better compiler. NetBSD couldn't use anything else for being able to target the dozen of architectures it already does. ReactOS itself can't use anything else if it wants to fully support Linux. But just because projects are forced to use a compiler doesn't make that compiler good. The reason they all use gcc is *lack of choice*, the very fundamental reason that FOSS exists. Just like Windows is full of flaws, yet used in 90% of computers worldwide, so is GCC, and the reason is lack of choice and of freedom.
Besides, just like Windows has a very strong internal architecture and at its core is a remarkable OS, so is GCC as a compiler. Some of its developers are true compiler designers and some work for large companies, many of which even hold and license patents to GCC. The optimizer in GCC is very powerful and can even rival MSVC in some cases. The cases where it doesn't cause a bug. Because this *is* the problem behind GCC! It's a remarkable, powerful and portable compiler, yet it is unreliable and sometimes downright stupid. Recall your unsuccessful warnings patch to emulate MSVC. Recall the 64-bit pointer bug I discovered. Recall the the lack of useful pragmas that other compilers support. Recall the inability to use STDCALL as default which means Fireball had to spend a week to "convert" a DDK sample to ReactOS and which makes *any* DDK code uncompilable by GCC (purposeful sabotage?). Recall the register allocation bug 2 years ago which used ebx *before* push ebx to save it, and I can name more.
Sure, a compiler can have bugs, but on this level, it is simply unacceptable. I've found two MSVC bugs in my lifetime, reported them, and both got fixed within weeks... without creating two more bugs! The GCC team still can't put software engineering in places. It's not an agile project, it's an aging project. Just look through their code and you'll quickly realize why so many bugs appear and why the compiler is unreliable. Instead of choosing a target release, and making it feature complete, then spending months to fix every single bug reported, they make a new release every other month, with new features and fix the bugs in the previous release. But of course, adding so many new features causes more new bugs to appear! Just look through their bugzilla to see the hilariously pathetic bugs GCC releases have had. I recall one bug which incorrectly interpreted print(--i) and print (i--).
So while it's great that they target so many architectures, gcc remains an aging beast which is likely to exhibit more and more bugs, and which will continue to stifle FOSS compiler innovation by being the only choice. GCC is truly the Windows of the FOSS compiler world. If you really care about open source and about giving Windows developers a reason not to use MSVC, OpenWatcom, Borland, Intel, etc, then re-write the win32 port of GCC from scratch, make it lean, make it mean, and get a team behind it that knows the basics of software architecting and engineering.
Best regards, Alex Ionescu
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Thomas Weidenmueller Sent: April-25-07 8:52 AM To: ReactOS Development List Subject: Re: [ros-dev] [ros-diffs] [dgorbachev] 26483: Undo r26482 change, waste more stack space.
While you love to bash gcc just because it has it's flaws there's many reasons so many projects use it, even commercial ones. MSVC/Intel/Whatever isn't really free. The number of systems they target is comperatively low and most importantly you rely on the vendor as no sources are available. They may be better in certain areas but not in all, and in some they're worse. All of them have bugs, not just gcc... And the most important thing: There's no other compiler that allows you to target that many different architectures as gcc.
Besides, adding a standard calling convention feature to gcc shouldn't be that big of a deal... These things are done with symbol attributes, maybe I'm going to work on something like that in the summer.
- Thomas
Alex Ionescu wrote:
That's all great except that every other compiler on the planet lets you specify the default convention PER PROJECT. Are you saying that with GCC,
I
need to recompile the compiler for every single application I want to
ship?
Maybe I have a fastcall stub DLL, a stdcall program and a cdecl C
compatible
DLL. I need three compilers for that? That's rubbish.
Fortunately, gcc does support a flag, -mrtd. Oh, but guess what, it's been broken since 2.95.
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of hto@mail.cnt.ru Sent: April-24-07 9:09 PM To: ReactOS Development List Subject: Re: [ros-dev] [ros-diffs] [dgorbachev] 26483: Undo r26482 change, waste more stack space.
stdcall default can be by altering spec file. If mingw/cygwin don't update there spec file in gcc that is there problem. As well there is a flag to make stdcall default |-mrtd. Little bit of a confusing name. Yes its provided for some strange reason mingw and cygwin don't use it. Windows is not the only OS with stdcall default. Some unix's its also default nothing that strange other than mingw/cygwin not using it. If in time rosbe becomes its own complier in gcc with its own spec file there is not reason why reactos cannot have it. Its the maintainers of mingw/cygwin that have set the defaults without it. So over the stdcall one either get up mingw/cygwin ribs or request rosbe gets a spec file of its own in gcc with reactos preferred settings.|
That is not strange. GCC's aim to provide uniform environment on different machines. _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
On 4/25/07, Alex Ionescu ionucu@videotron.ca wrote:
Besides, just like Windows has a very strong internal architecture and at its core is a remarkable OS, so is GCC as a compiler. Some of its developers are true compiler designers and some work for large companies, many of which even hold and license patents to GCC. The optimizer in GCC is very powerful and can even rival MSVC in some cases. The cases where it doesn't cause a bug. Because this *is* the problem behind GCC! It's a remarkable, powerful and portable compiler, yet it is unreliable and sometimes downright stupid. Recall your unsuccessful warnings patch to emulate MSVC. Recall the 64-bit pointer bug I discovered. Recall the the lack of useful pragmas that other compilers support. Recall the inability to use STDCALL as default which means Fireball had to spend a week to "convert" a DDK sample to ReactOS and which makes *any* DDK code uncompilable by GCC (purposeful sabotage?). Recall the register allocation bug 2 years ago which used ebx *before* push ebx to save it, and I can name more.
If you point out the bug numbers in question I'd be happy to pester the gcc team. I won't file a bug report for these issues as I don't know enough about them but get me a list with bugzilla IDs and I will at least spam them for a while.
1) 64-bit pointer bug: I asked Thomas to make a test-case and submit it. I don't know if he has. 2) Pragma support: GCC doesn't view msvc-compatibility as a priority. 3) -mrtd: Has been fixed and re-broken countless times. This is an example of one of them: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9601. Still present in 4.2 4) One of multiple Vista bugs: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30335.
There's also the fact that 4.1.2+ are unusuable on -j2 or more because they incorrectly map PCH files, so our build server is forced to use 3.4.5, which is incompatible with KJK's new PSEH. 4.2 is also incompatible with PSEH due to other, newly added exciting bugs.
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Steven Edwards Sent: April-25-07 12:15 PM To: ReactOS Development List Subject: Re: [ros-dev] [ros-diffs] [dgorbachev] 26483: Undo r26482 change, waste more stack space.
On 4/25/07, Alex Ionescu ionucu@videotron.ca wrote:
Besides, just like Windows has a very strong internal architecture and at its core is a remarkable OS, so is GCC as a compiler. Some of its
developers
are true compiler designers and some work for large companies, many of
which
even hold and license patents to GCC. The optimizer in GCC is very
powerful
and can even rival MSVC in some cases. The cases where it doesn't cause a bug. Because this *is* the problem behind GCC! It's a remarkable, powerful and portable compiler, yet it is unreliable and sometimes downright
stupid.
Recall your unsuccessful warnings patch to emulate MSVC. Recall the 64-bit pointer bug I discovered. Recall the the lack of useful pragmas that other compilers support. Recall the inability to use STDCALL as default which means Fireball had to spend a week to "convert" a DDK sample to ReactOS
and
which makes *any* DDK code uncompilable by GCC (purposeful sabotage?). Recall the register allocation bug 2 years ago which used ebx *before*
push
ebx to save it, and I can name more.
If you point out the bug numbers in question I'd be happy to pester the gcc team. I won't file a bug report for these issues as I don't know enough about them but get me a list with bugzilla IDs and I will at least spam them for a while.
On 4/25/07, Alex Ionescu ionucu@videotron.ca wrote:
- Pragma support: GCC doesn't view msvc-compatibility as a priority.
What Pragma statements are required? I guess there is no way to hack around them? At the very least we can bug the mingw developers about this one, if not the main gcc team. According to the gcc man page.....
The ISO standard specifies that the effect of the `#pragma' directive is implementation-defined. The GNU C preprocessor recognizes some pragmas, and passes unrecognized ones through to the preprocessor output, so they are available to the compilation pass.
Sorry for the multiple replies. I am taking a look at these issues piecemeal over the day and did not expect to get back to it so soon.
On 4/25/07, Alex Ionescu ionucu@videotron.ca wrote:
- One of multiple Vista bugs:
Danny seems to be on top of this one.
There's also the fact that 4.1.2+ are unusuable on -j2 or more because they incorrectly map PCH files, so our build server is forced to use 3.4.5, which is incompatible with KJK's new PSEH. 4.2 is also incompatible with PSEH due to other, newly added exciting bugs.
Is there a bug report for any of these issues?
Alex Ionescu wrote:
- 64-bit pointer bug: I asked Thomas to make a test-case and submit it. I
don't know if he has.
I hope so. So it disappears in time.
- Pragma support: GCC doesn't view msvc-compatibility as a priority.
Ok why. Microsoft does not take Gcc compatibility as a priority. MSVC does not support gcc Pragma's either. But gcc is being good and supporting _pragma from C99 allowing more flexable handling.
- -mrtd: Has been fixed and re-broken countless times. This is an example
of one of them: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9601. Still present in 4.2
Please take a closer look at what 4.2 is truly doing. Double set of builtins. -mrtd is swaping the builtins. The last post of so called problem is the expected result. With -mrtd you have stdcall builtins. Without you have cdecl. There are options where this can be still forced to be cdecl or stdcall only for builtins and that would give the result a lot of people would expect or inversed to what people expect.
In theory with a bit of tweeking cdecl and stdcall for builtin calls could be made perfectly acceptable since they are both there.
gcc version 3.4 20030130 (experimental) << mingw trash missing the double set of builtins and the other fix to -mrtd to be correct half of the double buildin patches and many other strange errors caused by mingw own runtime files.
As I said it was fixed. I did not say it was fixed how everyone expected.
- One of multiple Vista bugs:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30335.
There's also the fact that 4.1.2+ are unusuable on -j2 or more because they incorrectly map PCH files, so our build server is forced to use 3.4.5, which is incompatible with KJK's new PSEH. 4.2 is also incompatible with PSEH due to other, newly added exciting bugs.
Gcc is not alone with Vista Bugs. Firefox had about 100 regarding vista.. Microsoft worked on fixing them. Funny bit Microsoft developers are working on fixing some of the Vista bugs in gcc.
4.2 is known to have errors still a work in progress. So nothing to say if PSEH will or will not work in final release yet. No point jumping gun.
4.2 is a fairly large upgrade. Lots of important alterations. Price lot of havoc.
This is part of the problem of mingw. Lot of the versions are build from experimental versions then patches applied. And worst bit halfway threw a patch set being applied in a lot of cases. Just think for one minute some of the problems Reactos has when that is done.
Problem with gcc experimental versions they have not been threw the final bug squashing process. I am more trusting of a gcc if patchs from the experimental version has been hand picked. and applied to a stable version. At least weakness as kept to a limited number of places and a complete set should be extracted as a block not getting have a set of patchs.
Peter Dolding
---------------------------------------------------------------------- Get a free email address with REAL anti-spam protection. http://www.bluebottle.com
Peter Dolding wrote:
Alex Ionescu wrote:
- -mrtd: Has been fixed and re-broken countless times. This is an example
of one of them: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9601. Still present in 4.2
Please take a closer look at what 4.2 is truly doing. Double set of builtins. -mrtd is swaping the builtins. The last post of so called problem is the expected result. With -mrtd you have stdcall builtins. Without you have cdecl. There are options where this can be still forced to be cdecl or stdcall only for builtins and that would give the result a lot of people would expect or inversed to what people expect.
In theory with a bit of tweeking cdecl and stdcall for builtin calls could be made perfectly acceptable since they are both there.
gcc version 3.4 20030130 (experimental) << mingw trash missing the double set of builtins and the other fix to -mrtd to be correct half of the double buildin patches and many other strange errors caused by mingw own runtime files.
As I said it was fixed. I did not say it was fixed how everyone expected.
I did some more digging. Apparently adding microsoft symbols for stdcall and fastcall in mingw broke builtin auto fixing of call type.
Its nothing uncommon for me on other platforms to #pragma GCC system_header __attribute__((fastcall)) double cos( double x); And let it fall back on the builtin until I can add the function.
It is a form of automatic wrapping that is missing in action.
Peter Dolding
---------------------------------------------------------------------- Get a free email account with anti spam protection. http://www.bluebottle.com
Here is a crazy idea: dont just support the rosbe, but also pick a gcc version which basically builds ros alright and place it in the svn as an official ros supported compiler, upgrading when needed and if you find gcc trouble, fix it yourself, and if it is a fix official gcc could use, submit it there too!
sure it means allot to set aside a one supported compiler, but if stuff breaks, it really helps to know its not your (projects) fault
------ psudobuddha
So basically you suggest to fork gcc.
The idea is good, but I think this project doesn't have the required resources, as this would probably require a single dev to dedicate his whole spare time for this job.
Brian schrieb:
Here is a crazy idea: dont just support the rosbe, but also pick a gcc version which basically builds ros alright and place it in the svn as an official ros supported compiler, upgrading when needed and if you find gcc trouble, fix it yourself, and if it is a fix official gcc could use, submit it there too!
sure it means allot to set aside a one supported compiler, but if stuff breaks, it really helps to know its not your (projects) fault
psudobuddha
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
not quite, just do a little more than say it compiles on x version of gcc: actually set aside x version and when version y breaks ros compiling, dont use it, and if z gcc compiles ros, move on up: basicly set aside an ReactOS "Official" Compiler. If b feature is disabled by default in gcc, enable it in the "Official" compiler
On 6/6/07, David Hinz post.center@gmail.com wrote:
So basically you suggest to fork gcc.
The idea is good, but I think this project doesn't have the required resources, as this would probably require a single dev to dedicate his whole spare time for this job.
Brian schrieb:
Here is a crazy idea: dont just support the rosbe, but also pick a gcc version which basically builds ros alright and place it in the svn as an official ros supported compiler, upgrading when needed and if you find gcc trouble, fix it yourself, and if it is a fix official gcc could use, submit it there too!
sure it means allot to set aside a one supported compiler, but if stuff breaks, it really helps to know its not your (projects) fault
psudobuddha
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
This makes no sense, we don't really have compiler problems.
You're identifying a problem that doesn't exist.
Everyone should be using RosBE which includes the official ReactOS compiler, and is carefully tested to ensure stability.
Anyone not using RosBE is using an unsupported environment, and thus will be less likely to gain developer support if things start to go wrong.
It's best to let GCC handle the compiler side of things, and we'll take care of ReactOS.
_____
From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Brian Sent: 07 June 2007 01:11 To: ReactOS Development List Subject: Re: [ros-dev] [ros-diffs] [dgorbachev] 26483: Undo r26482 change,waste more stack space.
not quite, just do a little more than say it compiles on x version of gcc: actually set aside x version and when version y breaks ros compiling, dont use it, and if z gcc compiles ros, move on up: basicly set aside an ReactOS "Official" Compiler. If b feature is disabled by default in gcc, enable it in the "Official" compiler
On 6/6/07, David Hinz post.center@gmail.com wrote:
So basically you suggest to fork gcc.
The idea is good, but I think this project doesn't have the required resources, as this would probably require a single dev to dedicate his whole spare time for this job.
Brian schrieb:
Here is a crazy idea: dont just support the rosbe, but also pick a gcc version which basically builds ros alright and place it in the svn as an official ros supported compiler, upgrading when needed and if you find gcc trouble, fix it yourself, and if it is a fix official gcc could use, submit it there too!
sure it means allot to set aside a one supported compiler, but if stuff breaks, it really helps to know its not your (projects) fault
psudobuddha
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
On Thu, Apr 26, 2007 at 06:24:51PM +1000, Peter Dolding wrote:
Alex Ionescu wrote:
[...]
- Pragma support: GCC doesn't view msvc-compatibility as a priority.
I'd like to know more about which pragma's, and more details about the other potential incompatibilities. I have several large code bases I may be porting soon.
[...]
Ok why. Microsoft does not take Gcc compatibility as a priority. MSVC does not support gcc Pragma's either. But gcc is being good and supporting _pragma from C99 allowing more flexable handling.
I understand you saying gcc compatibility probably isn't a priority. I'd like to note that it is considered.
At the Microsoft Visual Studio .Net 2003 launch in Winnipeg, there was a reference to a new inheritance feature that gcc had for a while. This was said to be important at least partially because it allowed more gcc code to compile.
Although it's likely not a high general priority, some gcc compatibility is a priority as many customers and internal developers use gcc code. Microsoft considers migration from unix to be at least somewhat important, probably particularly to certain customers/contracts.
[...]
Gcc is not alone with Vista Bugs. Firefox had about 100 regarding vista.. Microsoft worked on fixing them. Funny bit Microsoft developers are working on fixing some of the Vista bugs in gcc.
I'm not entirely surprised. I recall hearing about NAPI or alike. If you look, you'll find MS using open source tools like perl in the windbg symbol server, chkinf... I've run into others that I don't recall offhand.
Microsoft has even hired many Open Source developers including Daniel Robinson of Gentoo fame. They even seem to have Open Source compatibility lab(s) that are reported from time to time.
There is a bit of "the right hand doesn't know what the left hand is doing". But I would imagine most MSVC developers would be willing to accommodate gcc compatibility requests. Also large open source projects probably provide a good application compatibility testbed. Some work on open source products may save future compatibility support requests too.
Drew Daniels Resume: http://www.boxheap.net/ddaniels/resume.html
-
Alex Ionescu -
Brian -
David Hinz -
Drew Scott Daniels -
Ged -
hto＠mail.cnt.ru -
James Tabor -
Peter Dolding -
ShadowFlare -
Steven Edwards -
Thomas Weidenmueller