Warnings in libiberty and libcpp prevent GCC 4.0 from bootstrapping itself,
because libcpp's configure uses -Werror.
The easiest way to reproduce this is to configure GCC 4.0 with
--enable-bootstrap so that libcpp is bootstrapped as well.
Severity is normal and not critical because releases do no
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-02-08
09:18 ---
Created an attachment (id=8139)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8139&action=view)
proposed patch
Pretty obvious patch if it weren't for the hunk in macro.c.
Patch is in stage2 of a topl
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-02-08
09:19 ---
CCing Geoff since he wrote the hunk I modify in macro.c. It looks like a pasto,
but I am not sure.
--
What|Removed |Added
---
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-08
09:24 ---
On ia64-unknown-linux-gnu, -O1 produces the same result that -O3 does.
Here's a shell script that I currently use for shotgun
testing of single optimization options:
for a in \
branch-count-reg cprop-r
g++ runs into an ICE when compiling aegis 4.20 on HP 10.20
/software/gcc/3.4.3/HP-UX-B.10/bin/g++ -Iaeget -Ilibaegis -Icommon
-I/work/include -O -c \
aeget/get/file/metrics.cc
aeget/get/file/metrics.cc: In function `void get_file_metrics(change_ty*,
string_ty*, string_list_ty*)':
aeget/get
--- Additional Comments From ralfixx at gmx dot de 2005-02-08 09:59 ---
Created an attachment (id=8140)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8140&action=view)
preprocessed source file
preprocessed source with commandline:
/software/gcc/3.4.3/HP-UX-B.10/bin/g++ -v -save-t
--- Additional Comments From ralfixx at gmx dot de 2005-02-08 10:01 ---
Created an attachment (id=8141)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8141&action=view)
preprocessed assembly source
assembly source (same commandline as .ii attachment)
--
http://gcc.gnu.org/bugzil
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-08
10:04 ---
For me -march=pentium4 or -march=pentium3 does not make a difference.
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-08
10:09 ---
-march=athlon should optimize for the K7 yes. What you probably run into
is a simple backend problem where the code generated for the K7 can, for
whatever reason, not be optimized as well as the i686 code.
--
What|Removed |Added
Summary|IBM 128bit long double |IBM 128bit long double
|format is not constant |format is not constant
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-08
10:13 ---
rth hacked the constraints recently to have better ra for some fp cases. Can
you see if the bug is still there today on mainline?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19653
--- Additional Comments From kunert at physik dot tu-dresden dot de
2005-02-08 10:13 ---
Subject: Re: [4.0 Regression] threefold performance
loss, not inlining as much
Good idea.
However, this provides just another knob to tune the inlining and it is not
obvious where to apply that
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-08
10:14 ---
Honza, this is one we should catch on the tree-profiling branch now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1046
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-08
10:19 ---
Kazu, is this still a problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14060
--- Additional Comments From giovannibajo at libero dot it 2005-02-08
10:42 ---
Please, try the opposite: disable optimizations through -O1 -fno-[optnam] and
see if you find out something.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
This is probably not really a bug, just a hole in the documentation. While
google can demonstrate how to get values into vectors, and the info pages the
names of the manipulation functions avaliable, there seems to be no
documentation on how to get at the results of the manipulation.
How do you ge
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-02-08
12:00 ---
(In reply to comment #0)
> If gcj is called while the environment variable CLASSPATH contains
> backslashes
> instead of slashes, jc1 (called by gcj) hangs without any error message.
> Could
> gcj/jc1 be
With 4 nested vec_add()'s gcc goes out of memory on my 512MB+1GBswap ppc box.
With 3 adds it consumes about 150MB of memory and eventually succeeds. The
preprocessor expands the y=... line into an exagerately huge expression. fftw3
fails to compile because of this.
Tested on gcc 3.4.1 and 3.4.3,
--
What|Removed |Added
Component|c++ |target
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug
--- Additional Comments From chris at bubblescope dot net 2005-02-08 13:24
---
Yep, that fixed it. Marking it as a dup.
*** This bug has been marked as a duplicate of 12096 ***
--
What|Removed |Added
--
--- Additional Comments From chris at bubblescope dot net 2005-02-08 13:24
---
*** Bug 18961 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08
13:27 ---
*** This bug has been marked as a duplicate of 19411 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08
13:27 ---
*** Bug 19821 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08
13:37 ---
Hmm, I thought this was documented but you use an union.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19820
Hi,
I get an ICE compiling arpcache.i with avr-gcc-3.4.3+:
avr-gcc -c -Os arpcache.i
arpcache.c: In function `NutArpCacheQuery':
arpcache.c:481: error: unable to find a register to spill in class
`POINTER_REGS'
arpcache.c:481: error: this is the insn:
(insn 90 207 206 5 (parallel [
(
--- Additional Comments From dieterbmeier at yahoo dot com 2005-02-08
13:45 ---
Created an attachment (id=8143)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8143&action=view)
arpcache.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19822
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08
13:49 ---
Fixed on the mainline.
We now combine the following RTL to fix the problem:
(insn 16 15 17 0 (set (reg:SI 126)
(lt:SI (reg:CC 127)
(const_int 0 [0x0]))) 382 {*rs6000.md:11380}
(insn_list
--
What|Removed |Added
Keywords||diagnostic
Last reconfirmed|2004-11-08 03:03:11 |2005-02-08 13:54:04
date|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08
13:55 ---
*** This bug has been marked as a duplicate of 18251 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08
13:55 ---
*** Bug 19822 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From amacleod at redhat dot com 2005-02-08 14:02
---
(In reply to comment #30)
> Subject: Re: [4.0 Regression] 10% increase in codesize with C code compared
to GCC 3.3
>
> On Mon, Feb 07, 2005 at 11:13:27PM -, steven at gcc dot gnu dot org wrote:
> > x = a
--- Additional Comments From neil at daikokuya dot co dot uk 2005-02-08
14:02 ---
Subject: Re: New: Preprocessor oom with nested vector operations
pochini at shiny dot it wrote:-
> With 4 nested vec_add()'s gcc goes out of memory on my 512MB+1GBswap ppc box.
> With 3 adds it consumes
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Target Milestone|---
--- Additional Comments From amacleod at redhat dot com 2005-02-08 14:26
---
(In reply to comment #28)
> Using var_to_partition does not help. The reason is that the SSA names with
> the same root var are not in the same partition, e.g.
>
> _7 -->
> x_3 --> x
> x_4 not coalesce
Newer linux kernels (2.6.11 in this case) check the executable for a
PT_GNU_STACK program header, and if it exists default to provide
non-executable memory (for stack _and_ malloced memory) on CPUs which
support this (all x86-64 CPUs and newer x86 ones).
It seems that gij is not prepared to h
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08
14:41 ---
I think this is a libffi problem in that it creates a closure but does not make
it exutable.
--
What|Removed |Added
-
--- Additional Comments From hundertmarck at boehme-weihs dot de
2005-02-08 15:02 ---
The Problem was using gcc-3.2 as bootstrap compiler. After using the system
cc the bootstrap finished successfully.
Now my g++ supports wstring :-D
Thanks to all!
--
http://gcc.gnu.org/bugzilla/sh
Hello
I want to compile gcc 4.0.0 20050202 on ibm aix 4.3.3. Bootstrap fails if
genattrtab runs:
build/genattrtab /soft/gnu/packages/gcc_cvs/gcc/gcc/config/rs6000/rs6000.md >
tmp-attrtab.c
out of memory allocating 80016 bytes after a total of 4161650636 bytes
I have not found an existing bug fo
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-08
15:09 ---
Subject: Bug 19801
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-08 15:08:53
Modified files:
gcc/doc: cppinternals.texi
gcc
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-02-08
15:09 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19801
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08
15:13 ---
*** Bug 19824 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08
15:13 ---
This is one, see PR 19082. You have to change your limits.
*** This bug has been marked as a duplicate of 19082 ***
--
What|Removed |Added
-
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-08
15:35 ---
Subject: Bug 19806
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-08 15:35:12
Modified files:
gcc: ChangeLog
gcc/config/cris: c
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-08
15:36 ---
(In reply to comment #34)
> Please, try the opposite: disable optimizations through -O1 -fno-[optnam] and
> see if you find out something.
Still the same four failures with
#! /bin/sh
for a in \
verb
--- Additional Comments From hp at gcc dot gnu dot org 2005-02-08 16:04
---
See http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00306.html>.
--
What|Removed |Added
--
Bug 19745 depends on bug 19806, which changed state.
Bug 19806 Summary: [4.0 regression] cris-axis-elf testsuite failure:
gcc.c-torture/execute/20001130-1.c compilation, -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19806
What|Old Value |New Value
--
--- Additional Comments From ornati at fastwebnet dot it 2005-02-08 16:13
---
gcc -v
Using built-in specs.
Configured with:
/var/tmp/portage/gcc-4.0.0_alpha20050130/work/gcc-4.0-20050130/configure
--enable-version-specific-runtime-libs --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-b
Apparently, the compiler likes -floop-optimize2 very much and does
not want it to be switched off:
$ gcc -O1 -fno-loop-optimize -fno-loop-optimize2 -S -fverbose-asm example.c
$ cat example.s
.file "example.c"
.pred.safe_across_calls p1-p5,p16-p63
// GNU C version 4.0.0 20050130 (
--- Additional Comments From fitzsim at redhat dot com 2005-02-08 16:30
---
Fixed on java-gui-branch.
--
What|Removed |Added
Status|NEW
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-08
16:36 ---
This blocks testing of compiler options in PR 5900.
--
What|Removed |Added
OtherBugsDepen
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-08
16:36 ---
I am not sure which of my tests of compiler options
were actually testing anything. There appears to be a bug
in passing at least one -fno - switch (see PR 19825).
Thomas
--
http://gcc.gnu.org/bugzi
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-02-08
16:43 ---
Patch (improving ivopts performance on the testcase by some 40%):
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00307.html
--
What|Removed |Added
This one *may* be related to c++/18470 but does *not* involve using... FWIW,
Icc accepts it, same for 3.4.3. Maybe a regression, fall out of recent work
in close areas... ?!?
template
class basic_string
{
typedef typename _Alloc::size_type size_type;
static const size_type _S_max
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-02-08
16:56 ---
Even shorter example:
template struct A
{
static const T i = 1;
char a[i];
};
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08
17:09 ---
This is at least a 4.0 regression and it looks like it is going to effect
libstdc++ also which is really bad.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08
17:10 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08
17:16 ---
XPASS: gcc.dg/tree-ssa/20040204-1.c scan-tree-dump-times link_error 0
is xfailed because it fails on most targets (except for ppc, and a couple of
others).
FAIL: gcc.dg/tree-ssa/loop-1.c scan-assembler-tim
--- Additional Comments From neroden at gcc dot gnu dot org 2005-02-08
17:26 ---
Shouldn't the warning killer for system header errors apply to this sort of
thing? Apparently it doesn't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08
17:33 ---
There is a section in the source which does this:
/* Enable new loop optimizer pass if any of its optimizations is called. */
if (flag_move_loop_invariants
|| flag_unswitch_loops
|| flag_pee
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08
17:34 ---
In fact the only thing which -floop-optimize2 does without enabling something
else at -O1 is to enable
-fbranch-count-reg which has no effect on ia64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=198
--- Additional Comments From neroden at gcc dot gnu dot org 2005-02-08
18:30 ---
>Is a fix likely to get into 4.0?
Yes, the hackish fix is in. I hope to get the cleaner fix in, but who knows.
>FYI Once I am able to build, the next issue is that the Ada libraries
>do not look into n
The following two function should produce the same asm because we can skip the
second call to f:
int f(void) __attribute__((const,pure));
int g(int i, int j)
{
int k = 0;
if(i)
k = f();
if (j)
k = f();
return k;
}
int h(int i, int j)
{
int k = 0;
if(i)
k = f();
else if (
--- Additional Comments From pochini at shiny dot it 2005-02-08 18:48
---
Sorry for the noise, I didn't find #19411 while browsing the database.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19821
--- Additional Comments From neroden at gcc dot gnu dot org 2005-02-08
18:51 ---
This has never worked.
It is recommended by the GNU coding standards, but it also requires truly
substantial work to get right without forcing rebuilds if 'make all' is
followed by 'make install'.
--- Additional Comments From neroden at gcc dot gnu dot org 2005-02-08
18:53 ---
I have considered doing this in the truly parallel way: namely, introducing
HOST_SUBDIR to go along with BUILD_SUBDIR and TARGET_SUBDIR.
It requires mangling of '..'s in many subdirectories, which is why
--- Additional Comments From neroden at gcc dot gnu dot org 2005-02-08
18:58 ---
Isn't this most likely to be an out-of-memory issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19813
Take the following program, it should run and work correct and not call abort
but with -O1/-O2 on the
mainline we call abort because LIM pulls out the call to f of the loop but
should not because f1 can
modify the global memory (and does). If I uncomment the store to the global
memory in the
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19828
--
What|Removed |Added
CC||ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19828
--- Additional Comments From joseph at codesourcery dot com 2005-02-08
19:07 ---
Subject: Re: __extension__ keyword doesn't suppress
warning on LL or ULL constants
On Tue, 8 Feb 2005, neroden at gcc dot gnu dot org wrote:
> Shouldn't the warning killer for system header errors apply
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From joel at oarcorp dot com 2005-02-08 19:16
---
Subject: Re: gnat tools not buildable cross
neroden at gcc dot gnu dot org wrote:
> --- Additional Comments From neroden at gcc dot gnu dot org 2005-02-08
> 18:30 ---
>
>>Is a fix likely to get into 4.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08
19:21 ---
: Search converges between 2004-11-12-161002-trunk (#631) and
2004-11-13-014001-trunk
(#632).
Mark, I suspect your patch for PR 18429 is responsible for the regression.
Could you please have a look?
--
--- Additional Comments From aph at gcc dot gnu dot org 2005-02-08 19:25
---
I don't think this is a libffi problem. gcj allocates trampolines on the heap,
not the stack.
I think this is a multilib problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19823
--- Additional Comments From drow at gcc dot gnu dot org 2005-02-08 19:27
---
Here's another related testcase. If you uncomment the store to global_int,
LIM will move only func_const out of the loop. With them both commented
out, however, the pure call gets moved out of the loop. func
--- Additional Comments From drow at gcc dot gnu dot org 2005-02-08 19:36
---
Here's another one. This may be a different bug. Suppose we have two pure
functions, one which checks whether a library is present and one which fetches
some piece of data from the library. Code looks like t
Between LAST_UPDATED:
Mon Feb 7 13:27:26 UTC 2005
and
Tue Feb 8 17:55:17 UTC 2005
the following regression was introduced for cris-axis-elf:
FAIL: 21_strings/basic_string/find/char/3.cc execution test
The message in libstdc++.log is:
PASS: 21_strings/basic_string/find/char/3.cc (test for excess
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08
19:50 ---
Is the problem here (in sematics.c):
/* Since this name was dependent, the expression isn't
constant -- yet. No error is issued because it might be
constant when things a
--- Additional Comments From bangerth at dealii dot org 2005-02-08 19:58
---
I can confirm this:
tmp/xxx> c++ x.cc
tmp/xxx> ./a.out
tmp/xxx> c++ x.cc -O2 -finline-functions -finline-limit=604
tmp/xxx> ./a.out
Segmentation fault
tmp/xxx> c++ -v
Using built-in specs.
Target: i6
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08
20:02 ---
(In reply to comment #2)
> Here's another one. This may be a different bug.
Yes that is a different (but related) bug. The problem is now, what is
definition of pure functions (for
that testcase).
Take
--- Additional Comments From bangerth at dealii dot org 2005-02-08 20:13
---
This is somewhat shorter, though maybe not much:
#include
#include
struct ltstr {
bool operator()(const char* s1, const char* s2) const
{ return strcmp(s1, s2) < 0; }
};
--- Additional Comments From snyder at fnal dot gov 2005-02-08 20:18
---
(In reply to comment #24)
> (In reply to comment #23)
> > This does not seem to be fixed so reopening.
> I opened another PR because it is related but not fully the same problem. (PR
19699).
We still (as of CVS fr
--- Additional Comments From hp at gcc dot gnu dot org 2005-02-08 21:05
---
Judging from the similarity of the frv-elf test-results and a brief look at
frv_print_operand_address, it has the same flaw as was fixed in this PR;
making sure there's a call to mark_decl_referenced for SYMBOL_R
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-08
21:07 ---
We have this hunk in the .vrp dump:
# BLOCK 1
# PRED: 4 (true,exec)
:;
iD.1901_30 = iD.1901_1;
D.1909_31 = D.1909_4;
i.0D.1911_5 = (unsigned intD.6) iD.1901_30;
D.1909_6 = D.1909_31;
D
--
What|Removed |Added
BugsThisDependsOn||19830
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19745
Regarding gcc.c-torture/execute/920501-8.c, there's an extra "0" in the
"1.00" part. Comparing to results for other targets (mmix, frv), it seems
the core sprintf function is miscompiled!
--
Summary: cris-elf testsuite failure: gcc.c-
torture/execute/920501-8.c
The following function really should be compiled to an empty function (DSE
should first remove the
store and then free of a malloc with no change inbetween and we should remove
both calls).
void *malloc(__SIZE_TYPE__);
void free(void*);
int f(void)
{
char *i = malloc(1);
*i = 1;
free (i);
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08
21:45 ---
WARNING: gcc.dg/20010912-1.c compilation failed to produce executable
as the following is in the testcase:
/* { dg-warning "not supported" "PIC unsupported" { target cris-*-elf*
cris-*-aout* mmix-*-* } 0 }
--- Additional Comments From craig dot powers at gmail dot com 2005-02-08
21:53 ---
Further testing indicates that the bug is caused by an array in a derived type
-- the pointer is not necessary.
program test
implicit none
type test_type
integer, dimension(5) :: a
end type te
According to Andrew Pinski , the following patch is useless because gcc should
be able to find the optimisation by itself.
Description : function preferable in cse.c can be simplified if we notice
that, at the end of the function :
if (regcost_a != regcost_b)
return regcost_a - regcost_
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08
23:34 ---
Confirmed, here is the full testcase by the way:
int f(int i, int j)
{
if (i!=j)
return i - j;
return 0;
}
Note I did not say the patch is useless but I just wantted to say that it would
be useful
Test gcc.dg/uninit-4.c has failed on powerpc64-unknown-linux-gnu with -m64
since 2004-12-17 for a bogus uninitialized variable warning. No other target
for which test results have been reported for the last few days gets this
failure. The change is with this patch:
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-08
23:52 ---
Jakub, so why not get your patch of comment #11 in first, and worry about the,
as you say yourself, unrelated bugs later?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19342
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08
23:57 ---
It also fails on powerpc-darwin with -m64 too. So maybe xfailing it for
powerpc*-*-* && lp64 would
be a better idea.
--
What|Removed |Added
---
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09
00:48 ---
(In reply to comment #5)
> This is somewhat shorter, though maybe not much:
Does -fno-strict-aliasing make this compile and run correctly?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19813
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09
00:51 ---
(In reply to comment #6)
> (In reply to comment #5)
> > This is somewhat shorter, though maybe not much:
>
> Does -fno-strict-aliasing make this compile and run correctly?
Because if it does then this is
--- Additional Comments From danglin at gcc dot gnu dot org 2005-02-09
01:22 ---
The stub placement issues in GNU ld still haven't been fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19799
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-09
01:44 ---
Subject: Bug 19799
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-09 01:43:51
Modified files:
gcc/testsuite : ChangeLog
gcc/testsuite/gcc.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-09
02:21 ---
Subject: Bug 19733
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-02-09 02:21:36
Modified files:
gcc/cp : Change
1 - 100 of 136 matches
Mail list logo
