--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-01-20
07:46 ---
Subject: RE: Temporary constant array descriptors being declared at wrong
binding level.
Andrew,
It turns out that the real overhead is the function call. I posted a patch to
inline DOT_PRODUCT, which
--- Comment #2 from kumba at gentoo dot org 2006-01-20 06:54 ---
Created an attachment (id=10684)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10684&action=view)
Use dmove/move where appropriate
Typo in original, this is the correct version.
--
kumba at gentoo dot org changed
--- Comment #1 from kumba at gentoo dot org 2006-01-20 06:48 ---
Created an attachment (id=10683)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10683&action=view)
Use dmove/move where appropriate
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25871
In gcc/config/mips/mips.h, the TRAMPOLINE_TEMPLATE macro uses three 32bit move
statements, that when working with 64bit code, will cause problems. The only
time this has been observed thus far was in filesystem code borrowed from grub
which relied heavily on nested functions.
A patch against trun
NOTE: Defaulting component because reported component no longer exists
When list of languages has java (--enable-languages=c,c++,ada,f77,objc,java)
passed then make bootstrap fails on java with the following error:
Making all in gcj
make[5]: Entering directory
`/root/gcc-build/x86_64-slackware-lin
--- Comment #4 from hp at gcc dot gnu dot org 2006-01-20 05:44 ---
Build succeeds for revision 110008.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25869
--- Comment #3 from hp at gcc dot gnu dot org 2006-01-20 05:15 ---
same mmix gdb session (ignore the CFI data messages, except for DannyB ;-)
(gdb) bt
#0 0x0819bffc in df_chain_unlink (dflow=0x84aa3f8, ref=0x8507480,
link=0x84fd06c)
at /home/hp/combined/combined/gcc/df-problems.c:11
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-20 05:13 ---
Here is the backtrace for powerpc-darwin:
#0 0x008b18e4 in df_chain_unlink (dflow=0x41e11b10, ref=0x4203f588,
link=0x420410a4) at /Users/pinskia/src/gcc/alias/gcc/gcc/df-problems.c:110
#1 0x008b1934 in df_chain_unl
--- Comment #1 from hp at gcc dot gnu dot org 2006-01-20 05:00 ---
Created an attachment (id=10682)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10682&action=view)
preprocessed point of failure
(gdb) show args
Argument list to give program being debugged when it is started is
--- Comment #1 from 1l8p4ex95x5001 at sneakemail dot com 2006-01-20 04:47
---
Created an attachment (id=10681)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10681&action=view)
File exhibiting problem when compiled with "g++ -c gtp8.cpp"
% gcc -v
Using built-in specs.
Target: i686
Last known to work with: "Tue Jan 17 02:44:03 UTC 2006 (revision 109801M)".
Known to fail with: "Fri Jan 20 03:42:13 UTC 2006 (revision 110017M)".
/home/hp/combined/mmixware-sim/./gcc/xgcc
-B/home/hp/combined/mmixware-sim/./gcc/ -nostdinc
-B/home/hp/combined/mmixware-sim/mmix\
-knuth-mmixware/newl
I have one template class munge_type which takes a type and has a typedef in
it, new_type. Another template class has another typedef in it, inner_type,
and a method that returns munge_type::new_type. If I define the
method outside the class, I get these errors:
gtp8.cpp:17: error: prototype for
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-01-20 04:39 ---
*** Bug 25867 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-20 04:39 ---
This is a dup of bug 17122.
*** This bug has been marked as a duplicate of 17122 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from relf at os2 dot ru 2006-01-20 04:10 ---
Created an attachment (id=10680)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10680&action=view)
b2.cpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25867
--- Comment #1 from relf at os2 dot ru 2006-01-20 04:09 ---
Created an attachment (id=10679)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10679&action=view)
b.cpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25867
g++ 4.0.3 as well as g++-3.4 fails to compile the attached program b.cpp with
the following errors:
b.cpp:12: error: declaration of 'operator-' as non-function
b.cpp:12: error: expected ';' before '<' token
Things become even worse if we make int x; private in class A (see b2.cpp).
g++ 4.0.3 sta
--- Comment #21 from mmitchel at gcc dot gnu dot org 2006-01-20 03:36
---
Fixed in 4.1.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #20 from mmitchel at gcc dot gnu dot org 2006-01-20 03:08
---
Subject: Bug 22136
Author: mmitchel
Date: Fri Jan 20 03:07:58 2006
New Revision: 110017
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110017
Log:
PR c++/22136
* name-lookup.c (do_class_us
--- Comment #19 from mmitchel at gcc dot gnu dot org 2006-01-20 03:07
---
Subject: Bug 22136
Author: mmitchel
Date: Fri Jan 20 03:07:49 2006
New Revision: 110016
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110016
Log:
PR c++/22136
* name-lookup.c (do_class_us
--- Comment #7 from pcarlini at suse dot de 2006-01-20 02:34 ---
Fixed for 4.1.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
--- Comment #12 from pcarlini at suse dot de 2006-01-20 02:34 ---
Fixed for 4.1.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
--- Comment #6 from paolo at gcc dot gnu dot org 2006-01-20 02:33 ---
Subject: Bug 25824
Author: paolo
Date: Fri Jan 20 02:33:21 2006
New Revision: 110010
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110010
Log:
2006-01-20 Perry Smith <[EMAIL PROTECTED]>
PR libstdc+
--- Comment #11 from paolo at gcc dot gnu dot org 2006-01-20 02:33 ---
Subject: Bug 25823
Author: paolo
Date: Fri Jan 20 02:33:21 2006
New Revision: 110010
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110010
Log:
2006-01-20 Perry Smith <[EMAIL PROTECTED]>
PR libstdc
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-20 01:33 ---
Interesting darwin-fallback.c got the fix:
2005-03-25 Geoffrey Keating <[EMAIL PROTECTED]>
* config/rs6000/darwin-fallback.c: Don't include .
Use our own structure definitions.
But not the host-da
--- Comment #8 from zadeck at naturalbridge dot com 2006-01-20 01:33
---
2005-01-19 Kenneth Zadeck <[EMAIL PROTECTED]>
PR rtl-optimization/25799
* df-problems.c (df_ru_confluence_n, df_rd_confluence_n):
Corrected confluence operator to remove bits from op2 bef
--- Comment #7 from zadeck at gcc dot gnu dot org 2006-01-20 01:28 ---
Subject: Bug 25799
Author: zadeck
Date: Fri Jan 20 01:28:34 2006
New Revision: 110008
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110008
Log:
2005-01-19 Kenneth Zadeck <[EMAIL PROTECTED]>
PR rtl-
--- Comment #6 from zadeck at gcc dot gnu dot org 2006-01-20 01:24 ---
Subject: Bug 25799
Author: zadeck
Date: Fri Jan 20 01:24:00 2006
New Revision: 110007
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110007
Log:
2005-01-19 Kenneth Zadeck <[EMAIL PROTECTED]>
PR rtl-
--- Comment #10 from hjl at lucon dot org 2006-01-20 01:02 ---
Binutils 2.16.1 is too old. There are so many bug fixes since it was released.
People can try the current Linux binutils at
http://www.kernel.org/pub/linux/devel/binutils/
or get the binutils from CVS.
--
http://gcc.gn
--- Comment #2 from amodra at bigpond dot net dot au 2006-01-20 00:56
---
Also fails on powerpc64-linux
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-20 00:55 ---
No feedback in 3 months.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
acinclude.m4 has a home-brewed rule to detect whether a target can support TLS.
This rule incorrectly decides that NetBSD can support this. The result is
that libgomp will not load, and faults with the error:
Unsupported relocation type 14 in non-PLT relocations
Rather than rolling its own rule,
--- Comment #9 from bkoz at gcc dot gnu dot org 2006-01-20 00:23 ---
H.J, are you seeing this kind of additional symptom with binutils-2.16.1:
FAIL: 21_strings/basic_string/cons/char/6.cc (test for excess errors)
Excess errors:
/mnt/hd/bld/H-x86-binutils-2.16.1/bin/ld:
testsuite_abi.o(
--- Comment #60 from steven at gcc dot gnu dot org 2006-01-20 00:06 ---
I've tested it on x86_64-unknown-linux-gnu and mips-elf (simulator, C only).
Richi, I would have commited the patch for this myself as obvious, with a
comment explaining why we have to call ir_type there and a promi
--
hjl at lucon dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-
--- Comment #1 from hjl at lucon dot org 2006-01-20 00:00 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01323.html
--
hjl at lucon dot org changed:
What|Removed |Added
---
--- Comment #6 from danglin at gcc dot gnu dot org 2006-01-19 23:53 ---
Fixed by patch.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #5 from danglin at gcc dot gnu dot org 2006-01-19 23:51 ---
Subject: Bug 25171
Author: danglin
Date: Thu Jan 19 23:51:07 2006
New Revision: 109992
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109992
Log:
PR testsuite/25171
* c-decl.c (check_bitfield
--- Comment #4 from danglin at gcc dot gnu dot org 2006-01-19 23:48 ---
Subject: Bug 25171
Author: danglin
Date: Thu Jan 19 23:48:07 2006
New Revision: 109991
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109991
Log:
PR testsuite/25171
* c-decl.c (check_bitfield
--- Comment #3 from danglin at gcc dot gnu dot org 2006-01-19 23:45 ---
Subject: Bug 25171
Author: danglin
Date: Thu Jan 19 23:45:49 2006
New Revision: 109990
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109990
Log:
PR testsuite/25171
* c-decl.c (check_bitfield
--- Comment #4 from uweigand at gcc dot gnu dot org 2006-01-19 23:19
---
FYI, the glibc folks have made a similar request w.r.t. adding
128-bit long double (IEEE quad) support for s390(x)-ibm-linux.
We're currently preparing a patch -- if there's still a chance
of getting this into 4.1
--- Comment #15 from uweigand at gcc dot gnu dot org 2006-01-19 23:10
---
This testcase also fails on s390x-ibm-linux (crash of f951).
The patch in comment 13 fixes the crash.
Any chance of getting the fix into 4.1?
--
uweigand at gcc dot gnu dot org changed:
What|R
--- Comment #8 from hjl at gcc dot gnu dot org 2006-01-19 22:36 ---
Subject: Bug 25797
Author: hjl
Date: Thu Jan 19 22:36:41 2006
New Revision: 109985
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109985
Log:
2006-01-19 H.J. Lu <[EMAIL PROTECTED]>
PR libstdc++/25797
--- Comment #7 from bkoz at gcc dot gnu dot org 2006-01-19 22:32 ---
paolo I can reproduce this on x86/linux with binutils 2.16.1
=== libstdc++ Summary ===
# of expected passes3837
# of unexpected failures134
# of unexpected successes 1
# of e
--- Comment #18 from mmitchel at gcc dot gnu dot org 2006-01-19 21:27
---
I've spoken with the folks at EDG, and we all agree that we should not be
checking that, in "using S::f", "S" is a base class of the current class if
we're in a template; the set of base classes of the template is
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-01-19 20:44
---
David has indicated to me that it's possible (but not certain) that the PowerPC
GNU/Linux community wants this on by default in GCC 4.1. Since we'd very much
like to avoid ABI changes throughout the 4.1 series, an
--- Comment #2 from dje at gcc dot gnu dot org 2006-01-19 20:28 ---
This is an enhancement request in conjunction with Glibc.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-19 20:27 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
Use IBM long double format in 32-bit PowerPC Linux and enable 128-bit long
double by default.
--
Summary: Enable IBM long double format in 32-bit PowerPC Linux
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ABI
Severity:
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-19 20:20 ---
Caused by:
2005-12-14 Ben Elliston <[EMAIL PROTECTED]>
* c-common.c (c_common_truthvalue_conversion): Generalise warning
for addresses converted to booleans; not just function addresses.
*
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-19 20:18 ---
Reduced C testcase:
int f(void *a)
{
return !(&a);
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-19 20:16 ---
Semi reduced:
void f(void);
class PNotifierFunction
{
public:
PNotifierFunction(
void * obj
) {
void * object;
object = ((&(obj)&&(obj)!=__null)?(obj): (f(),(obj)));
}
};
--
http
--- Comment #16 from amacleod at redhat dot com 2006-01-19 19:50 ---
Created an attachment (id=10678)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10678&action=view)
updated patch
I updated the patch to the current mainline, and have built and verified no
additional failures on
--- Comment #5 from bkoz at gcc dot gnu dot org 2006-01-19 19:21 ---
Ack! Some of this stuff was fixed on mainline and 4.1 recently. I thought I'd
gotten everything, but I guess not.
Please put this type of fix in 4.1 as well...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2582
--- Comment #4 from dcb314 at hotmail dot com 2006-01-19 19:17 ---
(In reply to comment #3)
> This has been faling since at least 20051219.
I rather suspect there would be a useful job for someone
to take each weekly snapshot of gcc 4.2 and make
sure it compiles some recentish distribu
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-19 19:16 ---
Reduced testcase:
struct g
{
int i;
};
struct f
{
struct g i;
};
int GSM_RingNoteGetFullDuration(struct g)__attribute__((const));
void savewav(struct f *gg)
{
struct g *Note;
long i = 0,j,length=0;
Note = &
--- Comment #35 from mark at codesourcery dot com 2006-01-19 19:14 ---
Subject: Re: [3.4/4.0/4.1/4.2 Regression] bitfield
layout change (regression?)
steven at gcc dot gnu dot org wrote:
> - Older HP compilers and MS compilers use zero-length bit-fields to force
> the following mem
This piece of code:
#include
using namespace std;
class A
{
private: class B {public: int l;};
public: B getB() { B b; return (b); }
};
int main()
{
A a;
cout << a.getB().l;
}
-
--- Comment #82 from pinskia at gcc dot gnu dot org 2006-01-19 18:59
---
*** Bug 25862 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 2006-01-19 18:59 ---
you are violating C/C++ aliasing rules, accessing doubles as int.
*** This bug has been marked as a duplicate of 21920 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from andreg at discreet dot com 2006-01-19 18:56 ---
Created an attachment (id=10677)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10677&action=view)
C++ test case
To compile: g++ -O3 test3.C -o test3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25862
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-19 18:54 ---
This has been faling since at least 20051219.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25861
The following test case produces wrong result when compiled with -O2 or -O3.
expected result (-O1, or using intel compiler):
ReadX: x = -5.9436e+29 [ OK ]
WriteX: [ OK ]
observed results (-O2 or -O3)
ReadX: x = 0 [ FAIL ]
WriteX:
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-19 18:53 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25861
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-19 18:50 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25860
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Summary|ice with -g -O2 -fPIC |[4.
--- Comment #1 from dcb314 at hotmail dot com 2006-01-19 18:48 ---
Created an attachment (id=10676)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10676&action=view)
C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25861
I just tried to compile package gnugk-2.2.3-2 from Suse Linux with a recent
GNU C compiler version 4.2 snapshot 20060114.
The compiler snapshot said
/home/dcb/gnu/42-20060114/results/bin/g++ -g -O3 -Wall -fmessage-length=0
-DHAS_RADIUS=1 -DHAS_MSG_NOSIGNAL=1 -D'MANUFACTURER=GNU'
-D'PROGRAMMNAME
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-19 18:45 ---
/* If this is a real operand, the operand is either ssa name or decl.
Virtual operands may only be decls. */
gcc_assert (is_real_op || DECL_P (var));
Was where it was crashing. The code has moved though.
--- Comment #1 from dcb314 at hotmail dot com 2006-01-19 18:44 ---
Created an attachment (id=10675)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10675&action=view)
C source code for ice
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25860
I just tried to compile package gammu-1.04.0-2 from Suse Linux with a recent
GNU C compiler version 4.2 snapshot 20060114.
The compiler snapshot said
Making common/service/backup/gsmback.c
common/service/gsmring.c: In function "savewav":
common/service/gsmring.c:93: internal compiler error: in a
--- Comment #26 from ebotcazou at gcc dot gnu dot org 2006-01-19 18:33
---
> In your closing arguments you said these static object need to be members of
> an array. How would I do that?
You need to use a single array for your table if all the elements have the same
type or a single b
--- Comment #13 from tromey at gcc dot gnu dot org 2006-01-19 18:23 ---
FWIW I suspect there is undefined code in gcjx.
For instance I think the constant evaluation code assumes
-fwrapv behavior. There could well be other undefined code,
but I don't know of any.
That said, it seems unl
--- Comment #25 from dick_guertin at yahoo dot com 2006-01-19 18:23 ---
In your closing arguments you said these static object need to be members of an
array. How would I do that? Here's a sample from comm.c where there is a
mixture of objects:
- - - -
static struct sckw sckw58 = {
0x4
--- Comment #24 from dick_guertin at yahoo dot com 2006-01-19 17:54 ---
Although you have closed this, many people would disagree with you. Laying out
static data this way has always 'worked' in the past, and continues to work
with -O, but not -O2. Just for completeness, here is a simp
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-19 17:53 ---
So this is a purify bug as valgrind says the memory is still reachable which is
correct because it is a thread specific location for the main thread. Closing
as invalid.
--
pinskia at gcc dot gnu dot org changed
--- Comment #34 from steven at gcc dot gnu dot org 2006-01-19 17:40 ---
I looked up a few links to see how people use zero-length bit-fields and what
semantics they're expecting. I mostly found links to compiler documentation
about how other compilers interpret these bit-fields. Perhaps
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-01-19 17:39
---
Fixed in GCC 3.4.6, 4.0.3 and later.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-01-19 17:37
---
Subject: Bug 25854
Author: reichelt
Date: Thu Jan 19 17:37:49 2006
New Revision: 109978
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109978
Log:
PR c++/25854
* pt.c (maybe_process_partial
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-01-19 17:35
---
Subject: Bug 25854
Author: reichelt
Date: Thu Jan 19 17:35:08 2006
New Revision: 109977
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109977
Log:
PR c++/25854
* pt.c (maybe_process_partial
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-01-19 17:33
---
Subject: Bug 25854
Author: reichelt
Date: Thu Jan 19 17:33:07 2006
New Revision: 109976
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109976
Log:
PR c++/25854
* pt.c (maybe_process_partial
--- Comment #3 from loizeaux1 at hotmail dot com 2006-01-19 17:30 ---
Here's the results I got after following the directions on the website you gave
me (I realize this may be moot since you pointed out that it is a false
positive, but I'll just do this for completeness' sake):
> cat te
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-01-19 17:29
---
Subject: Bug 25854
Author: reichelt
Date: Thu Jan 19 17:29:42 2006
New Revision: 109975
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109975
Log:
PR c++/25854
* pt.c (maybe_process_partial
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-01-19 17:29
---
Fixed in 4.2.0 and above.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-19 17:28
---
Subject: Bug 22099
Author: pinskia
Date: Thu Jan 19 17:28:53 2006
New Revision: 109974
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109974
Log:
2006-01-19 Andrew Pinski <[EMAIL PROTECTED]>
PR
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-01-19 17:18
---
Fixed in 4.2.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-01-19 17:18
---
Subject: Bug 15642
Author: pinskia
Date: Thu Jan 19 17:18:29 2006
New Revision: 109973
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109973
Log:
2006-01-19 Andrew Pinski <[EMAIL PROTECTED]>
PR
--- Comment #33 from mark at codesourcery dot com 2006-01-19 16:59 ---
Subject: Re: [3.4/4.0/4.1/4.2 Regression] bitfield
layout change (regression?)
matz at suse dot de wrote:
> --- Comment #32 from matz at suse dot de 2006-01-19 14:44 ---
> Mark, I agree that it's saner whe
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-19
16:41 ---
Subject: Re: gnatmake: error while loading shared libraries: libgcc_s.so.4:
cannot open
> So I guess the gnatmake rule needs to use $(GCC_LINK)
I'll try the above change
> one way or another (although th
--- Comment #4 from eweddington at cso dot atmel dot com 2006-01-19 16:22
---
Bjoerne, could you post a comment to this bug that includes the link to the
patch in the gcc-patches list?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25035
--- Comment #4 from charlet at adacore dot com 2006-01-19 16:19 ---
Subject: Re: gnatmake: error while loading shared libraries: libgcc_s.so.4:
cannot open
> For some reason, the above doesn't seem to have been used in linking gnatmake:
Indeed, gnatmake has to be handled specially.
S
> For some reason, the above doesn't seem to have been used in linking gnatmake:
Indeed, gnatmake has to be handled specially.
So I guess the gnatmake rule needs to use $(GCC_LINK)
one way or another (although there should be no difference between
trubk and 4.1 in that respect).
Same for gnatlin
--- Comment #2 from eweddington at cso dot atmel dot com 2006-01-19 16:18
---
I would concur with Richard. The fact that you're getting "no such instruction"
points to an issue with the assembler, and that you probably don't have a
target assembler (AVR assembler) installed, or you forg
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-19 16:11 ---
I wonder if we could get the aliasing mechanism to say that this array
descriptor is not changed and move the stores out of the loop.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24520
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-19
16:10 ---
Subject: Re: gnatmake: error while loading shared libraries: libgcc_s.so.4:
cannot open
> --- Comment #1 from charlet at adacore dot com 2006-01-19 15:53 ---
> Subject: Re: New: gnatmake: error
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-19 16:06 ---
Fixed by:
2006-01-09 Jeff Law <[EMAIL PROTECTED]>
* tree-ssa-dom.c (simplify_cond_and_lookup_avail_expr): Remove
code to propagate the RHS of a cast into COND_EXPR_COND. Remove
now unused
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-01-19 15:57
---
Confirmed. Reduced testcase:
===
struct A
{
ERROR;
~A();
};
struct B
{
virtual ~B();
};
struct C : B, A {};
struct D : C {};
D d;
===
--
reichelt at gcc dot gn
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-19
15:53 ---
Subject: Re: New: gnatmake: error while loading shared libraries:
libgcc_s.so.4: cannot open
> ../../gnatmake: error while loading shared libraries: libgcc_s.so.4: cannot
> open
> shared object file: No
--- Comment #1 from charlet at adacore dot com 2006-01-19 15:53 ---
Subject: Re: New: gnatmake: error while loading shared libraries:
libgcc_s.so.4: cannot open
> This doesn't happen on the trunk.
The following from ada/Makefile.in is supposed to take care of that:
GCC_LINK="$(CC) -
> This doesn't happen on the trunk.
The following from ada/Makefile.in is supposed to take care of that:
GCC_LINK="$(CC) -static-libgcc $(ADA_INCLUDES)"
(and uses of $(GCC_LINK) elsewhere in the tools).
Basically we certainly do *not* want to link with libgcc_s, in particular
to avoid this kind
1 - 100 of 141 matches
Mail list logo
