templateint sz
struct xxx_t {
char foo[sz];
char bar[0];
};
int main(int argc, char *argv[])
{
xxx_t0 xyz;
}
gcc -Wall foo.cpp -o foo
foo.cpp: In instantiation of xxx_t0:
foo.cpp:9: instantiated from here
foo.cpp:3: error: creating array with size zero (0)
foo.cpp:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
06:03 ---
(In reply to comment #7)
And I found another latent bug which makes it impossible to bootstrap GCC :(
Oh, I found a simple patch which fixes that, bootstrapping the fix with the fix
for this bug.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
06:11 ---
*** This bug has been marked as a duplicate of 19989 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
06:11 ---
*** Bug 22243 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
Please have a look at the following source, variable a is a two-dimension
array (5 X 5):
program array2
integer a(5, 5)
do i = 1, 5
do j = 1, 5
a(i, j) = i * j
write (*, *) a(i, j)
end do
end do
end program
After using
--- Additional Comments From woodzltc at sources dot redhat dot com
2005-06-30 06:39 ---
This is Feng's comment:
http://gcc.gnu.org/ml/fortran/2005-06/msg00479.html
Just FYI. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22244
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-30
08:29 ---
It's probably easiest to have xtoa() and friends extract
the integer for themselves.
If you do this, don't forget to increase the size of buffer[]
so it can hold largest_integer_kind*8+1 characters for
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-30
08:34 ---
Do we really want to fix this? It doesn't really
work with ifort, and it is a dubious feature, too.
I'm in favor of marking this WONTFIX.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20406
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-30
08:42 ---
Confirmed.
--
What|Removed |Added
Keywords|
--- Additional Comments From woodzltc at sources dot redhat dot com
2005-06-30 08:48 ---
For array, ifc will output the following debuginfo:
27e: Abbrev Number: 4 (DW_TAG_variable) TAG for variable array
DW_AT_decl_line : 2
DW_AT_decl_column : 42
--- Additional Comments From aph at redhat dot com 2005-06-30 08:58 ---
Ah, thanks. It was a causalty of a hard disk crash I had.
I'll do it once 4.0 is thawed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21428
--- Additional Comments From joseph at codesourcery dot com 2005-06-30
09:27 ---
Subject: Re: [4.0/4.1 Regression] struct copy
inlining generates overlapping memcpy
On Thu, 30 Jun 2005, pinskia at gcc dot gnu dot org wrote:
I think this is a latent bug as even 3.4 produces calls to
Building a cross toolchain gcc4.0.0-glibc2.2.5 with crosstool 0.35 produces the
following ICE.
sh4-linux-gcc dcigettext.c -c -O -Wall -Winline -Wstrict-prototypes
-Wwrite-strings -fno-unit-at-a-time -m4 -ml -I../include -I.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-30
11:07 ---
Subject: Bug 21967
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-06-30 11:06:56
Modified files:
gcc: tree-ssa-live.c ChangeLog
Log
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-06-30
11:13 ---
I don't think it is useful to fix this. The proper way of handling this kind
of loops is to just remove them, not to unroll them completely.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21449
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-30
11:17 ---
Not fixed by the patch for PR22234 :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
--- Additional Comments From irar at il dot ibm dot com 2005-06-30 11:38
---
Submitted a patch that fixes this: http://gcc.gnu.org/ml/gcc-patches/2005-
06/msg02228.html
--
What|Removed |Added
On i686-pc-mingw32, a simple compilation that worked before
(--enable-languages=c,f95) gives the following error (with Danny Smith's patch
from http://gcc.gnu.org/ml/gcc-patches/2005-05/msg9.html, because mingw32
adn cygwin bootstraps are broken):
gcc -I/home/FX/local/include
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
12:11 ---
*** This bug has been marked as a duplicate of 21623 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
12:11 ---
*** Bug 22246 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
12:18 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
12:20 ---
Confirmed, Paul B. said he was going to do this (IIRC).
--
What|Removed |Added
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-06-30
12:30 ---
The is_gimple_variable segfault seems as a duplicate of PR 21963 to me; could
someone please check whether the patch for that PR fixes the problem (I cannot
access x86_64 machine just now)?
--
hi!
I have a problem with multiply assigment at
i386-portbld-freebsd5.4
gcc version 4.0.1 20050609 (prerelease) [FreeBSD]
and the same problem in DJGPP with gcc 4.0.0
I've compiled my cpp file with this command line:
g++40 new.cpp
---new.cpp
#includecstdio
#define swap(a,b) a^=b^=a^=b
--
What|Removed |Added
CC||dberlin at gcc dot gnu dot
||org
GCC host
--
What|Removed |Added
Summary|tree-ssa-structalias.c: |[4.1 Regression] tree-ssa-
|`uint' undeclared |structalias.c: `uint'
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
13:11 ---
Fixed.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
algorithmus at gmail dot com [EMAIL PROTECTED] writes:
| ---new.cpp
| #includecstdio
|
| #define swap(a,b) a^=b^=a^=b
You're modifying objects more than once without intervening sequence
points. All bets are off. There is a standard utility std::swap() from
utility that works all the time.
--- Additional Comments From gdr at integrable-solutions dot net
2005-06-30 13:19 ---
Subject: Re: New: Incorrect work with multiple assigment.
algorithmus at gmail dot com [EMAIL PROTECTED] writes:
| ---new.cpp
| #includecstdio
|
| #define swap(a,b) a^=b^=a^=b
You're modifying
I don't believe the standard requires the following to be rejected, but as a QOI
issue I believe it should be. The debatable point is whether you believe the
composite of the first two is specified by a function definition; if you do then
you must reject. GCC rejects it if the order of the first
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
13:26 ---
There is no sequence points between the assignments of a[i] so the loading of
a[i] can be evaluated in
any order.
You want to define swap as:
#define swap(a,b) do{ a^=b;b^=a;a^=b;}while(0)
This is a
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
13:26 ---
*** Bug 22248 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-30
13:29 ---
g77 gets this right:
$ g77 -g array2.f
$ gdb ./a.out
GNU gdb Red Hat Linux (6.3.0.0-0.30.1rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License,
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
13:31 ---
Adding gcc.dg/c9[09]-const-expr-3.c to the summary so I don't get confused
between this bug and
PR 456.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
13:32 ---
Adding gcc.dg/c90-const-expr-1 to the summary so I don't confussed between
this bug and PR
5675.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
13:32 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
This seems to be -O2 related as compiling in debug mode doesn't produce this
ICE.
Compiler output from -v -save-temps:
sh4-linux-g++ -v -save-temps -c -pipe -O2 -Wall -W -D_REENTRANT -fPIC
-DQT_SHARED -DQT_BUILD_GUI_LIB -DQT_OPENSOURCE -DQT_NO_CAST_TO_ASCII
-DQT_MOC_COMPAT
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
13:34 ---
Make sure that you attach the preprocessed source.
--
What|Removed |Added
--- Additional Comments From sieb at sscd dot de 2005-06-30 13:35 ---
Created an attachment (id=9178)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9178action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22250
--- Additional Comments From algorithmus at gmail dot com 2005-06-30 13:35
---
no. I guess there is a problem.
just try this progam:
#includecstdio
#define swap(a,b) (a^=(b^=(a^=b)))
const int N = 2;
int a[N];
int main()
{
for(int i=0;iN;i++) a[i] = i;
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
13:37 ---
Parentheses are not seqeunce points. The comma operator is though.
*** This bug has been marked as a duplicate of 11751 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
13:37 ---
*** Bug 22248 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-06-30
13:58 ---
tree-ssa-structalias has had that uint since inception.
Kazu added it as part of VEC'ification prior to submission.
I believe you should be able to do s/uint/unsigned/.
If this works, please submit a
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
14:23 ---
The code is invalid, see PR 21975 which this is a dup of.
*** This bug has been marked as a duplicate of 21975 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
14:23 ---
*** Bug 22245 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
14:31 ---
Confirmed, related to PR 15663.
--
What|Removed |Added
BugsThisDependsOn|
This is similar to bug 21280, but it is _not_ fixed by the patches therein.
In fact it still happens with current 4.0 branch as of 2005-06-30.
Compile these files:
% cat a.h
#include vector
#pragma interface
struct A {
std::vectorchar vc;
};
% cat use.cc
#include a.h
A a;
int
--
What|Removed |Added
Keywords||diagnostic
Summary|pragma |[4.0/4.1 Regression] pragma
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-06-30 15:00
---
Testing a patch for bugs 22013 and 22098.
--
What|Removed |Added
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-06-30 15:00
---
Testing a patch for bugs 22013 and 22098.
--
What|Removed |Added
--- Additional Comments From matz at suse dot de 2005-06-30 15:01 ---
Andrew: that's not a diagnostic issue. While the diagnostic (the warning)
indeed is wrong and misleading (and probably points to the underlying cause
of this issue), the actual error I'm complaining about is
the
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
15:10 ---
(In reply to comment #1)
Yes which is why I did not confirm it yet because I did not look at fully. I
just added the diagnostic
keyword because it is still a wrong warning. I am adding wrong-code also.
-fnon-call-exceptions
-fdollars-in-identifiers -fno-common -o natWindow.s
GNU C++ version 4.1.0 20050630 (experimental) (powerpc-apple-darwin8.1.0)
compiled by GNU C version 4.1.0 20050630 (experimental).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler
--
What|Removed |Added
Component|libgcj |middle-end
Keywords||ice-on-valid-code
--- Additional Comments From andreast at gcc dot gnu dot org 2005-06-30
15:19 ---
Created an attachment (id=9179)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9179action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22253
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
15:21 ---
With checking enabled I get:
/Volumes/export/gcc/gcc-cvs/gcc/libjava/gnu/gcj/xlib/natWindow.cc: In member
function 'virtual
void gnu::gcj::xlib::Window::setWMProtocols(JArrayjint*)':
--- Additional Comments From matz at suse dot de 2005-06-30 15:23 ---
Ah, I see. Note that you must compile the reduced testcase (thanks for
that) with -O0, or with -fno-inline, otherwise the A::A ctor will be inlined
in use.cc (making the warning about the non-availability of it even
Given a simple testcase
/* Two int arrays testcase for ipaa. */
#define N 11
void f ();
void g (int* g1, int* g2);
main ()
{
f();
return;
}
void f ()
{
int a[N];
int b[N];
g(a,b);
return;
}
void g (int* g1, int* g2)
{
int i;
for (i=0; i N; i++)
g1[i] = g2[i];
}
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-06-30
15:33 ---
By These formals i mean g1 and g2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22254
--- Additional Comments From pcarlini at suse dot de 2005-06-30 15:39
---
By These formals i mean g1 and g2
Thanks for the clarification: I clearly remember someone at GCCSummit puzzled
by the spelling checker marking formal as error ;)
--
GCC Version: 3.4.2
OS: Solaris 8
GCC build: ../gcc-3.4.2/configure --enable-languages=c,c++,ada --disable-
shared --srcdir=/tools/gcc-3.4.2/gcc-3.4.2
The following code will cause a use_error to be raised =
with Direct_IO,
Text_IO;
procedure testit is
type Item is
record
--- Additional Comments From charlet at gcc dot gnu dot org 2005-06-30
15:49 ---
Nothing critical about this bug, so changing severity/priority.
Arno
--
What|Removed |Added
--- Additional Comments From charlet at gcc dot gnu dot org 2005-06-30
15:51 ---
There is no bug showned here.
It looks like a setup/procedural problem.
I'd suggest asking for advice on e.g. gcc-help list.
Arno
--
What|Removed |Added
--- Additional Comments From brianstensrude at hotmail dot com 2005-06-30
15:58 ---
(In reply to comment #1)
Nothing critical about this bug, so changing severity/priority.
Arno
(In reply to comment #1)
We have ported over 1200 files from Verdix to the GCC compiler and have a few
--- Additional Comments From charlet at gcc dot gnu dot org 2005-06-30
16:02 ---
This is a place where you can report bugs to volunteers, so it is
inapropriate to make this kind of request nor expect guarantees as
to when bugs should be fixed.
If you need guarantees on fixes, I'd
struct node { int* operator int*(); };
gets you:
foo.cc:1: error: operator `int*' declared to return `int'
BTW, a better diagnostic would be something like:
error: operator `int*' should not declare a return type
--
Summary: diagnostic shows wrong type
Product: gcc
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-30
16:41 ---
Ack.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From bangerth at dealii dot org 2005-06-30 17:14
---
Confirmed. Also happens with 3.3.x.
W.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-06-30 17:15
---
FWIW, here's the icc output:
tmp/g icc -Xc -ansi -c x.cc
x.cc(1): error: return type may not be specified on a conversion function
struct node { int* operator int*(); };
^
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
17:22 ---
Confirmed, reduced testcase:
struct allocator { ~allocator() {} };
struct _Vector_base
{
struct _Vector_impl
{
int* _M_start;
int* _M_finish;
_Vector_impl()
: _M_start(0), _M_finish(0)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
17:24 ---
I should note that if we fix PR 21636, this becomes a latent bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22253
I found this while reducing PR 22253.
The following invalid code ICEs:
struct _Vector_impl
{
_Vector_impl
: _M_start(0), _M_finish(0){}
};
--
Summary: ICE on invalid code, forgot parentheses for constructor
Product: gcc
Version: 4.0.1
Status:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
17:31 ---
Oh, not a regression either.
--
What|Removed |Added
Known to fail|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
17:34 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg02238.html.
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-30
17:40 ---
Looks like a bug. Honza?
--
What|Removed |Added
CC|
--
What|Removed |Added
Severity|normal |enhancement
Keywords||diagnostic
Known to fail|
--- Additional Comments From giovannibajo at libero dot it 2005-06-30
17:58 ---
Also you could simply use std::swap as Gaby suggested.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22248
--- Additional Comments From giovannibajo at libero dot it 2005-06-30
18:08 ---
I wonder why it's not caught by a tree verifier then.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22253
--- Additional Comments From giovannibajo at libero dot it 2005-06-30
18:09 ---
It does.
--
What|Removed |Added
BugsThisDependsOn||21963
--- Additional Comments From algorithmus at gmail dot com 2005-06-30 18:21
---
thanks for your suggestions. I usually use STL. But I held training contest for
Ukrainian team before International Olympiad in Informatics and one guy's used
this swap macros that doesn't work at my
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
18:21 ---
Confirmed, changing uint to unsigned was able to bootstrap on powerpc-darwin
just fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22247
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
18:22 ---
Confirmed, changing uint to unsigned was able to bootstrap on powerpc-darwin
just fine.
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2005-06-30
18:27 ---
It's there: -Wsequence-point, which is also enabled by -Wall.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22248
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
18:31 ---
(In reply to comment #7)
It's there: -Wsequence-point, which is also enabled by -Wall.
But it will not warn about this testcase as we have array[index] but that is
filed as PR 16202.
--
An sh-elf build fails with:
/mnt/scratch/nightly/2005-06-28/sh-elf/./gcc/xgcc
-B/mnt/scratch/nightly/2005-06-28/sh-elf/./gcc/ -nostdinc
-B/mnt/scratch/nightly/2005-06-28/sh-elf/sh-elf/newlib/ -isystem
/mnt/scratch/nightly/2005-06-28/sh-elf/sh-elf/newlib/targ-include -isystem
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-30
19:13 ---
Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg02249.html.
This might
improve code gen in SPEC but since I have not tried, I don't know but I know
that Richard Earnshaw was
asking
--
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
||patches/2005-
|
Building gcc on i686-pc-mingw32 fails with:
/home/FX/ibin/./gcc/xgcc -B/home/FX/ibin/./gcc/ -B/mingw/i686-pc-mingw32/bin/
-B/mingw/i686-pc-mingw32/lib/ -isystem /mingw/i686-pc-mingw32/include -isystem
/mingw/i686-pc-mingw32/sys-include -O2 -I../../gcc/gcc/../winsup/w32api/include
-DIN_GCC-W
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-30
20:16 ---
Looks related to bonzini's 2005-06-16 patch
(http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00667.html). Adding him to Cc list.
--
What|Removed |Added
--
What|Removed |Added
Summary|spawnv cannot execute gcc/as|[4.1 Regression] spawnv
||cannot execute gcc/as
Target
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-30
20:43 ---
Subject: Bug 22247
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-06-30 20:43:46
Modified files:
gcc: ChangeLog tree-ssa-structalias.c
When compiling PIC code for the this-adjusting thunk for a method of a class
with two or more base classes, the sparc_output_mi_thunk() function fails to
preserve the pic register itself (%l7) when using load_pic_register() to find
the address of the thunk's target. If the thunk is invoked from a
--
What|Removed |Added
Component|c++ |target
Keywords||wrong-code
--
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
||org
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-30
20:53 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From gdr at integrable-solutions dot net
2005-06-30 20:56 ---
Subject: Re: diagnostic shows wrong type
bangerth at dealii dot org [EMAIL PROTECTED] writes:
| Confirmed. Also happens with 3.3.x.
I think this happens because when the C++ front-end finds that a
--- Additional Comments From gdr at integrable-solutions dot net
2005-06-30 20:57 ---
Subject: Re: Incorrect work with multiple assigment.
algorithmus at gmail dot com [EMAIL PROTECTED] writes:
| I guess, it'll be useful if the developers add some warning message
| for
--- Additional Comments From scp at predict dot com 2005-06-30 21:00
---
This fix has not made it to the gcc_4_0 branch, and the problem still exists in
gcc4.0.0. It is trivially recreated using the same test code:
gcc -v -o cv cv.cpp -lstdc++
Reading specs from
--- Additional Comments From laurent at guerby dot net 2005-06-30 21:04
---
For the record, after twenty hours of compilation on an Athlon 64 3000+
(x86_64-linux), a build with --enable-checking=all,gcac,fold,rtl detects
something wrong in fold. I'm attaching the .i.
LAST_UPDATED Wed
1 - 100 of 153 matches
Mail list logo
