I was wondering whether it is possible to have GCC produce a warning
whenever a non-virtual method in the base class is hidden by a method in the
derived class. I know this is possible for virtual methods by using
the -Woverload-virtual switch, but I haven't been able to find the
equivalent for non
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-04-01
08:25 ---
Committed fix at http://gcc.gnu.org/ml/gcc-cvs/2005-04/msg00019.html
--
What|Removed |Added
--
Bug 19454 depends on bug 20600, which changed state.
Bug 20600 Summary: [4.1 regression] failure for pass.c on x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20600
What|Old Value |New Value
---
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-04-
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-01
10:43 ---
Seen in wxGTK on i386:
../../../../contrib/src/ogl/drawn.cpp:1019: internal compiler error: in
cp_tree_equal, at cp/tree.c:1552
../../../../contrib/src/ogl/mfutils.cpp:157: internal compiler error: in
cp_tree
In the C++ standard, section 9.3 paragraph 2:
"A member function definition that appears outside of the class definition
shall appear in a namespace scope enclosing the class definition."
This is similar to 7.3.1.2p2 except for class members.
Therefore, the following code should be rejected
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-01
11:23 ---
Subject: Bug 19454
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-01 11:23:08
Modified files:
gcc: Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-01
11:23 ---
Subject: Bug 20600
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-01 11:23:08
Modified files:
gcc: Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-01
11:39 ---
Subject: Bug 15700
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-01 11:38:53
Modified files:
gcc/testsuite : ChangeLog
Log message:
Add
--
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495
The following 3 equvalent variants of the same primitive program should lead to
the same code, but they don't:
1. C source:
static inline int f1();
static inline int f2();
int main() { f1(); }
static inline int f1() { f2(); }
static inline int f2() { return 1; }
Its assembler output:
.
--- Additional Comments From Thomas dot Koenig at online dot de 2005-04-01
11:45 ---
No write or print statement is necessary:
$ cat assign.f90
program main
assign 1000 to i
1000 format (A)
end
$ gfortran assign.f90
$ gfortran -fdump-parse-tree assign.f90
In file ass
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-01
12:41 ---
Subject: Bug 20635
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-01 12:41:19
Modified files:
gcc: Change
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
12:54 ---
Fixed in 3.4.0 and above with unit-at-a-time.
--
What|Removed |Added
Status|UNCO
character(len = 10),parameter:: a = 'hello'
print *, a, "world"
end
the output:
helloworld.
--
Summary: Don't pad parameter strings.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
13:08 ---
*** This bug has been marked as a duplicate of 13140 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
13:08 ---
*** Bug 20711 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
13:11 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--
Bug 20225 depends on bug 20635, which changed state.
Bug 20635 Summary: [4.0 Regression] ICE in cgraph_mark_reachable_node
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20635
What|Old Value |New Value
---
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
13:17 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From ncm at cantrip dot org 2005-04-01 13:24
---
Subject: Re: basic_string::_M_rep() can produce an unnaturally aligned pointer
to _Rep
On Fri, Apr 01, 2005 at 11:42:27AM -, pcarlini at suse dot de wrote:
>What|Removed |A
--- Additional Comments From pcarlini at suse dot de 2005-04-01 13:31
---
Ok, my change was only dictated by consistency, and the original idea of using
"enhancement" is not mine ;) Let's remove "enhancement" from both. By the way,
I really noticed yesterday for the first time that basic
--
What|Removed |Added
Severity|enhancement |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670
--- Additional Comments From Thomas dot Koenig at online dot de 2005-04-01
13:34 ---
This patch fixes the test case. It also includes my
EOR patch for advancing I/O.
This is regression-tested on mainline. I'll submit a proper
patch when I have finished regression-testing it on 4.0.
-
When emit_no_conflict_block is handed these insns:
(insn 597 0 598 (set (reg:SI 405)
(mem/i:SI (reg/f:SI 154 virtual-stack-vars) [0 x+0 S4 A32])) -1 (nil)
(nil))
(insn 598 597 599 (parallel [
(set (reg:SI 404)
(ashift:SI (reg:SI 405)
(co
--- Additional Comments From pcarlini at suse dot de 2005-04-01 14:26
---
> I think it is not OK to include or .
I agree. Actually, probably we have already briefly discussed that (privately)
with Benjamin. Is there something wrong with just using if () abort() instead?!?
(in case we c
--- Additional Comments From pcarlini at suse dot de 2005-04-01 14:34
---
I think we can safely close this one.
--
What|Removed |Added
Status|UNCONFIRMED
When I tried to compile and link java application into an exacutable using GCJ
v3.4.3 in Linux Red Hat 3.4.3-9.EL4, it produces error messages:
[EMAIL PROTECTED]:~/testarea/build$ ./gcjbuild
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.3/specs
Reading specs from /usr/lib/gcc/i386-redhat-
--
What|Removed |Added
Severity|critical|normal
Component|libgcj |java
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20715
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
14:52 ---
You might want to try a snapshot of 4.0.0 which has AWT support builtin.
Also this is not a link error, this is at compile time still.
This error usually shows up if you try to compile a .jar and a .java fil
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-04-
--- Additional Comments From jack dot rong at cloakware dot com 2005-04-01
14:58 ---
Subject: RE: gcj link error
It is a compilation error. Thanks.
Jack
-Original Message-
From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED]
Sent: Friday, April 01, 2005 9:52 AM
To:
--
What|Removed |Added
Summary|gcj link error |gcj compilation error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20715
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-01
15:01 ---
Subject: Bug 20604
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-01 15:01:31
Modified files:
gcc/treelang : ChangeLog lang-specs.h
Log message:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
15:01 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-04-01
15:20 ---
Created an attachment (id=8507)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8507&action=view)
proposed patch
This implements a similar dependency check as in emit_libcall_block,
except that we might
--
What|Removed |Added
OtherBugsDependingO||20695
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20714
--
What|Removed |Added
BugsThisDependsOn||20714
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20695
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-01
15:28 ---
Forget comment #4. The problem is in the testsuite file (I corrected it, this
test now FAILs, but will be fixed soon by Dale's patch).
--
What|Removed |Added
--
The fortran testsuite routine
"/gfortran/gcc/gcc/testsuite/gfortran.fortran-torture/execute/backspace.f90" is
actually incorrect - C should actually be 'a' not 'b' - gfortran incorrectly
returns 'b' and passes the bad test.
[dranta:~/tests/gfortran] dir% gfortran -o backspace backspace.f90
[dran
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
15:34 ---
This was just fixed by " François-Xavier Coudert":
* gfortran.fortran-torture/execute/backspace.f90: Check
after backspace and read was incorrect.
--
What|Removed
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-01 16:23
---
Let me replace the testcase as follows so that
I can remove dependence on PR 20701.
extern void bar (int);
int
foo (int *p, int b)
{
int a;
if (b)
bar (123);
else
bar (321);
a = *p;
if (p
Many g++ and libstdc++ testcases started failing on mainline on ia64-hpux on
20050331. The failures are of the form:
ld: (Warning) Unsatisfied symbol "std::basic_stringbuf, std::allocator >::~basic_stringbuf()" in file
/scratch/gcc/nightly-2005-03-31-mainline/ia64-hp-hpux11.23/build_gcc/build/ia6
unsigned long foo (unsigned long *a, unsigned long *b,
unsigned long *c, int d)
{
unsigned long e, f;
if (d <= 0) return 0;
asm ("# registers %0 %1 %2 %3 %4 %5"
: "+a" (e),"+c" (d), "+r" (f)
: "r" (a), "r" (b), "r" (c));
return e;
}
at -O2 results in
# reg
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-01 16:47
---
Before FRE. (That is, the result of copyprop)
foo (array)
{
int D.1134;
int D.1133;
int * D.1132;
:
D.1132_3 = array_2 + 4B;
# VUSE ;
D.1133_4 = *D.1132_3;
if (D.1133_4 != 0) goto ; else got
Bootstrap on mainline on hppa2.0w-hpux has started failing on 20050401 in the
build of libgcc with the stage1 compiler.
/home/gcc/nightlies/gcc-mainline-2005-04-01/gcc/libgcc2.c: In function
'__muldi3':
/home/gcc/nightlies/gcc-mainline-2005-04-01/gcc/libgcc2.c:533: internal compiler
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-01 16:56
---
Created an attachment (id=8508)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8508&action=view)
File which ICEs
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20719
AWT applications crash when processing certain key events because the
keysym-to-keycode mapping is wrong. The crash is preceded by this warning:
** (:7916): WARNING **: No keyval found for hardware keycode 233
*** glibc detected *** free(): invalid pointer: 0x085819a0 ***
--
Summary:
the error ``crosses initialization of `...''' is wrongly omited
--
Summary: [regression from 3.4.2 to 3.4.3] crossing of a
initialization left undetected on goto
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: no
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
19:19 ---
This is not a regression and here is an example (compile on 3.2.3 with -O2 -
fomit-frame-pointer on i686-pc-linux-gnu and you get the same behavior as
pointed out here):
unsigned long foo (unsigned long *a,
--- Additional Comments From nefercheprure at gmail dot com 2005-04-01
19:22 ---
Created an attachment (id=8509)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8509&action=view)
the preprocessed file that demonstrates the regression
g++ -v -c logger.cc produces this message:
Readi
--
What|Removed |Added
Keywords||accepts-invalid
Known to fail||3.4.3
Known to work|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
19:42 ---
There is at least an ICE on the mainline.
--
What|Removed |Added
Keywords|accepts-
--- Additional Comments From jozef dot behran at krs dot sk 2005-04-01
19:49 ---
> This is still valid code because the struct could be defined below still.
But if the struct is not defined anywhere (not even below its use), a warning
should
occur. If you send the first declaration
In varasm.c, function_section() and current_function_section() invoke target
hook select_section with boolean "unlikely" as the second argument. The
second argument is suppose to specify if the decl contains relocations, not if
it should be placed in the unlikely section.
--
Summar
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-04-01
20:00 ---
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00097.html
--
What|Removed |Added
Key
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
Status|WAITING
--- Additional Comments From joseph at codesourcery dot com 2005-04-01
20:19 ---
Subject: Re: Attempt to use undefined structure tag triggers
no diagnostic
On Fri, 1 Apr 2005, jozef dot behran at krs dot sk wrote:
> Note that the code is valid, but unusual. If you see a structure tag
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
20:58 ---
If you deference or do an assignment like:
TType *a, *b;
b->Pointer = a;
You will either get an error or a warning saying the code is invalid.
Also as mentioned by JSM, it is a way to provide opaque
--- Additional Comments From mark at codesourcery dot com 2005-04-01 21:17
---
Subject: Re: [PR debug/19345] remap TYPE_STUB_DECL during inlining
Alexandre Oliva wrote:
> TYPE_STUB_DECL was NULL in the testcase given in the bug report
> because tree inlining failed to remap TYPE_STUB_DE
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
21:25 ---
Also reproducable on i686-pc-openbsd3.1.
--
What|Removed |Added
CC|
--
What|Removed |Added
Keywords||build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20719
--- Additional Comments From frederic dot riss at gmail dot com 2005-04-01
21:45 ---
Andrew, I don't fully get what you mean and seeing no activity on this bug makes
me wonder if you expect some feedback from me... Experimenting based on your
comment I tried using -fno-weak, but it doesn
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
21:48 ---
(In reply to comment #2)
> Andrew, I don't fully get what you mean and seeing no activity on this bug
> makes
> me wonder if you expect some feedback from me... Experimenting based on your
> comment I tried
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
21:57 ---
Reduced testcase for the accepts invalid, I will then reduce the ICE on the
mainline soon (note you have
some other invalid code in there):
bool f();
void g(int i)
{
if (i) goto bad;
bool a = f();
ba
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
21:57 ---
: Search converges between 2004-10-26-161001-trunk (#611) and
2004-11-03-014001-trunk
(#612).
: Search converges between 2004-10-28-004002-3.4 (#106) and
2004-11-01-004001-3.4 (#107).
--
http://gcc.gn
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-04-01
22:16 ---
I have a patch for this that solves it.
Waiting for TCB merge to post
--
What|Removed |Added
The following code now ICEs on the mainline:
template class srp;
template struct ptr
{
template ptr(const srp &other);
};
template struct srp
{
template operator ptr(void) const;
};
ptr parent_get()
{
srp parent;
return parent;
}
Note we did reject this before even though it is inv
--- Additional Comments From pcarlini at suse dot de 2005-04-01 22:54
---
Humpf! A problem with the trivial fix using abort() is that doesn't emit
diagnostic about the failure point. This is relevant for , which
uses _GLIBCXX_DEBUG_ASSERT/PEDASSERT directly.
--
http://gcc.gnu.org/bu
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01
22:55 ---
I think the ICE was caused by:
2005-03-31 Nathan Sidwell <[EMAIL PROTECTED]>
PR c++/19203, implement DR 214
* call.c (joust): Use more_specialized_fn.
* cp-tree.h (DEDUCE_ORDER): R
--- Additional Comments From pcarlini at suse dot de 2005-04-01 23:02
---
...and also elsewhere (there are more uses besides ).
--
What|Removed |Added
AssignedTo|pca
--
What|Removed |Added
Keywords||wrong-code
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--
What|Removed |Added
Severity|critical|normal
Keywords||diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-02
00:09 ---
Because we only warn if you take the address and then cast so if you have a
tempary variable
inbetween, we don't warn.
Note really strict aliasing warnings are hard to produce as it is only a bug if
you
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-02
00:16 ---
pr19049.f:10: note: not vectorized: can't determine dependence between:
(*a_38)[D.722_49] and
(*a_38)[D.721_51]
pr19049.f:10: note: bad data dependence.
--
What|Removed
--- Additional Comments From hjl at lucon dot org 2005-04-02 00:28 ---
It is getting worse. Both libtool and java testsuite try to outsmart
each other. Each tries to put `\' in front `$' for file name.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20693
Consider this program;
namespace N {
int function( char * ) { return 200; }
// uncomment the next line to see a surprising error:
//template< typename T > int function();
// The error is:
// foo.cpp: In function `int main()':
--
What|Removed |Added
CC||kjd at duda dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20724
--- Additional Comments From law at redhat dot com 2005-04-02 01:31 ---
Some notes on recent poking and prodding.
The big perl speedup is consistent on my P4 -- but perl shows no significant
change on my AMD box. Perl spends ~50% of its time in one routine (regexec)
and, surprise, that'
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-02
02:27 ---
Subject: Bug 20526
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-02 02:26:52
Modified files:
gcc/java : ChangeLog gcj.texi
libjava
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-02
02:27 ---
Subject: Bug 20090
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-02 02:26:52
Modified files:
gcc/java : ChangeLog gcj.texi
libjava
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-02
02:30 ---
Subject: Bug 20526
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-02 02:30:41
Modified files:
gcc/java : Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-02
02:30 ---
Subject: Bug 20090
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-02 02:30:41
Modified files:
gcc/java : Change
--
What|Removed |Added
CC||vektor at dumbterm dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20699
--
What|Removed |Added
CC||danglin at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/sh
Consider:
struct s {
int *n;
};
int
foo (unsigned int i, struct s *array)
{
int *p = array[i].n;
if (p)
{
int *q = array[i].n;
if (p != q)
return 1;
}
return 0;
}
Note that the second load is unnecessary, but FRE does not remove it.
Here is the dump before FR
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-02 04:41
---
Danny, could you take a look?
This occurs even with your patch to tree-ssa-pre.c to fix PR 20703.
--
What|Removed |Added
-
--
What|Removed |Added
Keywords||rejects-valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20724
88 matches
Mail list logo