La nouvelle collection Eté est en ligne aujourd'hui
Si vous NE PAS LIRE Pouvez cet email, cliquez ici (http://front.chemise-web.eu/php/emailing/view_mail.php?CODE=50NPGRAA_213681&HASH=aa89dca0b0a485e84897beb9b0d80233) Chemiseweb.com: La nouvelle collection Été est en ligne, plus de 300 modèles. (http://lt.chemise-web.eu/r.php?i=50NPGRAA_213681_1&l=http% 3A% 2F% 2Fwww.chemiseweb.com% 2F) FABRICANT DE CHEMISES MODE HAUT DE GAMME, VENTE DIRECTE ET SANS INTERMEDIAIRE, DU FABRICANT AU CONSOMMATEUR. PLUS DE 300 MODELES EN STOCK DE 36,99 à 45 PRIX MAXIMUM. Livraison sous 48 H. Retrouvez-nous sur Facebook (http://lt.chemise-web.eu/r.php?i=50NPGRAA_213681_2&l=http% 3A% 2F% 2Fwww.facebook.com% 2Fpages% 2FWWWCHEMISEWEBCOM% 2F287136851768%% 3Fref 3DMF) Chemise RAFAELLO 45 : chemise Dans Fabriquée Un homme satin tissus 100% coton, très mode avec col fils véritable rose double sur blanc, intérieur du col et pied de col blanc, bicolore Pointe poignet, intérieur du poignet capucin et blanc en opposition. Une chemise de la mode au look original bicolore Dans cette version, à porter de préférence ouvert col. (http://lt.chemise-web.eu/r.php?i=50NPGRAA_213681_3&l=http% 3A% 2F% 2Fwww.chemiseweb.com%% 2FChemises_cintrees 2Fdetail_Z17EB1_885.htm) Bonne visite sur Chemiseweb.com (http://lt.chemise-web.eu/r.php?i=50NPGRAA_213681_1&l=http% 3A% 2F% 2Fwww.chemiseweb.com% 2F) En application de la loi n ° 78 17 du 6 janvier 1978 modifiée par la Loi du 6 Août 2005 relative à l'informatique, aux fichiers et aux libertés, les participants Disposent d'un droit d'accès, de modification, de rectification et de suppression des données personnelles Concernant les Auprès de servicecli...@chemiseweb.com (mailto: servicecli...@chemiseweb.com) Si vous voulez vous désinscrire, cliquez ici (http://front.chemise-web.eu/php/emailing/unsuscribe.php?CODE=50NPGRAA_213681&HASH=aa89dca0b0a485e84897beb9b0d80233)
[Bug tree-optimization/42706] [4.5 Regression] ICE in gimple_op, at gimple.h:1634, (IPA SRA)
--- Comment #9 from jakub at gcc dot gnu dot org 2010-02-08 14:40 --- The testcase fails on the 4.4 branch, as -fipa-sra isn't a valid option there. H.J., can you please before committing testsuite backports at least run make check? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42706 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#568881: gnat-4.4: Type to stream input/output broken on big endian archs
Package: gnat-4.4 Version: 4.4.3-1 Severity: normal The output of write_stream is different regarding the architecture it is executed : powerpc (big endian): hexdump -C ./output_stream.dat fa da da da de ad be ef amd64 (little endian): ef be ad de da da da fa i386 (little endian): ef be ad de da da da fa mips (big endian): fa da da da de ad be ef sparc (big endian): fa da da da de ad be ef As far as I understood streams, the output should be neutral regarding of the architecture. *** write_stream.adb with Ada.Streams.Stream_IO; with Interfaces; procedure Write_Stream is File : Ada.Streams.Stream_IO.File_Type; Item_To_Write : constant Interfaces.Unsigned_64 := 16#Fada_D_Ada_Dead_Beef#; Stream : Ada.Streams.Stream_IO.Stream_Access; begin Ada.Streams.Stream_IO.Create (File, Name => "output_stream.dat"); Stream := Ada.Streams.Stream_IO.Stream (File); Interfaces.Unsigned_64'Output (Stream, Item_To_Write); Ada.Streams.Stream_IO.Close (File); end Write_Stream; -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc64) Kernel: Linux 2.6.30-2-powerpc64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnat-4.4 depends on: ii gcc-4.4 4.4.3-2The GNU C compiler ii gnat-4.4-base 4.4.3-1The GNU Compiler Collection (gnat ii libc6 2.10.2-5 Embedded GNU C Library: Shared lib ii libc6-dev 2.10.2-5 Embedded GNU C Library: Developmen ii libgcc1 1:4.4.3-2 GCC support library ii libgmp3c2 2:4.3.2+dfsg-1 Multiprecision arithmetic library ii libgnat-4.4 4.4.3-1Runtime library for GNU Ada applic ii libgnatprj4.4 4.4.3-1GNU Ada Project Manager ii libgnatvsn4.4 4.4.3-1GNU Ada compiler version library ii libmpfr1ldbl 2.4.2-3multiple precision floating-point gnat-4.4 recommends no packages. Versions of packages gnat-4.4 suggests: pn ada-reference-manual (no description available) pn gnat-4.4-doc (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#568881: marked as done (gnat-4.4: Type to stream input/output broken on big endian archs)
Your message dated Mon, 08 Feb 2010 16:33:17 +0100 with message-id and subject line Re: Bug#568881: gnat-4.4: Type to stream input/output broken on big endian archs has caused the Debian Bug report #568881, regarding gnat-4.4: Type to stream input/output broken on big endian archs to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 568881: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568881 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: gnat-4.4 Version: 4.4.3-1 Severity: normal The output of write_stream is different regarding the architecture it is executed : powerpc (big endian): hexdump -C ./output_stream.dat fa da da da de ad be ef amd64 (little endian): ef be ad de da da da fa i386 (little endian): ef be ad de da da da fa mips (big endian): fa da da da de ad be ef sparc (big endian): fa da da da de ad be ef As far as I understood streams, the output should be neutral regarding of the architecture. *** write_stream.adb with Ada.Streams.Stream_IO; with Interfaces; procedure Write_Stream is File : Ada.Streams.Stream_IO.File_Type; Item_To_Write : constant Interfaces.Unsigned_64 := 16#Fada_D_Ada_Dead_Beef#; Stream : Ada.Streams.Stream_IO.Stream_Access; begin Ada.Streams.Stream_IO.Create (File, Name => "output_stream.dat"); Stream := Ada.Streams.Stream_IO.Stream (File); Interfaces.Unsigned_64'Output (Stream, Item_To_Write); Ada.Streams.Stream_IO.Close (File); end Write_Stream; -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc64) Kernel: Linux 2.6.30-2-powerpc64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnat-4.4 depends on: ii gcc-4.4 4.4.3-2The GNU C compiler ii gnat-4.4-base 4.4.3-1The GNU Compiler Collection (gnat ii libc6 2.10.2-5 Embedded GNU C Library: Shared lib ii libc6-dev 2.10.2-5 Embedded GNU C Library: Developmen ii libgcc1 1:4.4.3-2 GCC support library ii libgmp3c2 2:4.3.2+dfsg-1 Multiprecision arithmetic library ii libgnat-4.4 4.4.3-1Runtime library for GNU Ada applic ii libgnatprj4.4 4.4.3-1GNU Ada Project Manager ii libgnatvsn4.4 4.4.3-1GNU Ada compiler version library ii libmpfr1ldbl 2.4.2-3multiple precision floating-point gnat-4.4 recommends no packages. Versions of packages gnat-4.4 suggests: pn ada-reference-manual (no description available) pn gnat-4.4-doc (no description available) -- no debconf information --- End Message --- --- Begin Message --- > As far as I understood streams, the output should be neutral regarding of > the architecture. Where did you get that idea? The output seems perfectly normal to me. And remember that I used to to embedded programming on PowerPC and deal with endianness issues :) ARM 13.13.2(9/2) says: "[...] the representation of those stream elements is implementation defined. [...]" -- Ludovic Brenta. --- End Message ---
Bug#568881: gnat-4.4: Type to stream input/output broken on big endian archs
xavier grave wrote: > Ludovic Brenta a écrit : >>> As far as I understood streams, the output should be neutral regarding >>> of the architecture. >> >> Where did you get that idea? > > Using gnat 3.15p I didn't have this kind of problem. > I used to push to a stream connected to a socket an integer type > without bothering about endianness. Then I guess you were using a stream of a specific type that did the bothering for you, converting everything to network byte order because it was a *socket* stream type. For a stream attached to a file, the compiler cannot assume that you need to convert to network byte order. >> The output seems perfectly normal to me. And >> remember that I used to to embedded programming on PowerPC and deal with >> endianness issues :) > > I don't dare to question your competences :) > >> ARM 13.13.2(9/2) says: "[...] the representation of those stream >> elements is implementation defined. [...]" > > Let assume I have a symmetric program to read from my stream (ie here my > file). If I read the file on an arch different of the one that was used > to write it, Ada should ensure me (as far as I understand the point of > portability) that I can read from my stream without thinking about it > because a Ada.Streams is a standard package. No, I don't think that's true. GNAT on amd64 and GNAT on sparc are two different implementations of Ada and nothing forces them to use inefficient conversions to network byte order without consent from the programmer. Therefore, if you need such conversion, you must say so explicitly. Maybe you'd like to look at http://www.ibpaus.de/downloads/index.html -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#568881: gnat-4.4: Type to stream input/output broken on big endian archs
Also read http://groups.google.ca/group/comp.lang.ada/browse_thread/thread/4c06e1e4fc2bf2d1 -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processed: [bts-link] source package gcc-4.3
Processing commands for cont...@bugs.debian.org: > # > # bts-link upstream status pull for source package gcc-4.3 > # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html > # > user bts-link-upstr...@lists.alioth.debian.org Setting user to bts-link-upstr...@lists.alioth.debian.org (was bts-link-de...@lists.alioth.debian.org). > # remote status report for #438791 (http://bugs.debian.org/438791) > # * http://gcc.gnu.org/PR6257 > # * remote status changed: SUSPENDED -> RESOLVED > # * remote resolution changed: (?) -> INVALID > # * closed upstream > tags 438791 + fixed-upstream Bug #438791 [libstdc++6-4.3-dev] [PR libstdc++/6257] [DR 456] C-library symbols enter global namespace Added tag(s) fixed-upstream. > usertags 438791 - status-SUSPENDED Bug#438791: [PR libstdc++/6257] [DR 456] C-library symbols enter global namespace Usertags were: status-SUSPENDED. Usertags are now: . > usertags 438791 + status-RESOLVED resolution-INVALID Bug#438791: [PR libstdc++/6257] [DR 456] C-library symbols enter global namespace There were no usertags set. Usertags are now: status-RESOLVED resolution-INVALID. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
[bts-link] source package gcc-4.3
# # bts-link upstream status pull for source package gcc-4.3 # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org # remote status report for #438791 (http://bugs.debian.org/438791) # * http://gcc.gnu.org/PR6257 # * remote status changed: SUSPENDED -> RESOLVED # * remote resolution changed: (?) -> INVALID # * closed upstream tags 438791 + fixed-upstream usertags 438791 - status-SUSPENDED usertags 438791 + status-RESOLVED resolution-INVALID thanks -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#568881: gnat-4.4: Type to stream input/output broken on big endian archs
original message- De: "Ludovic Brenta" ludo...@ludovic-brenta.org A: xavier.gr...@ipno.in2p3.fr Copie à: 568...@bugs.debian.org Date: Mon, 08 Feb 2010 17:02:09 +0100 - > > xavier grave wrote: >> Ludovic Brenta a écrit : As far as I understood streams, the output should be neutral regarding of the architecture. >>> >>> Where did you get that idea? >> >> Using gnat 3.15p I didn't have this kind of problem. >> I used to push to a stream connected to a socket an integer type >> without bothering about endianness. > > Then I guess you were using a stream of a specific type that did the > bothering for you, converting everything to network byte order because > it was a *socket* stream type. For a stream attached to a file, the > compiler cannot assume that you need to convert to network byte order. You are right (as usual :), sorry for this new non useful bug report), I have found in a lab corner an old gnat-3.15p install (x86 and ppc) and the behaviour is exactly the same (different files). So this is the stream implementation for the sockets in gnat-3.15 that swap the things and no more with gnat-4.4 ? >> >> Let assume I have a symmetric program to read from my stream (ie here my >> file). If I read the file on an arch different of the one that was used >> to write it, Ada should ensure me (as far as I understand the point of >> portability) that I can read from my stream without thinking about it >> because a Ada.Streams is a standard package. > > No, I don't think that's true. GNAT on amd64 and GNAT on sparc are two > different implementations of Ada and nothing forces them to use inefficient > conversions to network byte order without consent from the programmer. > Therefore, if you need such conversion, you must say so explicitly. So may be I should find the place where the problem is in g-socket*, if there is a problem at all ? > Maybe you'd like to look at http://www.ibpaus.de/downloads/index.html Thanks for the link. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
[Bug libstdc++/42460] man page errors for generated libstdc++ man pages
--- Comment #21 from bkoz at gcc dot gnu dot org 2010-02-09 04:50 --- Subject: Bug 42460 Author: bkoz Date: Tue Feb 9 04:49:49 2010 New Revision: 156617 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156617 Log: 2010-02-08 Benjamin Kosnik PR libstdc++/42460 * include/tr1_impl/regex: Fix quoting issues in doxygen markup. * include/bits/random.h: Fix multi-line doxygen function markup. 2010-02-08 Matthias Klose PR libstdc++/42460 * include/std/istream: Fix '\' quoting in doxygen markup. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/random.h trunk/libstdc++-v3/include/std/istream trunk/libstdc++-v3/include/tr1_impl/regex -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42460 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#565776: jxplorer: need libgcj10-awt package dep if running java with gcj rt
On 07/02/10 10:43 AM, Gabriele Giacone wrote: > Simon Kjika'qawej wrote: >> Severity important because it runs OK otherwise if you install it. >> This is why folks use pbuilder and such to build packages. I don't >> either, but I should ;). Anyway, installing libgcj10-awt make it >> 'happy'. > Hi Simon, sorry for the delay. > > What version of gcj you use? I guess gcj-4.3 because gcj-4.4 already > depends on libgcj10-awt and gcj-4.5 in experimental depends on > libgcj11-awt. For that reason, I think gcj-4.3 should depends on > libgcj9-awt and you shouldn't need to install it manually. > For 4.3, we have the opposite dependency: libgcj9-awt depends on > gcj-4.3-base. > > GCC maintainers, what do you think about that? > > > Thanks, > Gabriele > About the delay, that's OK. I think it was 4.4 at the time, as it is now. Yes it was, in fact. Simon -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
