You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(63) |
Sep
(78) |
Oct
(111) |
Nov
(104) |
Dec
(39) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(69) |
Feb
(68) |
Mar
(23) |
Apr
(61) |
May
(56) |
Jun
(122) |
Jul
(82) |
Aug
(44) |
Sep
(63) |
Oct
(73) |
Nov
(77) |
Dec
(102) |
2008 |
Jan
(34) |
Feb
(51) |
Mar
(39) |
Apr
(43) |
May
(8) |
Jun
(59) |
Jul
(69) |
Aug
(97) |
Sep
(140) |
Oct
(72) |
Nov
(37) |
Dec
(35) |
2009 |
Jan
(70) |
Feb
(104) |
Mar
(42) |
Apr
(121) |
May
(161) |
Jun
(109) |
Jul
(90) |
Aug
(85) |
Sep
(104) |
Oct
(59) |
Nov
(76) |
Dec
(145) |
2010 |
Jan
(123) |
Feb
(45) |
Mar
(37) |
Apr
(9) |
May
|
Jun
(5) |
Jul
(22) |
Aug
|
Sep
(4) |
Oct
(5) |
Nov
(2) |
Dec
(83) |
2011 |
Jan
(19) |
Feb
(33) |
Mar
(14) |
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
(8) |
Dec
(8) |
2012 |
Jan
(2) |
Feb
(4) |
Mar
(1) |
Apr
|
May
(5) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
From: Sébastien L. <sq...@gm...> - 2010-07-23 10:40:23
|
Everything is not over yet. There is still a large amount of windows mobile device out there that deserve cegcc. "windows phone" may be a silly thing, it's not the dominant os on the market yet. I hope cegcc will continue to live for those of us who have normal WM phones. Remember, there is still software written for the ataris and amigas. Sebastien On Fri, Jul 23, 2010 at 10:57 AM, İsmail "cartman" Dönmez < is...@na...> wrote: > > > Pavel Pavlov wrote: > > > > I think I was subscribed to cegcc before 4.5.0 was released (release date > > is like a couple of months ago). > > I tried to merge and see what I can do to fix it, but I came to > conclusion > > that it's all wasted time. I'm not going to do this same job once there > is > > a new gcc, since they don't want to take cegcc changes into mainline and > > they announced that arm-wince-pe support will be removed in 4.6.x. It's > > even difficult to get any replies related to arm/wince on gcc mailing > > list. > > If windows phone won't support native development I really hope that > > winphone7 will be born dead and completely eliminated from the marked > > asap. Major apps announced that they are dropping windows mobile support: > > firefox mobile, skype and almost every app that had a windows mobile port > > as a supplementary port. Wince existed for years and newbies like iphone > > and android stormed by wince and the only reason I personally programmed > > for wince is because it's possible to use portable code that runs on pc > > and windows mobile. I hardly doubt that I'll be ever learning Silverlight > > or whatever is required for winphone 7, or better to say I hope they > > miserably fail so that I wouldn't need to learn what Silverlight Is all > > about ... In one of their blogs about winpne7 and silverlight they said > > something like "500000 silverlight developers in a matter of a day became > > also windows phone 7 developers"... is that 500000 downloads of > > Silverlight they consider that there is 500000developers??!?? Complete > > BS... > > > > > > > Its time to RIP cegcc, Danny and others took their time and did a great > job, > however Microsoft doesn't wanna play this way. > > Anyhow thanks to everybody for keeping this project alive so far. > > ciao, > ismail > > > ----- > Regards, > İsmail DÖNMEZ > > -- > View this message in context: > http://cegcc-devel.3372302.n2.nabble.com/Porting-cegcc-changes-to-latest-version-of-cegcc-tp5278887p5328817.html > Sent from the cegcc-devel mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Cegcc-devel mailing list > Ceg...@li... > https://lists.sourceforge.net/lists/listinfo/cegcc-devel > |
From: İsmail c. D. <is...@na...> - 2010-07-23 09:17:03
|
Pavel Pavlov wrote: > > I think I was subscribed to cegcc before 4.5.0 was released (release date > is like a couple of months ago). > I tried to merge and see what I can do to fix it, but I came to conclusion > that it's all wasted time. I'm not going to do this same job once there is > a new gcc, since they don't want to take cegcc changes into mainline and > they announced that arm-wince-pe support will be removed in 4.6.x. It's > even difficult to get any replies related to arm/wince on gcc mailing > list. > If windows phone won't support native development I really hope that > winphone7 will be born dead and completely eliminated from the marked > asap. Major apps announced that they are dropping windows mobile support: > firefox mobile, skype and almost every app that had a windows mobile port > as a supplementary port. Wince existed for years and newbies like iphone > and android stormed by wince and the only reason I personally programmed > for wince is because it's possible to use portable code that runs on pc > and windows mobile. I hardly doubt that I'll be ever learning Silverlight > or whatever is required for winphone 7, or better to say I hope they > miserably fail so that I wouldn't need to learn what Silverlight Is all > about ... In one of their blogs about winpne7 and silverlight they said > something like "500000 silverlight developers in a matter of a day became > also windows phone 7 developers"... is that 500000 downloads of > Silverlight they consider that there is 500000developers??!?? Complete > BS... > > Its time to RIP cegcc, Danny and others took their time and did a great job, however Microsoft doesn't wanna play this way. Anyhow thanks to everybody for keeping this project alive so far. ciao, ismail ----- Regards, İsmail DÖNMEZ -- View this message in context: http://cegcc-devel.3372302.n2.nabble.com/Porting-cegcc-changes-to-latest-version-of-cegcc-tp5278887p5328817.html Sent from the cegcc-devel mailing list archive at Nabble.com. |
From: Pavel P. <pa...@su...> - 2010-07-16 21:35:54
|
> -----Original Message----- > From: Vincent Richomme [mailto:fo...@sm...] > Sent: Friday, July 16, 2010 16:22 > To: Pavel Pavlov > Cc: dan...@sc...; ceg...@li... > Subject: Re: [Cegcc-devel] Porting cegcc changes to latest version of cegcc > > On Thu, 15 Jul 2010 16:45:51 -0400 > wrote: > >> > I also thought about updating cegcc, but decided against it because > >> > I found merging/rebasing with Subversion too cumbersome. Thought > >> > about doing it cleanly with git (import gcc svn with all its > >> > history, copy cegcc on top, rebase on latest gcc) - this way, we > >> > could easily extract separate patches from cegcc, and submit them to > gcc. > >> > >> I won't go into a discussion about which version management system to > >> use, I know too little of the differences between them. I doubt that > >> subversion, or even cvs, give you much less useful support here. > >> > >> Basically, take a diff between 4.4.0 and (somewhere before my DLL > >> changes) and you should be up and running quickly. > >> > > > > Hi Danny, > > I tried to do the merge into gcc tags/release_4_5_0 mearged all > conflicts, > > made a couple of changes, but the end result is discouraging. > > First of all, if I tried my simple test related to alignment, I see > > that the 4.5.0 cegcc does not align stack variables, the other big > > issue is > that > > it still has double size dlls full of zeros. > > > > I tried to check your changes related to 6.1 dll, and these changes > > are really small (two commits only). I tried to comment them out but > > the > result > > was still the same and did not have any effect. > > Maybe I didn't do something correctly... or maybe your change didn't > > actually have that negative effect. Are you sure that because of your > > change you get that problem? > > thanks > > > > > > Hi, > > Just for information, when I was still using actively cegcc and watching this ML > I think Pedro Alves made a patch for gcc-4.5. > Please try to find it in the archives and if you cannot find it I will try. > I think I was subscribed to cegcc before 4.5.0 was released (release date is like a couple of months ago). I tried to merge and see what I can do to fix it, but I came to conclusion that it's all wasted time. I'm not going to do this same job once there is a new gcc, since they don't want to take cegcc changes into mainline and they announced that arm-wince-pe support will be removed in 4.6.x. It's even difficult to get any replies related to arm/wince on gcc mailing list. If windows phone won't support native development I really hope that winphone7 will be born dead and completely eliminated from the marked asap. Major apps announced that they are dropping windows mobile support: firefox mobile, skype and almost every app that had a windows mobile port as a supplementary port. Wince existed for years and newbies like iphone and android stormed by wince and the only reason I personally programmed for wince is because it's possible to use portable code that runs on pc and windows mobile. I hardly doubt that I'll be ever learning Silverlight or whatever is required for winphone 7, or better to say I hope they miserably fail so that I wouldn't need to learn what Silverlight Is all about ... In one of their blogs about winpne7 and silverlight they said something like "500000 silverlight developers in a matter of a day became also windows phone 7 developers"... is that 500000 downloads of Silverlight they consider that there is 500000developers??!?? Complete BS... |
From: Vincent R. <fo...@sm...> - 2010-07-16 20:22:18
|
On Thu, 15 Jul 2010 16:45:51 -0400 wrote: >> > I also thought about updating cegcc, but decided against it because I >> > found merging/rebasing with Subversion too cumbersome. Thought about >> > doing it cleanly with git (import gcc svn with all its history, copy >> > cegcc on top, rebase on latest gcc) - this way, we could easily >> > extract separate patches from cegcc, and submit them to gcc. >> >> I won't go into a discussion about which version management system to >> use, >> I know too little of the differences between them. I doubt that >> subversion, >> or even cvs, give you much less useful support here. >> >> Basically, take a diff between 4.4.0 and (somewhere before my DLL >> changes) and you should be up and running quickly. >> > > Hi Danny, > I tried to do the merge into gcc tags/release_4_5_0 mearged all conflicts, > made a couple of changes, but the end result is discouraging. > First of all, if I tried my simple test related to alignment, I see that > the 4.5.0 cegcc does not align stack variables, the other big issue is that > it still has double size dlls full of zeros. > > I tried to check your changes related to 6.1 dll, and these changes are > really small (two commits only). I tried to comment them out but the result > was still the same and did not have any effect. > Maybe I didn't do something correctly... or maybe your change didn't > actually have that negative effect. Are you sure that because of your > change you get that problem? > thanks > > Hi, Just for information, when I was still using actively cegcc and watching this ML I think Pedro Alves made a patch for gcc-4.5. Please try to find it in the archives and if you cannot find it I will try. Regards |
From: Pavel P. <pa...@su...> - 2010-07-15 20:47:30
|
> > I also thought about updating cegcc, but decided against it because I > > found merging/rebasing with Subversion too cumbersome. Thought about > > doing it cleanly with git (import gcc svn with all its history, copy > > cegcc on top, rebase on latest gcc) - this way, we could easily > > extract separate patches from cegcc, and submit them to gcc. > > I won't go into a discussion about which version management system to use, > I know too little of the differences between them. I doubt that subversion, > or even cvs, give you much less useful support here. > > Basically, take a diff between 4.4.0 and (somewhere before my DLL > changes) and you should be up and running quickly. > Hi Danny, I tried to do the merge into gcc tags/release_4_5_0 mearged all conflicts, made a couple of changes, but the end result is discouraging. First of all, if I tried my simple test related to alignment, I see that the 4.5.0 cegcc does not align stack variables, the other big issue is that it still has double size dlls full of zeros. I tried to check your changes related to 6.1 dll, and these changes are really small (two commits only). I tried to comment them out but the result was still the same and did not have any effect. Maybe I didn't do something correctly... or maybe your change didn't actually have that negative effect. Are you sure that because of your change you get that problem? thanks |
From: Pavel P. <pa...@su...> - 2010-07-13 10:02:05
|
It appears that 4.4.0 cegcc doesn't align properly. There's a simple test code: typedef struct{ int i; short d __attribute__((aligned(16))); } test16 __attribute__((aligned(16))) ; void do_test16_dummy(void *); void do_test16_stack(int N) { test16 tmp[N]; do_test16_dummy(&tmp[0]); } >From that code, sizeof test16 is at least 32 bytes, but cegcc 4.4.0 compiles it as if it was 16 bytes only. At the same time gcc for android based on 4.4.0 generates correct code, cegcc 4.1.0 also generates correct code. Command line used: /opt/mingw32ce-4.4.0/bin/arm-mingw32ce-gcc -O3 -std=gnu99 -fomit-frame-pointer -S -o align16.s.4.4.0 align16.c Outputs: do_test16_stack: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 1, uses_anonymous_args = 0 stmfd sp!, {fp, lr} mov r0, r0, asl #4 // <-- error, sizeof test16 has to be 32! add r0, r0, #16 add fp, sp, #4 sub sp, sp, r0 add r0, sp, #15 bic r0, r0, #15 bl do_test16_dummy sub sp, fp, #4 ldmfd sp!, {fp, pc} same compilation with 4.1.0: do_test16_stack: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 1, uses_anonymous_args = 0 mov ip, sp stmfd sp!, {r4, fp, ip, lr, pc} mov r0, r0, asl #5 // <--- OK add r0, r0, #8 mov r4, sp rsb sp, r0, sp add r0, sp, #7 sub fp, ip, #4 bic r0, r0, #7 bl do_test16_dummy mov sp, r4 sub sp, fp, #16 ldmfd sp, {r4, fp, sp, pc} android ndk gcc 4.4.0: do_test16_stack: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 1, uses_anonymous_args = 0 mov r0, r0, asl #5 // <--- OK add r0, r0, #8 stmfd sp!, {fp, lr} add fp, sp, #4 sub sp, sp, r0 mov r0, sp bl do_test16_dummy sub sp, fp, #4 ldmfd sp!, {fp, pc} Any ideas what could be wrong? 4.4.0 from android is OK, could that be related to wince related changes or it's (more likely) because there is some bugs related to coff and alignment in gcc code?.. The reason I came to that error is that I had a weird problem: I was getting misalignment crashes and wanted to printout addresses of some structure members and their alignment. At some point I got strange output, where address of structure was clearly not 16 bit aligned, but that same address modulo 16 would output 0! After I run some tests it looks like it's related to this alignment problem. |
From: Pavel P. <pa...@su...> - 2010-07-12 23:06:07
|
> -----Original Message----- > From: Danny Backx [mailto:dan...@sc...] > Sent: Monday, July 12, 2010 16:20 > To: Pavel Pavlov > Cc: ceg...@li... > Subject: RE: [Cegcc-devel] Porting cegcc changes to latest version of cegcc > > On Mon, 2010-07-12 at 14:59 -0400, Pavel Pavlov wrote: > > After checking some files I noticed that VERSIONS file and checked out > > octorer 17 2009 version of binutils. I merged all the changes into > > latest version of binutils. Also, I noticed that versions of binutils > > in cegcc svn has some strange changes, which look to me more likely > > like incorrect merge from previous versions of binutils. Plus, there > > are a bunch of files that simply do not exist in that 0ct17,2009 > > version of binutils. > > The reason I wanted to merge binutils is because I have that strange > > problem that dlls produced with cegcc-4.4.0; dlls are almost twice > > bigger compared to builds with cegcc 4.1.0 (because half of the > > produced dll is filled with zeros). I checked object files that go > > into the dll and all of them are normal and have no zeros, but the > > final dll is full of shi...., I mean zeros. So, it looked as if it was > > a linker problem and the linker is part of binutils package. I thought > > that if I take latest binutils I'll probably get it fixed. > > Still, after I merged changes into latest binutils I got the same > > results and the binaries produced are almost bitexact (at least that's > > a good sign that I didn't screw up with the merge). > > The "twice as big" and "zeroes" issue might be a consequence of my > incomplete work on supporting WinCE 6.1+ DLLs. Incomplete because I got > zero support and then when I was loosing courage, I got the Android device > ... > > You can take out the WinCE 6.* changes and you'll probably see that that > issue is gone. > I don't understand completely what you mean here. What was the original reason for your changes that caused that doubled size&zeroes problem? Is that the infamous problem when binaries did not load on newer phones? By the way, I fixed that problem on my side differently. Because dlls that I load are quite big (around 10MB in total) then I have huge problem on Windows Mobile. Who knows windows mobile memory model will understand that: it's related to 32MB per process slot and all dlls combined take away upper part of that slot. So, either way, 10MB of dll's will likely cripple entire phone and will affect most of apps running on the phone; so I wrote my own dll loader. Basically, I load it using regular fread, parse PE headers, allocate executable pages and do all relocations manually... so, as of now I'm not that worried if gcc builds dll that doesn't load :) it seems that there some strange thing in wince loader, my manually written loader loads them just fine and works well. I'll try to see svn log for your changes to try to figure out what the problem was, maybe I'll have some luck |
From: Danny B. <dan...@sc...> - 2010-07-12 20:23:03
|
On Mon, 2010-07-12 at 08:23 +0200, Max Kellermann wrote: > On 2010/07/11 10:11, Danny Backx <dan...@sc...> wrote: > > I can give you and other interested parties write access to the cegcc > > svn if you like. > > Hi Danny & Pavel, > > I also thought about updating cegcc, but decided against it because I > found merging/rebasing with Subversion too cumbersome. Thought about > doing it cleanly with git (import gcc svn with all its history, copy > cegcc on top, rebase on latest gcc) - this way, we could easily > extract separate patches from cegcc, and submit them to gcc. I won't go into a discussion about which version management system to use, I know too little of the differences between them. I doubt that subversion, or even cvs, give you much less useful support here. Basically, take a diff between 4.4.0 and (somewhere before my DLL changes) and you should be up and running quickly. > We are still waiting that Pedro Alves merge the cegcc changes > upstream... I'm not entirely sure that this will happen. Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info |
From: Danny B. <dan...@sc...> - 2010-07-12 20:18:18
|
On Mon, 2010-07-12 at 14:59 -0400, Pavel Pavlov wrote: > After checking some files I noticed that VERSIONS file and checked out > octorer 17 2009 version of binutils. I merged all the changes into > latest version of binutils. Also, I noticed that versions of binutils > in cegcc svn has some strange changes, which look to me more likely > like incorrect merge from previous versions of binutils. Plus, there > are a bunch of files that simply do not exist in that 0ct17,2009 > version of binutils. > The reason I wanted to merge binutils is because I have that strange > problem that dlls produced with cegcc-4.4.0; dlls are almost twice > bigger compared to builds with cegcc 4.1.0 (because half of the > produced dll is filled with zeros). I checked object files that go > into the dll and all of them are normal and have no zeros, but the > final dll is full of shi...., I mean zeros. So, it looked as if it was > a linker problem and the linker is part of binutils package. I thought > that if I take latest binutils I'll probably get it fixed. > Still, after I merged changes into latest binutils I got the > same results and the binaries produced are almost bitexact (at least > that's a good sign that I didn't screw up with the merge). The "twice as big" and "zeroes" issue might be a consequence of my incomplete work on supporting WinCE 6.1+ DLLs. Incomplete because I got zero support and then when I was loosing courage, I got the Android device ... You can take out the WinCE 6.* changes and you'll probably see that that issue is gone. Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info |
From: Pavel P. <pa...@su...> - 2010-07-12 19:31:17
|
> > On 2010/07/11 10:11, Danny Backx <dan...@sc...> wrote: > >> I can give you and other interested parties write access to the cegcc > >> svn if you like. > > > > Hi Danny & Pavel, > > > > I also thought about updating cegcc, but decided against it because I > > found merging/rebasing with Subversion too cumbersome. Thought about > > doing it cleanly with git (import gcc svn with all its history, copy > > cegcc on top, rebase on latest gcc) - this way, we could easily > > extract separate patches from cegcc, and submit them to gcc. > > We are still waiting that Pedro Alves merge the cegcc changes upstream... > > Vincent > By the way, if anybody will do that, I think we should consider some changes that I had to apply to cegcc: gcc\config\arm\coff.h : (see http://readlist.com/lists/gcc.gnu.org/gcc-help/3/19086.html ) /* COFF targets use constant pool instead of MOVW/MOVT. */ #define TARGET_USE_MOVT 0 This makes sure that gcc doesn't try to generate MOVW/MOVT sequence for relocs when you build for armv7. It's probably binutils limitation, the error is: ....s: Assembler messages: ....s:10: Error: cannot represent BFD_RELOC_ARM_MOVW relocation in this object file format. Still, that kinds of relocs are probably supported by the kernel (IMAGE_REL_BASED_HIGH and IMAGE_REL_BASED_LOW fron winnt.h) The other important change is in gcc\config\arm\wince-pe.h: #define BIGGEST_ALIGNMENT 64 has to be changed to 128. Many project use attribute aligned of 16 and gcc for that kind of attributes issues a warning that max platform alignment is 8 and aligns to 8 bytes only (which may or may not happen to be 8 bytes). The reason for "has to be" instead of "should be" is because some neon instructions require 16 byte alignment. (vst.128) |
From: Pavel P. <pa...@su...> - 2010-07-12 18:59:50
|
> -----Original Message----- > From: Danny Backx [mailto:dan...@sc...] > Cc: ceg...@li... > Subject: Re: [Cegcc-devel] Porting cegcc changes to latest version of cegcc > > On Sat, 2010-07-10 at 19:41 -0400, Pavel Pavlov wrote: > > I'm thinking to update my version of cegcc to latest version of gcc. It look as > the project is almost sleeping now. > > That's because my wife and daughter "stole" my two devices in exchange for > me being "allowed" to buy an Android phone. > > > So, I'd like to try to take changes made in cegcc into some latest release of > binutils and gcc. What's the recommended way to do it?.. > > Talk to the relevant mailing list. > > > I already tried to compare, but the differences are HUGE so I can't know > myself what fixes I'll need to apply to gcc. > > Can you maybe tell me what version of gcc and binutil (svn revision) was > initially taken as a base for cegcc, so that I could make a diff and apply it to > latest version of gcc/binutils? > > See src/VERSIONS . After checking some files I noticed that VERSIONS file and checked out octorer 17 2009 version of binutils. I merged all the changes into latest version of binutils. Also, I noticed that versions of binutils in cegcc svn has some strange changes, which look to me more likely like incorrect merge from previous versions of binutils. Plus, there are a bunch of files that simply do not exist in that 0ct17,2009 version of binutils. The reason I wanted to merge binutils is because I have that strange problem that dlls produced with cegcc-4.4.0; dlls are almost twice bigger compared to builds with cegcc 4.1.0 (because half of the produced dll is filled with zeros). I checked object files that go into the dll and all of them are normal and have no zeros, but the final dll is full of shi...., I mean zeros. So, it looked as if it was a linker problem and the linker is part of binutils package. I thought that if I take latest binutils I'll probably get it fixed. Still, after I merged changes into latest binutils I got the same results and the binaries produced are almost bitexact (at least that's a good sign that I didn't screw up with the merge). > > I can give you and other interested parties write access to the cegcc svn if > you like. > If I knew anything about gcc internals and all these weird scripts that it uses, I'd took write access to svn, but compiler and everything related to it is something that I have zero knowledge about. I wouldn't even be sure to commit my merge because I can't even approve my changes, I merely compared folders of oct17,2009 binutils with binutils folder from gcc, and manually applied the same change to the latest version of binutils. All my changes would still need to be checked by others who have knowledge of gcc or cegcc changes. I can post a diff that I made to binutils svn if it's of any value to the project. I'm thinking to try to do the same task with gcc 4.4.5 on weekend when I have some more free time. |
From: Vincent T. <vt...@un...> - 2010-07-12 06:28:30
|
On Mon, 12 Jul 2010, Max Kellermann wrote: > On 2010/07/11 10:11, Danny Backx <dan...@sc...> wrote: >> I can give you and other interested parties write access to the cegcc >> svn if you like. > > Hi Danny & Pavel, > > I also thought about updating cegcc, but decided against it because I > found merging/rebasing with Subversion too cumbersome. Thought about > doing it cleanly with git (import gcc svn with all its history, copy > cegcc on top, rebase on latest gcc) - this way, we could easily > extract separate patches from cegcc, and submit them to gcc. We are still waiting that Pedro Alves merge the cegcc changes upstream... Vincent |
From: Max K. <ma...@du...> - 2010-07-12 06:23:37
|
On 2010/07/11 10:11, Danny Backx <dan...@sc...> wrote: > I can give you and other interested parties write access to the cegcc > svn if you like. Hi Danny & Pavel, I also thought about updating cegcc, but decided against it because I found merging/rebasing with Subversion too cumbersome. Thought about doing it cleanly with git (import gcc svn with all its history, copy cegcc on top, rebase on latest gcc) - this way, we could easily extract separate patches from cegcc, and submit them to gcc. Max |
From: Danny B. <dan...@sc...> - 2010-07-11 08:10:10
|
On Sat, 2010-07-10 at 19:41 -0400, Pavel Pavlov wrote: > I'm thinking to update my version of cegcc to latest version of gcc. It look as the project is almost sleeping now. That's because my wife and daughter "stole" my two devices in exchange for me being "allowed" to buy an Android phone. > So, I'd like to try to take changes made in cegcc into some latest release of binutils and gcc. What's the recommended way to do it?.. Talk to the relevant mailing list. > I already tried to compare, but the differences are HUGE so I can't know myself what fixes I'll need to apply to gcc. > Can you maybe tell me what version of gcc and binutil (svn revision) was initially taken as a base for cegcc, so that I could make a diff and apply it to latest version of gcc/binutils? See src/VERSIONS . I can give you and other interested parties write access to the cegcc svn if you like. Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info |
From: Pavel P. <pa...@su...> - 2010-07-11 03:25:41
|
I'd like to do it, but I'd need some help as I don't have so much free personal time :) I already tried it and it's not so trivial since I have no idea about most of the changes made to gcc/binutils and I don't know what I'd need to take into updated gcc. That's why I asked in my other email what svn version exactly was taken as baseline for current cegcc 4.4.0 so that I could make a diff and apply same changes to latest gcc to see it works or not. I think log2 is fixed in other versions of gcc; Android build at least doesn't have that log2 problem. > -----Original Message----- > From: Zack [mailto:fb...@co...] > Sent: Saturday, July 10, 2010 23:19 > To: Pavel Pavlov > Subject: Re: [Cegcc-devel] Are math functions busted??.. (4.1.0 & 4.4.0) > > I only tried using log2. Perhaps a more comprehensive test is in order... > > I don't know why people would abandon Cegcc, unless perhaps they were > using it for professional projects, and selling their products to phone users. > Hobbyists like myself would not care so much what Microsoft does or when. > But if they are using it for professional projects, why is log2 broken? It's a > contradiction. > > It may be worth updating to the latest gcc. My question is, how much work is > involved... and who will do it? > -Zack > > >> -----Original Message----- > >> From: Zack [mailto:fb...@co...] > >> Sent: Saturday, July 10, 2010 23:08 > >> To: Pavel Pavlov > >> Subject: Re: [Cegcc-devel] Are math functions busted??.. (4.1.0& > >> 4.4.0) > >> > >> I reported the log2 problem a couple months ago to this mailing > >> list but no one responded. > >> -Zack > > > > Hi Zack, did you have any similar problems with any other math functions? > > It seems that people are not interested in cegcc since MS plans not to > > support native development on their upcoming WinPhone7 (I doubt that > > anyways) > > > > > >>> I tried to compile x264 out of curiosity and when I finally built it > >>> I tried to run > >> the code and got error message from x264 encoder saying that it was > >> miscompiled. > >>> After debugging the code I found out what was the source of error > >>> and > >> what code was miscompiled. > >>> Basically, log2 and log2f function return wrong results. So, I'm > >>> curios if it's a > >> known issue and if there might be some other unpleasant surprises > >> with some other math functions. > >>> A simple test to verify wrong results: > >>> > >>> #include<math.h> > >>> > >>> #define log2f_correct(x) (logf(x) * 1.44269504088896340736f) > >>> > >>> for(int lambda=0; lambda<5; ++lambda){ > >>> for(int i=2010; i<2020; ++i){ > >>> printf ("TEST1: lambda: %d, xxx => %f; log2f(i+1) => %f\n", > >> lambda, lambda * (log2f(i+1)*2 + 0.718f + !!i) + .5f, log2f(i+1)); > >>> printf("TEST2: lambda: %d, xxx => %f; log2f_correct (i+1) => > >> %f\n", lambda, lambda * (log2f_correct (i+1)*2 + 0.718f + !!i) + .5f, > >> log2f_correct(i+1)); > >>> } > >>> } > >>> > >>> Results are always incorrect, here's a sample output: > >>> [INFO ] [-2071554222] 18:28:17: x264: TEST2: lambda: 1, 2013 xxx => > >>> 24.168262; log2f_correct (i+1) => 10.975131 [INFO ] [-2071554222] > >>> 18:28:17: x264: TEST1: lambda: 1, 2013 xxx => 12.764759; log2f(i+1) > >>> => 5.273379 > >>> > >>> > >>> > >>> > >>> It has to be some sort of loop with expression, otherwise gcc will > >>> compute log2f at compile time and will produce correct output (that > >>> matches results of log2f_correct) > >>> > >>> I verified it with both builds of cegcc and had identical errors. > >>> > > |
From: Pavel P. <pa...@su...> - 2010-07-10 23:41:43
|
I'm thinking to update my version of cegcc to latest version of gcc. It look as the project is almost sleeping now. So, I'd like to try to take changes made in cegcc into some latest release of binutils and gcc. What's the recommended way to do it?.. I already tried to compare, but the differences are HUGE so I can't know myself what fixes I'll need to apply to gcc. Can you maybe tell me what version of gcc and binutil (svn revision) was initially taken as a base for cegcc, so that I could make a diff and apply it to latest version of gcc/binutils? thanks |
From: Pavel P. <pa...@su...> - 2010-07-10 23:34:41
|
I tried to compile x264 out of curiosity and when I finally built it I tried to run the code and got error message from x264 encoder saying that it was miscompiled. After debugging the code I found out what was the source of error and what code was miscompiled. Basically, log2 and log2f function return wrong results. So, I'm curios if it's a known issue and if there might be some other unpleasant surprises with some other math functions. A simple test to verify wrong results: #include <math.h> #define log2f_correct(x) (logf(x) * 1.44269504088896340736f) for(int lambda=0; lambda<5; ++lambda){ for(int i=2010; i<2020; ++i){ printf ("TEST1: lambda: %d, xxx => %f; log2f(i+1) => %f\n", lambda, lambda * (log2f(i+1)*2 + 0.718f + !!i) + .5f, log2f(i+1)); printf("TEST2: lambda: %d, xxx => %f; log2f_correct (i+1) => %f\n", lambda, lambda * (log2f_correct (i+1)*2 + 0.718f + !!i) + .5f, log2f_correct(i+1)); } } Results are always incorrect, here's a sample output: [INFO ] [-2071554222] 18:28:17: x264: TEST2: lambda: 1, 2013 xxx => 24.168262; log2f_correct (i+1) => 10.975131 [INFO ] [-2071554222] 18:28:17: x264: TEST1: lambda: 1, 2013 xxx => 12.764759; log2f(i+1) => 5.273379 It has to be some sort of loop with expression, otherwise gcc will compute log2f at compile time and will produce correct output (that matches results of log2f_correct) I verified it with both builds of cegcc and had identical errors. |
From: James T. <jam...@gm...> - 2010-07-08 17:18:58
|
sorry for the last mail, I've confirmed that cegcc really generate coff format obj , which can be linked by MS tools. On Fri, Jul 9, 2010 at 12:50 AM, James Tyou <jam...@gm...> wrote: > -- just add [] in title > > Hi, All, > > First thanks to Cegcc for everything! > > years ago, I use arm-wince-pe to compile c file with inline assembly, > produce COFF object file, then link by MS links. > but seems the current cegcc toolchain can not produce MS-COFF capabilities > file, > > AM I WRONG? > > Or, only by building DLL file with cegcc, the inline asm feature of GCC > toolchain can be used? > > > Best Regards > jT > |
From: James T. <jam...@gm...> - 2010-07-08 16:50:41
|
-- just add [] in title Hi, All, First thanks to Cegcc for everything! years ago, I use arm-wince-pe to compile c file with inline assembly, produce COFF object file, then link by MS links. but seems the current cegcc toolchain can not produce MS-COFF capabilities file, AM I WRONG? Or, only by building DLL file with cegcc, the inline asm feature of GCC toolchain can be used? Best Regards jT |
From: James T. <jam...@gm...> - 2010-07-08 16:29:49
|
Hi, All, First thanks to Cegcc for everything! years ago, I use arm-wince-pe to compile c file with inline assembly, produce COFF object file, then link by MS links. but seems the current cegcc toolchain can not produce MS-COFF capabilities file, AM I WRONG? Or, only by building DLL file with cegcc, the inline asm feature of GCC toolchain can be used? Best Regards jT |
From: Peter V. K. <kha...@gm...> - 2010-07-07 17:45:02
|
Hello everyone. I have one problem. I am trying to compile a simple WinCE demo-project. make wince /opt/mingw32ce/bin/arm-mingw32ce-g++ -D_WIN32_WCE=0x400 -D_WIN32_IE=0x400 -fno-exceptions -o TaskBarSample_wince.exe TaskBarSample.cpp -I/opt/mingw32ce/arm-mingw32ce/include -L/opt/mingw32ce/arm-mingw32ce/lib -lcommctrl -laygshell -lcoredll -lceshell /tmp/ccCNWZtf.o:TaskBarSample.cpp:(.text+0x268): undefined reference to `Shell_NotifyIconW' /tmp/ccCNWZtf.o:TaskBarSample.cpp:(.text+0x5b8): undefined reference to `Shell_NotifyIconW' collect2: ld returned 1 exit status But: grep Shell_NotifyIconW * shellapi.h:BOOL WINAPI Shell_NotifyIconW(DWORD,PNOTIFYICONDATAW); shellapi.h:#define Shell_NotifyIcon Shell_NotifyIconW And: /opt/mingw32ce/bin/arm-mingw32ce-strings -f /opt/mingw32ce/arm-mingw32ce/lib/lib*.a |grep Shell_NotifyIcon /opt/mingw32ce/arm-mingw32ce/lib/libcoredll6.a: Shell_NotifyIcon /opt/mingw32ce/arm-mingw32ce/lib/libcoredll6.a: __imp_Shell_NotifyIcon /opt/mingw32ce/arm-mingw32ce/lib/libcoredll6.a: Shell_NotifyIcon /opt/mingw32ce/arm-mingw32ce/lib/libcoredll6.a: Shell_NotifyIcon /opt/mingw32ce/arm-mingw32ce/lib/libcoredll6.a: __imp_Shell_NotifyIcon /opt/mingw32ce/arm-mingw32ce/lib/libcoredll.a: Shell_NotifyIcon /opt/mingw32ce/arm-mingw32ce/lib/libcoredll.a: __imp_Shell_NotifyIcon /opt/mingw32ce/arm-mingw32ce/lib/libcoredll.a: Shell_NotifyIcon /opt/mingw32ce/arm-mingw32ce/lib/libcoredll.a: Shell_NotifyIcon /opt/mingw32ce/arm-mingw32ce/lib/libcoredll.a: __imp_Shell_NotifyIcon Whats wrong? -- Peter V. Khaninyov |
From: Pavel P. <pa...@su...> - 2010-06-22 09:34:28
|
> -----Original Message----- > From: Vincent Richomme [mailto:fo...@sm...] > Sent: Tuesday, June 22, 2010 03:43 > To: Vincent Torri > Cc: ceg...@li... > Subject: Re: [Cegcc-devel] status of the project > > On Tue, 22 Jun 2010 08:53:43 +0200 (CEST), Vincent Torri <vt...@un...> > wrote: > > Hey, > > > > I would like to know the status of this project. I haven't seen any > > message for months on that ML > > > > thank you > > > > Vincent Torri > > > > > Hello, > > you should ask what is the status of Windows Mobile OS and I would answer > that it is currently dying because now Microsoft is moving to a new OS (the one > in Windows Phone) that will only allow managed code (Silverlight). > I read that they will still support windows mobile for a few years because they > cannot break compatibility too quickly but to me it means that cegcc is > deprecated. > Still, it will be the same arm phone with pe executables. Just like android and iphone, they will eventually have to allow some level of native development (for cpu intensive processing for example), otherwise they will turn from business oriented os to a toy oriented os ;) Anyways, I really would like cegcc changes to make into official gcc so that all the latest changes in gcc (and there are a lot in arm related parts) could be also used by cegcc. |
From: Vincent T. <vt...@un...> - 2010-06-22 09:33:14
|
On Tue, 22 Jun 2010, Pavel Pavlov wrote: > > >> -----Original Message----- >> From: Vincent Richomme [mailto:fo...@sm...] >> Sent: Tuesday, June 22, 2010 03:43 >> To: Vincent Torri >> Cc: ceg...@li... >> Subject: Re: [Cegcc-devel] status of the project >> >> On Tue, 22 Jun 2010 08:53:43 +0200 (CEST), Vincent Torri <vt...@un...> >> wrote: >>> Hey, >>> >>> I would like to know the status of this project. I haven't seen any >>> message for months on that ML >>> >>> thank you >>> >>> Vincent Torri >>> >>> >> Hello, >> >> you should ask what is the status of Windows Mobile OS and I would answer >> that it is currently dying because now Microsoft is moving to a new OS (the one >> in Windows Phone) that will only allow managed code (Silverlight). >> I read that they will still support windows mobile for a few years because they >> cannot break compatibility too quickly but to me it means that cegcc is >> deprecated. >> > > Still, it will be the same arm phone with pe executables. Just like > android and iphone, they will eventually have to allow some level of > native development (for cpu intensive processing for example), otherwise > they will turn from business oriented os to a toy oriented os ;) > Anyways, I really would like cegcc changes to make into official gcc so > that all the latest changes in gcc (and there are a lot in arm related > parts) could be also used by cegcc. I 100% agree with you. cegcc must be merged upstream in gcc. Pedro talked about that some month ago, but no news anymore about the merge. Vincent Torri |
From: Vincent T. <vt...@un...> - 2010-06-22 09:25:04
|
On Tue, 22 Jun 2010, Vincent Richomme wrote: > On Tue, 22 Jun 2010 08:53:43 +0200 (CEST), Vincent Torri > <vt...@un...> wrote: >> Hey, >> >> I would like to know the status of this project. I haven't seen any >> message for months on that ML >> >> thank you >> >> Vincent Torri >> > Hello, > > you should ask what is the status of Windows Mobile OS and I would answer > that it is currently dying because now Microsoft is moving to a new > OS (the one in Windows Phone) that will only allow managed code > (Silverlight). dying, maybe, but not dead. > I read that they will still support windows mobile for a few years because > they cannot > break compatibility too quickly but to me it means that cegcc is > deprecated. I do not agree: it will be deprecated when there is no Windows CE / Pocket PC devices anymore > More information here : > > http://www.osnews.com/story/23249/Windows_Phone_7_Based_on_Windows_Embedded_Compact_7 > http://www.zdnet.com/blog/microsoft/could-menlo-signal-a-change-in-microsofts-mobile-strategy/6077 > http://www.itwriting.com/blog/2361-no-native-code-on-windows-phone-7-says-microsoft-so-what-about-flash.html Thank you for the links :-) Vincent Torri |
From: Vincent R. <fo...@sm...> - 2010-06-22 07:59:26
|
On Tue, 22 Jun 2010 08:53:43 +0200 (CEST), Vincent Torri <vt...@un...> wrote: > Hey, > > I would like to know the status of this project. I haven't seen any > message for months on that ML > > thank you > > Vincent Torri > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Cegcc-devel mailing list > Ceg...@li... > https://lists.sourceforge.net/lists/listinfo/cegcc-devel Hello, you should ask what is the status of Windows Mobile OS and I would answer that it is currently dying because now Microsoft is moving to a new OS (the one in Windows Phone) that will only allow managed code (Silverlight). I read that they will still support windows mobile for a few years because they cannot break compatibility too quickly but to me it means that cegcc is deprecated. More information here : http://www.osnews.com/story/23249/Windows_Phone_7_Based_on_Windows_Embedded_Compact_7 http://www.zdnet.com/blog/microsoft/could-menlo-signal-a-change-in-microsofts-mobile-strategy/6077 http://www.itwriting.com/blog/2361-no-native-code-on-windows-phone-7-says-microsoft-so-what-about-flash.html |