Re: Please allow gcc-doc-defaults 4.1.1.nf3 into etch
> On Sat, Dec 16, 2006 at 03:37:48PM +0300, Nikita V. Youshchenko wrote: > > > - If you have a package that needs updating, *please* don't forget > > > to contact us. *Don't expect us to find out about it on our own*. > > > > Please allow gcc-doc-defaults 4.1.1.nf3 into etch. > > This upload fixes RC bug (#403328); the only change from previous > > version is addition of missing Conflicts: entry. > > I don't understand why this is listed as a Conflicts:, instead of as a > Conflicts: + Replaces:. Matthias, could you please comment? Frankly saying, I still don't understand the details of 'Conflicts+Replaces vs Conflicts' issue. Reading policy 7.5 and around doesn't help much. Is 'Conflicts+Replaces' more correct in this case? Why? I'm ready to upload version with 'Conflicts+Replaces' at any moment if needed. Nikita -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401385: This might not be as easy as I thought...
I wrote: Having looked a little deeper, it appears it *does* use dh_strip after all. The file to examine is debian/rules.d/binary-ada.mk. I'll try modifying that file to add --keep-debug to the dh_strip commands to see if that does anything useful... And indeed it does. Very nicely, actually. Using this made it possible to set breakpoints at line number locations within the source of the Ada system libraries (e.g., the debug pool). So the question now is: does anyone reading this have any preferences on whether or not I should go to the trouble of breaking out the debug files into separate debug packages? Using --keep-debug causes the debug files to be put into the same package as the actual libraries, but there's another option that allows you to tell dh_strip which package to put the resulting debug files into. -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401385: This might not be as easy as I thought...
Hi Kevin, Thanks for taking all that trouble. The debugging information should not go into the package libgnat-4.1, because that's a run-time-only package not intended for developers. Instead, the debugging information should go either to a new package (libgnat-4.1-dbg), either into package gnat-4.1, which already contains the static library with debugging information as well as the compiler. Creating a new package is a better long-term solution, because sooner or later we'll want to switch to multilib. In a multilib system, we do not want to have both libraries and programs in the same package. Are you comfortable editing debian/control.m4 and debian/rules.d/binary-ada.mk to add the new package? Then send me a patch? If you do that then I'll review and apply your patch into the next upload. PS. Make sure libgnat-4.1-dbg depends on libgnat-4.1, and recommends gnat-gdb (>= 6.4). Also, gnat-4.1 should recommend libgnat-4.1-dbg but not depend on it. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processing of gcc-4.2_4.2-20061217-1_i386.changes
gcc-4.2_4.2-20061217-1_i386.changes uploaded successfully to localhost along with the files: gcc-4.2_4.2-20061217-1.dsc gcc-4.2_4.2-20061217.orig.tar.gz gcc-4.2_4.2-20061217-1.diff.gz gcc-4.2-source_4.2-20061217-1_all.deb cpp-4.2-doc_4.2-20061217-1_all.deb libgcj8-jar_4.2-20061217-1_all.deb libgcj8-src_4.2-20061217-1_all.deb libstdc++6-4.2-doc_4.2-20061217-1_all.deb gfortran-4.2-doc_4.2-20061217-1_all.deb gcc-4.2-doc_4.2-20061217-1_all.deb gcc-4.2-locales_4.2-20061217-1_all.deb gcc-4.2-base_4.2-20061217-1_i386.deb libgcc1_4.2-20061217-1_i386.deb lib64gcc1_4.2-20061217-1_i386.deb libgomp1_4.2-20061217-1_i386.deb lib64gomp1_4.2-20061217-1_i386.deb cpp-4.2_4.2-20061217-1_i386.deb protoize_4.2-20061217-1_i386.deb fixincludes_4.2-20061217-1_i386.deb libmudflap0_4.2-20061217-1_i386.deb libmudflap0-4.2-dev_4.2-20061217-1_i386.deb lib64mudflap0_4.2-20061217-1_i386.deb gobjc++-4.2-multilib_4.2-20061217-1_i386.deb gobjc++-4.2_4.2-20061217-1_i386.deb gobjc-4.2-multilib_4.2-20061217-1_i386.deb gobjc-4.2_4.2-20061217-1_i386.deb libobjc2_4.2-20061217-1_i386.deb lib64objc2_4.2-20061217-1_i386.deb gcj-4.2-base_4.2-20061217-1_i386.deb gcj-4.2_4.2-20061217-1_i386.deb gij-4.2_4.2-20061217-1_i386.deb libgcj8_4.2-20061217-1_i386.deb libgcj8-awt_4.2-20061217-1_i386.deb libgcj8-awt-gtk_4.2-20061217-1_i386.deb libgcj8-awt-qt_4.2-20061217-1_i386.deb gappletviewer-4.2_4.2-20061217-1_i386.deb libgcj8-dev_4.2-20061217-1_i386.deb libgcj8-dbg_4.2-20061217-1_i386.deb libffi4_4.2-20061217-1_i386.deb libffi4-dev_4.2-20061217-1_i386.deb lib64ffi4_4.2-20061217-1_i386.deb g++-4.2-multilib_4.2-20061217-1_i386.deb g++-4.2_4.2-20061217-1_i386.deb libstdc++6_4.2-20061217-1_i386.deb lib64stdc++6_4.2-20061217-1_i386.deb lib64stdc++6-4.2-dbg_4.2-20061217-1_i386.deb libstdc++6-4.2-dev_4.2-20061217-1_i386.deb libstdc++6-4.2-pic_4.2-20061217-1_i386.deb libstdc++6-4.2-dbg_4.2-20061217-1_i386.deb libgfortran2_4.2-20061217-1_i386.deb lib64gfortran2_4.2-20061217-1_i386.deb gfortran-4.2-multilib_4.2-20061217-1_i386.deb gfortran-4.2_4.2-20061217-1_i386.deb treelang-4.2_4.2-20061217-1_i386.deb gcc-4.2-multilib_4.2-20061217-1_i386.deb gcc-4.2_4.2-20061217-1_i386.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processing of gcc-snapshot_20061217-1_i386.changes
gcc-snapshot_20061217-1_i386.changes uploaded successfully to localhost along with the files: gcc-snapshot_20061217-1.dsc gcc-snapshot_20061217.orig.tar.gz gcc-snapshot_20061217-1.diff.gz gcc-snapshot_20061217-1_i386.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug target/30255] register spills in x87 unit need to be 80-bit, not 64
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-18 20:16 --- *** This bug has been marked as a duplicate of 323 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30255 --- 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #85 from pinskia at gcc dot gnu dot org 2006-12-18 20:16 --- *** Bug 30255 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||whaley at cs dot utsa dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 --- 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401385: This might not be as easy as I thought...
Ludovic Brenta wrote: > Hi Kevin, > > Thanks for taking all that trouble. The debugging information should > not go into the package libgnat-4.1, because that's a run-time-only > package not intended for developers. That may be true, but developers aren't the only ones who might make use of these files. Anyone who gets a crash in an Ada application could get a much better traceback (for filing a bug report) with these files in place than without. Independent of the potential issues described below, we should give some serious thought to including the debugging files with the runtime package. It does bloat the package a bit, though. > Instead, the debugging information should go either to a new package > (libgnat-4.1-dbg), either into package gnat-4.1, which already contains > the static library with debugging information as well as the compiler. > > Creating a new package is a better long-term solution, because sooner or > later we'll want to switch to multilib. In a multilib system, we do not > want to have both libraries and programs in the same package. OK, I'll be happy to do that if we ultimately decide it's the right way to go. But see below. > Are you comfortable editing debian/control.m4 and > debian/rules.d/binary-ada.mk to add the new package? Then send me a > patch? If you do that then I'll review and apply your patch into the > next upload. Binary-ada.mk is what I was editing to test this to begin with, so from what I can tell all I need to do is to change the option to dh_strip to get it to put the debugging files into separate pacakges. But given that the control file is generated from an m4 master, changing binary-ada.mk in the required way may be a problem. The argument to dh_strip will be --dbg-package, and it takes the name of the target package as its argument. That's a problem because the package names are generated from the m4 master. Unless binary-ada.mk is also generated from an m4 master, how do I get the package names to be correct? If I have to hardcode them (which implies we have to change their names every time we uprev the version), then there'd be little point in having an m4-generated control file. The bottom line is that unless the same variables that are used for substitution in the m4 control master file are available to binary-ada.mk, this is going to be much more involved than it would be if we simply include the debugging data files with their primary packages (which is what I'm doing right now). -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gcc-snapshot_20061217-1_i386.changes ACCEPTED
Accepted: gcc-snapshot_20061217-1.diff.gz to pool/main/g/gcc-snapshot/gcc-snapshot_20061217-1.diff.gz gcc-snapshot_20061217-1.dsc to pool/main/g/gcc-snapshot/gcc-snapshot_20061217-1.dsc gcc-snapshot_20061217-1_i386.deb to pool/main/g/gcc-snapshot/gcc-snapshot_20061217-1_i386.deb gcc-snapshot_20061217.orig.tar.gz to pool/main/g/gcc-snapshot/gcc-snapshot_20061217.orig.tar.gz Override entries for your package: gcc-snapshot_20061217-1.dsc - source devel gcc-snapshot_20061217-1_i386.deb - extra devel Announcing to debian-devel-changes@lists.debian.org Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gcc-4.2_4.2-20061217-1_i386.changes is NEW
cpp-4.2-doc_4.2-20061217-1_all.deb to pool/main/g/gcc-4.2/cpp-4.2-doc_4.2-20061217-1_all.deb cpp-4.2_4.2-20061217-1_i386.deb to pool/main/g/gcc-4.2/cpp-4.2_4.2-20061217-1_i386.deb fixincludes_4.2-20061217-1_i386.deb to pool/main/g/gcc-4.2/fixincludes_4.2-20061217-1_i386.deb (new) g++-4.2-multilib_4.2-20061217-1_i386.deb optional devel The GNU C++ compiler (multilib files) This is the GNU C++ compiler, a fairly portable optimizing compiler for C++. . On architectures with multilib support, the package contains files and dependencies for the non-default multilib architecture(s). g++-4.2_4.2-20061217-1_i386.deb to pool/main/g/gcc-4.2/g++-4.2_4.2-20061217-1_i386.deb gappletviewer-4.2_4.2-20061217-1_i386.deb to pool/main/g/gcc-4.2/gappletviewer-4.2_4.2-20061217-1_i386.deb gcc-4.2-base_4.2-20061217-1_i386.deb to pool/main/g/gcc-4.2/gcc-4.2-base_4.2-20061217-1_i386.deb gcc-4.2-doc_4.2-20061217-1_all.deb to pool/main/g/gcc-4.2/gcc-4.2-doc_4.2-20061217-1_all.deb gcc-4.2-locales_4.2-20061217-1_all.deb to pool/main/g/gcc-4.2/gcc-4.2-locales_4.2-20061217-1_all.deb (new) gcc-4.2-multilib_4.2-20061217-1_i386.deb optional devel The GNU C compiler (multilib files) This is the GNU C compiler, a fairly portable optimizing compiler for C. . On architectures with multilib support, the package contains files and dependencies for the non-default multilib architecture(s). gcc-4.2-source_4.2-20061217-1_all.deb to pool/main/g/gcc-4.2/gcc-4.2-source_4.2-20061217-1_all.deb gcc-4.2_4.2-20061217-1.diff.gz to pool/main/g/gcc-4.2/gcc-4.2_4.2-20061217-1.diff.gz gcc-4.2_4.2-20061217-1.dsc to pool/main/g/gcc-4.2/gcc-4.2_4.2-20061217-1.dsc gcc-4.2_4.2-20061217-1_i386.deb to pool/main/g/gcc-4.2/gcc-4.2_4.2-20061217-1_i386.deb gcc-4.2_4.2-20061217.orig.tar.gz to pool/main/g/gcc-4.2/gcc-4.2_4.2-20061217.orig.tar.gz gcj-4.2-base_4.2-20061217-1_i386.deb to pool/main/g/gcc-4.2/gcj-4.2-base_4.2-20061217-1_i386.deb gcj-4.2_4.2-20061217-1_i386.deb to pool/main/g/gcc-4.2/gcj-4.2_4.2-20061217-1_i386.deb gfortran-4.2-doc_4.2-20061217-1_all.deb to pool/main/g/gcc-4.2/gfortran-4.2-doc_4.2-20061217-1_all.deb (new) gfortran-4.2-multilib_4.2-20061217-1_i386.deb optional devel The GNU Fortran 95 compiler (multilib files) This is the GNU Fortran compiler, which compiles Fortran 95 on platforms supported by the gcc compiler. . On architectures with multilib support, the package contains files and dependencies for the non-default multilib architecture(s). gfortran-4.2_4.2-20061217-1_i386.deb to pool/main/g/gcc-4.2/gfortran-4.2_4.2-20061217-1_i386.deb gij-4.2_4.2-20061217-1_i386.deb to pool/main/g/gcc-4.2/gij-4.2_4.2-20061217-1_i386.deb (new) gobjc++-4.2-multilib_4.2-20061217-1_i386.deb optional devel The GNU Objective-C++ compiler (multilib files) This is the GNU Objective-C++ compiler, which compiles Objective-C++ on platforms supported by the gcc compiler. . On architectures with multilib support, the package contains files and dependencies for the non-default multilib architecture(s). gobjc++-4.2_4.2-20061217-1_i386.deb to pool/main/g/gcc-4.2/gobjc++-4.2_4.2-20061217-1_i386.deb (new) gobjc-4.2-multilib_4.2-20061217-1_i386.deb optional devel The GNU Objective-C compiler (multilib files) This is the GNU Objective-C compiler, which compiles Objective-C on platforms supported by the gcc compiler. . On architectures with multilib support, the package contains files and dependencies for the non-default multilib architecture(s). gobjc-4.2_4.2-20061217-1_i386.deb to pool/main/g/gcc-4.2/gobjc-4.2_4.2-20061217-1_i386.deb lib64ffi4_4.2-20061217-1_i386.deb to pool/main/g/gcc-4.2/lib64ffi4_4.2-20061217-1_i386.deb lib64gcc1_4.2-20061217-1_i386.deb to pool/main/g/gcc-4.2/lib64gcc1_4.2-20061217-1_i386.deb lib64gfortran2_4.2-20061217-1_i386.deb to pool/main/g/gcc-4.2/lib64gfortran2_4.2-20061217-1_i386.deb lib64gomp1_4.2-20061217-1_i386.deb to pool/main/g/gcc-4.2/lib64gomp1_4.2-20061217-1_i386.deb lib64mudflap0_4.2-20061217-1_i386.deb to pool/main/g/gcc-4.2/lib64mudflap0_4.2-20061217-1_i386.deb lib64objc2_4.2-20061217-1_i386.deb to pool/main/g/gcc-4.2/lib64objc2_4.2-20061217-1_i386.deb lib64stdc++6-4.2-dbg_4.2-20061217-1_i386.deb to pool/main/g/gcc-4.2/lib64stdc++6-4.2-dbg_4.2-20061217-1_i386.deb lib64stdc++6_4.2-20061217-1_i386.deb to pool/main/g/gcc-4.2/lib64stdc++6_4.2-20061217-1_i386.deb libffi4-dev_4.2-20061217-1_i386.deb to pool/main/g/gcc-4.2/libffi4-dev_4.2-20061217-1_i386.deb libffi4_4.2-20061217-1_i386.deb to pool/main/g/gcc-4.2/libffi4_4.2-20061217-1_i386.deb libgcc1_4.2-20061217-1_i386.deb to pool/main/g/gcc-4.2/libgcc1_4.2-20061217-1_i386.deb libgcj8-awt-gtk_4.2-20061217-1_i386.deb to pool/main/g/gcc-4.2/libgcj8-awt-gtk_4.2-20061217-1_i386.deb libgcj8-awt-qt_4.2-20061217-1_i386.deb to pool/main/g/gcc-4.2/libgcj8-awt-qt_4.2-20061217-1_i386.deb libgcj8-awt_4.2-20061217-1_i386.deb to pool/main/g/gcc-4.2/libgcj8-awt_4.2-20061217-1_i386.deb libgcj8-dbg_4.2-20061217-1_i386.deb
[Bug target/30255] register spills in x87 unit need to be 80-bit, not 64
--- Comment #2 from whaley at cs dot utsa dot edu 2006-12-18 20:43 --- Hi, While it may be decided not to fix this problem, this is not a duplicate of bug 323, and so it should be closed for another reason if you want to ignore it. 323 has a problem because of the function call, where a programmer knows that a round-down can occur by examining the code. This problem is due to register spilling, and so no amount of source examination can figure out if this could occur. Therefore, 323 can be worked around by the knowledgable user, and this one cannot. Also, the 323 would require a pragmas or something to prevent, whereas this problem could be completely avoided merely by spilling the 80-bit value when gcc decides to spill. Since this problem cannot be worked around, and has a much more discrete fix, it is very different indeed from the much harder to fix 323. Thanks, Clint -- whaley at cs dot utsa dot edu changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30255 --- 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug target/30255] register spills in x87 unit need to be 80-bit, not 64
--- Comment #3 from whaley at cs dot utsa dot edu 2006-12-18 21:16 ---
BTW, in case it isn't obvious, here's the fix that I typically use for problems
like bug 323 that I cannot when it is gcc itself that is unpredictably spilling
the computation:
void test(double x, double y)
{
const double y2 = x + 1.0;
volatile double v[2];
v[0] = y2;
v[1] = y;
if (v[0] != v[1]) printf("error\n");
}
The idea being that the volatile keyword prevents gcc from getting rid of the
store/load cycle, which forces the round-down. This allows me to still do this
kind of comparison, w/o the speed loss of associated with -ffloat-store (the
compare itself becomes slow due to the store/load, but the body of the code
runs as fast as normal), or the loss of precision associated with always
rounding to 64 bit, as when you change the x87 control word.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30255
--- 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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug target/30255] register spills in x87 unit need to be 80-bit, not 64
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-18 22:04 --- The problem with register spilling and what PR 323 is talking about is all the same issue really, it is just exposed differently. *** This bug has been marked as a duplicate of 323 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30255 --- 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #86 from pinskia at gcc dot gnu dot org 2006-12-18 22:04 --- *** Bug 30255 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 --- 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug target/30255] register spills in x87 unit need to be 80-bit, not 64
--- Comment #5 from whaley at cs dot utsa dot edu 2006-12-18 22:14 --- I cannot, of course, force you to admit it, but 323 is a bug fixable by the programmer, and this one is not. The other requires a lot of work in the compiler, and this does not. So, viewing them as the same can be done, in the same way that all x87/gcc bugs are the same, or all precision bugs are the same, but since neither their genesis or solution are the same, it is misleading to do so. Saying you don't care to fix it is an honest answer, closing it because it is a duplicate of a much larger and harder problem for which known workarounds exist is not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30255 --- 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401385: This might not be as easy as I thought...
Kevin Brown writes: > That may be true, but developers aren't the only ones who might make > use of these files. Anyone who gets a crash in an Ada application > could get a much better traceback (for filing a bug report) with > these files in place than without. > > Independent of the potential issues described below, we should give > some serious thought to including the debugging files with the runtime > package. > > It does bloat the package a bit, though. The overriding reason is multilib. We will make a separate -dbg package, and we will probably even move the static library to another package, too. Better do it right the first time. [...] > But given that the control file is generated from an m4 master, > changing binary-ada.mk in the required way may be a problem. The > argument to dh_strip will be --dbg-package, and it takes the name of > the target package as its argument. That's a problem because the > package names are generated from the m4 master. [...] The only part of the package name that will change across versions is the version number, and there is a macro in the Makefiles for that: $(GNAT_VERSION). All package names in binary-ada.mk are derived from that macro, and we pass its value to m4 so it generates control from control.m4. So, no problem. See the top 15 lines of binary-ada.mk of you're not convinced. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug target/30255] register spills in x87 unit need to be 80-bit, not 64
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-12-18 23:02 --- >I cannot, of course, force you to admit it, but 323 is a bug fixable by the > programmer, and this one is not. Depends on what you mean by fixable by the programmer because most people don't know anything about precusion issues. This was a design of the x86 back-end because it gives a nice speed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30255 --- 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401385: This might not be as easy as I thought...
Ludovic Brenta writes: > Kevin Brown writes: > > That may be true, but developers aren't the only ones who might make > > use of these files. Anyone who gets a crash in an Ada application > > could get a much better traceback (for filing a bug report) with > > these files in place than without. > > > > Independent of the potential issues described below, we should give > > some serious thought to including the debugging files with the runtime > > package. > > > > It does bloat the package a bit, though. > > The overriding reason is multilib. We will make a separate -dbg > package, and we will probably even move the static library to another > package, too. Better do it right the first time. > > [...] +1, as done for the libstdc++ library package. I would like to see this work beeing done for 4.2 (as available in our svn archive), but as a prerequisite we would need to have the gnat 4.1 patches ported forward to 4.2 (or even better submitted upstream). Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401385: This might not be as easy as I thought...
Ludovic Brenta wrote: > Kevin Brown writes: > > That may be true, but developers aren't the only ones who might make > > use of these files. Anyone who gets a crash in an Ada application > > could get a much better traceback (for filing a bug report) with > > these files in place than without. > > > > Independent of the potential issues described below, we should give > > some serious thought to including the debugging files with the runtime > > package. > > > > It does bloat the package a bit, though. > > The overriding reason is multilib. We will make a separate -dbg > package, and we will probably even move the static library to another > package, too. Better do it right the first time. Yeah, I'm all for that. I just wasn't sure how hard it would be. > The only part of the package name that will change across versions is > the version number, and there is a macro in the Makefiles for that: > $(GNAT_VERSION). All package names in binary-ada.mk are derived from > that macro, and we pass its value to m4 so it generates control from > control.m4. So, no problem. See the top 15 lines of binary-ada.mk of > you're not convinced. OK, this should (hopefully) be relatively easy then. It takes a number of hours for the package to build on my box, so it'll take some time for me to make the changes and debug them. -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
GCC 4.1 build-depends on binutils (>= 2.17.50) but it is not in Debian
That version of binutils is nowhere to be found in Debian: not in testing, not in unstable and not in experimental. So I'm wondering why it is necessary to build-depend on it, and whether or not I should revert that particular change (see revision 1669). I'm already building with BINUTILSV set to 2.17 instead; is there any risk involved? Thanks -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug target/30255] register spills in x87 unit need to be 80-bit, not 64
--- Comment #7 from whaley at cs dot utsa dot edu 2006-12-19 00:31 --- >Depends on what you mean by fixable by the programmer because most people don't know anything about precusion issues. Most people don't know programming at all, so I guess you are suggesting that errors that are fixable at the source-code level must nonetheless always be fixed by the compiler? More to the point, the people who truly care about precision *are* often aware of these kinds of fixes, but they are helpless in this case, unlike for bug 323 (which is why they should not be conflated). My point was that for bug 323, there is something the user can do to fix, and that something does not hurt overall performance or accuracy. Since the problem I reported is caused completely by gcc, impacts accuracy in the same way as reordering (which gcc prohibits), and there is nothing that the user can do to fix without drastic loss of performance or accuracy, gcc is the only place it can be fixed. This problem is a narrow discrete case that can clearly be fixed by gcc, whereas 323 is a broad class of problems which cannot be fixed without adding to the C language the concept of mixed precisions within a type. Therefore, I strongly believe that it is perfectly valid to say that 323 cannot be solved in gcc, but clearly untrue to say that about this case, and so this bug report should have been closed as "we don't care", not as "duplicate". >This was a design of the x86 back-end because it gives a nice speed. The fix I suggested would only slow spill (note: I mean gcc-spilled code, not explicit load/stores by the programmer) code, and would therefore make noticable performance difference in very few cases. Note that unlike the straw-man of bug 323 I am *not* advocating gcc handle all extra precision behavior, just its undetectable spill rounding. If the performance issue is greater than I suspect, obviously there could be a flag for this behavior. I find it a bit anomolous that a compiler that is so picky about bit-level accuracy that it forbids reordering operations without a special flag, feels free to randomly round in an algorithm, even though the fix would not hurt performance as much as not performing reordering optimizations does, and introduces the same type of error. That it does so on the most common platform on earth just adds to the beauty :) Thanks, Clint -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30255 --- 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402971: It seems like this bug is actually related to libpthread-dev
After purging the package libpthread-dev the above code doesn't make g++ yield that error message. The program actually works like it's supposed to after being compiled. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
