--- Comment #16 from ebotcazou at gcc dot gnu dot org 2005-11-12 08:17
---
> The patch from comment 14 seems to be working fine without any other changes.
> I have bootstrapped and am currently running the testsuite. Looks OK so far.
Zack's patch for 4.x doesn't work as-is for 3.4.x
--- Comment #6 from debian-gcc at lists dot debian dot org 2005-11-12
09:33 ---
(In reply to comment #2)
> I gather therefore that Debian
> is building GCC passing --enable-libstdcxx-allocator=mt, something absolutely
> not obvious and not trivial in its consequences.
Correct. That dec
--- Comment #4 from debian-gcc at lists dot debian dot org 2005-11-12
09:35 ---
works with HEAD 2005
--
debian-gcc at lists dot debian dot org changed:
What|Removed |Added
---
--- Comment #3 from pcarlini at suse dot de 2005-11-12 11:27 ---
(In reply to comment #2)
> As for the original bug report: it's easy to verify by inspecting the source
> that _Mem_fn has no base class as required.
I beg to disagree. Have you really checked the actual versions of it for
--- Comment #4 from doug dot gregor at gmail dot com 2005-11-12 11:33
---
This is not a bug. TR1 3.5 refers to member function pointers, not member data
pointers as in the submitted test case. mem_fn has no result_type for member
data pointers because the constness of the result type de
--- Comment #3 from sraa at kse dot nl 2005-11-12 12:07 ---
We found out that the stackpointer was unbalanced at a given point. Via a small
program in assembly wich reads the stackpointer that I placed at suspicious
points in the code I found a function that didn't restore the stackpoint
--- Comment #1 from pcarlini at suse dot de 2005-11-12 12:45 ---
Doug, can you look a bit into this one too? Thanks!
--
pcarlini at suse dot de changed:
What|Removed |Added
---
--- Comment #2 from doug dot gregor at gmail dot com 2005-11-12 13:23
---
I don't know how to classify this. The basic problem is one that isn't
really solveable without rvalue references: you can't pass a literal
(e.g., 0) into the operator() of a reference_wrapper or any other
functio
--- Comment #3 from pcarlini at suse dot de 2005-11-12 13:27 ---
Hi Doug. First thing to do, before actually studying your extremely useful and
detailed reply (THANKS), is adding Howard in CC...
--
pcarlini at suse dot de changed:
What|Removed |Add
tr1::reference_wrapper::operator()() should not dereference get() before
calling the function object, because get() returns a reference (not a pointer).
--
Summary: tr1::reference_wrapper improperly calls nullary function
objects
Product: gcc
--- Comment #1 from doug dot gregor at gmail dot com 2005-11-12 13:31
---
Created an attachment (id=10225)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10225&action=view)
Mainline (4.1.0) patch to test and fix this problem
The fix is trivial. The changes to the test case cause f
--- Comment #2 from pcarlini at suse dot de 2005-11-12 13:33 ---
Thanks a lot. I will take care of applying the patch asap.
--
pcarlini at suse dot de changed:
What|Removed |Added
make check fails with -O2 on powerpc64-linux and powerpc-linux with gcc-4.1
Works ok with gcc-4.0, and also with 4.1 and -O1.
ppc64:
make[2]: *** [/usr/src/packages/BUILD/glibc-2.3/cc-nptl/math/test-float.out]
Error 1
make[2]: *** [/usr/src/packages/BUILD/glibc-2.3/cc-nptl/math/test-double.out]
Er
--- Comment #1 from olh at suse dot de 2005-11-12 14:07 ---
Created an attachment (id=10226)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10226&action=view)
pr24819-failure.txt
make check errors on powerpc-linux
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24819
--- Comment #6 from gcc-bugzilla at kayari dot org 2005-11-12 14:12 ---
Created an attachment (id=10227)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10227&action=view)
alternative fix
This is a fixed version of the previous patch that passes tests on
linux-x86_64.
This patch ma
--- Comment #4 from joseph at codesourcery dot com 2005-11-12 14:24 ---
Subject: Re: gcc.dg/tls/pr24428.c execution test and
gcc.dg/tls/pr24428-2.c execution test fail on IA32
On Thu, 10 Nov 2005, jakub at gcc dot gnu dot org wrote:
> Does even a trivial __thread using program break
--- Comment #15 from debian-gcc at lists dot debian dot org 2005-11-12
14:59 ---
workaround works with 4.0.3 on alpha-linux as well, 4.1 build currently fails
in stage3
Matthias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18434
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Component|regression |tree-optimiza
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-12 15:31 ---
Waiting for a testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Co
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24819
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-12 15:36 ---
No feedback in 3 months (T-3 days).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P3
Summary|197.parser performance drop |[4.1 Regression] 1
--- Comment #16 from laurent at guerby dot net 2005-11-12 16:11 ---
Arnaud has a patch for this issue on trunk and a better workaround patch for
4.0.
Could you post your stage3 failure?
--
laurent at guerby dot net changed:
What|Removed |Added
---
// Compile this with -O2 -ffast-math to get segfault
double floor (double);
double bar (double sum)
{
int i;
for (i = 0; i < 256; i++)
sum += floor (0.5 + (i - 128));
return sum;
}
--
Summary: [4.1 regression] SEGV in integer_valued_real_p at
gcc/builtin
--- Comment #1 from laurent at guerby dot net 2005-11-12 16:36 ---
confirmed on x86_64-linux gcc version 4.1.0 2005 (experimental)
z.c: In function 'bar':
z.c:3: internal compiler error: tree check: expected class 'expression', have
'constant' (real_cst) in integer_valued_real_p, at
trunk 2005, configured for alpha-linux-gnu
Matthias
stage1/xgcc -Bstage1/ -B/usr/lib/gcc-snapshot/alpha-linux-gnu/bin/ -c -O2
-gnatpg -gnata -g -O1 -fno-inline \
-I- -I. -Iada -I../../src/gcc/ada ../../src/gcc/ada/a-except.adb -o
ada/a-except.o
:0: warning: 'const' attribute directive
--- Comment #17 from debian-gcc at lists dot debian dot org 2005-11-12
16:41 ---
(In reply to comment #16)
> Arnaud has a patch for this issue on trunk and a better workaround patch for
> 4.0.
>
> Could you post your stage3 failure?
actually, it's a stage2 failure, files as PR24821
(cd ada/bldtools/sinfo; gnatmake -q xsinfo ; ./xsinfo ../../sinfo.h )
mkdir -p ada/bldtools/einfo
cp -p ../../gcc/gcc/ada/einfo.ads ../../gcc/gcc/ada/einfo.adb
../../gcc/gcc/ada/
xeinfo.adb ada/bldtools/einfo
(cd ada/bldtools/einfo; gnatmake -q xeinfo ; ./xeinfo ../../einfo.h )
raised STORAGE_ERRO
--- Comment #1 from laurent at guerby dot net 2005-11-12 16:51 ---
Likely to be the same problem than mips/powerpc. Note there's a negatively
reviewed patch that solves this problem.
*** This bug has been marked as a duplicate of 22533 ***
--
laurent at guerby dot net changed:
--- Comment #25 from laurent at guerby dot net 2005-11-12 16:51 ---
*** Bug 24821 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22533
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24820
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-12 16:58 ---
integer_valued_real_p is missing a break or something. Looking more into it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24820
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-12 17:03 ---
This is a latent bug from 2003 (3.4 time frame):
* builtins.c (integer_valued_real_p): New function to test if
a floating point expression has an integer valued result.
(fold_trunc_transparent_mathfn)
--- Comment #3 from dnovillo at gcc dot gnu dot org 2005-11-12 17:47
---
Testing new patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24703
--- Comment #5 from john at johnmaddock dot co dot uk 2005-11-12 17:53
---
Thanks for the clarification Doug: having re-read the text, the issues list,
and scratched my head for a while I agree with you. I'll update the Boost test
case appropriately.
Feel free to close this one down a
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-12 18:27 ---
I will take care of this one, it is a simple matter of a break missing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
We ICE building lapack on x86_64 with
/usr/lib64/gcc/x86_64-suse-linux/4.1.0/f951 zlatmr.f -ffixed-form -quiet
-dumpbase zlatmr.f -mtune=k8 -auxbase zlatmr -O3 -version -funroll-all-loops -o
/tmp/cclbQYB1.s
zlatmr.min.f:69: internal compiler error: in insert_save, at caller-save.c:719
--
--- Comment #4 from john at johnmaddock dot co dot uk 2005-11-12 18:32
---
Doug's right: according to 3.4p4 passing an rvalue results in implementation
defined behaviour. So you can support it or not as you wish. I'll update the
Boost test case accordingly.
However... I predict that
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-12 18:32 ---
Created an attachment (id=10228)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10228&action=view)
reduced testcase
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24823
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-12 18:40 ---
This is a recent regression. This worked with PR 20051106 but not with
2005.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from hhinnant at apple dot com 2005-11-12 19:02 ---
> (1) Strong-arm a C++ front-end guru into implementing rvalue references,
> then use them in the TR1 function objects. Heck, we'll need 'em
> for C++0x anyway :)
At the risk of being reckless. Yes... wel
g++ ICE with error message:
test.cc:24: internal compiler error: in build_abbrev_table, at dwarf2out.c:6427
Please submit a full bug report,
g++ call: g++ -c -gdwarf-2 -feliminate-dwarf2-dups test.cc -o test.o
testcase:
---8X--
namespace N {
struct I {};
tem
--- Comment #1 from wanderer at rsu dot ru 2005-11-12 19:04 ---
Created an attachment (id=10229)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10229&action=view)
testcase source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24824
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-12 19:09 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-12 19:10 ---
Confirmed.
106665 works, 106727 fails
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24823
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #3 from kargl at gcc dot gnu dot org 2005-11-12 19:16 ---
Subject: Bug 24787
Author: kargl
Date: Sat Nov 12 19:16:40 2005
New Revision: 106828
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106828
Log:
PR libfortran/24787
* intrinsics/string_intrinsics.c (string_scan
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-12 19:26 ---
I have a patch already.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Ass
--- Comment #4 from kargl at gcc dot gnu dot org 2005-11-12 19:48 ---
Subject: Bug 24787
Author: kargl
Date: Sat Nov 12 19:48:25 2005
New Revision: 106830
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106830
Log:
PR libgfortran/24787
* gfortran.dg/scan_1.f90: New test.
* intri
--- Comment #5 from kargl at gcc dot gnu dot org 2005-11-12 19:50 ---
Fixed on mainline and 4.0.x
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-12 20:05 ---
This is an easy extension on top of PR 20318. Mine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-12 20:06 ---
Will look into marking _Jv_AllocObjectNoFinalizer with the non zero attribute
which is added with PR 20318.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-12 20:08 ---
Mine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|dnovillo a
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-12 20:09 ---
This is actually a dup of bug 21856.
*** This bug has been marked as a duplicate of 21856 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-12 20:09 ---
*** Bug 24242 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from jakub at gcc dot gnu dot org 2005-11-12 20:42 ---
Subject: Bug 24761
Author: jakub
Date: Sat Nov 12 20:42:23 2005
New Revision: 106831
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106831
Log:
PR c++/24761
* pt.c (tsubst_copy_asm_operands): N
--- Comment #7 from jakub at gcc dot gnu dot org 2005-11-12 20:43 ---
Subject: Bug 24761
Author: jakub
Date: Sat Nov 12 20:43:27 2005
New Revision: 106832
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106832
Log:
PR c++/24761
* pt.c (tsubst_copy_asm_operands): N
--- Comment #8 from jakub at gcc dot gnu dot org 2005-11-12 20:44 ---
Subject: Bug 24780
Author: jakub
Date: Sat Nov 12 20:44:55 2005
New Revision: 106833
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106833
Log:
PR c++/24780
* typeck.c (complete_type): Set TYPE
--- Comment #9 from jakub at gcc dot gnu dot org 2005-11-12 20:45 ---
Subject: Bug 24780
Author: jakub
Date: Sat Nov 12 20:45:47 2005
New Revision: 106834
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106834
Log:
PR c++/24780
* typeck.c (complete_type): Set TYPE
As pointed out in this thread:
http://gcc.gnu.org/ml/java/2005-11/msg00124.html
Once we have the capability to annotate methods as returning 'not null', we
have a win if standard runtime methods are so annotated as appropiate.
--
Summary: Standard runtime methods that are known to n
--- Comment #3 from andreast at gcc dot gnu dot org 2005-11-12 21:06
---
The other languages like g++, gfortran, obj-c++ and objc should be fixed with
this patch which is applied on trunk.
http://gcc.gnu.org/ml/gcc-cvs/2005-11/msg00503.html
So, the question is now, can you reproduce t
At some point between 4.0 and 4.1 the mechanism for option handling was
changed over to the new style using the .opt file but the default setting of
quickcall seems to have been lost in the process.
adding the following 2 lines into h8300.c
#undef TARGET_DEFAULT_TARGET_FLAGS
#defi
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||kazu at gcc dot gnu dot org
Priority|P3
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-12 22:13 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-12 22:14
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-12 22:14 ---
Confirmed, this one is harder than the new operator.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2005-11-12 22:22
---
Subject: Bug 24584
Author: jvdelisle
Date: Sat Nov 12 22:22:53 2005
New Revision: 106838
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106838
Log:
2005-11-12 Jerry DeLisle <[EMAIL PROTECTED]>
P
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2005-11-12 22:22
---
Subject: Bug 24699
Author: jvdelisle
Date: Sat Nov 12 22:22:53 2005
New Revision: 106838
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106838
Log:
2005-11-12 Jerry DeLisle <[EMAIL PROTECTED]>
P
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2005-11-12 22:31
---
Subject: Bug 24719
Author: jvdelisle
Date: Sat Nov 12 22:31:18 2005
New Revision: 106839
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106839
Log:
2005-11-12 Jerry DeLisle <[EMAIL PROTECTED]>
P
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2005-11-12 22:31
---
Subject: Bug 24785
Author: jvdelisle
Date: Sat Nov 12 22:31:18 2005
New Revision: 106839
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106839
Log:
2005-11-12 Jerry DeLisle <[EMAIL PROTECTED]>
P
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2005-11-12 22:31
---
Subject: Bug 24699
Author: jvdelisle
Date: Sat Nov 12 22:31:18 2005
New Revision: 106839
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106839
Log:
2005-11-12 Jerry DeLisle <[EMAIL PROTECTED]>
P
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2005-11-12 22:31
---
Subject: Bug 24584
Author: jvdelisle
Date: Sat Nov 12 22:31:18 2005
New Revision: 106839
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106839
Log:
2005-11-12 Jerry DeLisle <[EMAIL PROTECTED]>
P
Executing on host: /test/gnu/gcc-3.3/objdir/gcc/xgcc
-B/test/gnu/gcc-3.3/objdir/
gcc/ /test/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/attr-weakref-1.c -O2
-fno-show
-column /test/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/attr-weakref-1a.c -lm -o
./attr-weakref-1.exe(timeout = 300)
ld: Unsatisfied s
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-11-12 23:03 ---
works with 3.3, so a regression.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2005-11-12 23:13
---
Fixed in 4.0.3 and 4.1
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2005-11-12 23:13
---
Fixed in 4.0.3 and 4.1.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2005-11-12 23:20
---
Fixed in 4.0.3 and 4.1
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2005-11-12 23:21
---
Fixed in 4.0.3 and 4.1 .
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2005-11-12 23:22
---
Fixed in 4.0.3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24584
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2005-11-12 23:29
---
With my last patch () that I am currently commiting, the list of unimplemented
intrinsics is now:
Access, fcn, Check file accessibility.
ChMod,sub, Change file modes.
FSeek,fcn, Position file (low
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-12 23:43 ---
(In reply to comment #8)
> I got the same ICE with one of the SPEC2006 candidate benchmarks on
> x86_64-linux-gnu.
Was this before or after my fix for PR 18157 went in? Because this and that
bug had the same ICE bu
$ cat z.f
program z
i = Z'80203040'
if (i .ne. Z'80203040') call abort
end
$ gfortran z.f
$ ./a.out
Aborted
$ g77 z.f
$ ./a.out
$
This is a signedness/cast issue. .t02.original shows:
int4 i;
i = 080203040;
if ((int8) i != 080203040)
{
_gfortran_abort ()
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-12 23:53 ---
(In reply to comment #0)
> (And why is hexadecimal shown as 0 in the dump?)
Because that means TREE_OVERFLOW is set for some reason.
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Re
--- Comment #9 from tkoenig at gcc dot gnu dot org 2005-11-12 23:56 ---
Yes, this is fixed for mainline. Great!
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-13 00:16 ---
The way we can mark the function/function type is in build_method_invocation,
we have to change how BUILD_APPEND calls build_method_invocation and add a new
argument or something like that (we build the real call exp
--- Comment #5 from sabre at nondot dot org 2005-11-13 01:24 ---
Is this safe? People can define their own operator new's, some of which may
return null...
-Chris
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476
--- Comment #13 from steven at gcc dot gnu dot org 2005-11-13 01:38 ---
Doesn't happen anymore on current mainline.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from steven at gcc dot gnu dot org 2005-11-13 01:41 ---
IIUC, this is one of the things that's being worked on in the dataflow-branch.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2005-11-13 01:43 ---
This hasn't been addressed yet in r106784.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-13 02:10 ---
(In reply to comment #5)
> Is this safe? People can define their own operator new's, some of which may
> return null...
Yes because the normal operator new guarante not to return NULL by the C++
standard. And if i
--- Comment #7 from sabre at nondot dot org 2005-11-13 02:13 ---
> Yes because the normal operator new guarante not to return NULL by the C++
> standard.
Sure.
> And if it returns a NULL that is undefined behavior, it should be
> throwing an exception when memory could not be allocated
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-13 02:24 ---
(In reply to comment #7)
>From 3.7.3/3:
Any allocation and/or deallocation functions defined in a C++ program shall
conform to the sematics specified in 3.7.3.1 and 3.7.3.2.
---
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #2 from dann at godzilla dot ics dot uci dot edu 2005-11-13
02:47 ---
Simplified testcase:
struct cpuinfo_x86 {
unsigned char x86;
unsigned char x86_vendor;
unsigned char x86_model;
unsigned char x86_mask;
char wp_works_ok;
char hlt_works_ok;
char hard_math;
--- Comment #9 from sabre at nondot dot org 2005-11-13 02:51 ---
yup, you're right. Great!
-Chris
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476
Running /test/gnu/gcc-3.3/gcc/gcc/testsuite/objc.dg/dg.exp ...
FAIL: objc.dg/bitfield-1.m (test for excess errors)
FAIL: objc.dg/bitfield-1.m execution test
FAIL: objc.dg/bitfield-3.m (test for excess errors)
FAIL: objc.dg/bitfield-3.m execution test
FAIL: objc.dg/bitfield-5.m (test for excess erro
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-13 03:25 ---
Is this a regression? If this is a regression, was this caused by:
2005-11-09 Alexandre Oliva <[EMAIL PROTECTED]>
PR other/4372
* gthr-dce.h, gthr-posix.h, gthr-posix95.h, gthr-solaris.h,
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-13
03:32 ---
Subject: Re: libobjc testsuite failures
> Is this a regression? If this is a regression, was this caused by:
Yes, things were ok on 2005-11-07.
> 2005-11-09 Alexandre Oliva <[EMAIL PROTECTED]>
>
>
--- Comment #1 from danglin at gcc dot gnu dot org 2005-11-13 03:46 ---
Also fails on hppa2.0w-hp-hpux11.11. So, probably fails on all hppa*-*-hpux*
targets.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24827
The only way I know how to reproduce this is with -fmudflap, but
that's only because *C* code doesn't normally generate constructors.
With -fmudflap, each of the mudflap constructors are run twice. An objdump
run on the object files shows two ctor sections, one named ".ctor" and
one named ".ctor.
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-13 04:07 ---
Alexandre could you look into this one and PR 24827?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 131 matches
Mail list logo
