Current mainline gcc appears to miscompile FFTW:
wget http://fftw.org/fftw-3.1.tar.gz
tar xvzf fftw-3.1.tar.gz
cd fftw-3.1
/scratch/fftw-3.1> gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /scratch/gcc/configure --quiet
--prefix=/afs/mpa/data/martin/ugcc --enable-languages
--- Comment #17 from mattias at virtutech dot se 2006-03-02 09:22 ---
We have resorted to case-by-case workarounds, usually a cast which would have
been an identity operation had the condition been true. That is,
if (sizeof x == 8)
return x << 32 | x;
would have its second line
--- Comment #3 from wielemak at science dot uva dot nl 2006-03-02 09:24
---
Andrew,
If you think this is a real and still present bug I could try to add a
little main() to the file and turn the file into a stand-alone program.
I guess it is pretty likely it depends on nasty details in
--- Comment #18 from fxcoudert at gcc dot gnu dot org 2006-03-02 09:37
---
(In reply to comment #17)
> For i=3 or greater, gfortran and ifort agree on the value of b. However, for
> the above, gfortran now gives 0, whilst ifort gives 1. I happen to think that
> 0 makes more sense but.
--- Comment #4 from wielemak at science dot uva dot nl 2006-03-02 10:08
---
Oops, must be ./configure --enable-mt
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26511
--- Comment #2 from pcarlini at suse dot de 2006-03-02 10:24 ---
Benjamin, can you have a look? The issue seems simple, in its essence: on
64-bit machines the recently added __copy_streambufs export is wrong - in fact
we are not exporting anything - because it reads everywhere:
_ZSt17
--- Comment #10 from aph at gcc dot gnu dot org 2006-03-02 10:31 ---
No, that patch doesn't help. Still get the same result at -O2:
[EMAIL PROTECTED] eclipse]$ /home/aph/gcc/install/bin/gcj -c -O2 -g -fPIC
-findirect-dispatch -fjni AbstractCommentParser.class
org/eclipse/jdt/internal/c
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org
|dot org |
--- Comment #2 from bonzini at gnu dot org 2006-03-02 10:47 ---
Recategorizing to bootstrap since it is a build system bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26500
--- Comment #1 from martin at mpa-garching dot mpg dot de 2006-03-02 11:00
---
I just checked that
CFLAGS="-O3" ./configure --enable-portable-binary
fails, but
CFLAGS="-O3" ./configure --enable-portable-binary
works as it should.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #2 from martin at mpa-garching dot mpg dot de 2006-03-02 11:01
---
(In reply to comment #1)
> I just checked that
>
> CFLAGS="-O3" ./configure --enable-portable-binary
>
> fails, but
>
> CFLAGS="-O3" ./configure --enable-portable-binary
Sorry for the typo here. I meant,
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-02 12:15 ---
Do you have a simple testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26528
--- Comment #4 from martin at mpa-garching dot mpg dot de 2006-03-02 12:18
---
(In reply to comment #3)
> Do you have a simple testcase?
I wish I had :(
At the moment I'm trying to find out which optimisation flags are causing the
trouble. The current minimum set of flags to reproduce
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-03-02 12:20
---
Subject: Bug 26291
Author: reichelt
Date: Thu Mar 2 12:20:52 2006
New Revision: 111637
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111637
Log:
PR c++/26291
* decl.c (grok_op_properties)
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-03-02 12:22
---
Now also fixed on the 4.1 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-02 12:29 ---
Can you attach the preprocessed source?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-02 12:37 ---
According to known to fail, it fails in 4.1.0 but Jim's comment suggest
otherwise, hmm.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26330
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-02 12:53 ---
This still happens as of today.
with the C testcase from comment #1, we get:
Invalid sum of incoming frequencies 894, should be 9
:;
__builtin_abort ();
Invalid sum of incoming frequencies 9106, should be 9991
:
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-02 12:57 ---
Confirmed. It's dom2 messing up.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-02 13:00 ---
4.1.0 has also after dom2:
Invalid sum of incoming frequencies 673, should be 21
:;
__builtin_abort ();
Invalid sum of incoming frequencies 9327, should be 9979
:;
return;
4.0.2 has even different mismatched f
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-02 13:40 ---
(In reply to comment #4)
> "-O1 -ftree-vrp -finline-functions".
> More to come...
Can you try "-O3 -fwrapv"? It might be the source have undefined code in it
for signed overflow and changes to VRP exposed it.
Also
--- Comment #6 from martin at mpa-garching dot mpg dot de 2006-03-02 13:52
---
(In reply to comment #5)
> Can you try "-O3 -fwrapv"? It might be the source have undefined code in it
> for signed overflow and changes to VRP exposed it.
Bingo! Thanks for this hint, I wouldn't have foun
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-02 14:00 ---
CCing Honza, maybe he knows the answer but I cannot find it in the ISA
documention.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from dir at lanl dot gov 2006-03-02 14:02 ---
Hi Jerry,
As you may have guessed, I added this problem to the things that my program
looks for. You got that one and all the ones like it, but here is another one
from a slightly different class (rewind after reading
--- Comment #6 from brett dot albertson at stratech dot com 2006-03-02
14:15 ---
(In reply to comment #5)
> A real patch for 4.2 is posted at
>
> http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00094.html
>
I can confirm that this patch allows me to bootstrap again. I'm running the
tes
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-03-02 14:15
---
*** This bug has been marked as a duplicate of 26053 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2006-03-02 14:15
---
*** Bug 24345 has been marked as a duplicate of this bug. ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-02 14:21
---
(In reply to comment #9)
> Acutally f3 is not fixed but I don't understand how not.
No f3 is fine, f4 is broken still.
*p = (int) *p != -1;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18908
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-02 14:24 ---
This is interesting, we now get BIT_FIELD_REF.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15826
--- Comment #3 from randolph at tausq dot org 2006-03-02 14:27 ---
Subject: Re: gcc generates code that does not allow retrieval
of struct arguments with debugger
pinskia at gcc dot gnu dot org wrote:
> --- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-02 12:37
> --
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-debug
Known to fail|4.0.3 4.1.0 |4.0.3
--- Comment #7 from martin at mpa-garching dot mpg dot de 2006-03-02 14:29
---
(In reply to comment #6)
> If I understand correctly, this is most likely a bug in FFTW, right? If so,
> I'll report it to FFTW people.
On the other hand, gcc 4.1 also has VRP, but it seems to work fine. Ha
--- Comment #4 from pluto at agmk dot net 2006-03-02 14:32 ---
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24592.pdf
page 33:
[ Zero-Extension of 32-Bit Results. ]
(...) when performing 32-bit operations with a GPR destination
in 64-bit mode, the processor ze
--- Comment #5 from jakub at gcc dot gnu dot org 2006-03-02 14:48 ---
(define_insn "*movdi_xor_rex64"
[(set (match_operand:DI 0 "register_operand" "=r")
(match_operand:DI 1 "const0_operand" "i"))
(clobber (reg:CC FLAGS_REG))]
"TARGET_64BIT && (!TARGET_USE_MOV0 || optimize_
--- Comment #5 from luiscasinhas at mail dot telepac dot pt 2006-03-02
15:03 ---
Sure! Please feel free to change the current bug status to whatever status you
may see fit.
Best regards
--
luiscasinhas at mail dot telepac dot pt changed:
What|Removed
--- Comment #3 from bjkeen at super dot org 2006-03-02 16:03 ---
Created an attachment (id=10956)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10956&action=view)
compute_frame_pointer_to_cfa_displacement internal error source trigger
--
http://gcc.gnu.org/bugzilla/show_bug.cg
When moving from gcc 3.4.3 to 4.1.0, I found a record definition, that causes a
compiler crash:
4.1.0 (i686-pc-linux-gnu) in get_memory_rtx, at builtins.c:1086
raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:380
The compiler has been compiled from source without any special settings, i.e.
> confi
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-02 16:04 ---
Fixed for 4.2.0 by enabling of toplevel bootstrap.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from bjkeen at super dot org 2006-03-02 16:06 ---
I have this same problem, only with Fedora Core 2/x86, building the
cross-compiler for AVR as well. gcc4.1 and gcc 4.03 both stop with this error.
I have attached the preprocessed source file resulting from the following
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-03-02 16:10 ---
(In reply to comment #7)
> On the other hand, gcc 4.1 also has VRP, but it seems to work fine. Has VRP
> become more aggressive, or might it have a new bug?
VRP has become more aggressive or it might be still a bug.
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-03-02 16:10 ---
aermod of Polyhedron has the same problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21130
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-02 16:12 ---
gcc_assert (! DECL_BIT_FIELD (field));
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26529
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-02 16:19 ---
__builtin_memcpy (&_init->protocol_characteristics.F, &T52s.F, 30);
Reduced testcase:
package DATA is
type UNSIGNED_8 is new INTEGER range 0 .. (2 ** 8) - 1;
for UNSIGNED_8'SIZE use 8;
type ADDRE
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-02 16:27 ---
This also happens on the 4.1 branch too, I did not notice it until today.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
The following code will segfault when saying:
g++ -Os test.cpp -o test && ./test
but not with any other -O? options such as
g++ -O3 test.cpp -o test && ./test
preprocessed source:
# 1 "test.cpp"
# 1 ""
# 1 ""
# 1 "test.cpp"
int main()
{
try{
throw 8;
}catch(...){}
}
--
Summary
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-02 16:32 ---
This works in 4.1.0 and above. Closing as fixed since this is not a
regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from steven at gcc dot gnu dot org 2006-03-02 17:47 ---
Not being able to use the HP assembler is definitely not a GCC bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26508
Given the following code:
BEGIN CODE
template
class SomeClass
{
};
#define MYMACRO(BLOCK) \
{ \
BLOCK\
} \
int
main(void)
{
MYMACRO({
SomeClass test;
});
}
END CODE
gcc (3.3.5 on Debian sarge, 3.4.4 on Free
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-02 18:27 ---
This is not a bug.
There are two arguments passed to the macro MYMACRO, "{\nSomeClass test;\n }".
the only way to force an argument passed to the preprocessor macros is to wrap
them in parentheses.
--
pinski
Martin Sebor wrote:
Andrew Pinski wrote:
On Mar 1, 2006, at 7:48 PM, Martin Sebor wrote:
Is there a recommended version of GNU binutils for 4.1? I have been
using 2.13 but the latest compiler doesn't seem to be happy with it.
I tried the latest, 2.16.1, but I get the same error with it as we
--- Comment #6 from janis at gcc dot gnu dot org 2006-03-02 19:10 ---
The test case starts passing on mainline with this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=109088
r109088 | sayle | 2005-12-27 23:27:34 + (Tue, 27 Dec 2005) | 11 lines
* fold-const.c (int_const_bi
From
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00084.html
there are
=== libmudflap tests ===
Running target unix
FAIL: libmudflap.c++/pass41-frag.cxx (test for excess errors)
WARNING: libmudflap.c++/pass41-frag.cxx compilation failed to produce
executable
FAIL: libmudfla
--- Comment #3 from rsandifo at gcc dot gnu dot org 2006-03-02 19:44
---
I said:
> I'm considering adding equivalent code to varasm.c. This will fix
> an inconsistency in the handling of zero-sized decls: sometimes
> they get a byte of storage allocated to them (giving them a unique
>
--- Comment #5 from wilbur dot harvey at spirentcom dot com 2006-03-02
20:01 ---
Subject: Re: compute_frame_pointer_to_cfa_displacement
erro r for avr target with --with-dwarf2
I gave up and deleted everything related.
I will see if I can re-create the environment again.
Wilbur
pi
--- Comment #6 from eric-gcc at omnifarious dot org 2006-03-02 20:25
---
I'm pleased that I came up with such a difficult test case for the optimizer.
I never thought it'd be that hard. :-)
I don't know anything about the internals, but...
The compiler has to generate everything dow
This is probably pretty dodgy C code, but I
find it strange that program foo.c compiles
while program bar.c gives an error. Is this
a bug?
--- foo.c --
#include
int main()
{
int ii;
ii = 276;
void *vv = (void *)ⅈ
}
--- foo.c --
--- bar.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-02 21:14 ---
The first one is ok C even though it is not OK C89 but it is fine C99.
The second one is not ok C at all, since you are deferencing a void pointer.
--
pinskia at gcc dot gnu dot org changed:
What|
#include
struct X
{
unsigned a:4;
};
int main()
{
struct X x = { 63u };
printf("%u\n", x.a);
return 0;
}
// end.
result:
g++bug.cpp; ./a
15
g++ -O bug.cpp; ./a
63
wrong result!!
--
Summary: bitfield wrong optimize
Product: gcc
Version: 4.1.0
--- Comment #7 from janis at gcc dot gnu dot org 2006-03-02 21:25 ---
The test started failing on mainline (before the 4.1 branch) with this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=103109
r103109 | spop | 2005-08-15 12:26:12 + (Mon, 15 Aug 2005) | 8 lines
PR 23391
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-02 21:35 ---
Confirmed, I don't know if this really a front-end issue or a tree opt issue as
we get in cpp:
x.a = 63;
D.2483_3 = x.a;
And then in FRE:
x.a = 63;
D.2483_3 = 63;
But x.a is not a full integer (there should
--- Comment #8 from roger at eyesopen dot com 2006-03-02 21:39 ---
I think I've found the problem. On mainline, its in tree-scalar-evolution.c
at around line 1652, where where handle NEGATE_EXPR in
interpret_rhs_modify_expr.
The code checks whether the type is SCALAR_FLOAT_TYPE_P, in wh
--- Comment #2 from jsm28 at gcc dot gnu dot org 2006-03-03 00:31 ---
Subject: Bug 26478
Author: jsm28
Date: Fri Mar 3 00:31:38 2006
New Revision: 111662
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111662
Log:
PR bootstrap/26478
* Makefile.in (stmp-int-hdrs):
--
Summary: wrong name lookup in clas
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gawrilow at math
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-03-03 00:37
---
The problem appears to be in error.c and occurs with file or internal I/O.
error.c returns as soon as it finds a match to END condition and never looks
for ERR.
--
jvdelisle at gcc dot gnu dot org changed:
--- Comment #3 from patchapp at dberlin dot org 2006-03-03 00:40 ---
Subject: Bug number PR 16136
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00173.html
--
http://gcc.gnu.org/bugzilla/s
This bug seems to be marked as "closed" under the Id 2922.
However, the attached testcase can be successfully compiled by gcc 3.3.5 and
3.4,5, while the brand new gcc 4.1.0 rejects it. If one puts everything in the
global namespace, it compiles again.
I fear, this issue is still far from being c
--- Comment #1 from gawrilow at math dot tu-berlin dot de 2006-03-03 00:47
---
Created an attachment (id=10957)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10957&action=view)
this testcase should compile without diagnostics
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=265
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-03 00:51 ---
No this should not compile and here is why:
class Rational {
public:
Rational& negate() { return *this; }
};
namespace pm {
Rational& inv_sign(Rational& x) { return x.negate(); }
}
Rational is in the topleve
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-03 00:52 ---
*** This bug has been marked as a duplicate of 26536 ***
*** This bug has been marked as a duplicate of 26536 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-03 00:52 ---
*** Bug 26535 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26536
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-03-03 01:51
---
Add a flush just before the truncate in st_write_done and comment seven is
fixed.I had it in there at first, then I took it out to see if things would
still work, and they did with the cases I had. A revised
This code:
extern char *nl_langinfo (int) __attribute__ ((__nothrow__));
char *
xtermEnvEncoding(void)
{
static char *result;
if (result == 0)
result = nl_langinfo(50);
return result;
}
gets compile by gcc-4.1.0 -march=i686 -mtune=i686 to:
xtermEnvEncoding:
[snip]
.L6:
movl
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-03 02:05 ---
This was already reported once before, this is a dup of bug 23488.
*** This bug has been marked as a duplicate of 23488 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-03-03 02:05
---
*** Bug 26537 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23488
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-03 02:08 ---
The problem has nothing to do with basic block reordering anyways. It is just
copying instructions and not optimizing them.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26537
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-03-03 02:10
---
(In reply to comment #5)
> It's strange that the load(*) does not get optimized, given that it's in the
> same BB as the store that precedes it...
>
>movl%eax, result.1282
> (*)movl
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2006-03-03 02:11
---
Subject: Bug 26423
Author: jvdelisle
Date: Fri Mar 3 02:11:07 2006
New Revision: 111664
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111664
Log:
2006-03-02 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #18 from dann at godzilla dot ics dot uci dot edu 2006-03-03
02:14 ---
(In reply to comment #17)
> (In reply to comment #5)
> > It's strange that the load(*) does not get optimized, given that it's in the
> > same BB as the store that precedes it...
> >
> >movl
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-03-03 02:16
---
(In reply to comment #18)
> Right, the copying happens in .bbro (as shown in PR26537).
> gcc-4.0 did the same kind of copying in .bbro, but it did not generate the
> redundant mov.
And that is because load PRE hap
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2006-03-03 02:16
---
Subject: Bug 26423
Author: jvdelisle
Date: Fri Mar 3 02:16:06 2006
New Revision: 111665
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111665
Log:
2006-03-02 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2006-03-03 02:17
---
Fixed on 4.1.1
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
St
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-03 02:17 ---
Can either one of you try the patch in PR 26015?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26504
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-03-03 05:13
---
Subject: Bug 26464
Author: jvdelisle
Date: Fri Mar 3 05:13:06 2006
New Revision: 111669
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111669
Log:
2006-03-02 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-03-03 05:21
---
Subject: Bug 26464
Author: jvdelisle
Date: Fri Mar 3 05:21:52 2006
New Revision: 111670
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111670
Log:
2006-03-02 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2006-03-03 05:44
---
Fixed now in 4.1.1
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from patchapp at dberlin dot org 2006-03-03 05:50 ---
Subject: Bug number PR26107
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00186.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #24 from jvdelisle at gcc dot gnu dot org 2006-03-03 06:00
---
Subject: Bug 26136
Author: jvdelisle
Date: Fri Mar 3 06:00:08 2006
New Revision: 111672
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111672
Log:
2006-03-02 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #25 from jvdelisle at gcc dot gnu dot org 2006-03-03 06:03
---
Subject: Bug 26136
Author: jvdelisle
Date: Fri Mar 3 06:03:01 2006
New Revision: 111673
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111673
Log:
2006-03-02 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #26 from jvdelisle at gcc dot gnu dot org 2006-03-03 06:04
---
Fixed on 4.1.1
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
St
Hi,
I am using Gentoo Linux.
I followed the following steps:
Make directory ~/src/packages/gcc-4.1-svn
Change directory to ~/src/packages/gcc-4.1-svn
Get sources via "svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch
gcc-4.1-branch"
make directory ~/src/packages/gcc-4.1-svn/test_build
--- Comment #1 from ayqazi at yahoo dot co dot uk 2006-03-03 06:49 ---
Created an attachment (id=10958)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10958&action=view)
Log of just the 'make install' command
make install executed separately again, and its complete output logged,
b
92 matches
Mail list logo
