--
What|Removed |Added
Severity|minor |normal
Summary|[3.3/3.4/3.5] exception in |[3.3/3.4/3.5 Regression]
|constructor
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-02-16
03:07 ---
I do not believe there is any ambiguity in the standard here.
This program should clearly through an exception of type "int" with the value
"1", and that exception should be caught in "main".
The problem
Accepted:
gcc-snapshot_20040215-1.diff.gz
to pool/main/g/gcc-snapshot/gcc-snapshot_20040215-1.diff.gz
gcc-snapshot_20040215-1.dsc
to pool/main/g/gcc-snapshot/gcc-snapshot_20040215-1.dsc
gcc-snapshot_20040215-1_i386.deb
to pool/main/g/gcc-snapshot/gcc-snapshot_20040215-1_i386.deb
gcc-snapshot
gcc-snapshot_20040215-1_i386.changes uploaded successfully to localhost
along with the files:
gcc-snapshot_20040215-1.dsc
gcc-snapshot_20040215.orig.tar.gz
gcc-snapshot_20040215-1.diff.gz
gcc-snapshot_20040215-1_i386.deb
Greetings,
Your Debian queue daemon
Probably you are the uploader of the following file(s) in
the Debian upload queue directory:
gcc-snapshot_20040215-1.diff.gz
gcc-snapshot_20040215-1.dsc
gcc-snapshot_20040215-1_i386.deb
This looks like an upload, but a .changes file is missing, so the job
cannot be processed.
If no .changes
On m68k-linux and parisc-linux between 3.3 and 3.4 the default
exception model changed from sjlj based exceptions to dw2 based
exceptions. Unfortunately at this time the soversion number of the
shared libgcc was not bumped. This patch bumps the version number for
these two archs to 2, if not config
LAST_UPDATED: Sat Feb 14 08:16:42 UTC 2004
Native configuration is alpha-unknown-linux-gnu
=== libjava tests ===
Running target unix
WARNING: program timed out.
FAIL: SyncTest execution - gij test
WARNING: program timed out.
FAIL: SyncTest execution - bytecode->native test
WARNI
LAST_UPDATED: Sat Feb 14 14:27:56 UTC 2004
=== acats tests ===
FAIL: c34005a
FAIL: c34005d
FAIL: c34005g
FAIL: c34005j
FAIL: c37213f
FAIL: c37215f
FAIL: c64106b
FAIL: ce2102c
FAIL: cxb3010
FAIL: cxb3014
FAIL: cxb3015
=== acats Summary ===
# of
LAST_UPDATED: Sat Feb 14 14:27:56 UTC 2004
=== acats tests ===
FAIL: ad8011a
FAIL: c380004
FAIL: c91004b
FAIL: c940010
FAIL: c94002g
FAIL: c94007a
FAIL: c95022b
FAIL: c95072a
FAIL: c95072b
FAIL: c954016
FAIL: c954017
FAIL: c974004
FAIL: c974009
FAIL: c9a
LAST_UPDATED: Sat Feb 14 08:16:42 UTC 2004
Native configuration is i486-pc-linux-gnu
=== g++ tests ===
Running target unix
XPASS: g++.other/init5.C Execution test
=== g++ Summary ===
# of expected passes8220
# of unexpected successes 1
# of e
LAST_UPDATED: Sat Feb 14 08:16:42 UTC 2004
Native configuration is powerpc-unknown-linux-gnu
=== g++ tests ===
Running target unix
XPASS: g++.dg/other/packed1.C execution test
XPASS: g++.other/init5.C Execution test
=== g++ Summary ===
# of expected passes
close 224735
thanks
Hola Daniel Jacobowitz!
> The string class does manage a certain amount of memory on its own. I
> seem to recall this fooling memory leak analyzers before.
Actually this seems to be the case, although it's not only the string
class, but the whole STL. This was brought to my
--- Additional Comments From gdr at gcc dot gnu dot org 2004-02-15 12:43
---
Adjust milestone
--
What|Removed |Added
Target Milestone|3.3.3 |3.3.4
--- Additional Comments From gdr at gcc dot gnu dot org 2004-02-15 12:43
---
Adjust milestone
--
What|Removed |Added
Target Milestone|3.3.3 |3.3.4
--- Additional Comments From gdr at gcc dot gnu dot org 2004-02-15 12:41
---
Adjust milestone
--
What|Removed |Added
Target Milestone|3.3.3 |3.3.4
15 matches
Mail list logo
