Try the test case abstract.fail.abstract2 from the mauve
verify module. (You will need jasmin to build this.)
This test case gets a SEGV in the unwinder:
Program received signal SIGSEGV, Segmentation fault.
uw_frame_state_for (context=0xbfff9998, fs=0xbfff98d8) at linux-unwind.h:125
125 in
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-04
06:13 ---
Created an attachment (id=9025)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9025action=view)
abstract/fail/abstract1.class
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21906
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-04
06:13 ---
Created an attachment (id=9026)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9026action=view)
abstract/fail/abstract2.class
I've uploaded the class files so that you don't
have to dig up jasmin.
--
struct virt { virt() : i(2) {} virt(int i) : i(i){} int i; };
struct der1 : public virtual virt { der1(int i) : virt(i) {} }
struct der2 : public virtual virt { der2(int i) : virt(i) {} }
struct top : public der1, public der2 {
top () : der1(0), der2(1) {} };
gets you:
struct virt { virt() : i(2) {} virt(int i) : i(i){} int i; };
struct der1 : public virtual virt { der1(int i) : virt(i) {} }
struct der2 : public virtual virt { der2(int i) : virt(i) {} }
struct top : public der1, public der2 {
top () : der1(0) {} };
gets you:
~/ootbc/members/src$ g++
A function declared: templatetypename T void operator(const T)
when called with an l-value of type invokeflow* is invoked with T bound to
invokeflow (missing the *), as shown by the diagnostic in the example
attached. The diagnostic itself is not the problem, it just shows the incorrect
binding;
--- Additional Comments From igodard at pacbell dot net 2005-06-04 10:32
---
Created an attachment (id=9027)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9027action=view)
compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21909
--- Additional Comments From igodard at pacbell dot net 2005-06-04 10:32
---
Created an attachment (id=9028)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9028action=view)
source code (compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21909
--- Additional Comments From igodard at pacbell dot net 2005-06-04 10:37
---
Sorry, my bad
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
--- Additional Comments From igodard at pacbell dot net 2005-06-04 10:42
---
Sorry, not my bad after all :-( I need some sleep.
Ivan
--
What|Removed |Added
If old dump files for a testcase are left, if the name of the dump file has
changed, errors like the following occur:
ERROR: gcc.dg/tree-ssa/structopt-1.c: error executing dg-final: couldn't open
structopt-1.c.t50.lim structopt-1.c.t53.lim: no such file or directory
UNRESOLVED:
--- Additional Comments From giovannibajo at libero dot it 2005-06-04
10:46 ---
I can't find anything in the standard which says that this should be an error,
regardless of what Comeau does. This looks like a genuine bug in the parser,
see parser.c:cp_parser_class_specifier: the
--- Additional Comments From giovannibajo at libero dot it 2005-06-04
10:48 ---
(In reply to comment #7)
There is some code which also delays inner functions until the outer function
is finished:
Of course I meant classes: There is some code which also delays inner
classes until
--- Additional Comments From chris at bubblescope dot net 2005-06-04 12:07
---
This is being held up by PR20408, Unnecessary code generated for empty structs,
as we'd have to pass
both the item to find and the comparitor (which is often an empty class) to
std::find_if
--
GCC mistakenly identifies a named parameter as a sentinel. Given the following
program, compiling with -Wformat GCC should warn about a missing sentinel on
the line indicated:
#include stddef.h
extern void foo (const char *, ...) __attribute__ ((__sentinel__));
void bar (void)
{
foo
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21911
$ cat imploop.f90
program main
call foo(5)
end program main
subroutine foo(n)
implicit none
integer :: n, i
real, dimension(5) :: a,b
print *,n
a = (/(i,i=n,1,-1)/)
print *,a
b = (/(i,i=5,1,-1)/)
print *,b
end subroutine foo
$ gfortran imploop.f90
$ ./a.out
5
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-04
14:59 ---
Huh, you missed the semi-colon which is what it is complaining about.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21907
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-04
14:59 ---
Again you missed the semi-colon.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21908
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-04
15:11 ---
We have /* { dg-final { cleanup-tree-dump lim } } */ in the testcase so it
should have cleaned up,
when did you get the version of HEAD?
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-04
15:16 ---
(In reply to comment #1)
This is being held up by PR20408, Unnecessary code generated for empty
structs, as we'd have to
pass both the item to find and the comparitor (which is often an empty class)
--
What|Removed |Added
Summary|[3.4/4.0/4.1 Regression]|[3.4 Regression] infinite
|infinite warning loop on bad|warning loop on bad array
--
What|Removed |Added
Attachment #9027|application/octet-stream|text/plain
mime type||
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-04
16:44 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-06-04
16:47 ---
Fixed with http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00127.html
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-04
16:53 ---
Fixed for 4.0.0..
--
What|Removed |Added
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-04
16:56 ---
No feedback in 3 months.
--
What|Removed |Added
Status|WAITING
/* { dg-do compile } */
/* { dg-options -O2 -g -m32 } */
union U { unsigned long u; unsigned long long v; };
struct S { long s; long t; };
extern unsigned int foo (unsigned long long *, unsigned int);
void bar (int x, union U y, struct S *z)
{
if ((x 3) == 2)
{
unsigned long long r
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-06-04
17:00 ---
21855 has some analysis. Better use that one.
*** This bug has been marked as a duplicate of 21855 ***
--
What|Removed |Added
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-06-04
17:00 ---
*** Bug 18178 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
Bug 19659 depends on bug 18178, which changed state.
Bug 18178 Summary: Missed opportunity for removing bounds checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18178
What|Old Value |New Value
--- Additional Comments From mhcox at bluezoosoftware dot com 2005-06-04
17:17 ---
Subject: RE: Nested class has access to Nestee's private member functions
From my copy of the C++ standard (ISO/IEC 14882:1998(E)) [class.access.net]
11.8.1:
The members of a nested class have
--- Additional Comments From mhcox at bluezoosoftware dot com 2005-06-04
17:20 ---
From my copy of the C++ standard (ISO/IEC 14882:1998(E)) [class.access.net]
11.8.1:
The members of a nested class have no special access to members of an
enclosing class, nor to classes or
--
What|Removed |Added
Target Milestone|--- |3.1.x/3.2.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6850
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-04
17:37 ---
Reopening for a second to ...
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-04
17:38 ---
Mark as a dup of bug 359.
This was DR 45.
*** This bug has been marked as a duplicate of 359 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-04
17:38 ---
*** Bug 21901 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From kargl at gcc dot gnu dot org 2005-06-04 17:39
---
Patch is give here
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00334.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21375
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-04
17:40 ---
Reopening for a second to ...
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-04
17:40 ---
Mark as invalid.
--
What|Removed |Added
Status|REOPENED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-04
17:41 ---
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#45
--
What|Removed |Added
With LAST_UPDATED: Thu Jun 2 10:12:34 UTC 2005 and ever since,
I get:
Running
/home/hp/combined/combined/gcc/testsuite/gcc.c-torture/compile/compile.exp ...
FAIL: gcc.c-torture/compile/20030703-1.c -O2 (test for excess errors)
FAIL: gcc.c-torture/compile/20030703-1.c -O3 -fomit-frame-pointer
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Target Milestone|---
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-04
17:49 ---
I want to say this was exposed by:
-2005-06-01 Diego Novillo [EMAIL PROTECTED]
-
- PR 14341, PR 21332, PR 20701, PR 21029, PR 21086, PR 21090
- PR 21289, PR 21348, PR 21367, PR 21368, PR
explains the change. Here are the
total times (removing the output file between each invocation):
ifort 8.0: 0,109
g77 3.3: 1,349
gfortran 4.1 20050604: 1,458
Blocksizes in bytes are:
ifort 8.0: 262144
g77 3.3: 4096
gfortran 4.1 20050604: 8192
Gfortran is the only one which uses mmap. Also, we
--- Additional Comments From pcarlini at suse dot de 2005-06-04 18:00
---
There is some truth in what Andrew and Chris are saying, and myself ;) : we
have quite a few improvements to merge to mainline and other in progress in
v7. Maybe, as an intermediate step, we will end up taking
--- Additional Comments From SSacek at appsecinc dot com 2005-06-04 18:28
---
I would like to thank you folks at gcc.gnu.org for taking a serious look at
this issue.
I wanted to write here a little bit about what I do and how this matter came
to light. It is my occupation to write
--- Additional Comments From aa056 at chebucto dot ns dot ca 2005-06-04
18:44 ---
For Red Hat Fedora Core 3, gfortran 4.0.0 doesn't lose output records:
$ ./chk-write-many
uname -a
Linux cerberus.cwmannwn.nowhere 2.6.11-1.14_FC3.stk16 #1 Tue Apr 12 14:39:51 EDT
2005 i686 i686 i386
--- Additional Comments From bangerth at ices dot utexas dot edu
2005-06-04 18:48 ---
Subject: RE: Nested class has access to Nestee's private
member functions
I read suggestions that this should be changed in the next standard, but I
don't think it's changed yet. Therefore, the
--- Additional Comments From igodard at pacbell dot net 2005-06-04 18:55
---
So I did :-) So where does the `der2::der2(const void**)' come from?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21908
--- Additional Comments From tobi at gcc dot gnu dot org 2005-06-04 19:04
---
It looks like I made a mistake there, the original code had a +1 in
gfc_set_backend_locus, as can be seeing by diffing rev 1.4 against rev 1.5. I
can't remember what all this was about at the moment, so I
--- Additional Comments From SSacek at appsecinc dot com 2005-06-04 19:17
---
Dear Giovanni Bajo,
Thank you for that detailed explanation. Based on what you said, it sounds
like a complex problem to solve; however, it may not be as difficult as it
first appears. Take the example
I would be nice if the functions atanh etc. (acosh, asinh, atanh, cosh, sinh,
tanh) were available as intrinsics. These functions are not part of the
Fortran 2003 standard. But they are defined e.g. in C's math.h or
tgmath.h, and other Fortran compilers provide these as well.
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-04
19:23 ---
Subject: Bug 21888
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-06-04 19:23:54
Modified files:
gcc: ChangeLog
gcc/config/alpha:
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-06-04 19:25
---
On 20050604 it's back to the first failure reported in this PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21886
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-04
19:25 ---
Subject: Bug 21888
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-06-04 19:25:48
Modified files:
gcc:
--- Additional Comments From hp at gcc dot gnu dot org 2005-06-04 19:26
---
It's mine, don't bother Diego.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-04
19:27 ---
Subject: Bug 21888
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-06-04 19:27:34
Modified files:
gcc:
--- Additional Comments From rth at gcc dot gnu dot org 2005-06-04 19:28
---
Fixed.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-04
19:30 ---
(In reply to comment #2)
So I did :-) So where does the `der2::der2(const void**)' come from?
It is a bug and a regression.
Reduced testcase for that bug:
struct virt { virt(){} virt(int i){} };
struct
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-04
19:32 ---
The error message is clear what the problem is, so closing as invalid.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-04
19:35 ---
(In reply to comment #7)
FWIW, WG21 thinks this is a bug:
http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_closed.html#456
And is fixed in 4.0.0 and above already.
--
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-06-04 19:36
---
Failures no longer appear on ia64-hpux on mainline on 20050604.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21292
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-04
19:38 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From tobi at gcc dot gnu dot org 2005-06-04 19:51
---
Hm, lb-linenum should start counting from line 1, so I've no idea what the
original code was trying to do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19195
./xgcc -B./ -B/home/dave/opt/gnu/gcc/gcc-4.1.0/hppa-linux/bin/ -isystem /home/da
ve/opt/gnu/gcc/gcc-4.1.0/hppa-linux/include -isystem /home/dave/opt/gnu/gcc/gcc-
4.1.0/hppa-linux/sys-include -L/home/dave/gnu/gcc-4.0/objdir/gcc/../ld -O2 -DIN_
GCC-W -Wall -Wwrite-strings -Wstrict-prototypes
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-04
20:29 ---
Very related to PR 21886.
--
What|Removed |Added
BugsThisDependsOn|
--
What|Removed |Added
OtherBugsDependingO||21916
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21886
at 0x7afeb230
GNU C version 4.1.0 20050604 (experimental) (hppa2.0w-hp-hpux11.11)
compiled by GNU C version 4.1.0 20050604 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
options passed: -I. -I. -I../../gcc/gcc -I../../gcc/gcc/.
-I../../gcc/gcc/../include
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-04
21:00 ---
Subject: Bug 16898
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-06-04 20:59:51
Modified files:
gcc/fortran:
--- Additional Comments From tobi at gcc dot gnu dot org 2005-06-04 21:00
---
Fixed.
--
What|Removed |Added
CC||tobi at gcc dot
--
Bug 20538 depends on bug 16898, which changed state.
Bug 16898 Summary: Aliasing problem with array descriptors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16898
What|Old Value |New Value
--- Additional Comments From tobi at gcc dot gnu dot org 2005-06-04 21:01
---
The patch has been on mainline since May 18th.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16898
--- Additional Comments From tobi at gcc dot gnu dot org 2005-06-04 21:56
---
I think this is the right thing to do, but I'm not sure it's the only bug. The
line number given in the ICE is minus two, but this patch only fixes an
off-by-one.
2005-06-04 Tobias Schluter [EMAIL
--- Additional Comments From tobi at gcc dot gnu dot org 2005-06-04 22:03
---
Hm, I couldn't reproduce the failure, but maybe I got some subtlety wrong which
is needed for this bug to trigger. I'd suggest we try this again once a fix for
pr19195 is in, for I think they're the same bug.
--- Additional Comments From schnetter at aei dot mpg dot de 2005-06-04
22:05 ---
I had a case where the line number was set to -123 in the end. With this
patch this works now.
I assumed that the get/set routines would be called repeatedly, and the line
number is reduced by one
--- Additional Comments From tobi at gcc dot gnu dot org 2005-06-04 22:06
---
Silly me, I could reproduce it now. With the patch I appended to PR 19195 this
is fixed.
*** This bug has been marked as a duplicate of 19195 ***
--
What|Removed |Added
--- Additional Comments From tobi at gcc dot gnu dot org 2005-06-04 22:06
---
*** Bug 20829 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From tobi at gcc dot gnu dot org 2005-06-04 22:08
---
There's definitely something wrong if we call this pair of functions 123 times
on the same function :-) The patch also fixes PR 20829, so I think I'll post it
to the list and commit it, either as obvious or
struct virt { virt() : i(2) {} virt(int i) : i(i){} int i; };
struct der1 : public virtual virt { der1(int i) : virt(i) {} };
struct der2 : public virtual virt { der2(int i) : virt(i) {} };
struct top : public der1, public der2 {
top () : der1(0), der2(1) {} };
int main() { top t; }
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-04
22:21 ---
Subject: Bug 19195
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-06-04 22:20:58
Modified files:
gcc/fortran: ChangeLog trans.c
--- Additional Comments From igodard at pacbell dot net 2005-06-04 22:22
---
p.s. I suppose that if there is only a single path to the virtual base then
explicit construction is meaningful and the explicit construction in the der*
classes is not wrong. But in the constructor for top the
--
Bug 20829 depends on bug 19195, which changed state.
Bug 19195 Summary: gfortran: ICE in final_scan_insn, at final.c:1843
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19195
What|Old Value |New Value
--- Additional Comments From tobi at gcc dot gnu dot org 2005-06-04 22:23
---
Fixed. Thanks, Erik.
--
What|Removed |Added
Status|NEW
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-04
22:43 ---
Subject: Bug 19195
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-06-04 22:43:17
Modified files:
gcc/fortran:
--
What|Removed |Added
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19195
Warnings about unused variables should point to the declaration of the
variable. Currently the warning points to the first line of the procedure
where the variable is declared:
subroutine a (x, y)
implicit none
integer x
integer y
x = 1
end subroutine a
$ ~/gcc/bin/gfortran
--- Additional Comments From schnetter at aei dot mpg dot de 2005-06-04
23:15 ---
I tried to reduce the failing source code, but failed to achieve much.
Depending on what lines I remove, the error changes, sometimes turning into a
bare segmentation fault. Even renaming the source
--- Additional Comments From schnetter at aei dot mpg dot de 2005-06-04
23:16 ---
Created an attachment (id=9030)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9030action=view)
Failing source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21915
System: 200MHz Pentium Pro PC, Windows 2k, Cygwin.
GCC Version: 4.1.0, from cvs 2005-06-02.
Before the bug appeared: I had downloaded a fresh copy of the CVS tree, and was
attempting to build a copy of gfortran using the following commands (yes, I now
know that trying to build _in_ the source
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-05
03:02 ---
This is how C++ is done, maybe a warning can be emitted but it seems like it
will emitt too much for
valid C++ code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21917
--- Additional Comments From sherpya at netfarm dot it 2005-06-05 03:59
---
the problematic dirs are target-libiberty target-libstdc++-v3
since adding this to target:
skipdirs=target-libiberty target-libstdc++-v3
compiles fine (cross compiling with linux), anyway I suppose this cannot
--- Additional Comments From sherpya at netfarm dot it 2005-06-05 05:15
---
as I posted in the duplicated bug thread, the problematic directories are:
target-libiberty target-libstdc++-v3
also I had a working build on cvs snapshot of 20050522,
btw in that build ATTRIBUTE_SENTINEL was
95 matches
Mail list logo
