--- Comment #3 from bkoz at gcc dot gnu dot org 2005-10-27 06:04 ---
Naming wise I think __gnu_ext makes more sense. It's what we should have used
for the extension namespace from the beginning.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24537
C:\Fortrangfortran TOBAM5.f
TOBAM5.f:527: internal compiler error: in gfc_assign_data_value, at
fortran/data
.c:319
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
Summary: internal compiler error
Used g++ 4.0.2 with accompanying libstdc++ 4.0.2 under SuSE Linux 10 64-bit and
Ubuntu Linux 5.10 32-bit. Using both 64-bit g++ with and without -m32 switch,
as well as 32-bit g++, cout occasionally produces a segfault which could not
be reproduced under 3.3.5 or various flavors of 3.4.
--- Comment #1 from springmalnachlinks at yahoo dot de 2005-10-27 07:46
---
Created an attachment (id=10068)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10068action=view)
Tic-Tac-Toe game, which produces the segfault under certain build envs
--
Hi,
We have a thread library which can't be optimized as much as before, because
-starting from gcc 3.4- functions calling setjmp can not be inlined. Our
problem is with our switchto function:
void switchto(task_t *cur, task_t *next) {
if (cur!=next) {
if (setjmp(cur-buf)
--- Comment #4 from pcarlini at suse dot de 2005-10-27 09:07 ---
(In reply to comment #3)
Naming wise I think __gnu_ext makes more sense. It's what we should have used
for the extension namespace from the beginning.
Of course I'm ok with __gnu_ext. Actually, I'm ok with anything you
--- Comment #3 from christopher dot eltschka at physik dot uni-regensburg
dot de 2005-10-27 09:11 ---
I just stumbled on the same problem, but with much more conventional numbers.
The following C++ test program demonstrates it:
#include iostream
// this just serves to calculate a
--- Comment #5 from erik dot edelmann at iki dot fi 2005-10-27 09:25
---
Patch here: http://gcc.gnu.org/ml/fortran/2005-10/msg00587.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24503
--- Comment #2 from pcarlini at suse dot de 2005-10-27 10:16 ---
I can see a few possible strategies:
1- Arches supporting the new __sync_fetch_and_add (at least, i686, x86_64,
powerpc
ia64, s390), could simply use it on the existing __bin._M_used.
2- Otherwise, a lock in
--- Comment #6 from eedelman at gcc dot gnu dot org 2005-10-27 10:26
---
*** This bug has been marked as a duplicate of 18883 ***
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from eedelman at gcc dot gnu dot org 2005-10-27 10:26
---
*** Bug 24503 has been marked as a duplicate of this bug. ***
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from eedelman at gcc dot gnu dot org 2005-10-27 10:28
---
Patch here: http://gcc.gnu.org/ml/fortran/2005-10/msg00587.html
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
When compiled with g77/gfortran, the double precision arpack examples hang
before executing the first line of code. gcc 3.3 works fine.
gcc 3.4.4, 4.0.2
x86 linux and mingw32
compile options: -funroll-all-loops -O3
Cezary Sliwa
--- Comment #4 from christopher dot eltschka at physik dot uni-regensburg
dot de 2005-10-27 10:38 ---
(In reply to comment #3)
As workaround for == 0, !! seems to work. Unfortunately I don't know a
workaround for 0 and 0.
Sorry for self-reply, but now I've found a simple
kl-nrb:~$ cat buggy.f90
program main
implicit none
character(4) :: a(2)
print *,fun(a)
contains
function fun(arg)
character(len=*), intent(in) :: arg(:)
integer :: fun(size(arg))
fun = 5
end function fun
end pkl-nrb:~$ gfortran41 buggy.f90
buggy.f90:4: internal compiler
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-10-27 11:18 ---
*** This bug has been marked as a duplicate of 17737 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-10-27 11:26 ---
Confirmed, in principle. Though, in this light, one needs to re-evaluate if
the branch cost of 1 is good for optimize_size. Same for x86_64, btw., which
should really get different size-cost table for 64bit.
--
--- Comment #2 from steven at gcc dot gnu dot org 2005-10-27 11:26 ---
Huh, how can this ICE be a duplicate of an accepts-invalid bug??
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24554
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-10-27 12:33 ---
Because if you look in that BUGs audit-trail we have
The error message is
city3s.f:0: internal compiler error: in gfc_assign_data_value, at
fortran/data.c:319
given the detailled information in this (24554)
With explicitely declared types for a function and it's entry points, I get a
'Duplicate key found!' error:
kl-nrb:~$ cat test_entry_2.f90
module foo
contains
function n1()
integer :: n1, n2
n1 = 1
return
entry n2()
n2 = 2
return
end function
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-27 13:37 ---
This is not a bug as if you inline it, the place setjmp goes to could be not
where you want to goto.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from samuel dot thibault at ens-lyon dot org 2005-10-27
13:45 ---
Subject: Re: gcc can't inline functions using setjmp
pinskia at gcc dot gnu dot org, le Thu 27 Oct 2005 13:37:32 -, a écrit :
This is not a bug as if you inline it, the place setjmp goes to could
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-27 13:59 ---
Related to PR14358
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24552
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-10-27 14:01
---
(In reply to comment #12)
I might have a fix for the two error messages, though it might also cause
other
issues, let see what happens in the test results.
It did not work.
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-27 14:11 ---
I have a simple fix for this, we just need to copy the type as it looks as it
is shared now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-10-27 14:11 ---
I believe it should be safe to inline, as inlining can only make a previously
invalid use of sjlj valid, but not the other way around.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24556
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-10-27 14:33
---
I will relook at this and post it soon.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-27 14:44 ---
A regression from 3.4.x and 3.3.x.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot
|dot org
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-10-27 15:48 ---
Confirmed as a diagnostics issue.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pluto at agmk dot net 2005-10-27 16:00 ---
With my patched gcc-4.1.0-20051019 the testcase works.
Applied patches: PR7776, PR20297, PR22429, PR22533, PR23948,
PR19505, PR20606, PR24069, PR24419, PR24172, PR24295, PR20928
[EMAIL PROTECTED] BUILD]$ gcc -Wall -O2
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-27 16:22 ---
Hmm, ICC gets it wrong too, maybe there is a misunderstanding somewhere.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24312
--- Comment #7 from steven at gcc dot gnu dot org 2005-10-27 16:26 ---
Could the dear reported at least try to provide a small test case?
I think this should not be marked as a regression. It's just sad that this
kind of non-bug keeps the regression count high, when in reality GCC 4.1
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-27 16:30 ---
I think this has been fixed as I get an error on i686-pc-linux-gnu with your
non-Pmode pointers expample. This was on the mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18182
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-27 16:40 ---
Closing as fixed for 4.0.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |3.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21939
--- Comment #8 from dann at godzilla dot ics dot uci dot edu 2005-10-27
16:43 ---
(In reply to comment #7)
Could the dear reported at least try to provide a small test case?
The testcase in the attachment contains only a 4 lines function:
HandleDeIconify, the rest is just fluff to
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-27 16:45 ---
This works now but I don't know if this is really fixed as the now libgfortran
just calls into malloc/free without wrapping it so we get errors like this.
Newer glibc should error out but I don't have it because I
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-27 16:46 ---
We get an ICE now:
t.f90:26: internal compiler error: in gfc_trans_arrayfunc_assign, at
fortran/trans-expr.c:2632
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-27 16:48 ---
Closing as fixed in 4.0.1.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-27 16:56 ---
Fixed for 4.0.3 and above.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from steven at gcc dot gnu dot org 2005-10-27 17:08 ---
And CSiBE tells you the story that GCC 4.1 produces smaller code overall.
http://www.inf.u-szeged.hu/csibe/draw-diag.php?draw=sum-osbasephp=s-i686-linux
So do the SPEC benchmark boxes btw.
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-27 17:21 ---
The realy problem here is that the xor is produced after reload and is really
only done on some x86 targets.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from tobi at gcc dot gnu dot org 2005-10-27 17:21 ---
We should bump the library file's version number.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24541
--- Comment #10 from steven at gcc dot gnu dot org 2005-10-27 17:31 ---
For the record, we're talking about:
1.file t.c
2.text
3.p2align 4,,15
4.globl foo
5
--- Comment #11 from steven at gcc dot gnu dot org 2005-10-27 17:34 ---
And FWIW there is also a problem with this insn, the length is wrong:
#(insn 11 46 47 0x2a955cc840 (set (reg:SI 0 eax [orig:61 x ] [61])
#(mem/f:SI (symbol_ref:SI (x)) [5 x+0 S4 A32])) 44 {*movsi_1} (nil)
#
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-27 17:57 ---
Closing as fixed for 4.0.2.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-10-27 17:59
---
This is still a bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-27 18:01 ---
You install a compiler via the installer you installed the OS from (since this
is GNU/Linux).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
According to the C++ standard the declarations of wcspbrk should take two cont
pointers or a (non-const pointer and a const pointer (in that order):
The actual declarations as if gcc 4.0 and apparently since introduction of the
second declaration take either two const pointers or two non-const
--- Comment #12 from dann at godzilla dot ics dot uci dot edu 2005-10-27
18:08 ---
(In reply to comment #9)
And CSiBE tells you the story that GCC 4.1 produces smaller code overall.
http://www.inf.u-szeged.hu/csibe/draw-diag.php?draw=sum-osbasephp=s-i686-linux
Well, it obviously
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-27 18:16 ---
Confirmed, the issue is in libstdc++.
inline wchar_t*
wcspbrk(wchar_t* __s1, wchar_t* __s2)
{ return wcspbrk(const_castconst wchar_t*(__s1), __s2); }
--
pinskia at gcc dot gnu dot org changed:
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-10-27 18:30 ---
Changing the summary to give a better idea what is going on here.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-27 19:21 ---
Patch posted: http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01582.html.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-10-27 19:36
---
Patch submitted: http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01583.html.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pcarlini at suse dot de 2005-10-27 19:42 ---
Thanks, likely will be the first svn library commit ;)
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-27 19:49
---
Will commit once SVN is alive:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01584.html.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Testcase:
struct A { void f(); };
void g() { A().f.a; }
GCC 3.4 and 4.0 display the following error message:
a.cpp:2: error: insufficient contextual information to determine type
This message is surprising, because, whatever the context, a compiler will
never be able to do anything useful
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-27 19:55 ---
2.95.3 to 3.2.3 gave:
t.cc: In function `void g()':
t.cc:3: request for member `a' in `{}.A::f', which is of non-aggregate type
`unknown type'
Which is close to what you were expecting so this is a regression.
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-27 20:01 ---
I might look into this soon.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-27 20:31 ---
Nothing can happen until 4.2.0 for this issue really as we need a real copy
prop for structs.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-27 20:34 ---
(In reply to comment #5)
It gets worse if the unknown escape is at the beginning of the file and then
you have about 100 more lines.
Or even in a different file.
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20681
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19989
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-10-27 21:15 ---
This is a combination of a GCC extension (of cast to union) and a C99 feature
(subscripting a non-lvalue array) so this is valid code (but undefined code)
even though it looks so weird.
Anyways I have a patch which
--- Comment #13 from hubicka at gcc dot gnu dot org 2005-10-27 21:18
---
This is patch I am testing to prevent the sharing. I think it is good idea in
addition to Richard's patch to make fold do it's job too:
void IOException( char);
inline int* dummy( const char* const mode )
{
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-27 21:55 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-27 22:00 ---
Confirmed, backtace:
#0 0x080ffa9b in convert_nonlocal_reference (tp=0xb7c6cabc,
walk_subtrees=0xbfe14468, data=0xbfe14538)
at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/tree-nested.c:829
#1 0x0836eea5 in
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-27 23:12 ---
For the second one, I get an ICE:
t.f90:10: internal compiler error: in gfc_conv_variable, at
fortran/trans-expr.c:355
But confirmed otherwise.
--
pinskia at gcc dot gnu dot org changed:
What
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-27 23:13 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-27 23:15 ---
(In reply to comment #1)
To let gdb recognize 'a' directly, some trick in gdb might be needed.
I don't know if some trickery is needed, just we might need to emit something
like what C++ does with it using
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-27 23:24 ---
Confirmed. This is a gdb bug as if I do:
set lang c
it works.
Oh, I think there is a dup around somewhere too.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-27 23:27 ---
This is more of a gdb bug as if I do:
set lang c
it prints out the array as a descriptor:
$2 = {data = 0x9a7f2d8, offset = -1, dtype = 265, dim = {{stride = 1, lbound =
1, ubound = 10}}}
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-27 23:32 ---
From the looks of it, some of these are really gdb issues as they work when you
do:
set lang c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24546
4.0.x and mainline have regressed WRT 3.4.x
// Ensure freelist is constructed first.
static int freelist_mutex = 1;
static void
_M_destroy_thread_key(void* __id)
{ int i = 0; }
void
_M_destroy_thread(void* __id)
{ int i = 0; }
gives:
%gcc -x c -g -O0 -c testme.cc
%nm
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-27 23:56 ---
This is because unit at a time is turned on by default.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-27 23:58 ---
I don't know if this is really can be considered a bug as the static defintions
are unused. If you want to keep them, you have to use the attribute used. But
I will let someone else (Mark?) to decide.
--
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-10-28 00:11
---
I wouldn't call this a regression; I don't think there's any guarantee that
unused statics stay around, even with -O0.
However, I tend to agree that it would be better if they did stay around at
-O0. In other
--- Comment #4 from samuel dot thibault at ens-lyon dot org 2005-10-28
00:21 ---
Well, there is indeed an issue: the address of some local variables might be
passed to other functions and then be modified in an external way between
setjmp() and longjmp(), and if some local variables
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-28 00:24 ---
(In reply to comment #3)
I wouldn't call this a regression; I don't think there's any guarantee that
unused statics stay around, even with -O0.
It is a regression as turning on unit-at-a-time at -O0 changed it.
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-28 00:37 ---
(In reply to comment #4)
That is not really GCC's fault.
Let me look into why setjmp was caused not to inline, there was a reason.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24556
--- Comment #6 from samuel dot thibault at ens-lyon dot org 2005-10-28
00:47 ---
Subject: Re: gcc can't inline functions using setjmp
pinskia at gcc dot gnu dot org, le Fri 28 Oct 2005 00:37:47 -, a écrit :
Let me look into why setjmp was caused not to inline, there was a
--- Comment #5 from mark at codesourcery dot com 2005-10-28 00:50 ---
Subject: Re: no static definition
pinskia at gcc dot gnu dot org wrote:
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-28 00:24
---
(In reply to comment #3)
I wouldn't call this a
When make bootstrap gcc4.0.2, I receive error:
make[3]: *** No rule to make target `../zlib/libz.a', needed by `fastjar'.
Stop.
What's error? How I do to fix? Thank you.
This is my configure command:
CXXFLAGS='-Xassembler gstabs' ../src/gcc-4.0.2/configure
--prefix=/usr/local/binut/
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-28 01:34 ---
(In reply to comment #5)
I understand it's a change. That's different from saying it's a regression.
It was an unexpected change really at least as far as I can tell
Then, this bug should be changed to be a
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-28 01:37 ---
First try to configure with an absolute path.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-28 01:39 ---
So this is not a bug. Closing as won't fix. You found the issue and the docs
for setjmp are really clear.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-28 01:42 ---
Second can you show how you build gcc?
And attached the full build log.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-28 01:52 ---
Does this work now, I think it does?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23720
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2005-10-28
02:01 ---
Subject: Re: FAIL: gcc.dg/debug/dwarf2/dwarf-char[123].c scan-assembler
0x[68][ \t]# DW_AT_encoding
Does this work now, I think it does?
Right, I'm not seeing it anymore.
Dave
--
--- Comment #7 from mark at codesourcery dot com 2005-10-28 02:16 ---
Subject: Re: no static definition
pinskia at gcc dot gnu dot org wrote:
Not really as unit at a time is considered an optimization and the C++
front-end just turns it on always.
I don't think that's accurate.
--- Comment #3 from luongductruong at gmail dot com 2005-10-28 02:32
---
Created an attachment (id=10070)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10070action=view)
GCC 4.0.2 Full Log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24562
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-28 02:34 ---
Fixed so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from luongductruong at gmail dot com 2005-10-28 02:39
---
(In reply to comment #2)
Second can you show how you build gcc?
And attached the full build log.
Following the instruction at gcc.gnu.org/install/configure.html
I attached the full build log. The error
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-28 02:45 ---
What tar file did you download?
You should have a zlib directory in the src directory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24562
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-28 03:36
---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01598.html.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-10-28 03:57
---
Actually I figured out how to fix the problem with my patch, just moving around
error mark node is what is needed here.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
1 - 100 of 109 matches
Mail list logo
