--- Comment #2 from chat95 at mac dot com 2005-12-03 07:58 ---
BTW: GCJ works perfectly.
% gcj -o foo --main=JREProperties JREProperties.java
% ./foo
112 97 116 104 46 115...
...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25239
--- Comment #1 from chat95 at mac dot com 2005-12-03 07:56 ---
Created an attachment (id=10396)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10396&action=view)
A file doesn't work properly with gij (gcc-4.1-20051125 snapshot)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=252
For i386-unknown-freebsd6.0 and gcc 4.1-20051125 snapshot,
For attached JREProperties.java, gij doesn't work properly, e.g:
% gcj -C JREProperties.java
% gij JREProperties
Abort (core dumped)
but JDK 1.4.2, JREProperties.class works perfectly.
% /usr/local/jdk1.4.2/bin/java JREProperties
106 97 1
--- Comment #3 from amodra at bigpond dot net dot au 2005-12-03 04:34
---
Author: amodra
Date: Sat Dec 3 04:26:37 2005
New Revision: 107992
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107992
Log:
PR rtl-optimization 25197
* dwarf2out.c (dwarf2out_frame_debug_
--- Comment #2 from amodra at bigpond dot net dot au 2005-12-03 04:29
---
Root cause already fixed.
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
--- Comment #15 from gdr at integrable-solutions dot net 2005-12-03 04:20
---
Subject: Re: exception_defines.h #defines try/catch
"hhinnant at apple dot com" <[EMAIL PROTECTED]> writes:
| --- Comment #14 from hhinnant at apple dot com 2005-12-03 01:25 ---
| (In reply to comm
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-03
03:19 ---
Subject: Re: [4.1/4.2 regression] gthr-dce.h:77: error: expected expression
before '{' token
> Created an attachment (id=10362)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10362&action=view)
> --
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-12-03 03:11 ---
I think you need to read
http://gcc.gnu.org/gcc-4.1/changes.html
It lists some of these issues.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25238
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-03 03:10 ---
(In reply to comment #4)
> Created an attachment (id=10395)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10395&action=view) [edit]
> gzipped preprocessed file for _cdsVector.cc from gcc 4.1.0
That is a differ
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2005-12-03
02:53 ---
Created an attachment (id=10395)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10395&action=view)
gzipped preprocessed file for _cdsVector.cc from gcc 4.1.0
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2005-12-03
02:50 ---
Andrew,
Thanks. For now the -ffriend-injection solves the problem. However,
there is one other compile issue with g++ 4.1.0 which the -ffriend-injection
doesn't fix (and I assumed was the same issue
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-03 02:03 ---
This is not a bug, it comes down to something like:
class a
{
friend void f(void);
};
int main(void)
{
f();
}
void f(void) {}
Friends don't inject into the scope at all.
In enumNameMap.hh, we have:
class
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2005-12-03
01:57 ---
Created an attachment (id=10394)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10394&action=view)
preprocessed file for posRMSDPot.cc from gcc 4.1.0
Target: powerpc-apple-darwin8
Configured with: ../
Regression in compiling c++. The file posRMSDPot.cc from the xplor-nih package
no longer compiles under g++ of gcc 4.1.0 but shows the compile error...
posRMSDPot.cc: In member function 'void PosRMSDPot::addRestraints(const
String&)':
posRMSDPot.cc:145: error: no match for 'operator>>' in 'iNoComm
--- Comment #14 from hhinnant at apple dot com 2005-12-03 01:25 ---
(In reply to comment #13)
> Subject: Re: exception_defines.h #defines try/catch
>
> I'm saying that if you're intending to use try/catch and yet not
> want what the mean in standard C++, nor what they would mean in GNU
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-03
01:10 ---
Subject: Re: FAIL: g++.dg/warn/huge-val1.C (test for excess errors)
> This test is for (or whatever headers define HUGE_VAL
> etc.), not . should indeed be fixincluded,
> but there may be definitions
--- Comment #14 from mmitchel at gcc dot gnu dot org 2005-12-03 01:03
---
Fixed in 4.0.3.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #13 from gdr at integrable-solutions dot net 2005-12-03 01:02
---
Subject: Re: exception_defines.h #defines try/catch
"hhinnant at apple dot com" <[EMAIL PROTECTED]> writes:
| (In reply to comment #8)
| > Subject: Re: exception_defines.h #defines try/catch
| >
| > "hhin
--- Comment #13 from mmitchel at gcc dot gnu dot org 2005-12-03 01:02
---
Subject: Bug 24173
Author: mmitchel
Date: Sat Dec 3 01:02:33 2005
New Revision: 107983
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107983
Log:
PR c++/24173
* decl.c (duplicate_decls):
--- Comment #12 from gdr at integrable-solutions dot net 2005-12-03 00:58
---
Subject: Re: exception_defines.h #defines try/catch
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| We really should not be defining keywords in the headers at all. If we
define
| bool somew
--- Comment #12 from mmitchel at gcc dot gnu dot org 2005-12-03 00:57
---
Subject: Bug 24173
Author: mmitchel
Date: Sat Dec 3 00:57:34 2005
New Revision: 107980
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107980
Log:
PR c++/24173
* decl.c (duplicate_decls):
--- Comment #11 from mmitchel at gcc dot gnu dot org 2005-12-03 00:57
---
Subject: Bug 24173
Author: mmitchel
Date: Sat Dec 3 00:56:57 2005
New Revision: 107979
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107979
Log:
PR c++/24173
* decl.c (duplicate_decls):
--- Comment #10 from mmitchel at gcc dot gnu dot org 2005-12-03 00:54
---
Subject: Bug 24173
Author: mmitchel
Date: Sat Dec 3 00:54:17 2005
New Revision: 107978
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107978
Log:
PR c++/24173
* decl.c (duplicate_decls):
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-12-03 00:54
---
Subject: Bug 24173
Author: mmitchel
Date: Sat Dec 3 00:54:01 2005
New Revision: 107977
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107977
Log:
PR c++/24173
* decl.c (duplicate_decls): D
--- Comment #3 from joseph at codesourcery dot com 2005-12-03 00:51 ---
Subject: Re: FAIL: g++.dg/warn/huge-val1.C (test for excess
errors)
On Sat, 3 Dec 2005, pinskia at gcc dot gnu dot org wrote:
> Hmm, limits.h should have been fixincluded but for some reason it was not.
This tes
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-03 00:40 ---
(In reply to comment #2)
> A warning would be really nice.
The warning was filed as PR 14024 and fixed for 4.2.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25235
--- Comment #2 from cdfrey at netdirect dot ca 2005-12-03 00:32 ---
Thanks for the info!
I can understand the examples in the article at
http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html but with my example
source code in this bug report, I can't seem to follow the optimizatio
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-03
00:14 ---
Subject: Re: FAIL: g++.dg/warn/huge-val1.C (test for excess errors)
> Hmm, limits.h should have been fixincluded but for some reason it was not.
Seems to be in gcc/include. It's possible there's somethin
Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/xgcc
-B/mnt/gnu/gcc-3.3/objdir/gc
c/ /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/tree-ssa/20031106-6.c -O1
-fdump-
tree-optimized -fno-show-column -S -o 20031106-6.s(timeout = 300)
PASS: gcc.dg/tree-ssa/20031106-6.c (test for excess errors)
FAIL:
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-03 00:05 ---
Hmm, limits.h should have been fixincluded but for some reason it was not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25236
Executing on host: /home/dave/gcc-4.1/objdir/gcc/testsuite/../g++
-B/home/dave/g
cc-4.1/objdir/gcc/testsuite/../
/home/dave/gcc-4.1/gcc/gcc/testsuite/g++.dg/warn
/huge-val1.C -nostdinc++
-I/home/dave/gcc-4.1/objdir/hppa-linux/libstdc++-v3/in
clude/hppa-linux -I/home/dave/gcc-4.1/objdir/hppa-linux/
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-12-02 23:35 ---
(In reply to comment #5)
> I would agree except for the fact that the results vary with g++ version, not
> gdb version.
Does that really matter as if debug info changes slightly and gdb does not
handle valid debug i
--- Comment #78 from pinskia at gcc dot gnu dot org 2005-12-02 23:32
---
*** Bug 25235 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-02 23:32 ---
You are violating C++ aliasing rules:
uint64_t back = pa_bswap_64(conv);
double d2 = *((double*)&back);
*** This bug has been marked as a duplicate of 21920 ***
--
pinskia at gcc dot gnu dot org
--- Comment #5 from schaudhu at blackrock dot com 2005-12-02 23:31 ---
I would agree except for the fact that the results vary with g++ version, not
gdb version.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25234
GCC version: g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.2/configure
--prefix=/home/source5/rootdir-gcc402 --enable-languages=c,c++
--enable-concept-checks
Thread model: posix
gcc version 4.0.2
Sample code that reprodu
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-02 23:29 ---
gcc produces debuging info for each of the variables, so maybe again this is
gdb bug:
.stabs "mfacts:(1,1)",128,0,37,-41
.stabn 192,0,0,.LBB2-.LFB994
.stabs "rcode:(0,1)",128,0,23,-12
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-02 23:26 ---
mfacts is in the debug info so that is not a GCC bug but a gdb bug. (even with
dwarf-2).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25234
--- Comment #2 from schaudhu at blackrock dot com 2005-12-02 23:23 ---
I tried all three. -ggdb produces more info per symbol, but does not change
the number of symbols.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25234
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-02 23:20 ---
Is there a reason why you are using -gstabs+ and not just -g or -ggdb which are
more likely to enable dwarf-2 and not stabs plus GNU extensions?
--
pinskia at gcc dot gnu dot org changed:
What|Rem
Different results on all three versions of g++ [2.95.3, 3.3.3, 4.0.0].
Only 2.95.3 produces the desired output.
After investigating the bug list, several potential duplicates have been
dismissed as not being the same issue, as listed below:
8542
10156
11098
24526
The issue was first noticed on
--- Comment #13 from jakub at gcc dot gnu dot org 2005-12-02 22:58 ---
Subject: Bug 25199
Author: jakub
Date: Fri Dec 2 22:58:33 2005
New Revision: 107957
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107957
Log:
PR target/25199
* config/i386/i386.md (movqi_1):
--- Comment #12 from jakub at gcc dot gnu dot org 2005-12-02 22:57 ---
Subject: Bug 25199
Author: jakub
Date: Fri Dec 2 22:57:03 2005
New Revision: 107956
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107956
Log:
PR target/25199
* config/i386/i386.md (movqi_1):
--- Comment #11 from jakub at gcc dot gnu dot org 2005-12-02 22:55 ---
Subject: Bug 25199
Author: jakub
Date: Fri Dec 2 22:55:35 2005
New Revision: 107955
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107955
Log:
PR target/25199
* config/i386/i386.md (movqi_1):
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #17 from pinskia at gcc dot gnu dot org 2005-12-02 21:53
---
Oh, and another case where we can get the parallel is for returning 128bit
structs on x86_64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24823
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-12-02 21:33 ---
It looks like not a single RTL optimizer triggering. It's bad from expand on,
and I guess having all mems around from the start is not making it easy.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25227
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25225
--- Comment #11 from hhinnant at apple dot com 2005-12-02 21:21 ---
(In reply to comment #10)
> (In reply to comment #9)
> > Not being someone with a lot of FE experience, I have more hesitation about
> > this latter approach.
>
> That solution still does not solve my issue of the diag
libgcc-std.ver includes __unordsf2 and __unorddf2. It should also include
__unordxf2 and __unordtf2 (in an appropriate version for when they get added -
GCC_4.2.0 if added mainline only, GCC_4.1.0 or GCC_4.0.3 or GCC_3.4.6 if also
added to a release branch, not GCC_3.3.4 alongside __unordsf2 and _
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-02 21:14 ---
(In reply to comment #2)
> I really don't think that the reply addresses the question. If a function
> returns an object it has to call a copy constructor. This code compiles if the
> copy constructor is declared as
--- Comment #2 from richard at rggibbs dot com 2005-12-02 21:11 ---
I really don't think that the reply addresses the question. If a function
returns an object it has to call a copy constructor. This code compiles if the
copy constructor is declared as
t1(const t1& tr);
but fails if de
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-12-02 21:06
---
(In reply to comment #9)
> Not being someone with a lot of FE experience, I have more hesitation about
> this latter approach.
That solution still does not solve my issue of the diagnostic issue.
We really sho
--- Comment #9 from hhinnant at apple dot com 2005-12-02 21:00 ---
(In reply to comment #8)
> Subject: Re: exception_defines.h #defines try/catch
>
> "hhinnant at apple dot com" <[EMAIL PROTECTED]> writes:
>
> | --- Comment #5 from hhinnant at apple dot com 2005-12-02 19:07 -
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-02 20:53 ---
This is expected and how C++ works.
t1(t1& tr);
is a copy constructor which only takes references which means it only takes
lvalues.
t1 dosomething(const t1& v) const;
That means it returns a variable and calling tha
The following code fails to compile because the copy constructor has a non
const argument - it works if the const qualifier is added to the input:
class t1 {
public:
t1(t1& tr);
t1 dosomething(const t1& v) const;
t1 dosamethingagain(const t1& v) const { return dosomething(v); }
t1 operat
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-02 20:44 ---
Actually it should generate code like:
lock; addl $-1,(%rdi)
jne .L4
jmp release
.L4:
ret
---
The lock is fully needed for correct behavior.
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-02 20:10 ---
*** Bug 25228 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25230
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-02 20:10 ---
*** This bug has been marked as a duplicate of 25230 ***
*** This bug has been marked as a duplicate of 25230 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-02 20:10 ---
I forgot one more thing, from local allocate:
;; Register 61 in 5.
;; Register 64 in 0.
;; Register 65 in 2.
Why are we putting reg 64 in ax, it says:
Register 64 used 2 times across 4 insns in block 3; set 1 time;
The program below should generate code that looks something like:
fput:
addl $-1,(%rdi)
jne .L4
jmp release
.L4:
ret
But instead generates:
fput:
movl$-1, %eax
lock
xaddl %eax, (%rdi)
decl%eax
jne .L4
jmp release
.p2al
--- Comment #2 from bcrl at kvack dot org 2005-12-02 20:06 ---
The attached program should generate code that looks something like:
fput:
addl $-1,(%rdi)
jne .L4
jmp release
.L4:
ret
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25229
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-02 20:05 ---
*** Bug 25229 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25228
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-02 20:05 ---
*** This bug has been marked as a duplicate of 25228 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
Summary: __sync_add_and_fetch cannot use condition flags from
subl
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc do
--
Summary: __sync_add_and_fetch cannot use condition flags from
subl
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc do
--- Comment #8 from gdr at integrable-solutions dot net 2005-12-02 19:29
---
Subject: Re: exception_defines.h #defines try/catch
"hhinnant at apple dot com" <[EMAIL PROTECTED]> writes:
| --- Comment #5 from hhinnant at apple dot com 2005-12-02 19:07 ---
| (In reply to commen
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-12-02 19:28
---
Confirmed.
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #6 from gdr at integrable-solutions dot net 2005-12-02 19:18
---
Subject: Re: exception_defines.h #defines try/catch
I agree with Benjamin.
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| I personally would like this fixed in libstdc++ as it is changing
|
--- Comment #7 from gdr at integrable-solutions dot net 2005-12-02 19:23
---
Subject: Re: exception_defines.h #defines try/catch
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Confirmed. This also causes problems in normal C++ code which does:
|
| #include
|
| int
--- Comment #6 from wilson at gcc dot gnu dot org 2005-12-02 19:16 ---
Oops. That patch should have a "| PROP_AUTOINC" in the new update_life_info
call. That would explain why I was seeing some unexpected de-optimizations
with the patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #5 from hhinnant at apple dot com 2005-12-02 19:07 ---
(In reply to comment #2)
> I'd rather you work around this in objective-c or objective c++.
How? I'm open to suggestions.
-Howard
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-02 19:04 ---
Confirmed. This also causes problems in normal C++ code which does:
#include
int f(void);
int main(void)
{
try {
f();
}catch (a) {}
}
Without the include, you get an error but with the include, you don't w
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-02 19:01 ---
(In reply to comment #2)
> We are trying to keep the libstc++ code as clean and representative of
> standards-conforming C++ code as possible, and have avoided __try, __catch,
> etc. or other uglification in favor of
--- Comment #2 from bkoz at gcc dot gnu dot org 2005-12-02 18:59 ---
We are trying to keep the libstc++ code as clean and representative of
standards-conforming C++ code as possible, and have avoided __try, __catch,
etc. or other uglification in favor of the actual C++ terms, ie try, ca
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-02 18:41 ---
Confirmed.
local allocate does:
Register 58 used 6 times across 12 insns; set 2 times; user var; dies in 2
places; pref AREG, else GENERAL_REGS.
Which says that reg 58 prefers (r)ax.
And then global allocate says/d
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25227
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-02 18:26 ---
Confirmed, Even though it is returned on the registers:
(call_insn 13 12 14 (set (parallel:BLK [
(expr_list:REG_DEP_TRUE (reg:DI 0 ax)
(const_int 0 [0x0]))
(expr_l
--- Comment #2 from hubicka at gcc dot gnu dot org 2005-12-02 18:21 ---
testing patch:
2005-12-02 Jan Hubicka <[EMAIL PROTECTED]>
* tree-ssa-loop-unswitch.c (tree_unswitch_single_loop): Free copy
tables.
Index: tree-ssa-loop-unswitch.c
==
--- Comment #10 from hubicka at gcc dot gnu dot org 2005-12-02 18:14
---
Testing patch:
2005-12-02 Jan Hubicka <[EMAIL PROTECTED]>
PR target/24969
* i386.c (classify_argument): Properly adjust offset of bitfield for
substructures.
Index: config/i386/i386.c
The following test program spills res onto the stack when the value res.result,
which is already in a register, should be passed in a register to
foo();
/* compile with: gcc -fomit-frame-pointer -S */
struct rw_res {
long result;
long pos_update;
};
struct file {
long f_p
--- Comment #8 from pcarlini at suse dot de 2005-12-02 18:13 ---
If my analysis is correct, this PR is still valid *only* for targets not
defining _GLIBCXX_HAVE_TLS. Otherwise, fixed by:
2005-11-21 Benjamin Kosnik <[EMAIL PROTECTED]>
Ulrich Drepper <[EMAIL PROTECTED]>
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-02 18:12 ---
ok, I have a fix without rewritting some of fold_binary. I just needed to
added a check for BIT_XOR_EXPR comming back, like invert_expr does.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23673
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2005-12-02 18:08
---
Commited to mainline, waiting a bit before committing to 4.1.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from pcarlini at suse dot de 2005-12-02 18:07 ---
Ah! Now I see, it's because of Benjamin and Ulrich recent changes, involving
thread local storage. Therefore my amended testcase proposal should be fine on
platforms not defining _GLIBCXX_HAVE_TLS. We should check that.
-
--- Comment #6 from pcarlini at suse dot de 2005-12-02 18:02 ---
Created an attachment (id=10392)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10392&action=view)
Puzzling testcase...
Humm, strange. The new testcase *passes*... Still, the original analysis makes
a lot of sense to
--- Comment #5 from pcarlini at suse dot de 2005-12-02 17:51 ---
... possibly using a "real" memory allocation, touching all the involved pages.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24025
--- Comment #4 from pcarlini at suse dot de 2005-12-02 17:50 ---
Sorry. Actually the testcase is not correct stand-alone, fails at line 13. I'm
currently checking whether is correct when the testsuite support (memory
limits) is present.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #32 from pinskia at gcc dot gnu dot org 2005-12-02 17:46
---
*** Bug 25221 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-02 17:46 ---
This is a dup of bug 11203.
*** This bug has been marked as a duplicate of 11203 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #16 from rth at gcc dot gnu dot org 2005-12-02 17:45 ---
Subject: Bug 22480
Author: rth
Date: Fri Dec 2 17:45:02 2005
New Revision: 107910
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107910
Log:
2005-09-14 Uros Bizjak <[EMAIL PROTECTED]>
PR middle-end/
--- Comment #31 from pinskia at gcc dot gnu dot org 2005-12-02 17:44
---
*** Bug 25226 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-02 17:44 ---
This is a dup of bug 11203, This is not really a bug. You are trying to use 8
registers but there are not 8 register there.
*** This bug has been marked as a duplicate of 11203 ***
*** This bug has been marked as
--- Comment #24 from aph at gcc dot gnu dot org 2005-12-02 17:43 ---
This is great, but an additional test case for dynamic method invocation is
needed.
We need to be able to continue if a class T that contains a method that refers
to a missing class M is initialized. At that time, the
--- Comment #3 from pcarlini at suse dot de 2005-12-02 17:40 ---
Created an attachment (id=10391)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10391&action=view)
Trivial testcase
Hi. I'm attaching a trivial testcase (*). In fact, I consider this bug pretty
serious! Howard, any ch
X-Bugzilla-Reason: CC
--- Comment #1 from pluto at agmk dot net 2005-12-02 17:39 ---
Created an attachment (id=10390)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10390&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25226
X-Bugzilla-Reason: CC
$ gcc dsputil_mmx.i -O2 -fomit-frame-pointer -fPIC
(...)
i386/h264dsp_mmx.c: In function ‘h264_h_loop_filter_luma_mmx2’:
i386/dsputil_mmx.c:618: error: can't find a register in class
‘GENERAL_REGS’
while reloading ‘asm’
--
Summary:
The following test program generates extra use of a temporary register for the
return value. I have narrowed the cause of the poor code generation to the
addition of the pos = file->f_pos; line -- removing it causes the extra
temporary register to disappear (and saves several unnecessary mov
instr
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2005-12-02 16:46
---
Subject: Bug 25116
Author: fxcoudert
Date: Fri Dec 2 16:46:49 2005
New Revision: 107900
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107900
Log:
PR libfortran/25116
* io/transfer.c (da
1 - 100 of 143 matches
Mail list logo
