Hi Aram,
i have gone through the a.out file after this error.
that is producing full of arm instructions other than the main
function(which is compiled for -mthumb).
where should i change for this corresponding error.
It is not clear what question you are asking here.
Ian has pointed out
Gabriel Dos Reis wrote:
Paolo Bonzini [EMAIL PROTECTED] writes:
| ISTR the name change was to avoid a switch named -fdump-rtl-rtl.
| To invent an option name alias and use a minor repetition in it
| as a reason for changing the old behavior is Bad.
|
| It is not merely an option name alias.
Hi there,
The assembler instructions themselves don't allow the target to be the same
as the source unfortunately so removing the '' is difficult. (If I enforce
the same thing without a '' in inline asm using builtins and building the
expression manually to generate a new reg rtx if the
; }
template typename T int ptr (volatile T*) { return 32; }
void foo() {}
int main()
{
return ref(foo) + ptr(foo);
}
==
GCC 2.95.3 - 3.4.0 return 0, GCC 3.4.1 - 3.4.4-20050222 return 2,
and now mainline again returns 0.
So
);
| }
| ==
|
| GCC 2.95.3 - 3.4.0 return 0, GCC 3.4.1 - 3.4.4-20050222 return 2,
| and now mainline again returns 0.
I would say that is the behaviour I would expect. I don't understand
the answer 2. I'll check with the C++ Core Working Group.
| So the question is: What is the correct return
Peter Seiderer wrote:
/*
* Gives error when compiled with gcc (eg. 3.4.2, gcc-4.0-20050123).
* No error with intel (8.1) or windows compiler.
*/
... try what they call strict-ansi mode...
Paolo.
# /opt/gcc-3.4.2/bin/g++ -Wall -ansi default_constructor.cpp
Peter Seiderer wrote:
# /opt/gcc-3.4.2/bin/g++ -Wall -ansi default_constructor.cpp
default_constructor.cpp:17: error: uninitialized const `a2'
:) :) what *intel* calls -strict_ansi, of course.
Paolo.
One reason that occurred to me is that I am issueing the v16sf move as four
subreg v4sf moves.
One thing I get are variable may not be initialised warnings:
v16sf test;
test = _builtin_matrix_mul( left, right );
return test;
Is there someway I can flag the moves to say that is moving the v16sf
On Tue, Feb 22, 2005 at 04:32:33PM +0100, Peter Seiderer wrote:
Thanks, reproducable with intel:
# icc -strict_ansi default_constructor.cpp
default_constructor.cpp(17): warning #854: const variable a2 requires an
initializer -- class A2 has no explicitly declared default constructor
On Fri, 2005-02-18 at 13:28 -0600, Pat Haugen wrote:
Is there a reason REG_POINTER isn't propagated to the target register for
rtl insns of the form reg_x = regP_y + reg_z, where regP_y is a reg
marked as REG_POINTER? It seems the attribute is only propagated when we
have reg_x = regP_y
The DWARF Workgroup of the Free Standards Group (http://www.freestandards.org)
is pleased to announce the creation of a website for the DWARF debugging format
(http://dwarf.freestandards.org).
The DWARF debugging format is used by compilers and debuggers to convey
a description of the source code
Dylan Cuthbert wrote:
Is there someway I can flag the moves to say that is moving the v16sf
whole so it doesn't need to be initialised and hence avoid the warning?
See emit_no_conflict_block in optabs.c.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
[EMAIL PROTECTED] (Dale Johannesen) wrote on 21.02.05 in [EMAIL PROTECTED]:
Simple Objective C programs such as
#include objc/Object.h
void foo(void) {
Object *o;
[o++ free];
}
result in calling objc_msgSend indirectly through a pointer, instead
of directly as they did in 3.3.
Brilliant!
This got rid of the warnings, *and* got rid of the spurious move I was
getting. Thanks for the advice!
The problem with the spurious move was with the move from memory to the
v16sf register, because it was doing it with subregs it thought it still had
to preserve the previous
On Feb 21, 2005, at 10:59 PM, Kai Henningsen wrote:
[EMAIL PROTECTED] (Dale Johannesen) wrote on 21.02.05 in
[EMAIL PROTECTED]:
Simple Objective C programs such as
#include objc/Object.h
void foo(void) {
Object *o;
[o++ free];
}
result in calling objc_msgSend indirectly through a pointer,
Dylan Cuthbert wrote:
For the last parameter (equiv) of emit_no_conflict_block I am putting in
gen_rtx_SET ( V16SFmode, op0, op1 ), does this seem correct to you?
This is supposed to be the value of op0 after the no conflict block. So
it should just be op1.
--
Jim Wilson, GNU Tools Support,
Ah, ok, sorry about that, I read it as being the equivalent of the whole
operation.
I'll throw op1 in there, thanks again.
Dylan
James E Wilson [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Dylan Cuthbert wrote:
For the last parameter (equiv) of emit_no_conflict_block I am putting
Hi,
I am sure this bug has been reported before, but I am
not able to track it down in bugzilla. Someone kindly
refer me to the relevant bug report.
-- Bug in -O2 level with following code construct,
#define FTYPE float
FTYPE fir_basic (FTYPE input, int ntaps, FTYPE h[],
FTYPE z[]);
for (ii
I successfully built gcc-3.4.3 on SuSE Linux 9.2:
Here is the relevant information:
config.guess:
i686-pc-linux-gnu
gcc -v:
Reading specs from /opt/gcc-3.4.3/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --prefix=/opt/gcc-3.4.3
Thread model: posix
gcc version
Would it be OK, if this warnings are disabled for system headers ?
Thanks,
-
Devang
--- c-decl.c.~1~2005-01-06 19:26:09.0 -0800
+++ c-decl.c2005-02-15 11:59:48.0 -0800
@@ -1169,11 +1169,15 @@ diagnose_mismatched_decls (tree newdecl,
*oldtypep = oldtype =
On Tue, 22 Feb 2005, Devang Patel wrote:
Would it be OK, if this warnings are disabled for system headers ?
What is the built-in function involved and what (and why) is the different
system header type? Is this a case where a system reuses a nonstandard
name GCC has built in for an entirely
HI All,
I am new to X-Windows programming and can't get my program to
work. The program compiles successfully but there is problem in the
linking part. Do we do it like other C Prog ie, gcc -o myprog myprog.c
or do we have to use some other options.
Can someone guide me with a demo
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-02-22
08:02 ---
I *hate* to be doing this, but once again, this is fixed
on current mainline.
--
What|Removed |Added
In gcc4 only djgpp and cygming targets have
HANDLE_PRAGMA_PACK_PUSH_POP defined, the gcc4 documentation does not say
these #pragmas are target spesific, there is also no configure option to
enable this for other (e.g *-elf) targets.
--
Summary: HANDLE_PRAGMA_PACK_PUSH_POP
Hi,
save the following dummy program as gfcbug24.F90 (capital F):
program gfcbug24_F90
print *, Hey, it works now!
end program gfcbug24_F90
Then compile with:
% gfortran -C gfcbug24.F90
I get:
gfortran: GCC does not support -C or -CC without -E
Preprocessing normally works, but the -C
--- Additional Comments From anlauf at hep dot tu-darmstadt dot de
2005-02-22 08:48 ---
It looks very much like a driver problem, because the option -std=f95
instead of -C makes it even funnier:
cc1: warning: command line option -std=f95 is valid for F95 but not for C
But at least it
--- Additional Comments From anlauf at hep dot tu-darmstadt dot de
2005-02-22 08:54 ---
While I'm at it: the option -pipe also has a funny side effect:
f951: error: unrecognized command line option -95
And it produces a file -95 in the current directory that contains
the preprocessed
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-22
09:31 ---
Arno, any objection to moving them to norun.lst until after the issue is
resolved?
--
What|Removed |Added
--- Additional Comments From charlet at adacore dot com 2005-02-22 09:46
---
Subject: Re: ACATS cxa3004 cxb3006 fail at compile time ambiguous expression
Arno, any objection to moving them to norun.lst until after the issue is
resolved?
Actually I do not see the interest, since
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-22
09:47 ---
Hum, this one is really tricky. It's indeed an aliasing problem and I think
your reduced, reduced testcase demonstrates that there might be a hole in the
flow-insensitive alias analysis for pointers that
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-22
09:51 ---
Actually I do not see the interest, since the test is wrong.
I would simply cvs remove it.
I was under the impression that moving it to the norun.lst was the canonical
procedure when waiting for an
--- Additional Comments From charlet at adacore dot com 2005-02-22 09:55
---
Subject: Re: ACATS cxa3004 cxb3006 fail at compile time ambiguous expression
I was under the impression that moving it to the norun.lst was the canonical
procedure when waiting for an ACAA's response (did
--- Additional Comments From jakub at gcc dot gnu dot org 2005-02-22 10:25
---
Looks like a strength reduction bug.
Smaller self-contained testcase:
extern void abort (void);
typedef struct { int a; char b[3]; } S;
S c = { 2, aa }, d = { 2, aa };
void *
bar (const void *x, int y, int
--- Additional Comments From gniccolai at yahoo dot com 2005-02-22 10:27
---
You say a hypothetical multithreaded C++ should state this as the semantics
for
static locals, and I don't disagree with you, provided we are not talking
about
one based on POSIX threads. POSIX
--- Additional Comments From dieterbmeier at yahoo dot com 2005-02-22
10:32 ---
Andy's patch works great for HEAD, but I get
patching file avr.md
Hunk #1 FAILED at 344.
1 out of 1 hunk FAILED -- saving rejects to file avr.md.rej
when patching 3_4 branch.
--
--- Additional Comments From coudert at clipper dot ens dot fr 2005-02-22
10:33 ---
This is really weird:
$ cat a.f90
integer :: i
open (unit=20, file='data')
read(20,*) i
write(*,*) ' foo '
backspace(20)
read(20,*) i
end
$ cat data
1
2
3
$ gfortran a.f90 ./a.out
foo
*
end
$ gfortran -std=f95 a.f90 ./a.out
hello world
$ ifort a.f90 ./a.out
hello world
$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/tmp/gfortran-20050222/irun
--enable-languages=c,f95
Thread model: posix
gcc version
--- Additional Comments From dieterbmeier at yahoo dot com 2005-02-22
10:41 ---
Try patch attached to PR 18251. Good chance it will fix.
I still fails. (18251.patch.bz2 applied)
If not, pass me the source for a llok at.
Its already attached to this pr.
--- Additional Comments From uros at kss-loka dot si 2005-02-22 10:49
---
The problem in mainline is that 'tree type' of RECORD_TYPE enters fold_convert()
and triggers gcc_unreachable() in line 2003.
However Borland C++ exits with error: Call to function 'g' with no prototype.
on line
--- Additional Comments From pcarlini at suse dot de 2005-02-22 11:24
---
Richard, your fix is causing the regression of libstdc++/14026, can you please
have a look again to both?!? Thanks in advance...
--
What|Removed |Added
--- Additional Comments From jakub at gcc dot gnu dot org 2005-02-22 11:32
---
I think the bug is in loop_giv_rescan assumes validate_change in:
if (v-giv_type == DEST_ADDR)
/* Store reduced reg as the address in the memref where we found
this giv. */
With LAST_UPDATED: Mon Feb 21 15:56:07 UTC 2005, these tests succeeded.
With LAST_UPDATED: Tue Feb 22 00:07:00 UTC 2005 they fail:
Running
/home/hp/cvs_areas/combined/combined/gcc/testsuite/gcc.c-torture/execute/execute.exp
...
FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O1
FAIL:
--- Additional Comments From hp at gcc dot gnu dot org 2005-02-22 12:02
---
Huh, forgot to fill in host and target...
This test used to be xfailed, btw, but should now pass due to generic
fabs optimizations.
--
What|Removed |Added
Hello,
this is my code:
templatetypename T void foo() {
unsigned char s[] = ;
(void)s;
}
int main() {
/* removing either of the calls below makes the error disappear */
fooint();
foochar();
}
Compiling this program with g++[0] results in
try.cc: In function `void foo()
--- Additional Comments From andrewhutchinson at cox dot net 2005-02-22
12:31 ---
Subject: Re: unable to find a register to spill in class
`POINTER_REGS'
if you can wait 12hrs I'll create 3.4 version.
Alternatively cut n paste from a 4.0 avr.md
the change is local to one area.
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-02-22
12:56 ---
Confirmed.
This fails since gcc 2.95.3 or earlier.
--
What|Removed |Added
making a simple standalone/embedable editor I fall on a strange behavior.
code crashing the compiler with -03 level of optimisation, no complaints with -
O2
It's still very bugged, but it's a pre_alpha code
this is quite a small programm
(less than 4000 words in the .i file)
should be good for
--- Additional Comments From stephane dot bosio at vendeeconcept dot com
2005-02-22 13:07 ---
Created an attachment (id=8254)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8254action=view)
pre processed sources
this source file crashes with -03
--
--
What|Removed |Added
Component|c |middle-end
Summary|crashing the compiler with -|crashing the compiler with -
|03
--- Additional Comments From ericw at evcohs dot com 2005-02-22 13:19
---
Subject: Re: unable to find a register to spill in class
`POINTER_REGS'
dieterbmeier at yahoo dot com wrote:
--- Additional Comments From dieterbmeier at yahoo dot com 2005-02-22
10:32 ---
Andy's
Problem:
If a struct has a member which is a multi-dimensionnal array of class with an
explicit assignment operator, a trivial implicit operator is generated instead
of a non trivial one.
Code:
//
#include stdio.h
class Manager
{
public:
Manager (void);
Manager (const Manager );
--- Additional Comments From falk at debian dot org 2005-02-22 13:40
---
Confirmed, this is an ICE on invalid code. This is a test case for 4.0 (but
for some reason it doesn't work for 3.4):
struct ED_Ligne { int x; };
void dealloue_ligne();
void dealloue_buff(struct ED_Ligne
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
13:45 ---
Basically this is the same as PR 16876.
*** This bug has been marked as a duplicate of 16876 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
13:45 ---
*** Bug 20141 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
13:48 ---
Caused by:
2005-02-21 Kazu Hirata [EMAIL PROTECTED]
* tree-cfg.c (fold_cond_expr_cond): New.
(make_edges): Call fold_cond_expr_cond.
(find_taken_edge): Accept nothing but
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
13:52 ---
This was fixed by the patch which fixed PR 18663 so closing as a dup.
*** This bug has been marked as a duplicate of 18663 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
13:52 ---
*** Bug 18705 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18663
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
14:00 ---
(In reply to comment #17)
Richard, your fix is causing the regression of libstdc++/14026, can you please
have a look again to both?!? Thanks in advance...
PR 20091 was opened for this regression.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
14:06 ---
-C is not valid option at all for bound checking. -fbounds-check is the
correct option.
*** This bug has been marked as a duplicate of 18452 ***
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
14:06 ---
*** Bug 20138 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From jakub at gcc dot gnu dot org 2005-02-22 14:15
---
This is a DOM bug.
Comment above lookup_avail_expr says:
NOTE: This function assumes that STMT is a MODIFY_EXPR node that
contains no CALL_EXPR on its RHS and makes no volatile nor
aliased
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
14:16 ---
Huh: For compatibility with Win32
Pragmas are C front-end and not preprocessor bugs.
Confirmed.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
14:19 ---
Note this was cause by:
2005-01-26 Diego Novillo [EMAIL PROTECTED]
PR tree-optimization/19633
* tree-ssa-alias.c (ptr_is_dereferenced_by): Also handle
CALL_EXPRs.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
14:21 ---
Also note that DOM is doing the correct thing as the DOM does not know that
func_other could
change the value of func_pure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20115
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
14:44 ---
If we changed the function in comment #0 like so:
int f(int a)
{
a=(a|1)^1;
return a;
}
Fold should do this simplification.
And likewise for comment #1 (which is just general case):
int f(int a,int b)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
14:56 ---
For pure calls the code would need to invalidate
all recorded pure calls whenever a stmt might modify global state.
Yes this was done with GLOBAL_VAR before Diego's patch but now it is not done
with
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org |org
Status|NEW
--
What|Removed |Added
CC||tromey at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20104
--- Additional Comments From aph at gcc dot gnu dot org 2005-02-22 15:05
---
The failure is here:
package org.eclipse.jdt.internal.compiler.impl;
public class CompilerOptions ...
{
void updateSeverity(long irritant, Object severityString) {
if
--- Additional Comments From overholt at redhat dot com 2005-02-22 15:09
---
(In reply to comment #3)
1. Why was aload_3 generated? Which compiler genrated it?
snip
overholt, please let me know how this jar file was generated.
This jar file was generated by ecj.
--
Although I don't believe this is a regression, I do believe it's a bug which
should
ideally be remedied as soon as reasonably possible; as it seems unreasonable to
require any target to support data types more than twice as large as it's
pointer
type, or required by the language standards; so
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
15:19 ---
Dwarf2 unwinding requires long long.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20143
--- Additional Comments From aph at gcc dot gnu dot org 2005-02-22 15:23
---
Ok, so the file was generated by ecj, but was ecj precompiled or interpreted?
What VM was ecj running on?
Does ecj generate this same bogus file for
org.eclipse.jdt.internal.compiler.impl.CompilerOptions
--- Additional Comments From overholt at redhat dot com 2005-02-22 15:25
---
(In reply to comment #5)
Ok, so the file was generated by ecj, but was ecj precompiled or interpreted?
ecj was running interpreted at the time
What VM was ecj running on?
gij
Does ecj generate this
I think that -r8 is supposed work, but with gfortran 02-20 on the macintosh -
[dranta:~/tests/gfortran] dir% gfortran -i8 -r8 -o test test.f
gfortran: unrecognized option '-r8'
[dranta:~/tests/gfortran] dir% cat test.f
program main
stop
end
--
Summary: gfortran:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
15:55 ---
*** This bug has been marked as a duplicate of 13464 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
15:55 ---
*** Bug 20144 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13464
When an include dir is given to gcc with the -isystem option the
warning: 'class CppUnit::ConcretTestFixtureFactoryErrorValueTest' has virtual
functions but non-virtual destructor is not suppressed as other warnings are.
This warning is new, with gcc34 or snapshot 20050116 this warning does not
--- Additional Comments From aph at gcc dot gnu dot org 2005-02-22 16:04
---
Forget that, second arg is a long. My mistake.
The compiled code is OK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20104
It does not like this construction -
[dranta:~/tests/gfortran] dir% gfortran -o common common.f90
common.f90:0: internal compiler error: backend decl for module variable pc
already exists
Please submit a full bug report,
with preprocessed source if appropriate.
See
The C++ frontend issues an ICE when compiling the following invalid
code snippet:
void foo()
{
({x;});
}
bug.cc: In function 'void foo()':
bug.cc:3: error: 'x' was not declared in this scope
bug.cc:3: internal compiler error: tree check: expected class
--- Additional Comments From law at redhat dot com 2005-02-22 16:58 ---
Subject: Re: paradoxical subreg problem
On Mon, 2005-02-21 at 17:34 +, joseph at codesourcery dot com wrote:
--- Additional Comments From joseph at codesourcery dot com 2005-02-21
17:34 ---
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu
|dot org |
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
17:02 ---
Confirmed, only happens when checking is turned on.
--
What|Removed |Added
--- Additional Comments From jakub at gcc dot gnu dot org 2005-02-22 17:03
---
That's not a problem. The SUBREG is SUBREG_PROMOTED_VAR_P and
SUBREG_PROMOTED_UNSIGNED_P, which is a promise that the upper 32 bits are all 0.
The problem is that when using the KR style function
The diagnostic for the following invalid code snippet is hosed on mainline
(this only affects the C++ frontend):
==
void foo()
{
if (({int c[2];})) ;
}
==
bug.cc: In function 'void foo()':
bug.cc:3: error: could not convert '{#'decl_expr' not
I don't know if you want reports when these are hit or not -
[dranta:~/tests/gfortran] dir% gfortran -o transfer transfer.f90
transfer.f90: In function 'MAIN__':
transfer.f90:5: fatal error: gfc_todo: Not Implemented: Scalarization of
non-elemental intrinsic: __transfer1
compilation terminated.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
17:06 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
17:13 ---
*** Bug 20149 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
17:13 ---
*** This bug has been marked as a duplicate of 17298 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
17:15 ---
Confirmed, related to PR 17917.
--
What|Removed |Added
BugsThisDependsOn|
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-02-22
17:16 ---
The following code snippet shows a similar problem:
void foo()
{
if (({})) ;
}
bug.cc: In function 'void foo()':
bug.cc:3: error: could not convert
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
17:24 ---
I cannot reproduce this with 4.0 (20050222).
tin:~/src/gnu/gcctest/pr20145cat include/t.h
class t
{
virtual void f();
};
tin:~/src/gnu/gcctest/pr20145cat t.cc
#include t.h
class t1
{
virtual void f
=i686-pc-linux-gnu --enable-__cxa_atexit
--enable-languages=c++,objc,java,f95 --prefix=/
home/gates/pinskia/linux --enable-threads=posix --enable-shared
Thread model: posix
gcc version 4.0.0 20050222 (experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20145
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
17:26 ---
Can you include the preprocessed source (the preprocessed source will have the
thing if a header is a
system header or not)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20145
--
What|Removed |Added
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20025
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
17:53 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-02-22
17:56 ---
Here's a slightly reduced testcase.
===
#includestdio.h
struct A
{
A() : i() {}
A (const A);
~A()
{
printf (Destructor: i = %d\n,
Regression from 3.2/3.3, calling allocate with n==0 leads to a call of new.
Fixup all ext allocators, port to 3.4
--
Summary: allocate(0) consistency checks
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-22
18:14 ---
Subject: Bug 20056
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-22 18:14:04
Modified files:
libjava: ChangeLog verify.cc
Log message:
1 - 100 of 169 matches
Mail list logo
