--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-05-16 07:52 ---
The patch in comment #3 isn't sufficient for cases where C++ class members get
their dllimport status from attribute applied to class type, rather than from
explicit attribute on the member.
--- Additional Comments From gdr at integrable-solutions dot net
2005-05-16 09:07 ---
Subject: Re: static_cast falsely allows const to be cast away
"schlie at comcast dot net" <[EMAIL PROTECTED]> writes:
| --- Additional Comments From schlie at comcast dot net 2005-05-16 05:07
-
--- Additional Comments From sven at clio dot in-berlin dot de 2005-05-16
10:22 ---
(In reply to comment #7)
> > Is there a way to distinguish between unions (which are not usable as base
> > classes) and classes? If not, the standard is incomplete.
>
> You should know that 10 year
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16
11:25 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--
What|Removed |Added
Known to work||4.0.1 4.1.0
Target Milestone|4.1.0 |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
Some more on the 4.0.1 prerelease (gcc-4.0-20050507).
While trying to reproduce a problem with the -Wunreachable-code I stumbled of
this. Using the compiler Switches -O2 -O3 give the wrong Line number (25) of the
unused code and also repeats the error message 14 times. Using -Os gives the
right lin
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16
11:50 ---
This is a bug in glibc's headers which inlines memset.
--
What|Removed |Added
St
URIs may contain special hexadecimal byte codes in the format %HH where H is a
hexadecimal digit, either upper or lowercase. (RFC 2396 2.4.1)
When given a string containing lowercase hex codes such as %2c, the URI
constructor throws a URISyntaxException.
Steps to reproduce:
1. new URI("/a%2cb")
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-16
11:59 ---
Subject: Bug 20270
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-16 11:58:49
Modified files:
gcc/ada: Makefile.in ChangeLog
Log message:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-16
11:59 ---
Subject: Bug 20270
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-16 11:58:49
Modified files:
gcc/ada: Makefile.in ChangeLog
Log message:
--- Additional Comments From brion at pobox dot com 2005-05-16 12:00
---
Created an attachment (id=8899)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8899&action=view)
Test case
$ javac UriBugDemo.java && java UriBugDemo
ok: /a,b
ok: /a%2C,b
ok: /a%2c,b
$ gcj-4.0 -o UriBugDemo -
Hi..
I am facing problem, when i am going for installing in
the binutil 2.13.1 for the target powerpc.eabi , GNU
cross compiler for ecos.
These are the following bugs are coming at the Build
and install the GNU binary utilities:
make -w all install 2>&1 | tee make.out
After giving this command
--
What|Removed |Added
Target Milestone|4.0.0 |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19704
--
What|Removed |Added
CC||aph at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21591
--
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21428
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-05-16
13:07 ---
You say that p.s doesn't work. Could you explain why? The code appears
to be functionally identical to q.s, the only difference being that p.s
allows the assembler to reorder the code and q.s does not.
T
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-05-16
13:11 ---
Andrew's right. You're telling gcc that init_fallthru() and fini_fallthru()
are global functions, but your asms define it to be a local function.
--
What|Removed |Adde
--- Additional Comments From schlie at comcast dot net 2005-05-16 13:25
---
(In reply to comment #9)
Subject: Re: static_cast falsely allows const to be cast away
> Gabriel Dos Reis writes:
>| --- Additional Comments From schlie at comcast dot net 2005-05-16
>| (In reply to commen
Hi,
Sorry for the missing information above. gcc -v did not supply the above
information and for reasons unknown to me gccbug was not installed on the
system in question.
Compiling with -O changes the results of this program.
double u_im = 0;
extern double atan(double);
extern int printf(con
--- Additional Comments From fsmith at mathworks dot com 2005-05-16 13:48
---
Created an attachment (id=8901)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8901&action=view)
Minimal self-contained C program exhibiting problem
The answer provided by this program changes depending o
--- Additional Comments From fsmith at mathworks dot com 2005-05-16 13:49
---
Created an attachment (id=8902)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8902&action=view)
Pre-processed version of previous attachment.
Preprocessed version of previous file. The previous C file w
--- Additional Comments From fsmith at mathworks dot com 2005-05-16 13:50
---
Information from gcc -save-temps -v follows:
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1495)
/usr/libexec/gcc/darwin/ppc
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-05-16
13:52 ---
It's a problem of tree-lowering. In .t02.original we still have
return = (int) (a && b);
in .t03.generic it's
bool doAnd(bool, bool) (a, b)
{
int D.1578;
bool iftmp.0;
bool D.1582;
bool D.1583
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16
13:53 ---
This is a bug in Apple's GCC, it uses fmadd instructions when it is not safe,
please report this to Apple,
I think it is fixed in Apple's 4.0.0 GCC based compiler.
--
What|Removed
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-05-16
13:55 ---
Maybe the same problem results in
static inline bool wrap(bool f) { return f; }
bool bar(bool f)
{
return wrap(f);
}
producing
return (int) (bool) (int) (bool) (int) f;
(and more, if you add an
Consider the testcase
static inline bool wrap(bool f) { return f; }
bool bar(bool f)
{
return wrap(f);
}
we have in t67.optimized
return (int) (bool) (int) (bool) (int) f;
and in t14.oplower
bool bar(bool) (f)
{
int D.1592;
bool f;
bool D.1583;
int D.1582;
int D.1581;
int
--- Additional Comments From joel at oarcorp dot com 2005-05-16 14:00
---
Subject: Re: Segfault while compiling
libgfortran/intrinsics/selected_int_kind.f90
corsepiu at gcc dot gnu dot org wrote:
> --- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-14
> 08:33 -
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16
14:02 ---
Confirmed, this is mostly a tree combiner issue, but trying on the stupid
version of the tree combiner it
does not work, I don't know why yet.
--
What|Removed |Added
--
--- Additional Comments From fsmith at mathworks dot com 2005-05-16 14:04
---
How do I report it to Apple? On their site
http://developer.apple.com/documentation/DeveloperTools/gcc-3.3/gcc/gccbug.html#gccbug
they told me to report it here (effectively). But since, for reasons unknown
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-16
14:05 ---
(In reply to comment #24)
> Subject: Re: Segfault while compiling
libgfortran/intrinsics/selected_int_kind.f90
>
> corsepiu at gcc dot gnu dot org wrote:
>
> > Joel, do you recall the target in RTEMS whi
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16
14:08 ---
(In reply to comment #5)
> How do I report it to Apple? On their site
>
> http://developer.apple.com/documentation/DeveloperTools/gcc-3.3/gcc/gccbug.html#gccbug
http://bugreport.apple.com
--
http://gc
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aph at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From hjl at lucon dot org 2005-05-16 15:48 ---
Bug 21382 is a duplicate of bug 19664, which also requires the libstdc++
change.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
--- Additional Comments From mark at gcc dot gnu dot org 2005-05-16 16:03
---
The paperwork cleared with the FSF.
There was a glitch in the new "fully-automatic" system.
Apologies.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20504
There is an issue with array_allocator, which clearly surfaced while working
on libstdc++/19495. In a nutshell, the templated copy-constructor doesn't seem
to
play well with rebinds: after a rebind, the first copy-constructor call leads
to _M_array = 0 and no memory can be possibly returned by all
--- Additional Comments From pcarlini at suse dot de 2005-05-16 16:30
---
Forgot to say: probably the issue can be dealt with at the cost of increasing
its complexity. Logic could be added to the copy-constructor(s) to the effect
of keeping on using the existing allocated memory, i.e., n
--- Additional Comments From gdr at integrable-solutions dot net
2005-05-16 17:00 ---
Subject: Re: static_cast falsely allows const to be cast away
"schlie at comcast dot net" <[EMAIL PROTECTED]> writes:
| (In reply to comment #9)
| Subject: Re: static_cast falsely allows const to be
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16
17:41 ---
Templates are never copy constructors.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21609
--- Additional Comments From pcarlini at suse dot de 2005-05-16 17:51
---
Yes, sorry ;) (12.8). Summary fixed.
--
What|Removed |Added
Summary|array_allocator vs r
--- Additional Comments From rth at gcc dot gnu dot org 2005-05-16 18:14
---
True. I remember trying this, though, and in practice all it did was increase
register pressure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21588
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-16
18:23 ---
Subject: Bug 21556
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-16 18:22:50
Modified files:
gcc: ChangeLog
gcc/config/ia64: i
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16
18:24 ---
(In reply to comment #2)
> Templates are never copy constructors.
Just to clarify just in case some mistakes this for something different.
template member functions cannot be considered a copy constructor.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-16
18:26 ---
Subject: Bug 21556
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-16 18:25:50
Modified files:
gcc: Change
--- Additional Comments From rth at gcc dot gnu dot org 2005-05-16 18:26
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
struct S { char s; };
struct T { struct S t; };
struct S *const p = &((struct T * const) (0x4000))->t;
void
foo (void)
{
p->s = 0;
}
ICEs at -O2 e.g. on {x86_64,i386}-linux on gcc-4_0-branch. On HEAD it seems to
work by luck.
The problem seems to be tree sharing between p's initializer a
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-16
19:02 ---
Subject: Bug 20504
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-16 19:01:52
Modified files:
libjava: ChangeLog
libjava/gnu/regexp
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-16
19:03 ---
Subject: Bug 20504
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-16 19:03:02
Modified files:
libjava: Change
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-16
19:06 ---
I checked this in everywhere.
Thanks for taking the time to write the test cases, that is excellent.
--
What|Removed |Added
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16
19:15 ---
Hmm, shouldn't we unshare the tree when copy the value of p in? (oh that is
what your patch does).
I wonder if we can just get rid of
decl_constant_value_for_broken_optimization/decl_constant_value.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16
19:17 ---
Oh, I think the reason why the mainline does not create a new tree is because
we don't gimple twice.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21610
--- Additional Comments From ziga dot mahkovec at klika dot si 2005-05-16
19:18 ---
> I checked this in everywhere.
I was about to go through the procedure myself, but thanks anyway.
There was a typo in my initial ChangeLog entry though:
@@ -1,4 +1,4 @@
2005-03-17 Ziga Mahkovec <[EM
--- Additional Comments From gdr at integrable-solutions dot net
2005-05-16 19:19 ---
Subject: Re: Possible bug
"sven at clio dot in-berlin dot de" <[EMAIL PROTECTED]> writes:
| (In reply to comment #7)
| > > Is there a way to distinguish between unions (which are not usable as
base
--- Additional Comments From dje at gcc dot gnu dot org 2005-05-16 19:45
---
The testcase pr19155.f fails on AIX. I am confused if this is suppose to work
after the patch or not. Either the testcase should be XFAILed or something else
is wrong with the patch.
--
http://gcc.gnu.org/
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From hp at gcc dot gnu dot org 2005-05-16 19:48
---
I don't see a blame for this regression, so here goes.
Passed with LAST_UPDATED "Wed May 11 04:48:16 UTC 2005" on cris-elf and
mmix-knuth-mmixware, failed with "Wed May 11 12:21:26 UTC 2005" and since.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16
19:53 ---
Or it might be the testcase which is matching it wrong, someone already asked
about this testcase
before on IRC (IIRC) and the regex was just matching wrongly.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16
19:54 ---
Again this is a latent target bug, Devang's patch just exposed the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21050
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-05-16
19:57 ---
2005-05-11 Richard Guenther <[EMAIL PROTECTED]>
PR middle-end/19807
PR tree-optimization/19639
* fold-const.c (try_move_mult_to_index): Handle INTEGER_CST
and generic summa
Successfully built Ada compiler. When performing acats test, the test summary
shown below indicates the failures.
make: Entering directory `/cygdrive/d/Build-Ada/gcc'
test -d testsuite/ada/acats || mkdir -p testsuite/ada/acats
testdir=`cd ../../gcc-4.0-20050430/gcc/testsuite/ada/acats; ${PWDCMD-p
--- Additional Comments From joseph at codesourcery dot com 2005-05-16
20:01 ---
Subject: Re: [4.0/4.1 Regression] ICE in
make_decl_rtl
On Mon, 16 May 2005, pinskia at gcc dot gnu dot org wrote:
> Hmm, shouldn't we unshare the tree when copy the value of p in? (oh that is
> what you
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16
20:03 ---
(In reply to comment #3)
> If you get rid of decl_constant_value_for_broken_optimization then I
> suspect you'll lose some optimizations because fold doesn't operate on SSA
> so some constant values won't
--- Additional Comments From joseph at codesourcery dot com 2005-05-16
20:05 ---
Subject: Re: [4.1 Regression] gcc.dg/tree-ssa/loop-4.c
scan-tree-dump-times iter 0 fails
On Mon, 16 May 2005, pinskia at gcc dot gnu dot org wrote:
> Or it might be the testcase which is matching it wron
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-16
20:10 ---
I'm testing a patch.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |
--- Additional Comments From joseph at codesourcery dot com 2005-05-16
20:11 ---
Subject: Re: [4.1 Regression] vect-none.c ICE
On Mon, 16 May 2005, pinskia at gcc dot gnu dot org wrote:
> Again this is a latent target bug, Devang's patch just exposed the problem.
We don't make a dist
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-16
20:19 ---
Testcase pr19155.f does not fail on i386-linux, i686-freebsd and sparc-solaris.
With the patch committed, it is supposed to work. Can you investigate further
(compile the testcase manually and see why it f
--- Additional Comments From janis at gcc dot gnu dot org 2005-05-16 20:27
---
sixtrack and the testcase smsbug.f still fail on powerpc64-linux when compiled
with mainline GCC with the options "-m64 -O2 -fmodulo-sched". The other
failures with those options mentioned in comment #4 have
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-16
20:27 ---
Subject: Bug 21606
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-16 20:27:48
Modified files:
libjava: ChangeLog
libjava/java/net:
--- Additional Comments From joseph at codesourcery dot com 2005-05-16
20:28 ---
Subject: Re: [4.0/4.1 Regression] ICE in
make_decl_rtl
On Mon, 16 May 2005, pinskia at gcc dot gnu dot org wrote:
>
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16
> 20:03
--- Additional Comments From jason at redhat dot com 2005-05-16 20:28
---
Subject: Re: New: C++ front-end accepts "new" with VLAs
On 16 May 2005 02:16:51 -, "mmitchel at gcc dot gnu dot org" <[EMAIL
PROTECTED]> wrote:
> Steve Adamczyk has indicated that he feels that permitting d
On May 16, 2005, at 4:28 PM, joseph at codesourcery dot com wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org
2005-05-16 20:03 ---
(In reply to comment #3)
If you get rid of decl_constant_value_for_broken_optimization then I
suspect you'll lose some optimizations because
--- Additional Comments From pinskia at physics dot uc dot edu 2005-05-16
20:34 ---
Subject: Re: [4.0/4.1 Regression] ICE in make_decl_rtl
On May 16, 2005, at 4:28 PM, joseph at codesourcery dot com wrote:
>> --- Additional Comments From pinskia at gcc dot gnu dot org
>> 2005-05
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-16
20:35 ---
Subject: Bug 21606
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-16 20:35:23
Modified files:
libjava: Change
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-16
20:39 ---
I've checked in the fix.
Thanks for the simple test case.
--
What|Removed |Added
--- Additional Comments From janis at gcc dot gnu dot org 2005-05-16 20:41
---
The failure still exists with mainline GCC built last night:
elm3b145% /opt/gcc-nightly/mline-20050516/bin/gcc -O2 -ftree-vectorize -maltivec
-m64 crafty_bug.c
crafty_bug.c: In function main:
crafty_bug.c
See below(âEâ), it's trashed quote or something of that kind.
Yuri
--begin code--
E e;
--end code--
--begin error--
x.C:3: error: âEâ does not name a type
--end error--
--
Summary: Strange symbols printed all over the error messages
Product: gcc
Version: 4.0.0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16
20:52 ---
It is UTF-8 character, read the changes page. Basically you LANG/LN_*
environment variable says your
terminal supports UTF-8 but in reality it does not.
--
What|Removed
--- Additional Comments From yuri at Magma-DA dot COM 2005-05-16 21:05
---
Subject: Re: Strange symbols printed all over the error messages
Agree, I must have wrong setting.
But how does compiler with US English languege benefit of UTF anyways?
Isn't it better practice to not step on
--- Additional Comments From pinskia at physics dot uc dot edu 2005-05-16
21:07 ---
Subject: Re: Strange symbols printed all over the error messages
On May 16, 2005, at 5:04 PM, Yuri wrote:
> Agree, I must have wrong setting.
>
> But how does compiler with US English languege benefit
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16
21:27 ---
I have a patch for this.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
--- Additional Comments From dalej at gcc dot gnu dot org 2005-05-16 21:44
---
OK, what happens is that tail call creates a block 0 with multiple
predecessors, and the
out-of-ssa pass mangles that into this form:
# BLOCK 0
# PRED: 9 [14.9%] (true,exec) 1 [29.0%] (true,exec)
:;
--- Additional Comments From mrd at alkemio dot org 2005-05-16 22:34
---
(In reply to comment #5)
> Mark as invalid.
Why?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506
--- Additional Comments From fitzsim at redhat dot com 2005-05-16 22:45
---
Renamed libgcjawt.so on mainline. Closing.
--
What|Removed |Added
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16
22:54 ---
(In reply to comment #4)
> where ENTRY no longer falls into block 0, but is expected to jump to block
> 12. Expand has no
> idea such a thing is possible and falls through anyway. While it's not
> obviou
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16
22:57 ---
(In reply to comment #7)
> (In reply to comment #5)
> > Mark as invalid.
>
> Why?
Did you read comment #1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-16
23:14 ---
Subject: Bug 21399
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-16 23:14:02
Modified files:
gcc: ChangeLog tree-eh.c tree-flow.h tree-
--- Additional Comments From rth at gcc dot gnu dot org 2005-05-16 23:16
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From mrd at alkemio dot org 2005-05-17 00:33
---
(In reply to comment #8)
> Did you read comment #1.
Yes, but it's not clear.
> GCC doesn't know what constitutes a reference to a volatile memory
Is this to say the GCC developers believe the C language's definit
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-17
01:46 ---
Subject: Bug 21140
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-17 01:46:06
Modified files:
libjava: Change
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-17
01:50 ---
Fix checked in.
--
What|Removed |Added
Status|ASSIGNED|RESOL
The following gives "internal compiler error: in extract_insn, at
recog.c:2083", only with -fpic:
arm-softfloat-linux-gnu-g++ -fpic ../c/noerror/GPL/20010107-1.c
20010107-1.c is a C Torture file, containing only the following:
unsigned long x[4];
void foo(void)
{
((void
--- Additional Comments From flash at pobox dot com 2005-05-17 03:26
---
See also 19960 (darwin/m6811-elf) and 21613 (i686-linux/arm-linux).
--
What|Removed |Added
--- Additional Comments From flash at pobox dot com 2005-05-17 03:27
---
See also 19770 (hppa64/hppa64) and 21613 (i686-linux/arm-linux).
--
What|Removed |Added
--- Additional Comments From bernie at develer dot com 2005-05-17 05:40
---
I'm still seeing the artsd miscompilation with
gcc 4.0.0 20050512 (Red Hat 4.0.0-5), which contains everything
from gcc-4_0-branch upto 13-05-2005 (circa).
This is from an arts *client*:
Starting program: /home
gcc 4.0.0 generates code that has line (**) ignored (nothing is invoked in it's
place).
I am not sure in what kind of relationship does this code stand with C++
standard.
But although structure X::Z is undefined, technically method Y::r can be invoked
safely since X::Z definition isn't required
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-17
06:31 ---
Subject: Bug 15080
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-17 06:31:51
Modified files:
gcc/fortran: ChangeLog
gcc/testsuite : C
/testsuite : ChangeLog
Added files:
gcc/testsuite/gcc.c-torture/compile: 20050516-1.c
Log message:
PR tree-optimization/21610
* c-typeck.c (decl_constant_value_for_broken_optimization): If not
returning DECL, call unshare_expr.
* gcc.c-torture
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-17
06:48 ---
Subject: Bug 21492
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-17 06:48:19
Modified files:
gcc: ChangeLog cfgcleanup.c
gcc/t
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-17
06:51 ---
Subject: Bug 21454
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-17 06:51:48
Modified files:
gcc/testsuite : ChangeLog
gcc/cp : C
98 matches
Mail list logo
