--- Comment #10 from jvdelisle at gcc dot gnu dot org 2006-01-02 08:13
---
Submitted a new patch for approval that is a final fix for this bug.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
GCC target triplet|4.1 |
Target Milestone|--- |4.1.0
http://gcc
--- Comment #3 from paolo at gcc dot gnu dot org 2006-01-02 09:57 ---
Subject: Bug 24645
Author: paolo
Date: Mon Jan 2 09:57:49 2006
New Revision: 109236
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109236
Log:
2006-01-02 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #4 from pcarlini at suse dot de 2006-01-02 10:00 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
GNU C++ version 4.1.0 20051221 (prerelease) ICEs on the attached testcase with
> g++ nvl141082.min.i
/suse/rguenther/export/nvl141082.min.i: In function SI_RETURN
SiGetPeerName(SI_SOCK*, SAP_RAW*, SAP_USHORT*):
/suse/rguenther/export/nvl141082.min.i:48: internal compiler error: in
make_decl_rtl,
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-01-02 10:38 ---
Created an attachment (id=10575)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10575&action=view)
reduced testcase
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25632
--- Comment #23 from reichelt at gcc dot gnu dot org 2006-01-02 12:09
---
The testcase causes an ICE in gcc 3.4.x and 4.0.x.
It works on mainline and the 4.1 branch. But that behavior of the C++ frontend
deviates from the C frontend where the code is rejected.
So this should be fixed on
The following code snippet causes an ICE since GCC 3.4.0:
==
struct A {};
struct B : A
{
B() : A {}
};
==
bug.cc: In constructor 'B::B()':
bug.cc:5: error: expected `(' before '{' token
bug.cc:5: internal compiler error: in expand_aggr_
The following invalid code snippet is accepted since GCC 3.4.4:
=
template template struct A;
=
Might be related to PR 24314.
--
Summary: [3.4/4.0/4.1/4.2 regression] Multiple template parameter
The diagnostic for the following invalid code snippet got worse with
GCC 4.0.0:
=
struct A {};
A::operator int();
=
We now issue a duplicate message and some more bogus stuff:
bug.cc:3: error: no 'A::opera
I just downloaded and compiled gcc-4.2-20051231 with
./configure --prefix=/opt/gcc42
make
make install (root)
after setting LD_LIBRARY_PATH to /opt/gcc42/lib
$ /opt/gcc42/bin/gcc --version
gcc (GCC) 4.2.0 20051231 (experimental)
Copyright (C) 2005 Free Software Foundation, Inc.
This is fr
The following two invalid code snippets are accepted by the C++ frontend
(the members of A cannot be defined in B):
===
struct A { void foo(); };
struct B { friend void A::foo() {} };
===
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-01-02 13:53 ---
This seems to be fixed, I cannot reproduce with GNU F95 version 4.1.0 20051222.
So closing as dup of 24793.
*** This bug has been marked as a duplicate of 24793 ***
--
rguenth at gcc dot gnu dot org changed:
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-01-02 13:53
---
*** Bug 23202 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from jakub at gcc dot gnu dot org 2006-01-02 13:57 ---
This seems to be a reload bug, but Alan Modra's patch is correct.
In *.lreg we have:
(insn 577 78 11 2 (set (reg/f:DI 391)
(reg/f:DI 0 ap)) 5 {*movdi_internal} (nil)
(nil))
(insn 11 577 14 2 (set (reg/v/f:
The following invalid code snippet causes an ICE since GCC 4.0.0:
struct A { ~A(); };
struct B : A
{
template friend A::~A();
};
bug.cc:5: error: prototype for 'A::~A()' does not match any in class 'A'
bug.cc:1
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-01-02 13:58 ---
It's only ICEing with -pedantic. Looking at it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25183
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-01-02 14:29 ---
One possible fix would be to make
error.h:8: warning: ISO C restricts enumerator values to range of 'int'
an error instead of a warning in case of -pedantic (or always). Testing a
patch
to deal with TREE_OVERFLOW
With the _FORTIFY_SOURCE hackery we have the transposed args to memset
check which boils down to sth like
extern void foo(void);
extern char *pt;
extern void __warn_memset_zero_len (void);
typedef unsigned long size_t;
void e_malloc(size_t size)
{
if (size > 0)
foo ();
__builtin_constant_p
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-01-02 15:40 ---
Seems to happen with current 4.1 and mainline, too. But I'm wrong in that this
is not a regression. Seems this warning hack was introduced after our switch
to 4.1.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-01-02 16:27 ---
Patch posted.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
URL|
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-02 16:36 ---
Reduced testcase (even though it gives a different ICE, it is the same bug as
someone is forgetting to unshare_expr somewhere):
struct sockaddr_un {
char sun_path[1];
};
const unsigned SI_SUN_HEAD_LEN = (long)(((st
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.0.3 4.1.0 4.2.0
Known to work||4.0
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-02 16:44 ---
I cannot reproduce this on either powerpc-darwin or x86_64-linux-gnu.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-02 16:46 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-02 16:48 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-02 16:49 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-02 16:52 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
In this case:
class A
{
public:
int f() {return 2;}
};
class B : public A
{
public:
int f(int e) {return e;}
};
int main (void)
{
B test;
test.f();
}
I got an error while the A::f() method should be accessible without any
pr
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-02 16:54 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-02 17:02 ---
This is how C++ works.
You want to do one of the following to fix your code:
change the call to:
test.A::f();
or add in class B:
using A::f;
--
pinskia at gcc dot gnu dot org changed:
--- Comment #3 from kargl at gcc dot gnu dot org 2006-01-02 17:03 ---
I have a patch.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
CC|
Compiling gcc-4.1 core & g++, an SVN co of 2005.12.29 14h GMT on
SunOS x 5.8 Generic_117350-24 sun4u sparc SUNW,Sun-Fire-880
I get :
$HOME/Tools/binutils-2.16/bin/ld:libgcc/./libgcc.map: file format not
recognized; treating as linker script
$HOME/Tools/binutils-2.16/bin/ld:libgcc/./libgcc.ma
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-02 17:12 ---
Actually this is invalid and GCC is correct to do what it is doing. Quote from
the docs:
A return of 0 does not indicate that the value is not a constant, but merely
that GCC cannot prove it is a constant with the s
--- Comment #6 from wjaouad1 at netcourrier dot com 2006-01-02 17:13
---
Closed
--
wjaouad1 at netcourrier dot com changed:
What|Removed |Added
Status|WAITIN
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-02 17:17 ---
You forgot to include --with-gnu-ld.
*** This bug has been marked as a duplicate of 11003 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-02 17:17 ---
*** Bug 25641 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #9 from rakdver at gcc dot gnu dot org 2006-01-02 18:34 ---
As the comments in gimplify_cleanup_point_expr indicate,
it only handles cases when cleanup_exprs are not within nested
constructs (with the exception of conditions).
In this PR, the code basically looks like
clean
--- Comment #13 from bonzini at gnu dot org 2006-01-02 18:53 ---
Subject: Bug 25259
Author: bonzini
Date: Mon Jan 2 18:53:27 2006
New Revision: 109241
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109241
Log:
config:
2006-01-02 Paolo Bonzini <[EMAIL PROTECTED]>
PR t
--- Comment #14 from bonzini at gnu dot org 2006-01-02 18:55 ---
patch committed, please verify it works now
--
bonzini at gnu dot org changed:
What|Removed |Added
Hi,
As explained in Debian bug#345574 (http://bugs.debian.org/345574), g++ fails to
build cppunit due to a test suite failure. Debugging this, I found that the
compiler produces code which assumes that no register inside the called
function will clobber any register.
As it turns out, that's an in
--- Comment #1 from wouter at grep dot be 2006-01-02 19:27 ---
Created an attachment (id=10576)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10576&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25642
--- Comment #5 from bonzini at gnu dot org 2006-01-02 19:31 ---
Reconfirmed after the first load PRE patch went in, as it does not handle
globals.
--
bonzini at gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from bonzini at gnu dot org 2006-01-02 19:37 ---
Just for the record, I'm not sure about how much it is worth to have fold
perform all the various sorts of shift/and simplifications that combine can do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19986
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-02 19:44 ---
I have a patch for this which I need to test.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
Testcase:
subroutine mysub(n,v)
integer :: n
real:: v(n)
if (n<=0) return
do i=1, n
v(i) = i*i
end do
return
end subroutine mysub
--
Compile with -fbounds-checking -O2, and notice that there is still
_gfortran_runtime_error left in the asm.
--
Summary: VRP doe
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-02 20:23 ---
C testcase:
int v[1]={0};
void f(int n)
{
int i;
if (n <= 0)
return;
if (n > 0)
{
i = 1;
do {
_Bool t = i <= 0;
_Bool t1 = i > n;
_Bool t2 = t || t1;
if (
Fortran Testcase:
subroutine sub(a, b, c, n); dimension a(n), b(n), c(n); if (n<=0) return;c = a
+ b; end
C testcase:
int a[1000], b[1000], c[1000];
void sub (int n)
{
if (n <= 0)
return;
int i = 1;
do {
a[i-1] = b[i-1]+c[i-1];
i++;
} while (i <= n);
}
-
t.c:11: note
Gcc 4.0.2 configured with following options:
../gcc-4.0.2/configure --prefix=/home/gfleming/local
--enable-language=c,c++,java
When compiling with following line:
gcc -E -I/home/gfleming/local/include -I. glyphs-eimage.c | less
output shows that gcc always pulls in /usr/local/include/png.h and
--- Comment #6 from steven at gcc dot gnu dot org 2006-01-02 21:27 ---
Ehm, wouldn't "unsigned char *" alias everything? GCSE doesn't do load PRE for
me on the original test case, either. And, as long as "outbuf[outcnt] =
bi_buf;" has a V_MAY_DEF for outcnt, you're not going to see any
--- Comment #7 from steven at gcc dot gnu dot org 2006-01-02 21:30 ---
With an even more modified test case, load PRE does happen:
unsigned long outcnt;
extern void flush_outbuf(void);
void
bi_windup(unsigned int *outbuf, unsigned int bi_buf, unsigned long *outcnt)
{
unsigned long
--- Comment #4 from kargl at gcc dot gnu dot org 2006-01-02 22:23 ---
Subject: Bug 24640
Author: kargl
Date: Mon Jan 2 22:23:35 2006
New Revision: 109246
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109246
Log:
PR fortran/24640
* parse.c (next_free): Check for whitespace afte
--- Comment #5 from kargl at gcc dot gnu dot org 2006-01-02 22:24 ---
Committed to trunk. Patch will be committed to 4.1 in a day or two.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kargl at gcc dot gnu dot org 2006-01-02 23:38 ---
I have a patch for this.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Assign
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-01-03 00:24
---
ICE on valid, plausible code.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #3 from hujq_snick at 126 dot com 2006-01-03 02:28 ---
How to resolve it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21776
GCC,
Thanks in advance for any help...I am in trouble
I am using GCC 4.0.2 with binutils 2.16. All of my source code compiles fine,
and the partial linking seems to be fine, but I get an internal error with no
additional information of what is wrong on the final link. This is critical and
it
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-03 05:11 ---
Please report it to http://sourceware.org/bugzilla/ instead of here since this
only tracks GCC bugs and not binutils bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-01-03 05:30
---
Submitting patch for review.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25598
--- Comment #18 from steven at gcc dot gnu dot org 2006-01-03 06:20 ---
Subject: Bug 25130
Author: steven
Date: Tue Jan 3 06:20:21 2006
New Revision: 109264
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109264
Log:
* fold-const.c (operand_equal_p): Accept a NULL operan
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-01-03 07:16
---
TL does not take into account pending spaces and skips when no bytes have been
used yet so it 'thinks' that it is at the beginning of the record and can not
go left.
--
jvdelisle at gcc dot gnu dot org changed
67 matches
Mail list logo
