When compiling GNU classpath (CVS 20060901) with gcj, I get a
java.lang.VerifyError when running a Swing app with cacao:
jet:~/work/svn/batik/trunk-gcj $ /usr/local/cacao/bin/cacao -jar
batik-1.6/batik.jar samples/asf-logo.svg 21
Exception in thread main java.lang.VerifyError: (class:
--- Comment #1 from cam-gcc-bugzilla at aka dot mcc dot id dot au
2006-09-11 06:07 ---
Created an attachment (id=12221)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12221action=view)
The generated MetalLookAndFeel.class file.
This is the generated class file causing the verifier
--- Comment #6 from paul dot richard dot thomas at cea dot fr 2006-09-11
08:15 ---
The patch did not apply cleanly to 4.1; I will take a look tonight to try to
understand why.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28890
--- Comment #14 from victork at il dot ibm dot com 2006-09-11 08:16 ---
I will look if patch http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01171.html
fixes this one too and will remap it to 4.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26969
--- Comment #2 from mark at gcc dot gnu dot org 2006-09-11 09:39 ---
Subject: Re: New: gcj generates a MetalLookAndFeel class
that fails cacao's verifier
Hi,
On Mon, 2006-09-11 at 06:05 +, cam-gcc-bugzilla at aka dot mcc dot
id dot au wrote:
When compiling GNU classpath
--- Comment #3 from cam-gcc-bugzilla at aka dot mcc dot id dot au
2006-09-11 09:44 ---
Created an attachment (id=12223)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12223action=view)
MetalLookAndFeel.class as produced by ecj
Hi Mark.
Indeed, compiling it with ecj results in a
$ uname -a
Linux rogue 2.6.16-gentoo-r13 #1 PREEMPT Tue Aug 1 13:59:12 GMT 2006 i686 AMD
Athlon(TM) XP 2000+ GNU/Linux
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.1/configure --prefix=/home/laguest/opt/gcc-4.1.1
--enable-libada
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-09-11 10:41
---
*** This bug has been marked as a duplicate of 16634 ***
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rearnsha at gcc dot gnu dot org 2006-09-11 10:41
---
*** Bug 29004 has been marked as a duplicate of this bug. ***
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-09-11 10:42
---
Here's another test case, taken from maxdb:
Please do not attach other testcases to a PR, the underlying problems are
very
likely unrelated. Only testcases reduced from the original one are of any
help.
--
--- Comment #4 from dorit at il dot ibm dot com 2006-09-11 10:57 ---
You could help by looking at the source code (there are only a few dozens
places mentioning flag_unsafe_math_optimizations) and auditing which places
would be more suited to a new flag_reassociate_fp variable.
we'd
--- Comment #5 from eres at il dot ibm dot com 2006-09-11 11:21 ---
Hi,
Following Dorit's comment; We thought of starting this journey with a patch
that include the cases in the vectorizer and loop-unroll and gradually add the
rest of the cases that can go under flag_reassociate_fp.
ICE with gcc version 4.2.0 20060911 (experimental) when optimizing for code
size. Preprocessed example code follows. Compile with: g++ -Os -c foo.cc -o
foo.o
20060908 worked ok.
--
Summary: ICE when compiling with -Os
Product: gcc
Version: 4.2.0
--- Comment #1 from us15 at os dot inf dot tu-dresden dot de 2006-09-11
11:23 ---
Created an attachment (id=12224)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12224action=view)
Example testcase
This code triggers the bug.
--
--- Comment #4 from tbm at cyrius dot com 2006-09-11 11:31 ---
(In reply to comment #2)
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00230.html
What's the status of this patch?
--
tbm at cyrius dot com changed:
What|Removed |Added
--- Comment #6 from eres at il dot ibm dot com 2006-09-11 11:49 ---
I would also like to be assigned to this bug.
Thanks,
Revital
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28684
--- Comment #2 from tbm at cyrius dot com 2006-09-11 11:54 ---
I guess you mean this ICE:
/home/uas/cvs/drops/l4/kernel/fiasco/src/kern/kern_cnt.cpp:109: internal
compiler error: tree check: expected class 'expression', have 'exceptional'
(baselink) in get_base_var, at ipa-utils.c:224
--- Comment #3 from tbm at gcc dot gnu dot org 2006-09-11 11:59 ---
(sid)451:[EMAIL PROTECTED]: ~] x86_64-unknown-linux-gnu-g++ -c pr29016.cc
(sid)452:[EMAIL PROTECTED]: ~] x86_64-unknown-linux-gnu-g++ -c -O pr29016.cc
pr29016.cc:16: internal compiler error: tree check: expected class
--- Comment #6 from rearnsha at arm dot com 2006-09-11 12:14 ---
Subject: Re: compiler generates incorrect ARM instructions
when using long bitfields
On Wed, 2006-08-02 at 13:56, jason dot morgan at vpnsolutions dot uk dot
com wrote:
Where do I obtain EABI and what effect
In gcc/cp/typeck.c there is this code
pedwarn (ISO C++ forbids %s between pointer of type %void *%
and pointer-to-function, location);
Location will be different, English and untranslated, values depending on how
this code is reached. The result can not be properly translated. Even
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|pbrook at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--- Comment #3 from jakub at gcc dot gnu dot org 2006-09-11 14:22 ---
I believe OMP_PARALLEL handling in tree-nested.c isn't the only problem, see
e.g.:
extern void abort (void);
void
foo (int *j)
{
int i = 5;
int bar (void) { return i + 1; }
#pragma omp sections private (i)
{
--- Comment #4 from tromey at gcc dot gnu dot org 2006-09-11 15:08 ---
I tried to look at this today but the test is missing
a main method (I could work around the lack of a Makefile,
but this is more serious...)
--
tromey at gcc dot gnu dot org changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||mmitchel at gcc dot gnu dot
|
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-11 15:29 ---
This is why I mentioned BASELINK should be stripped.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29016
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29016
--- Comment #4 from jakub at gcc dot gnu dot org 2006-09-11 15:46 ---
Furthermore, I have no idea what would:
extern void abort (void);
int
baz (int (*bar) (void))
{
return bar ();
}
void
foo (int *j)
{
int i = 5;
int (*fn) (void);
int bar (void) { return i + 1; }
fn = bar;
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-11 15:53 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The c++ parser accepts:
enum { };
which is specifically listed in clause 7 paragraph 3 of the C++ standard as
ill-formed.
--
Summary: empty enum accepted
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: accepts-invalid
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-11 16:09 ---
Confirmed, not a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from janis at gcc dot gnu dot org 2006-09-11 16:19 ---
Sorry, I don't have an ia64 system on which to try wrong-code tests.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28604
--- Comment #7 from roger at eyesopen dot com 2006-09-11 16:36 ---
Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00406.html
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #6 from roger at eyesopen dot com 2006-09-11 16:52 ---
I believe I have a patch. I'm just waiting for the fix for PR28672 (which I've
just approved) to be applied, so I can complete bootstrap and regression test
to confirm there are no unexpected side-effects.
--
roger
--- Comment #39 from dje at gcc dot gnu dot org 2006-09-11 17:05 ---
Subject: Bug 27287
Author: dje
Date: Mon Sep 11 17:05:15 2006
New Revision: 116850
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116850
Log:
2006-09-11 Guenter Roeck [EMAIL PROTECTED]
David
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #5 from sje at cup dot hp dot com 2006-09-11 17:12 ---
I will see if I can find the checkin on the 4.1 branch that caused the failure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28604
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||gcc-bugs at gcc dot gnu dot
|
--- Comment #9 from tromey at gcc dot gnu dot org 2006-09-11 17:49 ---
Created an attachment (id=12225)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12225action=view)
preprocessed source
Added a self-contained .i file
Compile with -O2 = fails
Compile with -g = works
--
--- Comment #10 from tromey at gcc dot gnu dot org 2006-09-11 18:01 ---
Created an attachment (id=12226)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12226action=view)
valgrind report
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28096
--- Comment #11 from tromey at gcc dot gnu dot org 2006-09-11 18:06 ---
I compiled with -O1 and ran valgrind; the results were clean.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28096
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-09-11 18:18
---
-O2 -fno-gcse works.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from aldot at gcc dot gnu dot org 2006-09-11 18:26 ---
-pedantic-errors also has no effect. From a quick look, it does not occur in
fortran/* at all and should probably be removed.
I'm preparing an updated patch to add proper -Werror support that emits
'Warning' for
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-11 18:56 ---
http://gcc.gnu.org/ml/gcc-cvs/2006-09/msg00240.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Hello, Excuse me for my English because I learn English. I have found a bug for
convert a *.java to *.exe. When I would like use getCanonicalPath()or
getCanonicalFile() from class File in Java, I have a different results with the
*.class and the *.exe. I use Windows XP Home Edition. Can you
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu
2006-09-11 19:19 ---
Subject: Re: EXPONENT() broken for real constants
On Sun, Sep 10, 2006 at 10:43:21PM -, tobias dot burnus at physik dot
fu-berlin dot de wrote:
Comment #5 from tobias dot burnus at physik
The following (IMHO valid) code snippet triggers a segfault since GCC 3.4.0:
==
templateint struct A
{
void foo();
};
struct B
{
templateint N friend void AN::A::foo();
};
==
x1.cc:8:
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-09-11 19:28
---
Subject: Bug 28726
Author: ebotcazou
Date: Mon Sep 11 19:28:11 2006
New Revision: 116855
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116855
Log:
PR rtl-optimization/28726
* sched-deps.c
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-09-11 19:28
---
Subject: Bug 28726
Author: ebotcazou
Date: Mon Sep 11 19:28:41 2006
New Revision: 116856
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116856
Log:
PR rtl-optimization/28726
* sched-deps.c
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-09-11 19:32
---
Fixed in upcoming 4.1.2 release.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu
2006-09-11 19:33 ---
Subject: Re: EXPONENT() broken for real constants
On Mon, Sep 11, 2006 at 07:19:41PM -, sgk at troutmask dot apl dot
washington dot edu wrote:
gfortran is calling the wrong libm function.
The following invalid code snippet triggers a segfault since GCC 3.4.0:
==
struct A
{
templateint void foo()
{
A().template *foo0();
}
};
==
bug.cc: In member function 'void A::foo()':
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29021
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29020
The following invalid code snippet triggers a segfault since GCC 3.4.0:
==
struct A
{
operator int();
};
struct B : virtual A, A0 {};
int foo(B b)
{
return b;
}
==
bug.cc:6: error: expected
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29022
--- Comment #13 from dannysmith at users dot sourceforge dot net
2006-09-11 19:47 ---
In my sources for David Gay's gdtoa implemntation it say this:
/* On a machine with IEEE extended-precision registers, it is
* necessary to specify double-precision (53-bit) rounding precision
*
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-09-11 19:50 ---
(In reply to comment #2)
Please provide a testcase as well as the other required bits of info.
This is a stripped down cc1plus testcase:
void
f (unsigned char *a, int i)
{
i = a[0] 8 a[1];
}
This doesn't
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --enable-languages=c,c++,objc
--prefix=/software/linux/gcc/4.0.3
Thread model: posix
gcc version 4.0.3
The bug shows up with options -Os or -Ox (x = 1). Here is the source file:
main () {
unsigned char t1[1];
The following requires a diagnostic:
typedef static int T;
--
Summary: storage class specifier accepted for typedef (clause
7.1.1 ; 1)
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: accepts-invalid
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu
2006-09-11 20:31 ---
Subject: Re: EXPONENT() broken for real constants
On Mon, Sep 11, 2006 at 07:33:35PM -, sgk at troutmask dot apl dot
washington dot edu wrote:
I should also note that the parsing is
GCC configure data:
system type... i686-pc-cygwin
target system type... powerpc-xcoff-lynxos
build system type... i686-pc-cygwin
gcc -v
Reading specs from
/cross_compiler/tools/cygwin_ppc_gnu/lib/gcc/ppc-xcoff-lynxos/4.1.1/specs
Target: ppc-xcoff-lynxos
Configured with: gcc-4.1.1/configure
--- Comment #1 from mbo dot massimo at tiscali dot it 2006-09-11 20:36
---
Created an attachment (id=12227)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12227action=view)
source files to reproduce the problem
source file necessary to reproduce the bug.
Use gcc -S pkg_test.adb
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29025
--- Comment #6 from sje at cup dot hp dot com 2006-09-11 20:39 ---
It looks like this failure was introduced with r115620.
+2006-07-20 Paul Brook [EMAIL PROTECTED]
+
+ Backport from mainline.
+ PR 27363
+ * cse.c (cse_insn): Add destination addresses to hash table.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-11 20:48 ---
Fixed in 4.0.4 20060622.
This was either a dup of bug 26729 or bug 28045.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-11 20:50 ---
Confirmed, a regression from 3.4.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from sg313d at gmail dot com 2006-09-11 20:57 ---
Thank you for the fix. And for serving the GCC to the community. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28726
27.6.1.1 P4 says that formatted input functions should set badbit if a call to
fetch characters from the streambuf throws an exception.
The implementation of this in bits/istream.tcc is done after the sentry is
constructed. But the sentry's constructor may try to read whitespace, and it
is not
--- Comment #1 from jimrees at itasoftware dot com 2006-09-11 21:07 ---
Created an attachment (id=12228)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12228action=view)
bug reproducer program
bug reproducer, compile with g++ - any flags, but do not disable exceptions.
--
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |daney at gcc dot gnu dot org
|dot org
--- Comment #2 from jimrees at itasoftware dot com 2006-09-11 21:10 ---
fyi, a real world example of how this comes up? Construct a std::ifstream
using a pathname to a directory instead of a file. Under Linux and MacOS at
least, the basic_filebuf code is happy to open such a
According to clauses 7.3.3 ; 4 and 14.5.2 ; 7, the using declaration below
should elicit a diagnostic, since template conversion function specializations
are not supposed to be found by name lookup.
struct B
{
template class T operator T ();
};
struct D: B
{
using B::operator int;
};
--
--- Comment #3 from sebor at roguewave dot com 2006-09-11 21:25 ---
This sounds like it might be related to
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309. If so, and if
this case is important to you (the submitter) it might be helpful to give the
committee a little
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-11 21:27 ---
Confirmed, not a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from hjl at gcc dot gnu dot org 2006-09-11 21:30 ---
Subject: Bug 28672
Author: hjl
Date: Mon Sep 11 21:30:07 2006
New Revision: 116859
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116859
Log:
2006-09-11 Alexandre Oliva [EMAIL PROTECTED]
PR
--- Comment #13 from hjl at gcc dot gnu dot org 2006-09-11 21:34 ---
Subject: Bug 27537
Author: hjl
Date: Mon Sep 11 21:34:06 2006
New Revision: 116860
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116860
Log:
gcc/
2006-09-11 H.J. Lu [EMAIL PROTECTED]
PR target/13685
--- Comment #12 from hjl at gcc dot gnu dot org 2006-09-11 21:34 ---
Subject: Bug 28621
Author: hjl
Date: Mon Sep 11 21:34:06 2006
New Revision: 116860
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116860
Log:
gcc/
2006-09-11 H.J. Lu [EMAIL PROTECTED]
PR target/13685
--- Comment #22 from hjl at gcc dot gnu dot org 2006-09-11 21:34 ---
Subject: Bug 13685
Author: hjl
Date: Mon Sep 11 21:34:06 2006
New Revision: 116860
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116860
Log:
gcc/
2006-09-11 H.J. Lu [EMAIL PROTECTED]
PR target/13685
--- Comment #4 from amylaar at gcc dot gnu dot org 2006-09-11 21:45 ---
I suppose this is the same basic problem?
namespace N
{
int i;
}
void
f ()
{
using N::i;
using N::i;
}
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
I suppose it would make sense to emit a -Wunused warning for this code:
namespace N
{
int i;
}
void
f ()
{
using N::i;
}
--
Summary: No warning about unused names introduced with using
declarations
Product: gcc
Version: 4.2.0
[EMAIL PROTECTED] gujin]$ cat tmp.c
#include string.h
typedef struct {
unsigned short data[3];
union diskcmd {
unsigned udata[5];
unsigned char cdata[20];
} cmd;
} bootloader2_t;
bootloader2_t uninstall_mbr;
extern inline unsigned char
BOOT1_diskread (union
--- Comment #4 from jimrees at itasoftware dot com 2006-09-11 22:23 ---
Sure, the issue sounds interesting, and the committee's resolution statement is
definitely lame. Bug issue 309 seems to be more about what is _specified_
about sentry::sentry()'s behavior, and I don't necessarily
--- Comment #15 from sje at cup dot hp dot com 2006-09-11 22:31 ---
Bryce, have you looked at ifdef'ing the use of _Unwind_GetIPInfo in the Java
library? Would you be willing to do so? I have created an autoconf test
(GCC_CHECK_UNWIND_GETIPINFO) in trunk/config/unwind_ipinfo.m4 and
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last
--- Comment #5 from bero at arklinux dot org 2006-09-11 23:00 ---
Created an attachment (id=12229)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12229action=view)
Real test case
Oops, must have attached the wrong file, that was the test case for a much
older problem (PR24598,
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-09-11 23:01
---
Thank you for the fix. And for serving the GCC to the community. :)
You're welcome. Thanks for reporting the problem and for the nice testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28726
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-09-11 23:11
---
Fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28672
--- Comment #6 from tromey at gcc dot gnu dot org 2006-09-11 23:26 ---
Thanks for the updated test.
It fails for me if I compile it to .class with ecj, but not
if I compile it to .class with gcj.
The difference is in the qualification of the reference to
SUFFIX_CLASS in test2 .. ecj
--- Comment #5 from sebor at roguewave dot com 2006-09-12 00:16 ---
The reason why I think library issue 309 may be relevant is because while the
arithmetic extraction operator() is a formatted input function (and thus
subject to 27.6.1.1, p4, and required to begin by constructing a
--- Comment #4 from janis at gcc dot gnu dot org 2006-09-12 00:34 ---
Subject: Bug 28950
Author: janis
Date: Tue Sep 12 00:34:18 2006
New Revision: 116867
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116867
Log:
2006-09-11 Jack Howarth [EMAIL PROTECTED]
PR
--- Comment #15 from hjl at lucon dot org 2006-09-12 00:35 ---
Fixed:
http://gcc.gnu.org/ml/gcc-testresults/2006-09/msg00586.html
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #5 from janis at gcc dot gnu dot org 2006-09-12 00:42 ---
Subject: Bug 28950
Author: janis
Date: Tue Sep 12 00:42:27 2006
New Revision: 116868
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116868
Log:
2006-09-11 Jack Howarth [EMAIL PROTECTED]
PR
--- Comment #13 from hjl at gcc dot gnu dot org 2006-09-12 02:54 ---
Subject: Bug 28621
Author: hjl
Date: Tue Sep 12 02:54:42 2006
New Revision: 116870
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116870
Log:
gcc/
2006-09-11 H.J. Lu [EMAIL PROTECTED]
PR target/13685
--- Comment #23 from hjl at gcc dot gnu dot org 2006-09-12 02:54 ---
Subject: Bug 13685
Author: hjl
Date: Tue Sep 12 02:54:42 2006
New Revision: 116870
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116870
Log:
gcc/
2006-09-11 H.J. Lu [EMAIL PROTECTED]
PR target/13685
--- Comment #14 from hjl at gcc dot gnu dot org 2006-09-12 02:54 ---
Subject: Bug 27537
Author: hjl
Date: Tue Sep 12 02:54:42 2006
New Revision: 116870
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116870
Log:
gcc/
2006-09-11 H.J. Lu [EMAIL PROTECTED]
PR target/13685
--- Comment #1 from bangerth at dealii dot org 2006-09-12 03:58 ---
At first I thought that the warning is not useful since the variable may
in fact not be unused at all -- the using declaration simply makes the
name available in the present scope.
However, then I realized that this
--- Comment #5 from bangerth at dealii dot org 2006-09-12 04:00 ---
(In reply to comment #4)
I suppose this is the same basic problem?
No, that code is definitely legal and unobjectionable. Just as having two
extern declarations of the same variable in the same scope (or two forward
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-12 04:06 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-12 05:19 ---
6496 /* Only operator new(...) throw(), can return NULL [expr.new/13]. */
6497 if ((DECL_OVERLOADED_OPERATOR_P (current_function_decl) == NEW_EXPR
6498 || DECL_OVERLOADED_OPERATOR_P
--- Comment #7 from pault at gcc dot gnu dot org 2006-09-12 04:37 ---
Subject: Bug 28890
Author: pault
Date: Tue Sep 12 04:37:09 2006
New Revision: 116871
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116871
Log:
2006-09-12 Paul Thomas [EMAIL PROTECTED]
PR
1 - 100 of 131 matches
Mail list logo
