Hi,
Sorry if this is the wrong place to ask this, but I've heard about the
Summer of Code project to create lock-less containers for use with
GCC. What happened to that project? Is there code to download
anywhere?
Best regards,
dm.n9107
Hello,
I have a new port for CR16 (National Semiconductor's 16-bit processor)
for submission. While I was searching the mail archives, I found
following steps are required for submitting the patches to GCC:
1. Submit the patches for reviewing and approval to gcc-patches mailing
list. After
Hello all,
I am working for a private GCC target.
The target has 4 registers, each 32 bits reserved for arguments.
When passing arguments depending on the type of the argument either
registers or stack + registers will be used Sometimes the arguments
will be split between a memory location and
Hello,
I have downloaded sparc-rtems4.7 and would like to use it for a leon2 target
with fpu. I am puzzled on how the compiler inserts fpu instructions. My summary
is:
- The compiler does insert fpu instructions, if no fpu command line option is
given or if -mhard-quad-float is used.
- The
The gcc version used by RTEMS 4.7 is 4.1.1 with no patches in this area.
I duplicated this behavior with gcc 4.2.0. gcc 3.2.3 still generated FPU
instructions in his test case.
--joel
Peter A. Krauss wrote:
Hello,
I have downloaded sparc-rtems4.7 and would like to use it for a leon2 target
I have downloaded sparc-rtems4.7 and would like to use it for a leon2
target with fpu. I am puzzled on how the compiler inserts fpu instructions.
My summary is:
- The compiler does insert fpu instructions, if no fpu command line option
is given or if -mhard-quad-float is used.
- The
Eric Botcazou wrote:
I have downloaded sparc-rtems4.7 and would like to use it for a leon2
target with fpu. I am puzzled on how the compiler inserts fpu instructions.
My summary is:
- The compiler does insert fpu instructions, if no fpu command line option
is given or if -mhard-quad-float is
On Tue, 12 Jun 2007, Kenneth Zadeck wrote:
Kaveh R. GHAZI wrote:
I'm getting a new bootstrap failure today on sparc-sun-solaris2.10 which
I've filed under PR bootstrap/32312. GCC dies in stage1 building libgcc2,
I see that it's getting a SEGV because the variable df is nil. It might
be
Exception handling on the Blackfin was broken by the dataflow merge.
Inspecting the differences in the generated code, it appears that when
compiling functions like _Unwind_Resume in unwind-dw2.c, the dse pass
deletes necessary instructions.
Before:
(insn 56 55 57 7 (set (reg/v:SI 56 [ offset ])
Pompapathi V Gadad [EMAIL PROTECTED] writes:
My GCC assignment/disclaimer process with the FSF is complete. It
would be greatly appreciated, if someone can provide information about
the following:
a) Can the write permissions to port specific files can be obtained
even before submitting the
Mohamed Shafi [EMAIL PROTECTED] writes:
I am working for a private GCC target.
The target has 4 registers, each 32 bits reserved for arguments.
When passing arguments depending on the type of the argument either
registers or stack + registers will be used Sometimes the arguments
will be
Bernd Schmidt wrote:
There is a reference to current_function_uses_eh_return in dse.c, but
it's not clear to me what it's trying to achieve. Anyway, turning the
store into an unspec_volatile solves the problem. I've committed the
following.
I will look into this.
kenny
Hello,
I have two ssa vars (i0 and i1 in the following example); what is the
sequence to generate a new phi node corresponding to i3 -
if (...)
i0 = exp1
else
i1 = exp2
i3 = PHI(i0 , i1);
Thanks,
Revital
Hello,
Backtrace API is trapping when it is called inside a signal handler
to trace back an invalid function call.
Backtrace API is called from a signal handler. When the SEGFAULT signal
that is captured by the signal handler is due to the invokation of an
invalid function call, then
On 6/13/07, Kenneth Zadeck [EMAIL PROTECTED] wrote:
Richard Guenther wrote:
On Tue, 12 Jun 2007, Richard Guenther wrote:
On ia64 SPEC2000 I see fma3d and applu now miscompare.
On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO:
Snapshot gcc-4.2-20070613 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20070613/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Andrew --
Now that dataflow has gone in, you have the ball. When you feel that
PTR_PLUS is in suitable shape to go in, and the patches have been
reviewed, please merge and commit.
I know that there have been some reviews of the patches along the way,
and the concept has been appropriately
Hello Ian,
Thanks for the valuable information.
My GCC assignment/disclaimer process with the FSF is complete. It
would be greatly appreciated, if someone can provide information about
the following:
a) Can the write permissions to port specific files can be obtained
even before submitting the
On 6/13/07 11:33 PM, Andrew Pinski wrote:
I am testing the changes which were requested earlier today. I could
not tell if Diego's was an official approval or not. I have approval
currently officially only for the Fortran parts.
It was, with the changes I suggested, for the non-FE parts.
On 13 Jun 2007 10:47:33 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Mohamed Shafi [EMAIL PROTECTED] writes:
I am working for a private GCC target.
The target has 4 registers, each 32 bits reserved for arguments.
When passing arguments depending on the type of the argument either
--- Comment #3 from malitzke at metronets dot com 2007-06-13 06:06 ---
Maybe some people should read __carefully__ both the C standard and the new
GPL3
--
malitzke at metronets dot com changed:
What|Removed |Added
Found at:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/34f509b6b4241c6d/
program chkdata
character(len=20), dimension(4) :: string
data ( string(i) ,i=1,5 ) /
'A', 'B', 'C', 'D', 'E' /
write(*,*) string
end program chkdata
gfortran gives no
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-13 06:26 ---
Maybe some people should read __carefully__ both the C standard and the new
GPL3
What does that mean? There is a working draft of dfp in the C standards
committee
See
--- Comment #3 from daney at gcc dot gnu dot org 2007-06-13 06:26 ---
Created an attachment (id=13696)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13696action=view)
Proposed fix.
I will try to bootstrap the Proposed fix tomorrow.
--
--- Comment #4 from echristo at apple dot com 2007-06-13 06:36 ---
Patch looks reasonable.
--
echristo at apple dot com changed:
What|Removed |Added
CC|
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-13 06:46 ---
Dump shows:
static char string[4][1:20] = {A , B ,
C , D , E}
Check should probably be in resolve.c's
--- Comment #5 from malitzke at metronets dot com 2007-06-13 07:09 ---
All I want for gcc is that it meets both the letter __and__ the spirit of
applicable contracts and specifications.
First, the GPL is a contract, do __not__ take my word for it but consult a
lawyer.
Second, the C
--- Comment #3 from pault at gcc dot gnu dot org 2007-06-13 07:27 ---
(In reply to comment #2)
I can't reduce that any more, it depends on the module files being huge: if
you
trim them down to a lower number of symbols, they ICE disapears. And I can't
reproduced it either on
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-13 07:30 ---
The C extensions are disabled with --disable-decimal-float. I never said they
were not, in fact here is a quote from me:
Even if you disable dfp, libdecnumber is still needed to compile gcc as
disable-decimal-float
--- Comment #16 from rob1weld at aol dot com 2007-06-13 07:53 ---
I did some testing on the CVS of crlibm, (it needs a few files from
crlibm-1.0beta1.tar.gz).
The new docs list these interesting features:
portable to any system implementing the ISO-C99 and IEEE-754 standards,
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-06-13 08:02
---
(In reply to comment #3)
Are there any equivalences in the the sources for the modules and do they have
any data statements? Even if they do, I am not sure that I believe that the
PR29786 patch is involved -
--- Comment #11 from rob1weld at aol dot com 2007-06-13 08:06 ---
The configure script should check the headers against the library version.
Two people from gcc.gnu.org and I all got nailed by this. It may bite others
with less computer knowledge than ourselves.
The bug is this:
1):
--- Comment #1 from dorit at il dot ibm dot com 2007-06-13 08:41 ---
Sorry about the breakage. Does it work for you if you change the testcase as
follows?:
Index: pr32224.c
===
--- pr32224.c (revision 125641)
+++
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-13 08:50 ---
Sorry about the breakage. Does it work for you if you change the testcase as
follows?:
Yes it will fix it but note there is still a bug in the ia64 back-end anyways
so this bug should not be closed as being
--- Comment #5 from pault at gcc dot gnu dot org 2007-06-13 09:01 ---
Dear All,
I think that you are probably right - it looks like my patch for PR29786 is
to
blame, since it is the only thing to touch trans-common.c for a long time.
This is incorrect - it goes back at least as
--- Comment #6 from pault at gcc dot gnu dot org 2007-06-13 09:04 ---
PS - It also explains a failure by gfortran to produce a working version of the
PROTEUS tokamak equilibrium code. I just tried, for the first time, to compile
it with no optimization. It is SLOW but it goes. It
--- Comment #7 from pault at gcc dot gnu dot org 2007-06-13 09:30 ---
The problem lies with the common block aux32, which is declared in subroutine
unpki with 6 integer(4) arrays at the beginning and, elsewhere, is declared
with default reals. Apparently, this makes a mess of the
--- Comment #12 from rob1weld at aol dot com 2007-06-13 09:32 ---
Comment #10 From Andrew Pinski 2007
This is not a bug.
Here is the deal, the reporter compiled GCC with the new headers but is using
the old library (which is known to be buggy).
Comment #6 From Rob
warning: MPFR
--- Comment #13 from rob1weld at aol dot com 2007-06-13 09:38 ---
Reopen bug reason: Request we add proposed fix to main configuration script.
--
rob1weld at aol dot com changed:
What|Removed |Added
--- Comment #52 from seb at frankengul dot org 2007-06-13 10:12 ---
(In reply to comment #51)
I believe I'm seeing this bug using a redhat build: gcc4.1.1-1 (shows up all
the way through -51). It's only on 64bit FC5, 32bit is okay and am installing
FC6 to test. Building XULRunner
When compiling with g++ -fprofile-arcs -ftest-coverage ... I got the following
segmentation fault:
/temp//TypeDictionary.C: In function (static destructors for
/temp//TypeDictionary.C):
/temp//TypeDictionary.C:315: internal compiler error: Segmentation fault
Taking a look at the
--- Comment #17 from joseph at codesourcery dot com 2007-06-13 11:30
---
Subject: Re: Paranoia UCB GSL TestFloat libm tests fail
- accuracy of recent gcc math poor
I previously suggested to the crlibm authors that they consider assigning
it to the FSF for contribution to
--- Comment #3 from ubizjak at gmail dot com 2007-06-13 11:55 ---
(In reply to comment #2)
Sorry about the breakage. Does it work for you if you change the testcase
as follows?:
Yes it will fix it but note there is still a bug in the ia64 back-end anyways
so this bug should not
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-06-13 12:08
---
Can you provide a working patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32258
--- Comment #8 from pault at gcc dot gnu dot org 2007-06-13 12:26 ---
This fixes it but is, as yet unregtested. I'll do the business tonight and
will commit as 'obvious', if all is well.
Thanks, Dale!
Paul
Index: gcc/fortran/trans-common.c
--- Comment #5 from pranav dot bhandarkar at gmail dot com 2007-06-13
12:36 ---
Which RTL pass should take care of such induction variable optimization in 4.3
? For e.g In 4.1, It was old-loop that was doing it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-13 13:14 ---
Can you attach the preprocessed source?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-13 13:24 ---
Sorry if I was not clear before. This is the correct fix for the testcase but
not the bug itself. Users could accidently use the %q0 and then get the ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32274
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-13
13:28 ---
Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
It's my turn to ask: so what information does hppa_can_use_return_p
need to make the decision ?
We need to know that the return
--- Comment #7 from rask at sygehus dot dk 2007-06-13 13:36 ---
Looking at this again, I don't think the transformation I'm making with the
splitter is valid, because I'm making up a zero extension which wasn't there to
begin with. The upper part could have been non-zero before the
Even when an explicit interface is known, no warnings are generated when array
argument bounds (available to the compiler) don't match. Consider the
following:
module mod
implicit none
contains
subroutine a(n,v)
integer,intent(in)::n
real,dimension(n),intent(in)::v
write(*,*)v
end subroutine a
--- Comment #9 from dir at lanl dot gov 2007-06-13 13:39 ---
Your Welcome Paul,
With a little luck, the fix for this will cure the remaining problems that I
have been having with my programs when optimization is turned on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32302
--- Comment #1 from terry at chem dot gu dot se 2007-06-13 13:43 ---
(Whoops. Mixed up output in that last post. Only 8 reals are printed in
reality. My bad.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32317
--- Comment #2 from patrick dot pastoor at onespin-solutions dot com
2007-06-13 14:26 ---
I am really sorry. But I think there is no possiblity to upload a preprocessed
source here
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32316
--- Comment #2 from ckirshen at gnupower dot net 2007-06-13 14:37 ---
This problem definitely exists on both hpux 11v2 and 11v3, even when passing in
--with-gnu-as and --with-as. I'm trying this on gcc-3.4.3 and gcc-3.4.6
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18388
--- Comment #10 from pault at gcc dot gnu dot org 2007-06-13 15:00 ---
I goofed - the previous does not fix it at all.
I hope that I am not too late to stop folk from building with this patch.
Cheers
Paul
PS Compiling the subroutines separately or padding out the first aux32 both
--- Comment #6 from jakub at gcc dot gnu dot org 2007-06-13 15:22 ---
I see that PR25505 caused a bunch of code generation regressions.
On i?86, with -O2 -m32:
_Complex double foo (_Complex double x)
{
return __builtin_cexp (x);
}
generated code got much worse, similarly:
elemental
The spec file explains that the picture %c stands for
locale's date and time (including the time zone).
However, the replacement picture doesn't include %z (which
isn't supported AFAICS.)
from the spec:
-- %c locale's date and time (Sat Nov 04 12:02:33 EST 1989)
from the body:
[EMAIL PROTECTED] cat run.f90
subroutine aa(v)
integer,dimension(:),intent(out)::v
write(*,*)size(v)
v=0
end subroutine aa
program ff
implicit none
integer,dimension(10)::w
w=1
write(*,*)w
call aa(w(1:5))
write(*,*)w
end
[EMAIL PROTECTED] gfortran -Wall -W -fbounds-check -O --std=f95 --pedantic
+++ This bug was initially created as a clone of Bug #27668 +++
The following invalid code snippet triggers an ICE since GCC 3.4.0:
==
templatetypename class T, T = T() struct A {};
templateint void foo(Aint);
gcc-4.3 -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --enable-checking --prefix=/opt/gcc
--enable-shared --enable-threads --program-suffix=-4.3 --enable-__cxa_atexit
--disable-nls --with-mpfr=/usr/local
--enable-languages=c,c++,objc,obj-c++,treelang,fortran
In a template-context, pointers to overloaded methods are not correctly
resolved. the following main.cpp does not compile on gcc 4.1.2, however it does
compile on version 3.4.6:
#include boost/multi_index_container.hpp
#include boost/multi_index/member.hpp
#include
--- Comment #1 from tsarkov at cs dot man dot ac dot uk 2007-06-13 15:42
---
Created an attachment (id=13697)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13697action=view)
Preprocessed sources
Code that triggers ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32321
--- Comment #3 from ghazi at gcc dot gnu dot org 2007-06-13 15:45 ---
Fixed:
http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00615.html
by this patch:
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00842.html
--
ghazi at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from ghazi at gcc dot gnu dot org 2007-06-13 15:57 ---
(In reply to comment #2)
The generic implementation, including for SSE, is
isgreater (abs(f), FLT_MAX)
For isfinite, use islessequal instead. For isnan, one can use
isunordered(f, f)
For isnormal, it'd be
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-06-13 15:57 ---
If you would provide an explicit interface for AA, the binary would not
segfault:
$ cat pr32319.f90
program ff
implicit none
integer,dimension(4)::w
w=1
write(*,*)w
call aa(w(2:3))
write(*,*)w
contains
--- Comment #2 from terry at chem dot gu dot se 2007-06-13 16:10 ---
Ah. Of course explicit interfaces are required for automatic array arguments.
My Fortran-Fu seems to be deserting me at the moment. :-(
--
terry at chem dot gu dot se changed:
What|Removed
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-06-13 16:17 ---
Neither SUN nor Intel fortran compilers issue such a warning.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||spark at gcc dot gnu dot org
Keywords|
--- Comment #3 from terry at chem dot gu dot se 2007-06-13 16:23 ---
(In reply to comment #2)
Neither SUN nor Intel fortran compilers issue such a warning.
Indeed. That does not imply that gfortran shouldn't, though. Hence the
enhancement request.
--
[EMAIL PROTECTED] cat run.f90
module mod
implicit none
contains
subroutine aa(v)
integer,dimension(:),intent(out)::v
write(*,*)size(v)
v=0
end subroutine aa
end module mod
program ff
use mod
implicit none
integer,dimension(10)::w
w=1
call aa(w((/3,2,1/)))
write(*,*)w
end
[EMAIL PROTECTED]
The result of the division of 18446744065119617024llu by the result of (131)
is wrong on a 32bit platform.
Reproduce: gcc s.c ./a.out
should have exit code 0 but doesn't.
Expected: gcc -DEXPECTED s.c ./a.out
has exit code 0 as expected.
gcc -v
Reading specs from
--- Comment #1 from gcc at axel-naumann dot de 2007-06-13 16:50 ---
Created an attachment (id=13699)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13699action=view)
Test case as stated in the report.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32324
--- Comment #7 from jconner at apple dot com 2007-06-13 17:09 ---
(In reply to comment #6)
I see that PR25505 caused a bunch of code generation regressions.
On i?86, with -O2 -m32:
...
When you say regressions, I assume you mean size/performance, not correctness,
right? If so,
--- Comment #4 from appfault at hotmail dot com 2007-06-13 17:38 ---
Yes in addition to the issue of adding a test case, it is quite unsettling to
not know what might have fixed it. Reopening pending response to comment 2 and
comment 3.
--
appfault at hotmail dot com changed:
--- Comment #18 from kargl at gcc dot gnu dot org 2007-06-13 17:52 ---
The libm library is the least accurate and on average the fastest; though not
fastest for every function instance. The most accurate is always CRLibm,
sometimes it is fastest. The MPFR library is second most
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-13 17:53 ---
Look at PR 17108 also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from appfault at hotmail dot com 2007-06-13 17:56 ---
Ok well, I'll take your word on that, since I can't really tell where gcc and
ld end and glibc begins. It's perhaps glibc that is in need of better
documentation then. However if I file such a zilla I suspect it will
--- Comment #2 from andrew dot stubbs at st dot com 2007-06-13 18:00
---
As it happens, I encountered your real problem quite recently. :)
(int)(131) is undefined (C99 standard 6.5.7/4).
This modified version gives the same result both ways:
int main (){
unsigned long long a =
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-13 18:03 ---
Thanks for finding this bug! I think it is the following in the Fortran 2003
standard:
12.4.1.2 Actual arguments associated with dummy data objects
If a nonpointer dummy argument has INTENT (OUT) or INTENT (INOUT),
During a mainline bootstrap on alpha-dec-osf5.1b, the libstdc++ configure
failed:
checking for exception model to use... configure: error: unable to detect
exception model
make[1]: *** [configure-target-libstdc++-v3] Error 1
config.log reveals:
configure:13794: checking for exception model to
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c++ |target
This may be a duplicate of PR 28868
a.c
=
typedef struct a1 {
int x;
} a1_t __attribute__((may_alias));
=
a.c:3: internal compiler error: in splice_child_die, at dwarf2out.c:5503
Please submit a full bug report,
with preprocessed source if appropriate.
See
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-13 19:27 ---
It does not occur targeting
I doubt those use dwarf2/3 :).
*** This bug has been marked as a duplicate of 29436 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-06-13 19:27
---
*** Bug 32326 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from patchapp at dberlin dot org 2007-06-13 19:30 ---
Subject: Bug number PR32323
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/2007-06/msg00910.html
--
--- Comment #5 from daney at gcc dot gnu dot org 2007-06-13 19:44 ---
Unfortunatly the patch causes an ICE compiling crtstuff.c. I will have to
adjust it a bit...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32313
Given the following code:
--
typedef unsigned int size_t;
typedef unsigned long long uint64;
extern C {
extern void *memcpy (void *__restrict __dest,
__const void *__restrict __src, size_t __n) /*throw ()*/;
}
--- Comment #6 from dje at gcc dot gnu dot org 2007-06-13 20:00 ---
From IRC:
see.c:2732 makes a copy of an insn and then hacks on it with validate_change
(and it's close relatives). This copy has a basic_block, even though it is not
in the insn stream, as well as the same insn_uid as
--- Comment #3 from burnus at gcc dot gnu dot org 2007-06-13 20:12 ---
Subject: Bug 32323
Author: burnus
Date: Wed Jun 13 20:12:40 2007
New Revision: 125684
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125684
Log:
2007-06-13 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #4 from burnus at gcc dot gnu dot org 2007-06-13 20:14 ---
Fixed in 4.3.
As it is neither a regression nor a wrong-code bug, it will not be fixed for
4.2.1 or 4.1.3.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from ubizjak at gmail dot com 2007-06-13 20:20 ---
RFC patch at http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00916.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31723
--- Comment #6 from daney at gcc dot gnu dot org 2007-06-13 20:39 ---
Created an attachment (id=13700)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13700action=view)
Revised patch.
I don't know what I was thinking with the first version of the patch :-( The
new version I think
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-06-13 20:45
---
Hard to tell what is going wrong. I've been building and using compilers on
i386-darwin with no problem. Please contact the people behind HPC MacOS X to
see if they can help you using this compiler, or download
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-06-13 20:49
---
(In reply to comment #9)
I don't see the point of these questions though. After all, I confirmed your
bug with gcc 4.1, and also that it's fixed in 4.2 and 4.3. So the remaining
question is whether this
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||27766
nThis||
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||27766
nThis||
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
1 - 100 of 139 matches
Mail list logo
