Re: Official GCC git repository
On 18/04, Christopher Faylor wrote: | After consultation with Dan, I have set things up on gcc.gnu.org so that | the git repository is updated every time an email message is received | from the gcc-cvs mailing list. Great! Thanks to both of you.
Fontos!
Üdvözöllek! Indult a napokban egy toplista szeretném figyelmedet felhívni rá! http://warezone.hu/ Itt megtalálsz mindent ami érdekelhet! Ingyen letöltések, sms webek, web shopok, torrent oldalak, fórumok, ingyenkódok! A szerkesztők a nap 24 órájában ellenőrzik és a csaló oldalakat szűrik a toplistán! Nyereményjáték indul a napokban érdemes többször visszanézni az oldalra, pár napon belül kikerülnek a részletek az oldalra, nagy értékű nyereményeket sorsolunk! Terveink szerint a nyeremények között szerepel, plazmatv, lapmonitor, laptop stb stb! Érdemes nállunk böngészni! A cím: http://warezone.hu/ Válasz a toplistán szereplő válogatott oldalak közül! == Páran jelezték számunkra hogy nem kértek ilyen hírlevelet, az adatbázisokban lévő cimek keveredhettek, ebben a levélben küldünk egy linket amin le tudnak erről a hírlevélről íratkozni! Ha leíratkozik többet nem kap tőllünk ilyen hírlevelet! AMD WAREZ Amennyiben szeretnél leiratkozni a hírlevélről az alábbi linken törölheted magad: http://www.mailipar.hu/hirlevel.php?user=amdwarez&[EMAIL PROTECTED]&level=Leiratkozás&code=b646dcb44a
Re: US-CERT Vulnerability Note VU#162289
Sorry to be so late in joining this discussion. I'm the person who
originally notified Mark Mitchell about Microsoft's compiler performing
this same optimization under certain conditions. Since mailing Mark on
the subject I tried also VC++ 2008 and it behaves exactly like its
predecessor. Here's my test program, directly derived from Mark's test case:
int f(char *buf, int len) {
len = 1 << 30;
if (buf + len < buf)
return 1;
return 0;
}
int main()
{
char * b = "0123456789";
for ( int l = 0; l < 1 << 30; ++l )
f(b, l);
}
This is the command line shown by the IDE:
/Ox /GL /D "WIN32" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /Gm /EHsc
/MDd /GS- /Za /FAs /Fa"Debug\\" /Fo"Debug\\" /Fd"Debug\vc90.pdb" /W4 /c
/Wp64 /Zi /TP .\cert.cpp
This is the assembler listing generated by VC++ 2008. VC++ 2005's
listing differs only in the first line:
; Listing generated by Microsoft (R) Optimizing Compiler Version
15.00.21022.08
TITLE d:\src\cert\cert.cpp
.686P
.XMM
include listing.inc
.model flat
$SG-5 DB '0123456789', 00H
PUBLIC ?f@@[EMAIL PROTECTED] ; f
; Function compile flags: /Ogtpy
; File d:\src\cert\cert.cpp
_TEXT SEGMENT
?f@@[EMAIL PROTECTED] PROC ; f
; 2: len = 1 << 30;
; 3: if (buf + len < buf)
; 4: return 1;
; 5:
; 6:
; 7: return 0;
xor eax, eax
; 8: }
ret 0
?f@@[EMAIL PROTECTED] ENDP ; f
_TEXT ENDS
PUBLIC _main
; Function compile flags: /Ogtpy
_TEXT SEGMENT
_main PROC
; 12 :char * b = "0123456789";
; 13 :for ( int l = 0; l < 1 << 30; ++l )
; 14 :f(b, l);
; 15 : }
xor eax, eax
ret 0
_main ENDP
_TEXT ENDS
END
I can make my project files available if anybody is interested.
I also tested CodeGear (Borland)'s C++ Builder 2007 compiler and as far
as I can tell it doesn't perform this optimization. Maybe we should all
switch to their product ;-)
Cheers,
Nicola Musatti
--
Nicola.Musatti gmail com
Home: http://nicola.musatti.googlepages.com/home
Blog: http://wthwdik.wordpress.com/
Re: gcc compiler for pdp10
On Fri, 18 Apr 2008 21:56:38 -0400, Alan Lehotsky <[EMAIL PROTECTED]> wrote: >Martin, > >I did a port of GCC to the Analog Devices SHARC chip. I ended up supporting 3 >kinds of pointers for this chip (two for address >spaces and one for byte pointers - the chip itself is only word addressable >(although words can be from 16 to 48 bits in size >depending on what memory is being accessed.) > >I also worked on the Bliss-36 compiler at DEC, so I'm well acquainted with the >PDP10 architecture. > >I don't have access to any 10/20 HW, but I'd be happy to act as a >reviewer/advisor to your changes. > >Al Lehotsky > >On Apr 18, 2008, at 20:21, Martin Chaney wrote: >> >>Hi, >> >>I'm am the proprietor of a gcc compiler for the PDP10 architecture. >> >>(This is a compiler previously worked on by Lars Brinkhoff who left XKL some >>while before I joined XKL. It's possible some of you may have been familiar with >>him or the compiler from that time.) >> >>The compiler is currently in a state where it is synched with the both the 4.3 >>and 4.4 branches, and it passes the testsuite tests (with the exception of some >>I've flagged as expected failures for the pdp10). >> >>My employer is happy to release my work on the gcc compiler back to the >>gcc community and I've sent in a request for the necessary forms. >> >>The PDP10 architecture is unusual in various ways that distinguish it from >>the mainstream architectures supported by the gcc compiler and this has >>made the development of this compiler a significant task. Undoubtedly I've >>made customizations in inappropriate ways. I'm seeking contacts with people >>who might be able to advise me on how to cleanup my implementation to >>reduce the amount of #ifdef __PDP10_H__ I've sprinkled liberally throughout the >>source. Also, if its possible to get simple changes made to prevent breaking >>my PDP10 version and that are otherwise innocuous that would be wonderful. >>For example, the PDP10 word size is 36 bits; Fairly recently people have taken >>to writing code that assumes word size is a power of 2 even when it's >>straightforward to write in a manner that doesn't make that assumption. >> >>Considering the large number of files customized to get the PDP10 compiler >>working, I'm not sure whether it's possible to get it to build directly from the gcc >>trunk, but it would be nice to work toward that goal. >> >>Some other things which distinguish the PDP10 architecture from >>assumptions in the gcc code base include: its variety of formats of pointers >>only one of which can be viewed as an integer and that one is capable of >>referencing only word aligned data, a functional difference between signed and >>unsigned integers, and peculiarities to the use of PDP10 byte arrays which are >>very difficult to describe. >> >>Any help or advise would be appreciated. >> >>Martin Chaney >>XKL, LLC In http://pdp-10.trailing-edge.com/ there are ~6.5GB about PDP10 files where inside ~1.5GB are tapes in tap.bz2 format. It's a lot of obsolete software of more >20 years ago, it's only for hobbies because you won't find archaic 36 bit machines, and all the current modern machines are 32 and 64 bit.
Re: Official GCC git repository
On 4/18/08, Christopher Faylor <[EMAIL PROTECTED]> wrote: > After consultation with Dan, I have set things up on gcc.gnu.org so that > the git repository is updated every time an email message is received > from the gcc-cvs mailing list. > > We'll be monitoring the system to see if there is a load hit. If so, > we'll probably drop back to Dan's original method. FWIW, I did a quick calculation of the current month of commits, and there is an average of 31 per day, throwing out a crazy outlier of 121. Incorporating the 121 brings the average to 36 (next highest past 121 is 53, all other values are below 38. Data set for April: 33 16 39 46 35 36 53 15 21 25 31 38 121 26 21 27 39 32 41
Re: Official GCC git repository
On 4/19/08, NightStrike <[EMAIL PROTECTED]> wrote: > On 4/18/08, Christopher Faylor > <[EMAIL PROTECTED]> wrote: > Incorporating the 121 brings the average to 36 (next highest past 121 > is 53, all other values are below 38. s/38/48, 48 being the number of daily commits under the 30 minute model
Re: Official GCC git repository
On Sat, Apr 19, 2008 at 11:30 AM, NightStrike <[EMAIL PROTECTED]> wrote: > On 4/18/08, Christopher Faylor > > > <[EMAIL PROTECTED]> wrote: > > After consultation with Dan, I have set things up on gcc.gnu.org so that > > the git repository is updated every time an email message is received > > from the gcc-cvs mailing list. > > > > We'll be monitoring the system to see if there is a load hit. If so, > > we'll probably drop back to Dan's original method. > > FWIW, I did a quick calculation of the current month of commits, and > there is an average of 31 per day, throwing out a crazy outlier of > 121. > > Incorporating the 121 brings the average to 36 (next highest past 121 > is 53, all other values are below 38. The problem with commits is that the average is not what matters. Commits are bursty. People make 5 commits to different branches in the course of a minute or two, then there is nothing for another 15 minutes, etc.
Re: Official GCC git repository
On 4/19/08, Daniel Berlin <[EMAIL PROTECTED]> wrote: > The problem with commits is that the average is not what matters. > Commits are bursty. > People make 5 commits to different branches in the course of a minute > or two, then there is nothing for another 15 minutes, etc. Oh. Well... I still had fun writing the script :)
Re: Official GCC git repository
On Sat, 2008-04-19 at 11:34 -0400, NightStrike wrote: > On 4/19/08, Daniel Berlin <[EMAIL PROTECTED]> wrote: > > The problem with commits is that the average is not what matters. > > Commits are bursty. > > People make 5 commits to different branches in the course of a minute > > or two, then there is nothing for another 15 minutes, etc. > > Oh. Well... I still had fun writing the script :) Yeah, if performance is an issue, it'd probably help to play with responses to the commit trigger -- maybe wait for 2 minutes for the repo to become idle, and then prevent another update within 5 minutes (picking numbers out of my wossname). -- dwmw2
Re: US-CERT Vulnerability Note VU#162289
Nicola, Please send the project files to Robert Seacord. David --- Forwarded Message Date: Sat, 19 Apr 2008 19:12:13 +0200 From: "Robert C. Seacord" <[EMAIL PROTECTED]> To: David Edelsohn <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] Subject: Re: Nicola Musatti: Re: US-CERT Vulnerability Note VU#162289 David, Sure, please email us the project files. Thanks, rCs --- End of Forwarded Message
