Processed: gnat: Assert_Failure atree.adb:678 on invalid code (mixture of protected object and accept of entry family)

Processing commands for cont...@bugs.debian.org: > tags 339356 upstream Bug #339356 [gnat-4.3] gnat: Assert_Failure atree.adb:678 on invalid code (mixture of protected object and accept of entry family) Added tag(s) upstream. > forwarded 339356 http://gcc.gnu.org/PR40936 Bug #339356 [gnat-4.3] gn

Processed: Re: Processed: RFH: gnat-4.4 -- help needed to execute test cases

Processing commands for cont...@bugs.debian.org: > reassign 539562 wnpp Bug #539562 [gnat-4.4] RFH: gnat-4.4 -- help needed to execute test cases Bug reassigned from package 'gnat-4.4' to 'wnpp'. Bug #539562 [wnpp] RFH: gnat-4.4 -- help needed to execute test cases Ignoring request to alter found

Processed: RFH: gnat-4.4 -- help needed to execute test cases

Processing commands for cont...@bugs.debian.org: > clone 475374 -1 Bug#475374: RFH: gnat-4.3 -- help needed to execute test cases Bug 475374 cloned as bug 539562. > retitle -1 RFH: gnat-4.4 -- help needed to execute test cases Bug #539562 [wnpp] RFH: gnat-4.3 -- help needed to execute test cases

Bug#182360: fixed upstream ?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 procedure Close comes now in two versions in gnat.os_lib (see system.os_lib) : procedure Close (FD : File_Descriptor; Status : out Boolean); - -- Close file referenced by FD. Status is False if the underlying service - -- failed. Reasons for failure

Bug#182360: fixed upstream ?

I guess AdaCore wanted to preserve backward compatibility but the proper fix, of course, was for Close to raise an exception. This is not the case, so all programs using the buggy Close are still affected, so I would leave the bug open. It is quite ironic that Ada prevents programmers from ignori

Bug#339356: bug present also in gnat-4.4

gnatmake gnat_bug.adb gcc-4.4 -c gnat_bug.adb +===GNAT BUG DETECTED==+ | 4.4.1 (i486-pc-linux-gnu) Assert_Failure atree.adb:884 | | Error detected at gnat_bug.adb:13:10 | | Please submit a bug

Bug#538647: closed by Florian Weimer (Re: Bug#538647: g++-4.3: g++ examines second value to "?" always if it is a template)

* Philip Ashmore: >> * Philip Ashmore: >> >> >>> /*HERE*/enum { value = (wanted <= guess) ? result : next_value_type::value >>> }; >>> >> >> Not a bug. You need to implement your own conditional operator at the >> template level to make this work. The version with ?: is not valid >> C++

Results for 4.3.3 (Debian 4.3.3-15) testsuite on mips-unknown-linux-gnu

LAST_UPDATED: Mon Jul 27 23:16:21 UTC 2009 (revision 150136) Target: mips-linux-gnu gcc version 4.3.3 (Debian 4.3.3-15) Native configuration is mips-unknown-linux-gnu === g++ tests === Running target unix === g++ Summary for unix === # of expected passes

Results for 4.3.3 (Debian 4.3.3-15) testsuite on arm-unknown-linux-gnueabi

LAST_UPDATED: Mon Jul 27 23:16:21 UTC 2009 (revision 150136) Native configuration is arm-unknown-linux-gnueabi === libgomp tests === Running target unix === libgomp Summary === # of expected passes1749 # of unsupported tests 7

Results for 4.3.3 (Debian 4.3.3-15) testsuite on alpha-unknown-linux-gnu

LAST_UPDATED: Mon Jul 27 23:16:21 UTC 2009 (revision 150136) Native configuration is alpha-unknown-linux-gnu === libgomp tests === Running target unix WARNING: program timed out. FAIL: libgomp.c/autopar-1.c execution test FAIL: libgomp.fortran/threadprivate3.f90 -O3 -fomit-fram

Bug#539470: Warning: Immediates 21 and 32 will give undefined behavior.

Package: gcc-4.3 Tags: upstream, patch I'm filing this BR against gcc-4.3, but according to upstream it affects *all* versions of gcc, and in all Debian releases! During compilations using gcc-4.3 of the upstream 2.6.31-rc4 kernel, I twice noticed the following warning: {standard input}: Assemble