Re: [ros-dev] [ros-diffs] [dgorbachev] 26483: Undo r26482 change, waste more stack space.

[Alex Ionescu]

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(a)reactos.org [mailto:[e-mail]] On Behalf Of
dgorbachev(a)svn.reactos.org
Sent: April-24-07 1:06 AM
To: ros-diffs(a)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/…
==============================================================================
--- 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

[Peter Dolding]

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.

[Alex Ionescu]

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(a)reactos.org [mailto:[e-mail]] On
Behalf Of hto(a)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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[James Tabor]

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

[Peter Dolding]

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(a)reactos.org [mailto:[e-mail]] On
>  Behalf Of hto(a)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

[ShadowFlare]

On 4/24/07, Peter Dolding <oiaohm(a)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

[Thomas Weidenmueller]

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(a)reactos.org [mailto:[e-mail]] On
>  Behalf Of hto(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Alex Ionescu]

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(a)reactos.org [mailto:[e-mail]] 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(a)reactos.org [mailto:[e-mail]] On
>  Behalf Of hto(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>   
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[Steven Edwards]

On 4/25/07, Alex Ionescu <ionucu(a)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.

-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo

[Alex Ionescu]

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(a)reactos.org [mailto:[e-mail]] 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(a)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.

-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[Steven Edwards]

On 4/25/07, Alex Ionescu <ionucu(a)videotron.ca> wrote:
>   2) 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.


-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo

[Steven Edwards]

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(a)videotron.ca> wrote:
>   4) One of multiple Vista bugs:
>  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30335. 
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?

-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo

[Peter Dolding]

Alex Ionescu wrote:
>   1) 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.
>   2) 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.
>   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
>     
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.

>   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.
>     
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]

Peter Dolding wrote:
>   Alex Ionescu wrote:
>    
> >   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
> >    
> >       
>  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

[Brian]

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

[David Hinz]

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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Brian]

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(a)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(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev 
> _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  


-- 
brian

[Ged]

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(a)reactos.org [mailto:[e-mail]] 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(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________ 
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev




-- 
brian 



This message contains confidential information and is intended only for the individual
named. If you are not the named addressee you should not disseminate, distribute or copy
this e-mail. Please notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be
guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does
not accept liability for any errors or omissions in the contents of this message, which
arise as a result of e-mail transmission. If verification is required please request a
hard-copy version. 

Amteus PLC
57 Cardigan Lane,
Leeds, 
LS4 2LE
t:[phone]
f: [phone]

Registered in England No 4760795

http://www.amteus.com

[Drew Scott Daniels]

On Thu, Apr 26, 2007 at 06:24:51PM +1000, Peter Dolding wrote:
>   Alex Ionescu wrote: 
[...]
>   > 2) 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